A year of AI-driven transformation has redrawn the engineering manager's role. The pressures are new. The tools are not. This briefing maps the five tensions defining EM work today, and the operating gap that no existing template addresses.
Engineering management in 2026 is a fundamentally different job than it was eighteen months ago. The mainstream arrival of AI coding tools — Claude Code, Cursor, Windsurf, Copilot — has introduced an entire layer of responsibility that no manager training program prepared anyone for. Managers are now expected to select tools, measure their ROI, prevent quality regression, justify the spend to executives, and coach engineers through workflow changes that have no precedent.
At the same time, the old problems haven't gone anywhere. One-on-ones are still mostly wasted. Performance reviews still surprise people. The transition from senior engineer to engineering manager still fails at uncomfortably high rates. The cognitive load of context-switching has, if anything, increased — because the new work has been bolted onto the old, not substituted for it.
This briefing synthesizes industry data and field observations into five tensions defining the engineering manager's work in 2026. It then examines the gap in the tooling that has emerged to support the role — and what an integrated operating system designed for the work as it actually exists would look like.
The shift is real and recent. A year ago, GitHub Copilot was the dominant AI coding tool, used by 42% of teams. Today it has dropped to third. The current leader — Claude Code — did not exist as an option on last year's industry survey. Three tools now cluster within nine points at the top, with twelve more behind them. No tool has the monopoly Copilot once had, which means every engineering organization is now making active tooling decisions that didn't exist as decisions in 2024.
The manager's new responsibilities, all simultaneous: standardize tool selection across the team, justify the budget to finance, quantify ROI to executives demanding evidence, establish an audit trail of AI usage for compliance and code-quality review, and coach individual engineers who are at wildly different stages of adoption.
The uncomfortable position: managers are simultaneously told to push AI adoption harder and watch for AI-induced quality issues. The infrastructure to do either well — a tracking layer that captures which engineers are using which tools, on what code, with what outcomes — does not exist in any standard management toolkit. Managers are improvising it themselves, in spreadsheets, in Slack threads, in fragmented memory.
The remaining four tensions, the tooling gap analysis, and the shape of an integrated EM operating system. Delivered to your inbox, plus early access when our first product launches.
Engineering productivity has always been hard to measure. AI-augmented workflows have made the legacy metrics actively misleading. An engineer using Claude Code aggressively can ship three or four times as many pull requests in a week as the same engineer would have shipped in 2024. Lines of code, sprint velocity, PR throughput — all warped beyond usefulness.
This wouldn't be a crisis if executives understood the warping. They mostly don't. The pressure from above is for clean, defensible numbers showing "AI ROI," and the engineering manager is the person on the hook to produce them. Most are not equipped with the framework, the tooling, or the data to do so credibly.
The result is a measurement trap with three sides:
None of these are good answers. The honest answer — that productivity in an AI-augmented workflow requires a different framework, and that the framework is still being figured out — does not satisfy the question being asked.
The one-on-one meeting is the most important tool in an engineering manager's arsenal. It is also the most consistently misused. The patterns are well-documented and persistent:
The cost of a wasted one-on-one isn't just an hour. It's the engineer who quietly disengages. The brewing performance issue that goes uncaught until calibration. The career conversation that doesn't happen until the exit interview. A year of wasted one-on-ones with one direct report can be the difference between retention and resignation.
What the research suggests works: capturing the rules of the road in writing, treating commitments and follow-ups as durable records rather than ephemeral notes, and approaching each session with a structured prep step — even ten minutes of it — rather than walking in cold.
The infrastructure to do this exists in fragments — meeting note templates, prep checklists, follow-up reminders. None of it is integrated. Engineering managers running well-structured one-on-ones are doing so by force of personal discipline, not because their tools support them.
The most common complaint engineers raise about performance reviews is not that the feedback is hard. It is that the written narrative and the assigned rating don't match — that the words say one thing and the rating says another, or that the rating doesn't match the evidence. Engineers respect honest reviews. They lose trust in the process when they're surprised.
The root cause is structural. Most managers gather review evidence at review time, not continuously. They reconstruct a year of performance from memory, a handful of saved Slack messages, and whatever the engineer wrote in their self-review. The result is the kind of vague assessment that satisfies the bureaucratic requirement but does no actual work:
The alternative — capturing specific, dated evidence continuously throughout the cycle, then writing the review from accumulated material rather than memory — changes the entire calculus. Reviews become specific. Ratings track narrative. Hard feedback lands without surprise because it's been preceded by months of consistent signals. But this requires infrastructure that most managers don't have and won't build themselves.
Of all engineering management transitions, the first-time-manager transition fails at the highest rate. The pattern is consistent across organizations and well-documented across the management research literature. New managers take the role expecting it to be their previous job plus meetings. They discover instead that their previous technical excellence is now secondary to a set of skills they likely have never developed.
The failure modes recur with remarkable consistency:
Organizational support for the transition is minimal in most companies. New managers are typically given a job title, a team, and not much else. Existing manager templates and toolkits assume the manager already knows what they're doing — they provide structures for execution but not for navigation. The new manager is left to construct the operating system of the role from scratch, while simultaneously failing at the role.
The tools that have emerged to support engineering managers fall into three categories. Each addresses a fragment of the role. None addresses the whole.
Jellyfish, LinearB, Swarmia. Powerful and increasingly sophisticated, but priced for enterprise budgets ($30,000 to over $100,000 annually). They require executive buy-in, focus on team-level metrics rather than individual workflow, and live separately from the day-to-day operational work of running a team. The IC manager rarely buys these. They get installed above the manager's head, and the manager is asked to interpret their output.
The mid-market response: collections of Notion templates targeting engineering managers. The largest current offering — 50 EM Notion templates sold as a single bundle — exemplifies the architectural problem. Fifty individual templates, each solving a fragment, none structurally connected to the others. The manager who buys this collection now has fifty separate places to look. The 1:1 template doesn't know about the person template. The performance review doesn't know about the 1:1 history. Evidence captured in one workflow is invisible to another.
Second Brain, PARA, Building a Second Brain, and the broader category of generic productivity frameworks repurposed for managers. These are intellectually sound but role-blind. They were designed for knowledge workers in general, not engineering managers specifically. The databases reflect "projects" and "areas" rather than directs, 1:1s, on-call rotations, hiring loops, and the actual primitives of the EM role.
What does not exist, at any price point, is an integrated workspace where the one-on-one connects to the person, who connects to their projects, which feed into performance review evidence — where AI prompts live inside the actual workflow rather than in a separate library — and where the 2026-specific tensions (AI adoption, productivity measurement, evidence capture) are addressed as first-class problems rather than ignored.
This is the gap.
The architecture of a tool that addresses these tensions — rather than fragmenting them across fifty disconnected templates — has a recognizable shape:
This is the shape of the product Pagery is building. The briefing you have just read is the first piece of public work from the same body of research that informed the design.
Pagery builds operating systems for engineering managers. Our first product is the Engineering Manager Workspace — an integrated Notion system designed for engineering managers working in the AI-augmented era, with five to fifty direct reports, one to five years into the role.
This briefing is not a sales document. It is research we would write whether or not we sold a product. The product exists because the research surfaced a gap; the research did not exist to justify the product.
An integrated Notion workspace built for engineering managers working in the AI-augmented era. People, one-on-ones, projects, performance reviews, and AI-tooling tracking — connected in one workspace, designed for working managers with five to fifty reports.
Subscribers get notified the day the first workspace ships, with a launch-week discount before public pricing kicks in.