The Engineering Manager Job Just Split in Two
The Engineering Manager role used to be one job. It is now two, and most orgs have not noticed. Here's the split, the second role, and how to staff it.
The engineering manager role used to be one job. It is now two, and most orgs have not noticed.
The technical half of what an EM does, owning the context layer, the agent stack, the verification infrastructure, the hands-on technical bar of the team, has grown into a role of its own. The people half, hiring, coaching, performance, stakeholders, delivery accountability, has not shrunk. One person doing both is doing both badly, because both done well is more than one person should be expected to carry.
I argued earlier this year that the EM role needed to evolve to absorb context stewardship, quality judgment, and agent coordination as core responsibilities. That argument was directionally right and I still hold it. What I had wrong was the scale. I framed it as evolution of the existing role. In practice, at most team sizes, asking one EM to do those three new things alongside the people work, the operating cadence, and the delivery accountability is asking more than the role can carry. The evolution I described is happening. It is just not fitting inside one job anymore.
Many teams already have a name for the technical half. Engineering Lead. Tech Lead. Staff engineer with a leadership remit. The name is less important than the recognition that the scope no longer fits inside a single EM job. This post is about why the split happened, what each half owns, and how to staff the technical role without breaking the people one.
The Engineering Manager Job Now Contains Two Different Jobs
The EM role used to cluster cleanly. Sprint planning, 1:1s, stakeholder communication, performance reviews, hiring, the occasional architecture call. People work and technical work fed each other. The same conversations covered both. A good EM was someone who could do both with their left and right hand.
AI changed what the technical side of the job actually requires. Maintaining the context layer that AI tools work from. Owning the agent stack: which agents run, on what scope, with what guardrails. Setting the standard for what an agent-ready ticket looks like. Calibrating which categories of PR need deep review and which can ship on automated signal. Owning the verification infrastructure that makes agentic workflows safe to trust. Adapting CI to produce output an agent can interpret. Investing in the four layers an agent-ready repo needs, and keeping them in good shape as the codebase evolves.
This is not a list of things that can be picked up on Friday afternoons between 1:1s. It is a full role. It needs daily attention, hands-on work in the codebase, and judgment about technical decisions that compound across the team's output.
Meanwhile the people work has not shrunk. Engineers in AI-native teams need more coaching, not less, because the job they are doing is harder than the job they were doing before. They are not writing code from scratch as often. They are evaluating code an agent produced, in a system that demands architectural judgment they may not yet have. They are working in a discipline that is being redefined in real time. The EM who reduces 1:1s because they are busy with the context layer is removing support precisely when their team needs it most.
The result is a role that has two full jobs in it. Most EMs are doing both badly because both done well is more than one person should be expected to carry.
What the Technical Half of the Split Owns
Call the technical role what your org already calls it: Engineering Lead, Tech Lead, principal engineer with a leadership remit. I'll use Engineering Lead in the rest of this post for shorthand. The label is yours. The scope is what matters, and it should be explicit enough that the person doing the work, the EM they partner with, and the engineers they serve all know where the line sits.
The Engineering Lead owns four things.
The context layer. The CLAUDE.md, the architecture decision records, the module-level context files, the domain glossary. Not just owns it nominally. Maintains it. Reviews it when architecture changes. Flags when it drifts from what the code actually does. This is the infrastructure that makes AI tools reliable in the codebase. Most teams have a context file. Few have someone whose job is to keep it useful.
The agent stack. What agents are running, what scope they have, what guardrails they operate inside, what escalation paths exist when something goes wrong. This includes the obvious tools but also the unsexy plumbing: prompt templates, retrieval setups, eval harnesses, ops dashboards for agent activity. Decisions about which agents to ship, which to retire, which to extend are technical decisions with downstream consequences. The Engineering Lead makes them.
The verification infrastructure. Test suite agent-readiness. CI output structure. Risk-tiered review process. The systems that turn agent output into something the team can trust enough to ship. The current state of most teams: tests not written for agent feedback loops, CI output illegible to anything that isn't a human, reviews done at the same depth regardless of risk. Fixing this is technical work that an EM doing 1:1s and stakeholder syncs cannot do alongside everything else.
The hands-on technical bar. This is the controversial one. The Engineering Lead is in the code every week. They ship things. Not by doing the team's tickets, but by working in the systems the team uses: the agent harness, the eval framework, the context tooling, the more architectural changes nobody else has time for. Their week looks more like a staff engineer's week than an EM's week, with the difference being that they hold the org-level accountability for the technical bar of the team. They are not coding for output. They are coding because the technical bar of a team is held by what its technical leader is willing to ship.
The role is technical leadership in the literal sense: leading the technical work by being in it. That is not what most senior engineering leaders have done for years. It is what AI-native teams now require.
What the EM Still Owns
The split is real on both sides. Drawing the EM scope cleanly is as important as drawing the technical scope.
The EM owns the people. Hiring. Career growth. Performance review. 1:1s. Coaching engineers through the harder evaluation work they now do. Helping them develop judgment in a discipline that is changing under their feet. Spotting burnout. Building team culture. None of this is reduced by AI. Most of it intensifies, and the EM who is paying attention will tell you that the people work has become the harder half, not the easier half, of what engineering management is now.
The EM owns the operating cadence. Sprint planning if the team still has sprints, the new cadence if it does not. Stakeholder communication. Cross-team coordination. Outcome reviews. The visibility of the team's work upward and outward. The work that turns engineering output into something other functions can plan against.
The EM owns delivery accountability. Whether the team is shipping what it committed to. Whether the team's commitments are calibrated. Whether priorities are aligned across the work in flight. The EM is the answer to "is this team delivering."
The EM and Engineering Lead split delivery and technical accountability the way a CEO and CTO split business and technical accountability in a healthy startup. They work in close partnership. Neither is the other's boss. Both report to the head of engineering or equivalent. When they disagree, the disagreement resolves at the level above them, not by one of them overruling the other.
Why The Existing "Engineering Lead" Title Often Doesn't Carry the Split
Many orgs already have someone called Engineering Lead. The title exists. The job description, in most places, is some blend of "team lead with both technical and people responsibility" or "senior IC who manages a small team part-time." That is not the role described above.
The role above is technical-first, hands-on, peer to the EM, with no direct reports. The "Engineering Lead" most orgs have is closer to a junior EM, a hybrid carrying both people and technical work but at a smaller scope. That hybrid worked fine when both halves of the job were smaller. It does not carry the load when the technical half has grown into a full role.
If you already have Engineering Leads in your org, the question is whether their scope reflects the split this post describes, or whether they are doing the old hybrid version of the job at a junior level. If the latter, the work is to redefine the role at your scale, give it the technical-first scope, and clarify the peer relationship with EMs rather than the reporting line under them. If you call the role something else (Tech Lead, Principal Engineer, Staff Engineer with a leadership scope), the renaming is optional. The scope clarification is not.
How to Staff the Technical Role
The biggest mistake teams make when they create or redefine this role is treating it as a promotion track for senior engineers who want a path to management. The Engineering Lead is not a step up from staff engineer toward EM. It is a different role. The traits that matter for it are not the same traits that get someone promoted to staff, and confusing the two will produce someone who is unhappy in the role inside a year.
Three things tend to matter most.
Hands-on technical depth in the team's domain. The Engineering Lead has to be credible in the code. Not credible in a "they wrote a great design doc last quarter" sense. Credible in a "they shipped the agent harness rewrite last month" sense. A leader who has not been in the code recently cannot make the agent stack decisions, because the decisions require understanding what is actually hard in your specific system.
Comfortable working without a team to manage. Some senior engineers crave management responsibility. They will not be happy in this role. The Engineering Lead has no direct reports. They have peer relationships with engineers, they pair with them, they mentor by working alongside them. But they do not run 1:1s or own anyone's career growth. The role rewards people who would rather be in the code than in the spreadsheet.
Willingness to hold a public technical bar. The Engineering Lead's work is visible in the codebase. Every commit, every PR, every agent harness change. Senior engineers used to operating behind the curtain, advising others on technical decisions while not personally shipping, will struggle here. The role asks for someone who is comfortable being publicly accountable for technical taste.
These traits are real and they are not just senior engineer traits. The closest analog is a hands-on staff engineer who is more interested in the system than in the org chart. Promote those people in. If you do not have them, hire for them.
The compensation range sits at staff engineer level or slightly above. The reporting line goes to the same person the EM reports to. The performance review is run by that person, with the EM as a peer reviewer the same way the Engineering Lead is a peer reviewer for the EM.
What Goes Wrong When You Don't Make the Split
I have watched a few patterns play out in teams that kept the EM role doing both jobs.
The first pattern is technical drift. The team's context layer goes stale. Acceptance criteria stay vague. The agent stack works on a Monday and somebody decides on Tuesday that it is fragile and goes back to manual review for a class of work that should be agent-handled. Six months later the team has not made meaningful progress on the technical maturity of how AI is embedded in their work, even though the EM has been "working on it" the whole time. The work needed dedicated owner attention. It got part-time effort.
The second pattern is people degradation. The EM, sensing the technical work is more visible and more rewarded, shifts time toward it. 1:1s get cancelled. Engineers feel unsupported during the hardest skill transition of their careers. The team's morale drops, then the team's retention drops, then the team's output drops, and the leadership starts wondering why the AI adoption did not deliver what was promised. The cause was not the AI. The cause was that the manager who was supposed to coach the team through the transition stopped having time for it.
The third pattern is the slow split that happens anyway, but without acknowledgement. A senior engineer on the team starts doing the technical leadership work because the EM cannot. They do not have the title. They do not have the time formally protected. They do not have the public mandate to make calls in their area. They do the work anyway, and they burn out, or they leave, or they get promoted to staff engineer somewhere else and the team loses the de facto Engineering Lead. The split was happening. The org just refused to formalise it.
Formalising the role costs almost nothing. It is not necessarily another headcount, if you have the senior engineer who is already doing the work. It is a job description, a reporting line, a recognised seat at the table. Most of the orgs that benefit most from the split could make it tomorrow without a hiring requisition.
The Org Chart Conversation Most Leaders Have Not Had
Engineering leaders have spent the last year or two adopting AI tools and watching velocity metrics. The conversation that has not happened yet, in most orgs, is the structural one: who owns what now.
The split described above is the answer to a question most leaders have not yet asked clearly. Who owns the technical bar of the team when the technical bar requires hands-on work in systems the EM does not have time to be in? The answer is not "the staff engineer in their spare time," or "the EM when they get a chance," or "the head of engineering across all teams." The answer is a role with that responsibility as its job description.
The team shape that AI-native engineering needs is described elsewhere on this blog: smaller, senior-weighted, ownership-based, fewer handoffs. The leadership shape that goes with it is two roles, not one. EM for people and delivery. Engineering Lead, or whatever you call the technical equivalent, for technical depth and the agent stack. Equal status. Joint ownership of outcomes. Different days.
The orgs that make this split early get a year of compounding return on the technical work that gets done because someone is actually doing it. The orgs that do not make it spend a year wondering why their AI adoption produced velocity gains that did not show up in any meaningful business metric, while their best senior engineers slowly accept offers from companies that did make the split.
Team Topologies by Skelton and Pais made the case years ago that team structure is a first-class engineering decision. The split described here is what that argument looks like at the leadership layer in an AI-native team. The conversation costs nothing. The structure costs nothing. The role costs at most one promotion or one hire. The work it unlocks is the work that determines whether your team's AI adoption is an investment or an expense.
I help engineering teams close the gap between "we use AI tools" and "AI actually changed how we deliver." Book a 20-minute call and I'll tell you where the leverage is.
Working on something similar?
I work with founders and engineering leaders who want to close the gap between what their technology can do and what it's actually delivering.