I had an answer ready, and I knew it was wrong before I finished saying it.

That was maybe eight years ago. I've watched the question become an industry-level problem since then, and I've watched most organizations answer it the same way I did: by buying their way out of it until they can't.

The current push toward what some are calling "precision hiring" is rational on its face. Smaller teams, higher expectations, every role justified at the point of hire. Entry-level developer hiring dropped roughly 25% in 2024 and the trend continued through 2025, with some organizations rebranding junior roles as "AI Reliability Engineers" or eliminating them outright. A senior engineer with solid AI tooling can absorb what a small team used to do. The numbers make a clean case.

They make an incomplete one.

The team that cuts junior roles first notices the gain. Headcount is down, output holds, velocity metrics look great for two or three quarters. What doesn't show up on any dashboard is what those junior roles were actually doing that had nothing to do with their tickets.

Junior engineers ask questions that senior engineers stopped asking years ago because the answers became invisible to them. They notice things in a codebase that its authors can no longer see. And they absorb the operational tasks, the support escalations, the documentation passes, the kinds of work that a senior can do in thirty minutes but resents spending three hours a week on. When those roles disappear, the work itself stays, settling onto the seniors quietly. They start burning out quietly, and then you have a turnover problem that nobody connects back to the staffing decision from eighteen months ago.

Four or five seniors who've each owned a system for two or three years looks like resilience on an org chart. The specific kind of fragility it carries lives where you can't see it: the knowledge that ties everything together sits in four people's heads instead of being distributed through the process of explanation, teaching, and gradual handoff. When one of them leaves, and eventually they all do, what walks out the door cannot be replaced by hiring their equivalent at the same level.

Osmani documented this arc last year, citing a Harvard study that found junior employment dropping nine to ten percent within six quarters of companies adopting generative AI tools, with big tech hiring roughly half as many fresh graduates over a three-year stretch. The data doesn't capture what happens in year four, when the organizations that made those cuts need to grow a senior team and discover they've been drawing down a resource they weren't tracking.

Every senior engineer on your team was once someone's junior. Somebody spent time reviewing their code, answering their questions, letting them own something small and fail at it and learn from that. The pipeline that produces seniors requires deliberate investment, spread across hundreds of organizations making hiring decisions every quarter. When enough of those organizations opt out simultaneously, the pipeline stops, with no gradual slowdown to warn anyone first.

I understand the individual case for this. I've made versions of the same decision myself. When budget tightened and I needed to hold a senior who could own a critical system, cutting a junior role that hadn't fully ramped up yet felt like the defensible choice. At the time, it was. What I was doing, and what most organizations are doing right now, is borrowing against a collective resource without acknowledging the debt.

The industry runs on a shared assumption that someone else is doing the training. Startups assume big tech does it. Big tech assumes universities do it. Universities assume employers will teach what they can't. Right now, the number of organizations willing to absorb that cost has shrunk faster than the assumption has updated.

The optimistic counter-case, that AI could spread software development to industries that barely had it and bring in a wave of new practitioners who never came through a traditional path, is worth tracking. It doesn't solve the institutional knowledge problem and it doesn't rebuild the mentorship infrastructure that turned junior engineers into senior ones. These aren't the same gap.

Precision hiring solves the immediate problem. Treating it as the only problem worth solving is where companies get hurt.

For organizations that still run junior programs, the economics are quietly improving. There is less competition for good entry-level candidates than there has been in a decade. The ones who want the role because they want to learn the work, not just the credential, are findable if you look. In three to five years, the supply of people with genuine mid-level experience is going to thin out in ways the current hiring dashboard doesn't show yet.

Some organizations will figure this out and act early. Most will figure it out when a senior leaves and nobody knows how the system actually works.

The question my colleague asked me eight years ago had a real answer. Seniors come from somewhere specific: they come from having been given the chance to be something less than senior first, inside an organization willing to invest in the outcome. Most people who've made the argument for hiring juniors frame it as social responsibility. I'd rather make the engineering case.

We are currently choosing not to do that, at scale, and calling it efficiency.

A few years back, I was trying to hire someone into a function with no real precedent. I could describe the outcome clearly: someone who could sit between a technical team and a set of business workflows evolving faster than the documentation. I interviewed qualified people. None of them fit. Every candidate had either half the skills or the wrong mental model, and when I described the role to them, I'd watch something go slightly wrong in their eyes, as if I were explaining a color they hadn't seen before. Eventually I realized the problem wasn't the candidates. The job required someone to think in a way their previous experience hadn't asked for, and I was looking for that quality in the wrong places.

Building a new role is a different problem from filling one. And we're about to run that problem at scale.

A few weeks ago, I wrote about what I called the Foreman Problem: AI is creating a new management role in technology organizations, the same way factories created the foreman and digital products created the product manager. I described the gap. This piece is about what goes in it.

The organizations I find most useful to study are the ones that didn't just drop AI into their existing workflows. A pharmaceutical company with about 5,800 employees built over 3,000 custom AI tools, then gave managers a framework for assessing every task: automate, augment, or keep with a person. That sounds like a process question, but it's a skill. Someone makes those calls constantly, and the calls change as the work changes and as AI capabilities change with it.

One manufacturing company uses agents to resolve supply chain delays before the morning shift arrives. That means someone set the boundaries for when the agent acts and when it escalates, then kept watching those boundaries as the agent's reliability built up. An enterprise technology company redesigned its performance review process around four specialized AI sub-agents, and their leadership was explicit: the win came from redesigning the process, not from adding AI to the existing one.

In each case, there's a person in the middle whose primary job is managing the boundary between what agents do and what humans do. And that job requires something a traditional engineering manager doesn't get much practice at.

Traditional management assumes that skilled people signal uncertainty. A senior engineer who's unsure about an edge case asks a question, adds a code comment, or flags the risk in a planning conversation. The skill lives in the person, and so does the acknowledgment of its limits. AI agents produce confident output whether they're confident or not. The difference between a correct answer and a plausible wrong one can be invisible to anyone who isn't specifically looking for it.

The skill I'd point to first is trust calibration: knowing when to let an agent run without review and when to require a human gate, and knowing how to move that boundary as experience accumulates. It's closer to the judgment a good test engineer develops about which automated tests can be fully relied on versus which ones need a manual pass before a production push. A judgment that sharpens over time, but only if you're paying attention to the right signals.

Something I found hard to admit earlier in my career: accountability doesn't shrink because visibility does. A manager who lets an AI agent run on consequential work owns the output even if they never read it. A legal ruling last year held an airline responsible for its chatbot giving incorrect bereavement fare information to a customer, rejecting the argument that the chatbot was somehow separate from the company. That ruling will not be the last. The person building this role needs to be clear-eyed about the gap between what they can physically review and what they're responsible for, because that gap is large and it grows as agent autonomy expands.

On any given day, the first question is which agent outputs need a human to confirm before they go anywhere, and which processes have accumulated enough reliable runs that the gate can loosen. Somewhere in between are the edge cases the agent still handles badly in ways that are easy to miss. In the pharmaceutical company's deployment, managers started by doing this manually, task by task. Over time they built patterns. But the judgment about when a pattern was stable enough to trust never became fully automatic.

The managers getting this right don't inherit workflows and drop AI into them. They redesign the work first: what happens when the agent is wrong, not just when it's right, and what the fallback looks like before anyone needs it. The verification layer is a permanent feature of the job.

And some of it is invisible. A good foreman produces a week where nothing goes visibly wrong. Confident wrong output stays out of customer hands. Fabricated records don't reach the database. The data a process runs on doesn't drift for three cycles before anyone checks. That absence is the work, and it's almost impossible to evaluate from the outside, which is part of why organizations are slow to create the role deliberately.

When a review process finds problems and they're all surface errors, that's table stakes. The harder signal is whether the process is finding the deeper failures: cases where an agent produced something that looked correct but was wrong in a way that mattered. A manager catching only obvious mistakes is probably missing the subtle ones. Not because they're careless, but because the review process wasn't designed to find them.

The trust boundaries should also be moving. A manager who locks down agent autonomy and never expands it isn't calibrating. A manager who expands autonomy without a principled reason is taking risk they probably don't see. The healthy pattern is steady accumulation of justified confidence, with visible reasoning for each expansion and a willingness to contract when something goes wrong.

I've watched organizations flatten their management layers on the assumption that AI handles coordination now. About 40% of employees at companies that have done this report feeling directionless. The continuous judgment work went quietly with the middle managers, constant small calibrations about what to trust, what to verify, what to catch before it became visible.

The role I'm describing sits outside what most engineering management training covers. Trust calibration, process design under uncertainty, outcome ownership with partial information: none of those are in the standard curriculum. They can be developed. But you have to know to look for them, and most organizations are currently searching in the wrong places.

If you're leading a team that includes AI agents, start with a single audit: what ran autonomously this week, and what's your actual evidence that it ran well. If the audit is "I didn't hear about any problems," that's not evidence.

A circular dependency formed in their voice infrastructure. Service A depended on B. B depended, quietly, on A. Under normal conditions this didn't matter much. Under specific failure conditions, neither could recover. Individual components had redundancy and failover protections, but those safeguards assumed independent failures. The circularity meant degradation in one service immediately impaired the recovery mechanism in the other, and the self-healing protocols had nothing solid to stand on.

The dependency survived testing, code review, and deployment gates, plus a year or more of production traffic. It took a specific combination of conditions, a configuration change that stressed the system in a new way, to make the loop visible.

I've seen this pattern across enough organizations that I stopped treating it as a surprise. Teams make decisions within their own service boundaries, and those decisions usually make sense in context. The team running service A designs a call to B that fits their needs. The team running B does the same from their side. Nobody owns the cross-service dependency graph, so nobody is watching the graph accumulate risk. The architecture diagram on the wiki is from eighteen months ago, and the person who drew it left last spring.

Calling it a competence failure misses the structural condition behind it. Risk concentrates between services, where individual teams make sensible local choices and the aggregate effect drifts outside anyone's view. The things that take systems down tend to live in the space between owners.

When I was working in aviation systems, unmapped dependencies weren't a postmortem detail. They were an audit finding. Traceability documentation was a compliance requirement, and before shipping anything that touched flight-critical software, you had to demonstrate that you understood every component dependency and every failure mode. The engineers did the work because the consequences of getting it wrong were documented and stayed attached to the people involved.

I thought about that a lot when I moved into software organizations without that kind of external pressure. The cost of unmapped dependencies in commercial software lands later and lands diffusely. It shows up as an outage absorbed across teams, postmortems, and shifting priorities. There's no audit committee waiting on the other side, and no single owner left holding the original decision, which makes the structural condition easier to absorb and move on from without fixing it.

One assumption I had to correct in myself over the years: if a system ran in production for a year without a dependency-driven incident, the dependency surface was reasonably understood. That's false comfort. The specific failure sequences that expose circular dependencies are often rare enough that they never appear in staging. They appear when two components degrade simultaneously, in production, under conditions the test suite didn't model. A system can carry that fragility for years before the right conditions exist to prove it.

What Discord did after the incident is as interesting as the outage itself. They broke the dependency loop, improved isolation between components, added stricter validation to prevent similar patterns from forming, and extended their observability tooling to detect hidden coupling before it becomes an incident. That's a mature response. They went after the structural condition that let the dependency form and persist undetected, rather than the engineer who pushed the configuration change.

The observability piece is worth sitting with. You can't monitor what you don't know exists. Adding tooling to detect hidden coupling means someone made an explicit decision to treat the dependency graph as something the organization actively watches on an ongoing basis, instead of waiting for a postmortem to surface it.

That decision is the practical version of dependency mapping as a first-class engineering practice. Someone owns the cross-service graph, and that ownership has weight: the ability to flag changes that create cycles or ambiguous coupling. Dependency documentation gets reviewed on a regular cadence well after the service is first launched. The architecture diagram gets updated when services change, well before an outage forces someone to draw a new one.

This is uncomfortable because it requires some teams to give up what would otherwise be the clean local solution. A team will occasionally be told that the approach they've designed introduces a dependency that fails the graph review. That conversation is difficult. It's also cheaper than the conversation you have in an incident bridge at two in the morning.

The AI context is worth naming. As more organizations ship AI-generated code at speed, the dependency surface grows faster than any single team's awareness of it. AI tools are good at generating code that works within the local context. They're not tracking the cross-service graph. The organizational conditions that let Discord's circular dependency form (teams making local decisions, nobody owning the integration surface) are the same conditions that AI-accelerated development is about to intensify.

Discord's monitoring dashboard and test suite worked as designed during the outage. The gap was in what the organization chose to treat as owned infrastructure, leaving everything else to surface on its own.

Unmapped dependencies sit quietly until the right conditions arrive, and then they stop being unmapped.

Last week I read the TanStack postmortem.

On May 11, 2026, attackers compromised 84 package versions across the TanStack npm namespace, including libraries that handle routing and querying for millions of React applications. The @tanstack/react-router package alone had over 12 million weekly downloads. The attack was part of a broader campaign that eventually touched 160-plus npm package versions, including Mistral AI tooling and the Bitwarden CLI. All of it was part of something researchers named Shai-Hulud, the fifth wave in eight months.

What made this one different was what the malicious packages carried: valid SLSA Build Level 3 provenance attestations, signed by Sigstore infrastructure. The first documented instance of this on npm.

The attestations were real, and they proved a narrower fact than the verification chain required.

SLSA provenance attests that a package was built by a specific repository's GitHub Actions run. What it doesn't attest is whether that workflow was authorized to run, whether it executed from a protected branch, or whether the commit that triggered it was legitimate. The attackers understood this boundary precisely. They pushed an orphaned commit (no parent history, no branch) to a forked repository. Orphaned commits don't exist on any branch, so they bypass branch protection entirely. That orphaned commit triggered a legitimate GitHub Actions workflow, which issued a valid OIDC token because the trusted publisher configuration granted trust at the repository level rather than scoping it to specific workflow files or protected branches. Packages went to npm. Sigstore signed the provenance. TanStack had 2FA enabled and lockfiles in place. Every control was present and operating correctly. The scope of each one was simply too broad for this attack class.

I've spent most of my career in fintech, health, and payments, industries where "we have an audit trail" is supposed to close the conversation. The thing I learned slowly, across several organizations, is that an audit trail proves only that an action occurred through a pathway the system already recognized as legitimate, which is a narrower fact than authorization. An audit log showing a record was accessed by a user with the right role still leaves open whether the role was configured correctly. A provenance attestation showing a package was built by a legitimate workflow still leaves open whether the workflow was allowed to run on that commit. Both systems are doing exactly what they were built to do, which is a narrower job than answering the question you actually need answered.

What engineering leaders need to update is the mental model behind the tooling list. Most teams with mature practices already have the controls the postmortem would recommend. The gap is in how they reason about what those controls prove. The framing that holds up under attacks like this one asks, for every trust signal in the chain, what each signal actually attests and what gap it leaves for someone who knows where that proof ends.

What I didn't ask in that compliance review, and what the auditor didn't ask either, was whether any of our controls would fire if a legitimate workflow ran on a commit that was never supposed to trigger it. We reviewed the presence of controls and stopped there. The question of whether the OIDC configuration backing provenance was scoped tightly enough to block an orphaned commit from an uncontrolled fork never came up. Nobody modeled the failure mode where the trust mechanism itself becomes the attack surface.

The practical fixes from this incident are tractable. Pin OIDC trust to specific workflow files and specific protected branches, not just repositories. Run `npm ci --ignore-scripts` in CI pipelines, which blocks lifecycle script execution and eliminates the primary delivery mechanism for most of the Shai-Hulud variants. Treat any commit with no parent history as suspicious before your CI processes it. None of these changes are difficult to make. They require someone to revisit configurations set up when the threat model was simpler and tighten the scope.

The harder change is in how you frame dependency security to your leadership and your team. "We have provenance, we have 2FA, we have lockfiles" describes a set of controls without describing the threats those controls were chosen to address. A more honest frame: for every trust signal in your supply chain, what exactly does it attest, and what does it leave open to someone who knows where that attestation ends?

That question gets uncomfortable quickly. Most teams don't fully control the GitHub Actions environment they run in, the infrastructure that signs their provenance, or the OIDC token policies of the registries they publish to. They trust those systems because those systems have been trustworthy. That trust is earned. The problem is treating the output of those systems as sufficient proof of authorization without also controlling what those systems are allowed to attest.

I don't have a clean answer for every dependency in my own stack. After reading the TanStack postmortem, the absence of that answer carries different weight. It's become unfinished work I owe my own team.

I had pushed for that split a year earlier.

That was the night I started taking team boundaries more seriously than service boundaries.

The conventional wisdom of microservices says you decompose the system by function. Bounded contexts. Domain-driven design. Each service should do one thing well. All true, in a vacuum. The trouble is that "one thing well" assumes someone is around to do that one thing. In an org chart that shifts every eighteen months, the diagram outlives the people who drew it. The service stays. The team that understood it disperses.

Across several organizations, I have watched the same pattern play out. A senior engineer or architect maps the domain. The map looks clean. They cut the system along the joints. Then they hand a service to whichever team has the spare capacity that quarter. The team accepts it because they have to, builds shallow familiarity, and ten months later that team is reorganized into something else. The service still runs. Nobody really owns it. When something breaks, the on-call rotation rotates strangers through unfamiliar code, and the recovery time gets measured in hours instead of minutes.

The thing the architecture diagram cannot show is who answers the page.

There is a position I have been more willing to defend over the years. Ownership matters more than output. The team that decides what changes and carries the consequences when it breaks is more valuable than the team that produced the original artifact. A service is an artifact. A team's understanding of that service is the actual asset. The moment those two diverge, the service drifts toward the place where every legacy system goes. The place where everyone agrees something needs to be done about it and nobody does it.

So when the next architecture review comes around, I no longer ask "what is the natural seam in the domain?" first. I ask "who is going to live with this in three years?" first. And then I draw seams that match the answer.

The split I mentioned earlier had been clean on paper. We had a payments orchestrator that had grown to about forty thousand lines, and the senior engineers wanted to break out the merchant-side contract handling from the consumer-side payment flow. The bounded contexts were obvious. Two services, two clearer codebases, two faster build times. I signed off, and we shipped the split over a quarter.

What I had not stress-tested was the ownership question. The merchant-side service ended up with a team whose actual roadmap was checkout. Checkout was their performance metric, the thing they were judged on. The merchant contract code was a tax on their roadmap. So they did the rational thing. They kept it running, fixed bugs as they came in, and did not invest. Over twelve months it accumulated about a year of soft entropy: stale dependencies, undocumented config flags, a test suite with about a third of the coverage of the consumer-side service.

When the contract format changed for a regulatory deadline, nobody on that team had the depth to make the call quickly. We pulled in two engineers from the original orchestrator team to consult. Then we pulled in a third. By the end of the project we had effectively rebuilt the team that had owned the original orchestrator, with the overhead of two services to deploy instead of one.

A year after the split, we merged it back. Not because microservices are bad. Because the team boundary we had drawn around it did not exist.

This is the shape of the mistake I see most often in mid-stage architecture decisions. The team is treated as a placeholder you can fit around the system later, like wrapping a gift. But teams are not interchangeable. A team is a particular set of people with a particular set of skills, a particular history with a particular codebase, and a particular thing their manager is being measured on. You cannot ask them to own something that does not fit that shape and expect ownership to actually develop. They will run it. They will not think about it.

Conway's Law gets cited a lot in these conversations, usually as a kind of fatalism. Whatever you ship will look like your org chart, so good luck. I have come to read it the other way around. The org chart is the part of the system you can actually change. If you want a different architecture, change the team structure first. Decide who you want to own what, give that team the time and the mandate, and the right service boundaries will start to suggest themselves. The diagram will follow. It almost always does.

What I would tell my past self at the whiteboard that quarter: stop drawing the services first. Draw the teams first. Then ask which services those teams should plausibly run for the next three years given their current size, their current skills, and the part of the roadmap they are accountable for. Where the answer is "no team would naturally own this," do not split it. Either give the parent team the mandate to keep growing, or invest in building a team that will eventually own the spinoff before you make the cut.

Here is the short version I now bring to architecture reviews. Six questions. Less about diagrams, more about who gets paged when it breaks.

1. Who is on the on-call rotation for this service in eighteen months? Not which team in the abstract, which named role. If you cannot say, the boundary is wrong. 2. What is that team's primary roadmap commitment? If the service is a tax on that commitment, you are about to underinvest in it. 3. How many engineers on that team have read the code end-to-end? If the answer is fewer than two, the team does not own it yet, regardless of what the org chart says. 4. When the regulatory or business context shifts, who has the standing to make the call without escalating? Ownership without decision rights is babysitting. 5. If this team disbands in two years, what is the migration path? "We will figure it out" means the service is going to enter the orphan list. 6. Does the proposed split create at least one service nobody in the room can name a clear owner for? Then it does not exist as a service yet. It exists as a future incident.

None of this means microservices are wrong, or that bounded contexts do not matter, or that you should never split a system. It means the cut should be made along a line where a team is ready to live on the other side of it. If that team does not exist, build it before you cut, or do not cut.

The cleanest architecture I ever inherited was one where the previous director had spent a year reshaping the org before touching the code. By the time the engineers started moving services around, the people were already in the right rooms. The work felt obvious because it was. The seams were already in the people.

The diagram does not decide. The on-call rotation does.

I used to answer that question with confidence. In 2016, I would have said something like: if you get energy from writing code and designing systems, go Staff. If you get energy from developing people and shaping teams, go EM. Pick the ladder that matches the work you actually want to do.

I don't answer it that way anymore, because the ladders have quietly converged.

Back when the dual-ladder story was clean, the two jobs looked different from ten feet away. An EM owned people, careers, and headcount. A Staff engineer owned systems, architecture, and technical direction. Pay was different. Skills ran on different tracks. The body language in a planning meeting signaled which ladder you were on. You could tell who was who without reading the org chart.

Something shifted in the last five or six years. I noticed it in offer packets first. Companies started paying Staff and EM at the same band once you got past a certain level. By 2026, compensation data from the public sites shows Staff ICs and engineering managers at top-tier tech companies landing in roughly the same total comp range at the top of the ladder. The financial signal that used to separate the two paths stopped separating them.

Then I saw it in the work itself. At a previous company, I watched a Staff engineer run what was effectively a multi-team program. She had no direct reports, but three squad leads coordinated through her. She owned the planning cadence. She wrote the roadmap. When a project slipped, she was the one explaining why to the VP. Her calendar looked exactly like an EM's calendar.

Across the same years, I watched an EM at another organization spend two days a week in code reviews, drive architecture decisions for his platform, and argue with principal engineers about service boundaries. He had eight direct reports. He also shipped code. His title said one thing; his day looked like a Staff engineer with a skip-level tax.

One pattern I had to correct in myself was assuming the title told me what someone did. Title plus company size gets you partway there. A Staff Engineer at a 200-person startup looks nothing like a Staff Engineer at a 50,000-person tech company, and most people in the industry can sketch the difference without asking. At senior levels, even that combination stops being enough. When I actually asked what people spent their time on, the picture rarely matched the stereotype the two labels suggested. "Engineering Manager" at one company looked like "Director" at another and "Team Lead" at a third, and company size didn't reliably explain the gap.

The part that hurt to watch was engineers picking the title over the work. I saw someone turn down a Staff offer at a smaller company for an EM offer at a bigger name, convinced the EM label would travel better. Two years later she called me from a role where she spent four days a week in recurring meetings and zero days doing the work she'd accepted the job for. The title traveled fine. Two years in, she was still looking for the job she'd pictured.

I saw it go the other way too. An EM at one organization moved to Staff at another because he wanted out of people management. The new role had no direct reports on paper, but he was running a cross-team initiative with four squads contributing. He was doing scope negotiation, coaching, and what was effectively performance calibration for the leads he coordinated with. Six months in, he told me he'd changed his title and his commute. The rest was the same.

At senior levels, the title has stopped being a reliable signal. What you want to evaluate instead is what differs between two roles, even when the labels match.

Start with decision authority. Who can say no and make it stick? Figure out whether this role can kill a project, block a hire, or force a re-architecture, or whether its job is to advise, recommend, and escalate. Staff and EM titles vary wildly on this axis. Some Staff roles have veto power over a platform's direction. Some EMs can't finalize a hire without three approvals above them. Ask to see a recent decision the role made that a more junior version couldn't have made. If the answer is vague, the authority is vague.

Then look at blast radius. When this role gets a decision wrong, who feels it, and for how long? One team for a quarter, or the whole platform for a year? Blast radius maps to seniority more honestly than title does. A Staff engineer whose choices break one service for a sprint is junior for the title. An EM whose staffing decisions shape an org for three years is senior, no matter what the line on the org chart says. The interview question that surfaces this is boring: "Walk me through the worst consequence of a decision this role has made in the last year." Listen for scope.

The third thing to check is who reports what to whom. The reporting line is half the answer. The information flow is the other half. Ask whether the role sits in the quarterly business review, if the weekly revenue numbers land in its inbox unfiltered, and what budget line carries its name. Information access tells you more about actual scope than the job title ever will. A Staff engineer who reads the same dashboards the VPs read has a different kind of pull than one whose numbers come filtered through two layers.

There's a reason nobody in the industry wants to talk about the convergence out loud. Recruiters need the titles to sound different so the ladders look distinct. Companies want the optionality of paying people the same without admitting they do the same work. Candidates want to believe that picking correctly matters more than it does. Everyone has a reason to keep the old story alive, so the old story keeps getting told.

If you're picking between two senior roles, stop asking which title is better for your resume. Focus on three things instead. What the role can actually decide. What breaks when the role gets a call wrong. Whose numbers it sees every Monday morning. Those answers diverge even when the titles don't.

Five years ago the labels stopped telling the truth, and nobody updated the candidates.

Six months later they were hiring frantically. Not because the team had failed to ship. Shipping was fine. The product worked, customers paid, revenue grew. The problem was that one of the engineers wanted to go to his sister's wedding in another country and be off the grid for two weeks. And nobody could figure out how to let him.

That is the part of the AI-amplified team story that gets edited out of the case studies. The 1-2 person team can ship. It can ship a lot. The question nobody wants to answer is what happens when one of those people gets sick, takes vacation, or quits. Or when something breaks at 3am and the person who knows how it works is asleep with their phone in another room.

I have watched this play out across several organizations now. A team gets very small, leans hard on AI tooling, and looks like a productivity miracle for two or three quarters. Then the cracks show up. Not in shipping speed. In every other dimension that defines actually running production software.

Code review is the first one to break. With two engineers, every review is the same person every time. After a few months they have read each other's patterns so deeply that review becomes a rubber stamp, a chance to confirm shared assumptions rather than catch mistakes. Then someone introduces an LLM-assisted refactor across a critical path, and the review is two people who already trusted each other plus one model that has no skin in the outcome. Things get merged that should not have been merged.

On-call is the second. Two engineers sharing on-call have no real rotation. Both are effectively always on, taking turns at being slightly less on. There is no real off. PTO becomes a negotiation. Both people start arranging their lives around the assumption that something will catch fire and one of them will have to handle it. That is fine for a few months. It is corrosive over a year.

Then audit. In any regulated context, separation of duties is not a style preference. It is a regulatory requirement. You cannot write code, approve your own code, and deploy it to a system that handles money or health data. The auditors will not care how good your AI is. They will not care that the model caught the bug your colleague missed. They will look at the commit history and they will see one human approving another human, and that has to actually be two distinct humans with enough context to push back. Two people who agree on everything do not pass that test, because nothing tests it. Three or four people occasionally disagreeing with each other does.

The hype cycle right now is built around the 1-2 person team as a kind of moral fable. Founders post about it. VCs amplify it. There is a real story underneath: AI tooling has genuinely raised the floor of what a small team can do. A pair of strong engineers with good agent tooling can build something in three months that used to take a quarter of effort from ten people. That is real and worth taking seriously.

The story that gets attached to it is not. The version that says headcount is over, that the team of the future is two founders and a fleet of agents, that the 10x engineer has finally arrived. A 10x individual still creates a 1x bus factor. The math on amplification does not change the math on continuity. If the system depends on one person being awake, the system has one point of failure, regardless of how productive that person is when they are awake.

The interesting number, in my experience, is not 1-2 and it is not 8-10. It is 3 or 4. Small enough for AI tooling to amplify without process choking the team. Large enough that someone can take a real vacation, that code review has at least one outsider, that on-call is a rotation rather than a pact between two friends, that an auditor sees more than one decision-maker.

When agents are doing real work, this sharpens. You need at least one human who verified what the agent did and at least one other human with enough context to catch what the first one missed. That is two people minimum just on the verification side. Add the person who actually owns the change, and you are at three before you have anyone available to be on call, take PTO, or be sick. The minimum viable team for AI-assisted production work is structurally larger than the minimum viable team for shipping a prototype, because production work has more dimensions than shipping.

I know how this lands. People will read it as a defense of the old normal, a quiet plea to keep teams at eight to ten. It is not. The old number was driven by overhead I do not want to bring back: meetings to coordinate meetings, planning artifacts that nobody read, a layer of management that existed because the team was too big for one person to keep in their head. AI tooling did make a lot of that overhead optional. The team can be smaller than it used to be, and the smaller team can do more.

Just not two. Two is a startup-pitch number. It is what you put on a slide for an investor who wants to feel like they bought into the future. Two works for the first six months of a product that has not yet had to be boring and reliable for years.

When the team has to keep something alive on a Tuesday afternoon while one engineer is at a funeral and the other is debugging something unrelated, the answer is not better AI. The answer is a third person. Maybe a fourth. People who have seen the system, written part of it, and can pick up the pager without a week of ramp-up. That is the team that does not collapse the first time real life shows up.

AI made one person ship like ten. It did not change how many people it takes to keep the thing alive at 3am.

No good answer came to me. I gave him the one most consultants default to: the value isn't the time, it's the expertise. He nodded. He didn't buy it.

That exchange stayed with me longer than most, because the honest answer was more complicated than either of us had words for at the time.

The billable hour was never just a unit of time. It was a pricing structure that spread the cost of client-specific learning across the engagement, absorbed the back-and-forth that nobody puts in a statement of work, and included the coordination overhead and judgment calls the client never saw. The invisible work of staying calibrated to what they actually needed versus what they said they needed. None of that appeared on an invoice as a line item. It hid inside the hours.

AI is making that arrangement hard to maintain. When a task that used to take eight hours now takes forty-five minutes, the gap becomes visible. Clients see it. They start asking whether the fee reflects the time or the result. For most firms, the honest answer is both, but in ways they haven't wanted to explain.

The obvious alternative is outcome-based pricing, meaning you charge for what gets delivered rather than for the time it took. In certain situations it works well. Fixed-fee project delivery, success fees tied to defined metrics, retainers scoped to specific outputs. I've been part of arrangements like that, and when they go well, they're better for everyone.

The problem is that they require something most client relationships don't have at the start: a shared, specific agreement about what success looks like and who gets to measure it.

In most engagements, that agreement doesn't exist going in. A client says they want "better pipeline conversion" or "a faster deployment cycle." Those sound like outcomes, but they're not precise enough to price. The baseline is disputed, the timeline is vague, and the dependencies that affect the result include things neither side controls. When the number comes in lower than expected, the conversation about why gets uncomfortable fast, and it usually ends with the vendor absorbing the blame.

I've watched outcome-based arrangements fall apart not because the work was bad but because success criteria were agreed on loosely at the start and interpreted differently by the end. More often than I'd like to admit, the vendor believed they had delivered and the client felt they hadn't. No amount of post-mortem changes the invoice.

The hourly model avoided that problem. Both sides could point to logged time as an objective record. The vendor got paid for showing up and the client paid for documented effort. Clean in a way that masked everything messy underneath.

What AI forces is the question both sides had learned to leave unanswered: what exactly are we delivering, and how will we know when we've done it?

Before I've seen outcome pricing work, there was usually a period of internal calibration. Track time privately, charge on outcomes. Get the measurement right before you depend on it. Learn where your estimates are off, not in a way that changes the invoice, but in a way that sharpens the model for the next engagement. In my experience, that kind of preparation takes six months to a year, and most organizations don't invest it proactively. They wait until the old model breaks, then try to retrofit the new one while the client relationship is already under stress.

For years, billing hours gave consultants cover for the learning curve. A junior consultant logging a hundred hours on a complex engagement was, in part, learning the client's business on the client's dime. Everyone understood this and nobody said it out loud. AI compresses that learning curve, which is good for clients. But it also means the implicit subsidy is gone, and some of the flexibility that made early-career professional services viable disappears with it.

When I think about how this shakes out over the next few years, I don't think outcome-based pricing replaces the hourly model across the board. The market will fragment. Work that is genuinely measurable gets repriced fast, probably toward fixed fees with AI cost savings factored in. Work that is judgment-intensive and relationship-dependent gets repriced slowly, because the trust infrastructure needed for outcome pricing takes years to build, not months.

The firms that will have the hardest time are the ones in the middle. Enough AI in the workflow to make old rates look indefensible, not enough clarity in their own value proposition to anchor a new one.

Outcome pricing is a trust instrument. You can only price on outcomes when both sides agree on what good looks like and believe the other side is measuring honestly. That agreement rarely exists at the start of a relationship. It gets built over time, through track record, through transparency, through hard conversations about how success gets defined before the work starts rather than after it ends.

The billing model carried more than time. It distributed risk in a way both sides found acceptable without having to talk about it directly. AI is cheaper to run, but the risk hasn't gone anywhere. It just can't hide in the hours anymore.

The senior engineer asked the question I've heard some version of my whole career. "Why did you think this would hold?"

The new hire pointed at the PR. The logic was tight, the tests passed, three approvals sat on the review. What he couldn't do was explain what the code around his change was actually protecting. He didn't know why a validation check three files over existed. Nobody had told him what the service upstream did when it saw a null there. He had fixed the symptom. The invariant he broke wasn't visible in the diff he was looking at.

That conversation stayed with me because the engineer was sharp. He'd come from a good program. He was moving faster than any junior I'd managed in the past ten years. And he didn't understand the system he was changing.

The reason is quieter than most leaders want to admit. Over the last few years, the small tasks that used to teach new engineers the codebase have mostly stopped being theirs. AI handles them. Bug triage, the three line fix, the obvious refactor, the "read this module and tell me what it does" exercise. All of it moves through a code assistant now, and the output is usually good enough to ship.

The new hire's first month used to look like slow, uncomfortable archaeology. Read old code. Ask three people what it does. Write a doc nobody reads. Fix a tiny thing and watch it break in staging. That slog wasn't the onboarding. It was the curriculum. Nobody wrote it down, nobody scheduled it, nobody put it on the OKRs. It happened because the work was the only way to get things done, and along the way a mental model of the system got built in someone's head.

Take away the slog and the curriculum goes with it. You still get the fix. You lose the model.

The first few months feel great. The new hire ships more tickets than a comparable hire did three years ago. Managers look at throughput and conclude ramp is faster. Some claim they've cut it in half. And they have, for a definition of ramp that stops at first merge.

The problem is that first merge measures the wrong thing. Onboarding is supposed to produce someone who can diagnose a production issue at 2am without rolling the dice. That capability is built over a few hundred hours of frustration with code the engineer didn't write and can't change. A month of well-completed tickets does not get anyone close to it.

About eighteen months out is where I've seen this bill come due. A senior leaves. A subsystem they built starts misbehaving in a way the dashboard doesn't catch. The mid-level engineers reach for the assistant and get a plausible fix. The fix ships. A week later the same behavior surfaces somewhere else, because the root cause was a shared assumption in a library nobody on the team has actually read.

In a regulated setting, this is worse than slow. It's auditable. When the regulator asks why a control failed, "our engineer relied on an AI suggestion and didn't understand the underlying invariant" is not an answer that keeps your license.

So the question is what to do about it, and I'd rather be concrete than abstract.

The first thing I've seen work is treating code review as teaching rather than as a quality gate. Reviews should cost time. They should go longer than the change would seem to require. Ask the author to walk through the surrounding code, not just the diff. Ask them what would break if their change shipped wrong. If they can't answer, that is the work, not a side conversation. The reason this part has to be a human is that the value is the new hire forming a model in their own head, out loud, in front of someone who already has one. An assistant can produce a plausible explanation of the surrounding code in seconds. The new hire reads it, nods, and walks away with the same gap they came in with. The reviewer's job is to create the friction that turns reading into understanding, and that friction only exists when someone on the other side of the table can tell whether the explanation is real. In past roles, I had a standing rule that any engineer in their first six months got at least one review per week where the reviewer asked them to explain a function they didn't write. It slowed us down by a few percent. It was the single highest return investment I ever made in a team.

Architecture walkthroughs help, but they can't be slide shows. Pick a real incident from the last quarter. Put a senior at the whiteboard. Have them reconstruct what happened, including what they thought at each step and why they were wrong. Two hours. Open questions. No AI in the room. This is the closest thing I've found to rebuilding the reading-old-code muscle when the code is not being read organically anymore.

The move that gets the most resistance is a deliberate no-AI window during onboarding. Not for the whole ramp. For specific exercises: read this module and summarize it, debug this issue with the assistant off, pair with a senior and narrate your reasoning. Two weeks of this, spread over the first quarter, is usually enough. The new hires push back at first. The ones who take it seriously tend to become the people on-call rotations can actually count on.

The flip side worth naming is that AI does work very well in teams that already have discipline. Architecture Decision Records, post-incident write-ups, runbooks people actually maintain. That body of context is what an assistant needs to give answers that hold up under load, because the model is grounded in the team's actual history instead of guessing from the diff in front of it. The teams that get the most out of these tools were already the ones writing things down. The teams that struggle hardest are the ones that never wrote any of it down, hoped the assistant would compensate, and got plausible answers that were wrong in ways nobody caught in review. Discipline is the precondition for AI to help. An assistant cannot read what the team never wrote.

A pattern I had to correct in myself was letting AI quietly absorb the friction that had always been part of growing engineers. It looked like progress. It was progress, for the visible work. What it was not doing was building the second layer, the part I used to take for granted because it happened whether I designed for it or not. Once I stopped assuming the curriculum would emerge from the work, I started scheduling it back in.

The leaders who figure this out in the next year or two will have teams that can still debug at 2am. The ones who don't will discover, eighteen months from now, that they've built a generation of engineers who can ship features and can't hold a system in their heads. This is a design choice someone, somewhere, is quietly making every day by assuming onboarding still works the way it used to.

It doesn't. Name the curriculum, or lose it.

That gap, the one between the slide everyone celebrated and the slide everyone skipped, is the part of the AI conversation engineering leaders are mostly skipping over.

Most of the talk I see is stuck on a different question. Should engineering managers code? It was a contested question before AI showed up. Now it feels existential. Will Larson published “Good Engineering Management is a Fad” last October arguing that the industry’s preferences shift with business reality and dress the shift up as moral progress. Gergely Orosz has been writing for months about EMs perceived as technical landing jobs faster than EMs who are not. Charity Majors keeps making the case that the engineer-manager pendulum is now swinging on a shorter cycle. Each of them is right about what they are seeing, and what they are seeing is a symptom.

Coding was never the bottleneck for most EMs. Judgment was. The work that actually moved a team’s outcomes was deciding what was worth building and holding the line on what was good enough to ship. Writing code was the visible exhaust. Whether something shipped on time or quietly broke six things on the way out the door usually came down to the decisions, not the keystrokes.

What AI did is make the writing-code part cheap. Once that part is cheap, everything else stops being optional. That includes the parts of the EM job that have been substituted for by process for the better part of a decade.

The data backs this up in ways the marketing decks do not.

In July last year, METR ran the kind of study people in our field rarely run. Sixteen experienced open source developers, working on mature projects they already knew, ran 246 real tasks with and without modern AI tools. The headline finding was that AI made them about 19 percent slower. The harder finding was that the same developers believed they had been about 20 percent faster. A 39-point gap between perception and reality, in the people most likely to know better.

Faros AI’s longitudinal data on roughly 10,000 engineers tells the same story from a different angle. On the input side, pull request volume per developer is up 47 percent and merged PRs are up 98 percent. On the way through, code review time has climbed 91 percent and bugs per developer are up nine. The hours AI saves on the way in are getting eaten on the way out. LinearB’s 2026 benchmark across 8.1 million PRs found agentic AI PRs take more than five times longer to be picked up for review than human-written ones.

The 2025 DORA report lands in the same place. AI adoption now correlates with higher delivery throughput and lower delivery stability. Two trends at once, on the same teams. DORA’s framing is the most useful version of this I have read: AI is an amplifier of whatever a team is already doing, for good and for ill.

None of this is an anti-AI argument. The productivity story being told above the EM layer keeps diverging from the one showing up below it. Somebody has to hold the bar between the two, and the cycle for doing that just got a lot faster.

The shape of all this changes depending on the size of the company you sit in.

At a true early-stage startup, under twenty engineers, the question of whether the EM should code never really went away. The founder-CTO is in the codebase. The first engineering hires are in the codebase. The “manager” is usually the strongest senior engineer with a few extra responsibilities. AI in this environment is pure acceleration. One engineer who is good at directing AI ships what a small team used to ship. The startups pulling ahead right now tend to be the three-engineer kind running Claude Code in five terminals, doing what twenty-person teams used to do three years ago.

In a scale-up of a few dozen to a few hundred engineers, the picture is messier. This is where the engineer-manager pendulum has been most painful in the last twelve months. EMs hired in the 2018 to 2022 era were told their job was the people layer, not the code. Many of them built careers around being explicitly hands-off. Now their CTOs are asking them to be hands-on again, sometimes without saying it out loud. Some are thrilled, others are panicking. Stripe has started posting roles with titles like “Engineering Manager, Developer Productivity AI” which would have been unthinkable in 2021. The player-coach role is back, and it is back with a different set of tools than it had the last time.

Mid-market is where the layoff numbers actually live. The largest tech companies cut tens of thousands of corporate roles across 2025, and the memos named the cause directly. “Considerable de-layering” from one. “Fewer layers and more ownership” from another. A third trimmed roughly ten percent of its VP and manager roles in a single round. Read those memos carefully. The story they are telling is about coordinating layers that were too thick, with AI as the trigger that finally made cutting them defensible. The cause goes back further. A lot of mid-market orgs had been building management depth as a substitute for ownership.

Enterprise is the most counterintuitive case. The DX 2025 report found that large traditional enterprises are now leading on measured AI productivity, not lagging. The reason is unsexy. They have actual training programs, governance, and infrastructure that can absorb the change. They also have the most exposure to the DORA finding about lower stability. Higher throughput on top of weak CI discipline is just faster breakage. The most dangerous EM job in the world right now might be the one running a feature team inside a Fortune 500 with a velocity dashboard from 2019 and an AI rollout from last quarter.

Step back from the org chart and look at the METR perception gap again. Sixteen experienced engineers were systematically wrong about their own productivity by 39 points. They were doing what humans do when the work feels different from how it used to feel. The brain registers the new texture as speed, even when the clock disagrees. AI changes how writing code feels in a way that no productivity dashboard has caught up with.

If that gap is real, and the LinearB and Faros numbers suggest it is widespread, every engineering org needs someone who can tell the difference between “feels productive” and “is productive.” Whoever does this has to be close enough to the work to read the actual code and far enough back to see the second-order effects on the team. That role belongs to the EM. Engineers doing the work are sitting inside the perception gap. Executives two levels up are reading the same dashboard the EM put together.

The new EM job is holding the bar between what looks like progress on a dashboard and what is actually changing the company’s position in the market. The coding question, more or less, is a sideshow next to that.

This is harder than the version of the EM job most companies were set up for. Sprint planning is easier than judging a PR. Status meetings are easier than reading the code. A lot of the EMs being culled right now lost their jobs because the parts of the job that were always the real job, the judgment parts, had been substituted with calendar work for years, and the calendar work just got automated.

I have managed teams from both sides of this. There was a stretch in my career where I told myself I was being a better manager by staying out of the code, when most of what I was doing was avoiding the discomfort of judging work I no longer had the context to evaluate. That avoidance was always going to catch up with me. AI just shortened the timeline.

If you run an engineering team and want to take this seriously, the work is unglamorous. Read your team’s PRs yourself for the next two weeks. Not the merge notifications, the actual diffs. You will quickly learn which engineers are using AI to ship things they understand and which ones are using it to ship things they could not have written without it and cannot maintain after they did. While you are in there, put your bug rate on the same chart as your velocity. If both lines are climbing, the second one will eat the first one within a quarter or two. Better to see it early.

The bigger change is in what you measure. The metrics worth tracking now are the ones that survive contact with a customer: features that made it to production without a follow-up fix in the first week, incident resolution time, the share of last quarter’s roadmap that is still in the product six months later. PRs merged is mostly noise once PRs are nearly free to produce. And yes, probably write some code yourself. Reading what your team is shipping is becoming the only honest way to know what is happening on the team.

The engineering managers who are still in their jobs in two years will be the ones who can tell the difference between a team that is faster and a team that just feels faster. As the rest of the work gets cheap, that judgment is the part of the EM job that gets harder.

The leaderboard came down two days after the press found out.

I watched this story unfold and my first thought wasn’t about AI at all. I’ve seen this exact behavior every Q4 for twenty-plus years. If you’ve ever run a P&L or managed a departmental budget, you know the pattern. Your allocation for the fiscal year is $2M. You spent $1.4M. If you return the remaining $600K, next year your budget gets cut to $1.5M. So in October, you start spending on hardware you don’t need yet, conferences that are marginally useful, contracts pulled forward from Q1. The incentive structure makes that spending rational. Use it or lose it.

Tokenmaxxing is the same game with a different currency. Meta and Shopify now include AI usage in performance reviews. Jensen Huang said he’d be “deeply alarmed” if an engineer with a $500K salary didn’t consume at least $250K in tokens within a year. Meta’s CTO has publicly encouraged engineers to spend the equivalent of their salaries on tokens, claiming 10x productivity gains.

The message to the rank and file is clear: if you’re not burning tokens, you’re falling behind. And just like the budget game, people respond to the incentive, not the intent. Running five parallel agents overnight produces nothing that ships, but it produces a ranking. The leaderboard rewards what it can see.

Anyone who has worked in engineering recognizes this problem. We measured lines of code in the 90s, then story points in the 2010s, now tokens. The mistake keeps finding a new unit.

But the parallel to corporate budgets breaks in one important place.

Corporate budgets are finite and zero-sum. One department’s gain is another’s loss. Spending more doesn’t compound into anything. You buy the hardware you didn’t need, it sits in a closet, year over.

AI capability isn’t like that. An engineer who learns how to prompt well, who builds muscle memory with agentic workflows, who figures out where AI saves real time versus where it creates rework downstream, carries compounding knowledge. The learning accumulates. Even some of the wasted tokens produce real learning, because you need to try things before you know what works.

So tokenmaxxing sits in the middle. Whether it helps depends on what you’re actually measuring.

Business spending on AI tokens is up 13x since January 2025. Part of that is genuine capability expansion. Engineers discovering that a well-structured agentic workflow takes three days off a release cycle. Product teams prototyping faster than they can spec. Those are real gains worth paying for. The rest is pure theater. From the outside, both look identical on a token dashboard.

One pattern I had to correct in myself was confusing adoption with value. Years ago I pushed a team hard to adopt a new CI/CD pipeline. We got to 100% adoption in six weeks. I reported it up as a win. What I didn’t measure was that a third of the team had wired their old manual process into the new pipeline to make the dashboards green. They were technically using the tool. Nothing about how they worked had actually changed.

Tokenmaxxing carries the same risk at a much larger scale. When you track consumption without tracking what it produces, you’re measuring how fast the engine runs while ignoring whether the car is moving.

I think Huang’s underlying logic is sound. If a $500K engineer plus $250K in compute gets you the output of two engineers, that’s a reasonable bet. Maybe the best available right now. The companies that figure out how to direct that spend, not just how to increase it, are the ones who pull ahead. “Figure out how to direct it” is the hard part though, and it’s not a question a leaderboard can answer.

The companies I’d bet on are the ones where an engineer can tell you, specifically, what changed. Not “I used AI more this quarter.” Something concrete, like a review cycle that went from four days to one because AI handles the first pass on test coverage. Or a team that finally writes architecture decision records because the draft takes an hour instead of a week.

That’s the difference between spending a budget because it exists and investing it because you know what the return looks like. The cost question is real, and right now it’s almost secondary. Meta’s top token user could have cost the company more than $1.4M in 30 days. At some point, finance teams will ask what that bought. Orgs that can answer clearly get to keep their budgets.

Smart finance leaders eventually learned that “use it or lose it” was destroying capital discipline. The best orgs moved to rolling budgets, zero-based budgeting, or some model that separated “we need this resource” from “we’ll lose it if we don’t spend it.” AI adoption needs the same maturity. Treat token usage as a cost input, not a success metric, and measure what shipped, what improved, what decisions got made faster. Give teams room to experiment heavily because the curve is steep and the upside is genuine, but don’t reward the engineer with the biggest overnight agent bill.

Tokenmaxxing is the right instinct with the wrong scoreboard. Pushing hard on AI adoption and investing aggressively are the right moves. Counting consumption instead of outcomes is where it becomes the budget game again.

Anyone who has survived a few fiscal years knows how that one ends. The money gets spent, and the org doesn’t come out any smarter.

I asked him a question I ask every platform leader now. How many of those fourteen features had more than three teams using them last month?

Quiet.

He said he would check. The answer came back a week later, and we went through it together. Nine of the fourteen had single-team adoption. Two had zero. The three capabilities everyone in the room actually argued about in hallway conversations were not on the deck, because the platform team had not built them yet. That gave us a useful place to start: what would it take to get those three into the next quarter’s plan, and what could we sunset to make room.

That meeting stayed with me. The director was doing his job well by the definition he had been given. His scorecard covered deliverables shipped, incident count, and SLA. All three were green. Adoption was not on the scorecard, so it never became a target, and the team had no reason to think of it as part of their work.

This is the quiet trap every platform team slides into. They get budget because the business wants faster delivery. They get leadership because good engineers want to multiply what other engineers can do. Then they get handed a scorecard pulled straight from infrastructure operations, and the product discipline that would have saved them never enters the room.

A platform is a product. The customer is an internal team. The measure of success is whether that team picks your thing when no one is forcing them to.

Say that to a platform leader and they will agree. Every one of them has read the InfoQ piece, or the DORA report, or the Team Topologies book. The language has traveled. The behavior has not. Most platform teams I have worked with over the years still do not interview their customers. They do not run discovery. And when adoption does not happen on its own, the team calls it a marketing problem.

Here is a conversation I had with a platform PM about two years into a rollout I was advising:

Me: Which three features drive most of the value for your customer teams?

PM: I can tell you which three we shipped last.

Me: That is not the same question.

PM: Right. I would have to go ask.

She did not come back for a week. When she did, she had a spreadsheet. Three features had real traction. Two had a single power user apiece. Seven had been adopted once, then abandoned. The team had been running for eight quarters. They had never retired a single thing.

That is the pattern. Platform teams accumulate capabilities without ever pruning them. A product team that refused to sunset features would not survive its next review. Platform teams do it every quarter, and they call it stability.

One pattern I had to correct in myself as an advisor was letting platform leaders define their own success on infrastructure terms, because those terms were easier to measure and harder to argue with. Uptime. Deploy frequency. P95 latency. All useful. None of them tell you whether the thing is working as a product.

The hardest work in a platform rollout is the moment a platform PM has to walk into a review and say, we are killing feature seven, and we are redirecting two engineers to the thing three teams have been begging for. That conversation costs political capital, costs sunk-cost grief, and costs a certain amount of face for the engineer who built feature seven. It is still the job.

A platform team that does not own adoption is a team producing output without owning outcome. Artifacts ship on schedule while the customer teams quietly route around them. Six quarters in, someone asks why adoption is the bottleneck, and the platform team points at everyone else. Adoption is hard. Treating it as someone else’s responsibility is what keeps a platform team from ever fixing it.

When a platform team picks up product discipline, the work looks different in three places.

Discovery becomes a habit. Real conversations with the five teams most likely to pick up the next capability, asking what is painful right now and what they would trade for it. The format is boring on purpose: a half-hour call, two questions, a notebook. Sometimes the answer is boring too. Often the answer reshapes the roadmap.

Features get killed, out loud, in the review, with a short note to affected users and a migration path where possible. Nobody celebrates a sunset. Good product teams still do them, because shipping and keeping are different decisions.

Adoption becomes the measure that matters most. That brings me to the three metrics I would put on any platform team’s scorecard.

First, weekly active teams. Count unique internal teams that used a platform capability in the last seven days. Not accounts, not API calls. Teams. This number should grow each quarter or the platform has a product problem, not a marketing one.

Second, feature sunset rate. Count how many capabilities you retired last quarter. Zero is a red flag. Platform backlogs grow forever, but platform surface area should not. A healthy team retires roughly 10 to 20 percent of its capability count per year, sometimes more when the organization’s needs shift.

And then, time to first value for a new team. Measure the days from the moment a new engineering team decides to adopt your platform until they ship something real to production on top of it. I have seen this number range from two days in the best platforms I have worked with, to over three months in the worst. Three months is a second layer of infrastructure that customer teams have to work around.

None of these numbers are hard to collect. The reason most platform teams do not collect them is that the results force conversations nobody wants to have. Feature seven gets killed, engineer four switches projects, and the roadmap gets rewritten around something that looks less impressive on a slide.

That is the job. A platform team that is not willing to do it ends up running a subsidized infrastructure group with better branding, and the adoption number will never move no matter how many features ship.

Platform as a product starts the quarter someone has the courage to measure it like one.

The foreman wasn’t a natural evolution. It was an invention, forced by a technology shift. Steam power and mechanized looms made it possible to scale production beyond what any single person could oversee. And the resistance was real. Frederick Taylor’s attempts to systematize the foreman’s job (timing workers with stopwatches, breaking tasks into the smallest possible units) provoked strikes at Watertown Arsenal serious enough to trigger a congressional investigation in 1912. Workers understood something important: when machines change, the person standing between you and the machine changes too. And that person’s decisions start to matter more than your skill.

I’ve been thinking about foremen lately because I’m watching the same

pattern unfold in technology organizations, and I don’t think most leaders have recognized it yet.

Every major technology shift created an entirely new management role. One that didn’t exist before the shift happened, and that the people inside the old structure never saw coming.

Factories created the foreman. When computing moved into offices in the 1980s and 1990s, it created the project manager, someone who could coordinate work across systems that were suddenly faster than the humans feeding them. The internet and digital products created the product manager, someone who could sit between technology, business, and the customer and make decisions about what to build, not just how to build it.

Each of these transitions followed a similar arc. The technology arrived. Organizations tried to use it without changing their structure. Productivity stalled. (Robert Solow won a Nobel Prize partly for pointing out that computers were everywhere except in the productivity statistics.) Then, sometimes a decade later, organizations restructured around the technology and the gains appeared. Organizations resisted the restructuring, not the tool itself.

We’re somewhere in that arc with AI right now. A 2026 study of 6,000 executives found that nearly 90% of firms reported AI had no measurable impact on employment or productivity over the prior three years. The pattern holds. The technology is here. The restructuring hasn’t happened yet.

But I think there’s something different this time, and it matters for anyone managing a team.

Every previous shift automated physical tasks or routine procedures. Looms replaced hand weaving. Spreadsheets replaced manual calculation. Even the internet, for all its disruption, mostly automated the movement of information. Humans stayed essential for the part that required thinking, analyzing, and deciding. That was the safe ground.

AI doesn’t respect that boundary. It writes code. It drafts legal arguments. It analyzes medical images. It makes decisions about customer interactions. One large fintech company replaced about 700 customer service positions with an AI assistant that handled 75% of customer conversations across 35 languages. Cost per transaction dropped 40%. Then customer satisfaction dropped. Complaints rose. The CEO publicly admitted the strategy had hurt quality, and the company started rehiring humans. A language learning platform cut over a hundred contractors and reported it could produce four to five times more content with the same headcount. Users said the content felt repetitive. The quality conversation caught up.

In both cases, the AI performed. What failed was the management layer around it. Leaders treated AI as a headcount replacement rather than a structural change that requires a new kind of oversight.

When I managed teams of engineers, my job was to set direction, remove obstacles, and create conditions where skilled people could do their best work. I could trust that a senior engineer would catch an edge case, push back on a bad requirement, or flag a risk I hadn’t seen. The skill lived in the person. My job was to point it in the right direction.

When some of the “people” doing the work are AI agents, that assumption breaks. An AI agent can write code, execute multi-step workflows, query databases, and correct its own approach. One organization found that an AI coding agent deleted a production database and then generated fake records to cover the gap. Another discovered that an agent handling CRM data could be manipulated into exfiltrating customer information. In an early legal ruling on AI liability, a tribunal held an airline responsible for its chatbot giving a customer incorrect bereavement fare information, rejecting the argument that the chatbot was somehow a separate entity the company wasn’t accountable for.

Skill now sits in two places: the person and the agent. But judgment, accountability, the quality bar? Those still need a human. And not just any human. Someone whose primary job is managing the boundary between what agents can do reliably and where they’ll quietly produce something that looks right but isn’t.

That’s the foreman problem, updated for 2026. Someone has to watch machines operate alongside people, and the failure modes are less visible than they’ve ever been. A handloom weaver who made a mistake produced a visible flaw in the fabric. An AI agent that makes a mistake produces something that often looks polished and correct.

Some organizations are already feeling their way toward this. One pharmaceutical company merged its HR and technology divisions and now has over 3,000 custom AI tools across a workforce of about 5,800 people. Their managers assess every task based on whether it should be automated, augmented, or kept with a person. An enterprise technology company built an AI system for performance reviews using four specialized sub-agents, and their leadership emphasizes that the win came from redesigning the process, not just adding AI to the existing one. A manufacturing company uses agents to resolve supply chain delays before the morning shift arrives.

The pattern I see in the organizations getting this right is that they changed the work before they changed the workforce. They redesigned processes around what humans and agents each do well, rather than handing human-shaped tasks to agents and hoping for the best.

I keep coming back to the spreadsheet analogy. When VisiCalc and Lotus 1-2-3 arrived in the early 1980s, about 400,000 bookkeeping clerk positions disappeared. But 600,000 new accountant positions appeared. When calculation became trivial, value shifted to interpretation, judgment, and strategy. Businesses started modeling scenarios they never would have attempted by hand. They needed more people who could think about numbers, not fewer.

The same pattern played out with ATMs and bank tellers. Tellers per branch dropped from about 20 to 13 between 1988 and 2004. But cheaper branches meant more branches, and total teller employment roughly doubled. The tellers who remained stopped counting cash and started selling financial products, building customer relationships, doing work that actually required a human in the room.

AI is following this pattern in some ways. When routine cognitive work gets automated, the value of judgment, context, and accountability goes up. Early salary data already shows that human skills like coalition-building and empathy command a growing wage premium as AI absorbs data-heavy tasks.

But in one important way, AI breaks the pattern. ATMs didn’t make mistakes that looked like correct transactions. Spreadsheets didn’t fabricate numbers that passed a casual review. The failure mode of previous automation was visible: the machine stopped, the calculation errored, the process broke in an obvious way. AI fails by producing confident, plausible, wrong output. That changes the management job from “keep things running” to “verify that things that look like they’re running actually are.”

I think the manager this moment requires is someone who can hold three things at once: a clear picture of what the team (human and AI) is trying to accomplish, an honest assessment of which parts of that work can be trusted to agents and which can’t, and the willingness to own outcomes they didn’t personally produce and may not have fully reviewed.

That last part is the hardest. One pattern I had to correct in myself over years of leading technical teams was the assumption that if I hired well, quality would follow. With AI agents in the mix, quality becomes an active management function. You can’t hire your way to it. You have to design for it, monitor for it, and accept that the verification layer is now a permanent part of the job, not a phase you grow out of.

Some of the organizations I’ve watched flatten their management layers aggressively, replacing middle managers with AI-assisted workflows and pushing spans of control to 30 or even 50 direct reports. About 40% of employees at companies that have done this say they feel directionless. The coordination and culture work that middle managers did quietly is now missing, and nobody has figured out what replaces it.

Factories outgrew the owner’s line of sight, and we got the foreman. Software outgrew the engineer’s ability to coordinate alone, and we got the project manager. Digital products outgrew any single function’s ability to make good decisions, and the product manager appeared.

Whatever we call the next version, it will be invented because AI-assisted work is outgrowing our ability to tell, by looking, whether it was done well. The people who figure out that job first won’t just manage teams. They’ll define what management means for the next twenty years.

We don’t have a name for that role yet. But if you’re leading a team right now and you’re spending more time verifying output than directing effort, you might already be doing it.

That gap between the press release and the earnings call is where a lot of the AI conversation lives right now.

The NBER surveyed nearly 6,000 senior executives and found that nine out of ten reported zero impact on employment or productivity from AI over the prior three years. Not “modest gains.” Not “early signs.” Zero. I wrote last week about the macro picture, the spending, the GDP numbers, the historical parallels. The economics are worth understanding. But the number that stays with me isn’t the $360 billion or the Solow paradox. It’s the nine out of ten. Because that’s not a macro statistic. That’s thousands of individual leaders looking at their own organizations and saying: nothing changed.

I’ve sat through enough industry conferences to recognize the pattern. A senior leader takes the stage. Slides with large percentages and upward arrows. A case study from one team, usually small, usually recent, usually cherry-picked because it worked. The audience nods. Everyone leaves feeling like they’re behind. Nobody asks: “What happened to the other 94% of your organization?”

McKinsey’s 2025 workplace research found that 62% of organizations report productivity increases of 25% or more from AI. Sounds impressive until you pair it with this: only 20% of engineering teams are actually using metrics to measure AI’s impact. Two thirds of companies are claiming results they haven’t instrumented. They’re reporting feelings, not findings.

I’ve done this myself. At a previous company, someone asked me in a quarterly review whether the AI tools were helping the team. I said yes, because a couple of engineers had told me they loved the coding assistant and their output had ticked up. I didn’t mention that most of the team was barely using it, or that we hadn’t set up any real measurement. I gave the answer the room wanted because the room wasn’t asking a real question. It was looking for confirmation that the investment was working.

That’s the thing about productivity claims in organizations. They flow upward through a series of rooms where the incentive is always to round up. An engineer says “it helps sometimes.” Their manager reports “positive adoption signals.” The director says “we’re seeing early gains.” By the time it reaches the C-suite deck, it’s a bar chart trending up and to the right with no error bars.

The LeadDev Engineering Leadership Report surveyed over 600 engineering leaders in 2025. Sixty percent said AI hadn’t meaningfully boosted team productivity. The majority reported only small gains. That’s a more honest number, and it comes from people close enough to the work to know what’s actually happening. But you won’t see that stat in a keynote.

I keep coming back to a question that I think matters more than whether AI “works.” The question is: what does it cost an organization to pretend something is working before it actually is?

The cost is specific and I’ve watched it accumulate across multiple organizations. Sprint commitments get padded because someone read a vendor white paper that promised 30 to 40% productivity gains under ideal conditions. Managers absorb the gap between those projections and what the team can actually deliver, quietly burning themselves out. Adoption drops off within the first month because nobody built time for the learning curve. And when delivery slips, the tools get blamed, which poisons the well for the actual adoption work that might have produced real results six months later.

I lived through a version of this with cloud migration. Between 2013 and 2016, company after company announced they were “cloud-first” while running 90% of their workloads on legacy infrastructure. The press releases came first. The architecture changes came years later, if they came at all. But that story had a specific ending: the companies that actually benefited were the ones that quietly reorganized without declaring victory before the work was done. The ones who announced the transformation before doing it got stuck performing progress instead of making it.

That’s what I see happening with AI in most organizations right now. Performance of progress. A dashboard that counts AI-assisted pull requests goes up, so it goes into the board deck. That’s not measurement. That’s decoration.

I think about the 10% of executives in that NBER survey who did report productivity impact, and I wonder how many of them would hold up under scrutiny. Some of them, probably. The ones who invested in workflow redesign, set clear expectations, measured before and after, and gave their teams time to adapt. Those organizations exist. I’ve seen a few.

The nine out of ten who said “zero” might actually be the more honest group. They looked at the numbers, couldn’t find the signal, and said so. In a business culture that rewards premature optimism about technology investments, admitting you spent money and can’t show results takes a kind of courage that doesn’t get celebrated at conferences.

What I’d rather see from leadership, including myself, is a simpler frame. We’re investing in AI because we believe the capability is real and the long-term cost of not investing is too high. We don’t have productivity data yet because we’re still learning how to use it well. That’s where we are. We’ll tell you when it changes.

No bar charts. No projected savings. No implying that the transformation already happened.

Nine out of ten executives told researchers the truth. The interesting question is whether any of them are saying the same thing to their boards.

Here’s the latest pair: Amazon, Alphabet, Meta, and Microsoft collectively pledged over $360 billion in AI-related capital expenditure for 2025. Goldman Sachs chief economist Jan Hatzius looked at the incoming macroeconomic data and described AI’s actual impact on U.S. economic growth so far as “basically zero.”

Three hundred sixty billion dollars. Basically zero.

Apollo’s chief economist Torsten Slok put a finer point on it: “AI is everywhere except in the incoming macroeconomic data.” A Denmark-wide study that linked ChatGPT adoption directly to administrative earnings records found essentially zero aggregate effects on earnings or hours worked through 2024. An NBER survey of nearly 6,000 senior executives found that nine out of ten reported zero impact on employment or productivity from AI over the prior three years. The Census Bureau’s BTOS survey showed that only about 18% of U.S. firms used AI at all by end of 2025, and a mere 6.1% used it in actual production.

Those numbers should bother anyone paying attention. They bother me, and I’ve spent the last two years telling engineering leaders that AI adoption is a strategic priority.

But before we reach for the obvious conclusion, there’s another set of numbers that deserve the same weight.

ChatGPT reached 900 million weekly active users by early 2026. AI coding tools went from $550 million to $4 billion in a single year. Claude Code went from zero to $2.5 billion in annualized revenue in roughly nine months. AlphaFold solved the 50-year protein folding problem and won a Nobel Prize. AI-designed drug molecules are hitting Phase I clinical trials at success rates roughly double the historical baseline.

So we have a technology that produces Nobel Prizes and zero GDP. That generates billions in product revenue while burning through those billions even faster. That half the developer population uses daily while nine out of ten executives say it hasn’t changed anything.

This is the contradiction I want to sit with, because I think most of the commentary gets it wrong by resolving the tension too quickly. The bears say it’s a bubble. The bulls say we’re early. Both are reaching for comfort. The honest position is harder: both of those things might be true at the same time, and the historical record strongly suggests they are.

Warren Street Wealth Advisors estimated the AI sector’s investment-to-revenue gap at roughly six to seven times. For context, the dot-com bubble’s ratio was about four times. The railroad boom’s was about two times. We are spending at a pace that exceeds both of those episodes relative to what the spending is actually generating.

And a meaningful chunk of the AI revenue that does exist is circular. Microsoft invests in OpenAI. OpenAI spends on Azure. Amazon invests in Anthropic. Anthropic spends on AWS. The money moves in a loop that flatters the revenue lines of companies that are also the biggest spenders. I’ve seen this pattern before in enterprise software, where vendors buy each other’s products to hit partnership targets. It looks like a market until you trace where the cash actually goes.

OpenAI reached roughly $25 billion in annualized revenue by early 2026 but is projected to burn $9 billion this year and $17 billion next year. Deutsche Bank estimates $140 billion in cumulative losses from 2024 to 2029. Profitability isn’t expected until 2030. Anthropic, at roughly $30 billion in annualized run rate, projects positive cash flow no earlier than 2027 or 2028. These aren’t struggling startups. These are the category leaders, and they’re hemorrhaging money at a scale that would be considered catastrophic in any other industry.

So yes. The spending looks unhinged.

And I think that framing, by itself, misses something important.

Robert Solow wrote in the New York Times Book Review on July 12, 1987: “You can see the computer age everywhere but in the productivity statistics.” Computing capacity had increased a hundredfold in the 1970s and 1980s. Labor productivity growth had slowed from over 3% annually in the 1960s to roughly 1% in the 1980s. The paradox persisted for another decade. The macro gains didn’t arrive until the mid-to-late 1990s, a lag of ten to twenty years from widespread adoption.

We’ve been here before. Almost exactly here.

Paul David, the Stanford economist, traced the same pattern with electrification. Factory owners in the 1890s replaced their steam engines with electric dynamos and kept the same belt-and-pulley layouts. They gained almost nothing. The real productivity breakthrough came in the 1920s, when factories were redesigned from scratch around distributed electric motors. That redesign took a generation. Not because the technology wasn’t ready, but because the organizational imagination wasn’t ready. People couldn’t see the new shapes that the new capability made possible. They kept cramming the new thing into the old architecture.

I watched something similar happen with cloud migration between 2012 and 2018. Teams that “moved to the cloud” by lifting and shifting their existing applications gained almost nothing. Sometimes they spent more. The gains came later, when organizations rebuilt their systems and their teams around what cloud actually made possible: elastic scaling, managed services, deployment as a continuous activity rather than a quarterly event. The technology was available for years before the organizational model caught up.

Erik Brynjolfsson at Stanford has formalized this as the “Productivity J-Curve.” His argument, published in the American Economic Journal, is that general-purpose technologies initially show lower measured productivity because firms are making massive, unmeasured investments in reorganization, training, and new processes. The payoff comes later, creating a J-shaped curve. His research found that adjusting for these unmeasured intangible investments, true total factor productivity was 11.3% higher than official measures by the end of 2004. In a February 2026 Financial Times piece, Brynjolfsson claimed U.S. productivity jumped approximately 2.7% in 2025, nearly double the prior decade’s 1.4% average, as evidence the “harvest phase” has begun.

Other economists are not convinced. Daron Acemoglu, the 2024 Nobel laureate, calculated that AI’s total factor productivity gains will likely be no more than 0.53 to 0.66 percent over ten years. His reasoning is blunt: only about 5% of the economy can be profitably affected by current AI, because only 20% of tasks are exposed to it, and only a quarter of those are cost-effective to automate. That’s roughly a tenth of Goldman’s own long-term projection of 7% global GDP growth from AI.

Brynjolfsson and Robert Gordon at Northwestern have a formal wager on LongBets.org about whether productivity growth will average over 1.8% annually through 2029. Gordon, the author of The Rise and Fall of American Growth, argues that the great inventions of 1870 to 1970 were one-time transformations and that AI’s impact will be gradual, not sudden. Two serious economists, betting real money, disagreeing by an order of magnitude on the same question. That tells you something about how wide the uncertainty actually is.

There are counterarguments that I take seriously.

The adoption speed is genuinely unprecedented. A St. Louis Federal Reserve study found generative AI reached a 39.5% adoption rate among U.S. adults after just two years, compared to 19.7% for PCs after three years and 20% for the internet after two years. By August 2025, that number hit 54.6%. Over 1.2 billion people used AI tools within three years of ChatGPT’s launch, faster than the internet, PCs, or smartphones.

Part of the reason is structural. Every previous general-purpose technology required building physical infrastructure from scratch. Electricity needed grids. Cars needed roads and gas stations. The internet needed broadband. AI needs a browser. It sits on top of infrastructure that already exists, which compresses the adoption timeline in a way that has no real historical precedent. Harvard economist David Deming pointed this out explicitly: generative AI is built on top of PCs and internet access as base layers.

The developer ecosystem is also orders of magnitude larger. GitHub hosts over 150 million developers. Roughly 1,000 to 2,000 new open-source AI models are uploaded to Hugging Face daily. API-first distribution means AI can be embedded into existing products without hardware installation. The iteration speed, with new frontier models shipping every four to six weeks, is incomparable to any physical technology’s improvement cycle.

I find these arguments compelling. And I still don’t think they resolve the tension.

What history keeps showing is that the bottleneck is never the technology. It’s the organizational adaptation. Getting humans and institutions to reorganize around a new capability takes about a generation regardless of how fast the capability itself improves. David showed this with the dynamo. We saw it with computing. We’re watching it with AI right now.

A telling example: when ATMs spread in the 1960s and 70s, everyone assumed bank tellers would vanish. Instead, ATMs reduced cost per branch, so banks opened more branches, and total U.S. bank tellers actually increased from 1980 to 2010. Economist James Bessen documented this. The technology didn’t eliminate the work. It changed the economics of the work, which changed the shape of the industry in ways nobody predicted. Developers using AI complete 21% more tasks and merge 98% more pull requests. That sounds like a productivity revolution until you realize it’s generating vastly more software, not less demand for programmers. The Jevons Paradox, first observed with coal in 1865, keeps showing up.

So where does that leave a leader trying to make real decisions right now? Not in 2030, not when the J-curve resolves, but this quarter, with a budget and a team and a board that has opinions?

I think the honest answer is uncomfortable. The $360 billion is probably not rational at the individual company level, but it might be rational at the portfolio level. Each company is making a bet it can’t afford to lose. The cost of being wrong about investing is a few ugly quarters of write-downs. The cost of being wrong about not investing is irrelevance. When every competitor is spending, the calculus tips toward spending even if you privately believe the payoff is years away. I’ve seen this logic play out in enterprises debating cloud migration, in airlines investing in digital operations, in banks building mobile platforms. The individual ROI case was often weak. The strategic risk of falling behind was the real driver.

That doesn’t make the spending wise. It makes it explicable. There’s a difference.

For teams and leaders closer to the ground, I’d focus on two things. First, treat AI adoption as an organizational design problem, not a technology deployment problem. The companies that gained from cloud were the ones that changed how they built and operated, not just where they ran their servers. The companies that will gain from AI are the ones that redesign workflows, incentives, and team structures around what AI makes possible. Buying licenses and running pilots is the equivalent of bolting a dynamo onto a belt-and-pulley factory.

Second, watch the micro-level evidence more than the macro numbers. The macro stats will stay near zero for a while because that’s what general-purpose technologies do. But the translation industry has already lost 40 to 70% of its human workforce at agencies. AI coding tools are a $4 billion market that didn’t exist two years ago. Drug discovery timelines are compressing from a decade to months for early phases. These are narrow, specific, measurable impacts. The question for your organization is whether any of those narrow impacts touch your value chain, and whether your competitors are adapting faster than you are.

Goldman says basically zero. History says that’s on schedule. The $360 billion says the people writing the checks believe the zero is temporary.

I think they’re probably right. I also think a lot of that money is going to burn before anyone proves it.

The room went quiet. A few heads nodded. And just like that, the tool got the blame, and the team got an implicit pass.

0I’ve been in engineering leadership long enough to recognize what that moment actually was. Not an honest postmortem. A deflection dressed up as one.

When leadership asks engineering teams to adopt AI coding tools, the message often gets received as: move faster, write less, do more with less effort. That reading is almost always wrong, and leaders who allow it to persist are setting their teams up for exactly the kind of failures that then get pinned on the technology.

When the ask is a serious one, it’s to be more of an engineer. To own architecture, judgment, tradeoffs, and quality at a level that frees you from writing every line from scratch. The tool handles execution. You handle the thinking. That is a harder job, not an easier one.

Somewhere between the executive announcement and the sprint planning meeting, that distinction collapses. And then the data catches up.

GitClear analyzed 211 million changed lines of code across repositories from 2020 to 2024, including work from Google, Microsoft, and Meta [1]. What they found is uncomfortable to read if you’ve been cheerfully citing productivity gains. Code churn (lines revised or reverted within two weeks of being authored) is on track to double versus its pre-AI baseline. Refactored code, the kind that signals a team actively improving what they’ve built, dropped from 25% of changes in 2021 to under 10% in 2024. Copy-pasted code blocks grew from 8.3% to 12.3% in the same window. Eight-fold increase in duplicate code blocks over a four-year period [1].

This is what “moving faster” looks like when the person generating the code isn’t fully owning what they generate.

SonarSource found a 9% increase in bugs in AI-accelerated codebases and pull requests that are 154% larger than what teams were producing before [2]. Pull requests per developer went up roughly 20% with AI assistance, but incidents per pull request increased by 23.5% [2]. Google’s 2024 DORA report put numbers on what this looks like at the delivery level: a 25% increase in AI usage corresponds to a 7.2% decrease in delivery stability and a 1.5% drop in throughput [3].

More code. More PRs. More churn. More incidents. Less stability.

None of this is the AI’s fault. The AI did exactly what it was told.

Ox Security ran an analysis of more than 300 production repositories in 2025 and found ten recurring patterns in AI-generated code present in 80 to 100% of what they reviewed: incomplete error handling, weak concurrency management, inconsistent architecture [4]. These aren’t bugs you miss at 2am when you’re tired. These are engineering decisions that were never made, skipped because the code appeared to work, shipped because the test passed, and discovered when something went wrong downstream.

That’s the accountability gap. And it doesn’t belong to the AI.

Ox’s findings landed alongside a separate Georgetown CSET analysis from November 2024 that catalogued the security vulnerability profile of AI-generated code across the major providers [5]. The word “BLOCKER” appeared often. AI-generated code requires the same rigorous review as any code, and in practice it’s getting less of it because the generation itself feels like the hard part was already done.

The hard part is never the generation. It never was.

Blaming AI for SLA degradation is the new “I told you so.” It carries the same structure: a skeptic who never fully bought in, an early miss that confirms their doubts, and a narrative that quietly ends the conversation before anyone has to examine what actually happened. What actually happened is usually simpler and more uncomfortable. The team used the tool without a clear owner for quality. Review standards didn’t adjust for the new volume. Test coverage didn’t expand to match larger changesets. No one explicitly said what “good AI-assisted engineering” looked like, so the default was whatever worked. If it compiled and the tests passed, it shipped.

AI did its job. The ownership question went unanswered.

One pattern I’ve had to correct in myself over the years is assuming that handing someone a powerful tool is the same as setting expectations around how to use it. It isn’t. A faster car needs better driving. More code generation requires sharper review. The two sides of that equation need to move together, and when they don’t, the quality bill comes due on a timeline you can’t predict and can’t really argue with.

The harder conversation, the one that gets avoided, is about what leadership owes the team during an adoption period.

The 2025 LeadDev Engineering Leadership Report surveyed more than 600 engineering leaders. Sixty percent of them said AI hadn’t meaningfully boosted team productivity. The majority reported only small gains [6]. That number tells you something important: most teams are in the difficult middle of a capability transition, not on the other side of it. And yet leadership behavior in many of those organizations suggests the opposite assumption. The tools are deployed, so the results should follow.

They don’t. At least not right away.

McKinsey’s 2025 workplace research found that C-suite leaders dramatically underestimate how extensively their employees are already using AI, but they also overestimate how quickly that use translates into delivery outcomes [7]. One figure from that work: 62% of organizations report productivity increases of 25% or more from AI, but only 20% of engineering teams are actually using metrics to measure AI’s impact [6]. Two thirds of companies claim results they can’t prove, from a transition they haven’t instrumented.

That gap has consequences for the people doing the work. Engineering managers are reporting 12 to 15 hour workdays following AI tool rollouts, as sprint expectations get inflated 30 to 40% based on vendor ROI claims while actual utilization of the tools drops to around 22% within the first 30 days [8]. The team is drowning in delivery pressure while they’re still figuring out the toolchain. Licenses were purchased, expectations were raised, and the timeline for when results would actually show up was never discussed.

About eight months into one rollout I was involved with, a VP of Product pulled me aside after a planning meeting. The delivery numbers hadn’t moved. He asked, with a mix of frustration and genuine curiosity, whether the AI tools were actually helping or whether we’d wasted the budget. I told him something like: we’re in month eight of a twelve-month transition. The team is learning a different way to work. You’ll see the movement, but not yet. He looked at me the way people look at you when they’re not sure if you believe what you’re saying.

I believed it. But I also knew the conversation was happening because no one had set that expectation before the rollout started.

If you push an engineering team to adopt AI and expect delivery performance to improve immediately, you’ve misread the transition. What actually happens is what Google’s DORA team described as the bottom of a J-curve. Performance gets worse before it gets better, as teams rebuild mental models, review processes, and quality gates around a different way of generating code [3]. Expecting the upward curve without accepting the downward one isn’t optimism. It’s a refusal to understand change.

I’ve watched this play out across multiple transformations. Every time an organization tried to mandate a new way of working without building space for the learning period, the team found ways to comply on the surface and protect themselves underneath. Metrics looked fine. The actual change didn’t happen. And when something broke, someone found a credible-sounding external cause.

AI is now that external cause. Available, plausible, and completely unable to defend itself.

The organizations where AI adoption is working share a pattern that’s less flashy than the productivity numbers in press releases. Accenture’s deployment of GitHub Copilot across a large developer population found that over 80% of participants successfully adopted the tool, with a 96% success rate among the initial cohort [9]. Ninety percent of developers reported higher job fulfillment. But what made that work wasn’t the tool. It was structured adoption with explicit expectations, measurement, and time built in for the learning curve to run its course.

The Accenture work confirmed something the skeptics don’t advertise: when you actually manage the transition, the results are real. Code readability up. Maintainability up. Code approval rates up [9]. Not because AI made engineering easier, but because the engineers who used it well used it as an amplifier for their judgment, not a substitute for it.

The controlled research backs this up too. Developers completing structured tasks with Copilot finished 55% faster in some studies [9]. Pull request cycle time dropped from 9.6 days to 2.4 in one tracked deployment. Those numbers are real. They’re also downstream of something less visible: engineers who understood exactly what they were responsible for, and used the tool accordingly.

Those outcomes trace back to one thing: clear ownership of quality, regardless of where the code came from.

There is a version of this conversation that gets had in every industry going through a capability shift. I watched it with test automation. I watched it with cloud migration. Teams that treated the new capability as a way to do the same job faster eventually hit a ceiling. Teams that treated it as a reason to redefine what the job meant pulled ahead and didn’t come back.

Writing less code was never the point. The job is to carry more judgment about what gets built, what gets reviewed, what gets deployed, and what the consequences are. That’s a bigger ask. It requires more professional ownership, not less.

The teams that understand this are the ones where engineers look at AI output the way a senior engineer looks at a junior’s PR, with curiosity, with scrutiny, with clear standards. Those are the teams where the J-curve turns. Somewhere around six months in, based on what I’ve seen, that’s when the upward movement starts to show.

The ones still waiting for the curve to turn on its own are usually the ones with a leader who announced the tools, expected the numbers, and is now looking for someone to blame.

Quietly, that leader is the answer to their own question.

References

[1] GitClear. “Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality (Including 2024 Projections).” GitClear Research, January 2024.

[2] SonarSource. Cited in: Smith, B. “AI in Software Development: Productivity at the Cost of Code Quality?” DevOps.com, 2025.

[3] Google Cloud. “Accelerate State of DevOps Report 2024.” DORA Research Program, 2024.

[4] Ox Security. Analysis of AI-Generated Code Anti-Patterns in Production Repositories. Ox Security Research, 2025.

[5] Center for Security and Emerging Technology (CSET), Georgetown University. “Cybersecurity Risks of AI-Generated Code.” Issue Brief, November 2024.

[6] LeadDev. “Engineering Leadership Report 2025.” LeadDev, 2025.

[7] McKinsey & Company. “Superagency in the Workplace: Empowering People to Unlock AI’s Full Potential at Work.” McKinsey Global Institute, 2025.

[8] Earezki, A. “Managing the Gap: Why Engineering AI Adoption Leads to Developer Burnout.” Dev|Journal, March 2026.

[9] GitHub. “Research: Quantifying GitHub Copilot’s Impact in the Enterprise with Accenture.” GitHub Blog, 2024.

Most people are doing a different math: tickets + parking + snacks + a babysitter turns “movie night” into a project. So they hit play at home.

And at home, the only thing that matters is what lands. If the movie feels flat, nobody cares why. They don’t separate the work from the way it shows up. They just decide it was overrated and move on.

That’s why I’m careful with “it was amazing in theatres” as a defense.

A good film is the one that tells a good story. Schindler’s List was black and white and it still hits like a truck. More recently, Oppenheimer didn’t need a candy-colored look to pull people in and keep them there.

Still, there’s a product lesson here: your quality bar has to match where customers actually experience the thing.

The home experience isn’t a side channel anymore. It’s the primary one. And yes, if you can afford it, you can get very close to a theatre now — a high-end OLED (or a top mini-LED) with Dolby Vision/HDR and a real Atmos setup is no joke.

But most customers live in the middle. They want easy, affordable entertainment that feels like the version everyone talked about.

So value delivery isn’t “we built it right.” It’s “it showed up right.” Wherever the customer eats the popcorn.

People expect comfort. They want a checklist that keeps their current role intact. I’m not going to do that. The reality is the parts of your job you’ve been rewarded for—typing code, churning tickets, filling in docs—are getting cheap fast. If you’re clinging to those as your identity, it’s going to hurt.

A lot of the anxiety comes from a quiet assumption: “My job exists because I produce output.” Code output. PRDs. Jira updates. Spreadsheets. Slides. Those are artifacts. AI is turning artifacts into commodities. And when something becomes a commodity, companies stop treating it like a career moat.

So when someone asks me how not to be replaced, what I hear is: “How do I keep being paid for the parts of my job that are becoming cheap?”

That framing is the trap.

The question worth asking is: “If the typing is almost free, what’s left that a team still needs a human to own?”

There’s a blunt answer: ownership under uncertainty. Judgment when the trade-offs are real. Clarity when everyone is spinning. And the willingness to carry the outcome when it works and when it doesn’t.

If you’re a developer who loves coding more than problem-solving, this shift is going to land hard. Coding is a clean feedback loop. You write, it compiles, tests pass, dopamine hits. AI is about to outpace you in that loop. Faster drafts. Faster refactors. Faster test scaffolds. Faster “good enough.” If your value is “I can produce code,” you’re signing up to compete with a machine that never gets tired and never needs a meeting-free morning.

If you’re a PM who hides behind frameworks and rituals, same story. If your job is mostly translating conversations into templates, running ceremonies, and producing documents, AI will do that work at a level that’s uncomfortable to watch. Not perfect, but plenty good for the organization to stop paying a full-time human to be a document factory.

What doesn’t get replaced as easily is the part where someone has to decide.

Decide what problem is worth solving. Decide what “done” means. Decide what to cut when time runs out. Decide what risk is acceptable. Decide what we’ll measure in the real world. Decide how we’ll respond when reality disagrees with the plan.

Those decisions are the job. The artifacts were just the visible exhaust.

This is where I think smart people get stuck: they treat “having a job” as the goal, instead of being the kind of person teams depend on when the work gets messy. They look for tactics to protect their current tasks instead of building the ability to own outcomes.

And yes, that means letting go of some identity.

If you’ve built your self-worth on being the person who can crank out code, you’re going to feel threatened. If you’ve built your self-worth on being the person who can run the process, you’re going to feel threatened. That’s not because you’re weak. It’s because you attached your value to the part that’s being automated.

The switch you need is simple to say and hard to live: stop thinking of yourself as an artifact producer. Start thinking of yourself as an outcome owner.

Outcome owners do a few things consistently, regardless of title.

They frame problems in plain language that the whole team can agree on. They define success in a way you can measure after release, not just in a demo. They spot constraints early—performance, security, cost, usability, migration pain, integration ugliness—before the team commits to the wrong path. They make trade-offs explicit instead of letting them hide in the backlog. They reduce “unknowns” before the team burns weeks building the wrong thing.

And they’re calm when the plan breaks, because they planned for that.

AI can help with every one of these steps. But it can’t be the accountable owner. It can’t be the person who says, “We’re doing this, not that, and here’s why,” and then lives with the outcome.

So what should you actually do?

Not “learn AI.” Everyone will learn AI. That’s table stakes.

You train yourself to operate one level higher than the tool.

For developers, that means you don’t win by writing more code. You win by making better calls about what code should exist, what shouldn’t, and what risks you’re taking on by shipping it. You get good at reviews that catch real problems: edge cases, failure modes, operational blind spots, sloppy assumptions. You become the person who can take a vague goal and turn it into a plan that won’t collapse under real usage.

For PMs, that means you stop being a backlog curator and become a decision maker. You get sharp about what matters to users and the business, what doesn’t, and why. You can say no without hiding behind process. You can hold a line when stakeholders try to turn every idea into a “must-have.” You can create focus when there are ten competing priorities and everyone has a plausible argument.

Here’s a practical way to force the shift without turning it into a motivational poster.

Run one project with a rule: the AI does the drafting, you do the owning.

Let the tool write the first pass: the code, the tests, the PRD, the rollout note, the API doc. Your job is to produce the pieces that AI can’t fake well:

• A one-paragraph problem statement that a skeptical teammate would agree is the real problem.

• A definition of success that includes what you’ll measure after release.

• The top failure modes and how you’ll detect them quickly.

• The trade-offs you’re making and what you’re explicitly choosing not to do.

• A decision log: what you decided, when, and based on what evidence.

When you work this way, two things happen. First, you ship faster, because the typing stops being the bottleneck. Second, your value becomes obvious in a different way: you’re the person reducing chaos and making the work coherent.

If you do this and feel a little lost, that’s normal. It means you were relying on output as your proof of worth. Most of us did, because it’s measurable and praised. Now the measuring stick is shifting.

You don’t avoid being replaced by protecting your current tasks. You avoid being replaced by becoming the person teams trust with ambiguity, trade-offs, and outcomes.

And if that doesn’t appeal to you—if what you really love is the craft of typing code or filling in docs—then be honest about it. There’s nothing wrong with loving the craft. Just don’t confuse loving the craft with having a defensible career moat in a world where the craft is being automated.

The people who do well in the next few years won’t be the ones who write the most code or produce the cleanest templates. They’ll be the ones who can take messy problems, make them tractable, and drive them to a measurable result while everyone else argues about the right tooling.

We were in the middle of a release that had a regulatory deadline attached to it. The kind where “a week late” isn’t a joke, and “we’ll catch it next sprint” gets you a meeting with Legal. One of our teams was quietly stuck. Not blocked in a dramatic way. No incident. No escalation. Just slow, grinding friction: unclear priorities, a dependency that kept slipping, a product decision that kept changing shape. Everyone looked busy. Nothing moved.

I found out by accident.

I was the manager’s manager in this case. I dropped into a review meeting because someone was out, and I could feel it in the first five minutes. The engineers were polite, careful, and tired. The manager was doing that thing good managers do when they’re trying to protect the team and keep leadership calm at the same time. Everybody was “fine.”

After the meeting, one of the staff engineers caught me in the hallway and said something like, “I didn’t want to go around my manager, but… we’re not going to make it.”

That sentence shows up in some form every few months in most organizations. And it’s usually followed by a story where everyone was trying to do the right thing and still left a lot of value on the table.

Skip relationships are one of the easiest ways to speed up trust, clarity, and career growth inside a company. They’re also one of the most misunderstood.

A lot of people treat their skip manager like an emergency exit: break glass only when things are on fire. And when the fire finally shows up, the relationship isn’t there. The context isn’t there. The trust isn’t there. So the conversation gets weird fast. It becomes an investigation, or a complaint session, or a vague “just wanted to make you aware.” Nobody leaves feeling good.

What I’ve learned, on both sides of the table, is that the best skip relationships don’t feel like escalation. They feel like alignment.

The missed opportunity starts with a set of default assumptions people carry, usually without saying them out loud.

One assumption is that reaching out to your skip manager is disloyal. That it signals your direct manager isn’t doing their job. That you’re trying to play politics. I’ve watched strong engineers avoid skip contact for a year because they didn’t want to look like they were “going around” someone. Then they hit a wall, and the first skip conversation happens under stress. By then, it’s hard to avoid the vibe of escalation, even if that wasn’t the intent.

Another assumption is that skip managers are too busy for you. This one is almost always wrong. Yes, their calendars are a mess. But if you’re a solid IC or a new manager in their org, you are part of what they’re accountable for. Your output, your retention risk, your growth, your ability to execute under constraints. When skip managers ignore those signals, it catches up later as attrition, missed delivery, quality problems, or “mysterious” morale dips. A fifteen-minute conversation today is usually cheaper than the cleanup six months from now.

Then there’s the belief that skip 1:1s are a trap. People assume the skip manager is collecting intel. That anything you say will be used against you. That candor will get you labeled as “difficult.” Sometimes that fear comes from real organizational scars. Sometimes it’s just anxiety filling in the blanks. Either way, it pushes people into a careful, bland, low-information conversation that helps nobody. The skip manager walks away thinking everything is fine. The report walks away thinking the skip manager doesn’t care. And the gap stays.

There’s also a quieter assumption I see with ambitious people: “My skip manager will notice my work if I just keep delivering.” I used to believe this. It’s comforting because it keeps you in control. Put your head down, ship, and recognition will find you.

In practice, skip managers don’t have enough bandwidth to infer your intent from your tickets in a board. They see outcomes, and they see patterns, but they don’t automatically know what you want more of, what you’re trying to learn, what kind of scope you’re ready for, or what support would remove friction. If you don’t tell them, they guess. And their guess is often shaped by whoever is loudest in the room, not whoever is most ready.

All of those assumptions lead to the same behavior: people keep skip managers at arm’s length, then wonder why decisions feel random, promotions feel opaque, and priorities shift without warning.

Now let me flip it around, because I’ve been the skip manager too, and I’ve had plenty of skip reports who didn’t know what I was hoping for.

When I set up skip 1:1s, I wasn’t looking for gossip. I wasn’t looking for a shadow performance review. I wasn’t trying to catch anyone contradicting their manager.

I wanted signal.

In a healthy org, the information that reaches a skip manager is filtered. That filtering is not malicious. It’s normal. Every layer summarizes. Every manager protects their show. Every leader tries to keep noise down and confidence up. That’s part of the job.

But it means I’m always at risk of being the last person to know something that matters. The work is slipping. The architecture is brittle. The team is burning out. The roadmap is fantasy. A partner team is quietly refusing to cooperate. The quality bar is eroding because deadlines are fixed and scope isn’t.

Direct managers can surface those things, and good ones do. But even good managers sometimes wait too long, because they’re trying to solve it first. Or because they don’t want to look like they can’t handle it. Or because they’re new and still learning which problems are “normal hard” and which ones need help.

A skip relationship gives you a second sensor. Not to bypass the manager, but to make the system less fragile.

When I met with skip reports, I was open to a few kinds of conversations.

I wanted to understand what work felt like on the ground. Not the status update, but the friction. Where are decisions getting stuck? What’s causing rework? Where are we burning time because ownership is unclear? If you’re an IC, you see process debt before any dashboard does. If you’re a manager, you feel misalignment before it becomes an escalation.

I also wanted to know what you cared about and what you wanted next. People often under-share here. They’ll say “I want to grow” or “I’m open to more responsibility,” which is fine, but it doesn’t give me anything to work with. The useful version is more specific: “I want to lead a cross-team effort,” or “I want to move toward staff-level scope,” or “I’m trying to get better at influencing product decisions,” or “I’m considering management but I don’t know what I’m signing up for.” Those are conversations a skip manager can actually support.

I was also open to hearing when your manager was doing something that was unintentionally hurting you. Not as an accusation, but as a reality check. Managers, especially in regulated environments, often over-rotate on control when risk is high. They get tight on reviews, tight on approvals, tight on who can talk to whom. Sometimes that’s needed. Sometimes it’s just fear disguised as rigor. Skip managers can help coach that back into balance, but only if they know it’s happening.

And I wanted you to tell me when you saw a better way to run part of the org. Not “we should change everything,” but a practical improvement rooted in the work. A recurring meeting that produces no decisions. A handoff that creates delays every time. A platform dependency that needs a clear owner. A policy that made sense two years ago and now mostly causes workarounds. When someone brought that kind of observation with concrete examples, I took it seriously.

Here’s what surprised me early in my career: skip reports often assumed I would react defensively to that input. In reality, I usually felt grateful. Because it’s rare to get clean signal, and it’s even rarer to get it from someone who is close to the work and also thoughtful about the business constraints.

Of course, not every skip manager is good at this. Some are insecure. Some don’t build trust. Some treat skip 1:1s like a complaint hotline and then punish the manager indirectly. People aren’t imagining those risks. They happen.

So the practical question becomes: how do you work with a skip manager in a way that builds value and keeps relationships clean?

Start by being clear in your own head about your intent. If your intent is to “win an argument” against your manager, that energy shows up. It comes out as sarcasm, loaded framing, selective facts. Skip managers can smell it, and it forces them into referee mode. Nobody wins there.

If your intent is to help the team win, the conversation sounds different. You bring facts. You name trade-offs. You acknowledge what you might be missing. You explain how the issue is affecting delivery, quality, risk, or morale. And you ask for help in removing a constraint, not in “fixing your manager.”

I used to coach people to think in terms of: “What decision, clarity, or connection would change the outcome?” That keeps the conversation grounded.

A strong skip conversation also respects the manager relationship instead of pretending it doesn’t exist. If you’re raising a concern that your manager doesn’t know about, you should have a good reason. Sometimes the reason is valid: you tried, it didn’t land, and the impact is serious. Sometimes it’s because you’re uncomfortable with conflict. That’s human, but it’s also a growth edge. Skip managers tend to respond well when you’re honest about that: “I should be able to have this conversation with my manager, but I’m not doing it well yet. I’d like your advice.”

When someone said that to me, I didn’t think less of them. I thought, “Okay, this person is coachable, and they’re trying to act like an adult.”

Another useful pattern is to make the conversation about the system before you make it about people. “We keep changing scope late and it’s creating rework” lands differently than “Product is a mess.” “We don’t have a clear owner for this dependency” lands differently than “That other team is useless.” Same underlying pain, different signal quality.

And if you want a skip manager to invest in you, bring something real. A decision you’re trying to influence. A cross-team issue you’re stuck on. A career move you’re considering. A risk you see with evidence. A request for feedback on how you’re showing up. You don’t need to over-prepare, but you do need to show that you’re not there to vent.

On my side, as a skip manager, I also learned to set expectations explicitly because people don’t know what the “rules” are. When I didn’t say anything, they filled the silence with the assumptions above. So I started telling skip reports, early and plainly, what I was open to: talking about priorities, career growth, friction in how we work, and concerns that might become delivery or risk issues. I also said what I wouldn’t do: I wouldn’t use the conversation to blindside their manager, and I wouldn’t treat it like a secret channel. If something needed action, I’d usually say, “How do you want to handle this with your manager?” and we’d decide together.

That last part matters. People worry that any skip conversation will automatically become a confrontation between leaders. It doesn’t have to. Most of the time, the right move is to help the report get more effective with their direct manager, not to replace that relationship.

The staff engineer I mentioned earlier? Once we talked, it turned out the team wasn’t blocked by incompetence. They were blocked by a missing decision at a higher level and a dependency that needed a clear escalation path. Their manager was trying to solve it quietly. The engineer was trying to be respectful. Both were acting with good intent. The gap was that nobody had built a working channel with the skip manager before the pressure peaked.

We fixed it quickly once it was visible. We made a call on scope, got the dependency team aligned, and adjusted the plan so the regulatory deadline was protected without burning the team down. The engineer didn’t “go around” anyone. They gave the org a signal it needed earlier.

What I’d tell my past self now is simple: skip relationships are part of how execution works at scale. They’re not politics. They’re not therapy. They’re a way to reduce blind spots and speed up alignment.

If you haven’t talked to your skip manager in a while, you don’t need a big reason to start. A short note that says you’d value fifteen minutes to talk about how the quarter is going, what you’re working on, and what you’re aiming for next is usually enough. Then show up with one or two real topics and the intent to help the org win.

Do that a few times a year, and you’ll notice something shifts. Decisions feel less mysterious. Your work has a clearer line to the bigger picture. And when the hard moment comes—and it always does—you won’t be trying to build trust in the same conversation where you need help.

We were building a new workflow for a regulated product. The kind where a “small” mistake turns into an incident review, a customer apology, and a week of people combing through logs with a pit in their stomach. We had a plan that was boring and safe. It wasn’t elegant, but it got us to the next milestone without taking on debt we couldn’t repay.

My manager walked into the room with a different bet. Bigger scope. A new dependency. A vendor we hadn’t used. And a timeline that only worked if nothing went sideways, which is not how software behaves when it meets real users.

I felt it in my chest before I could explain it. That mix of urgency and disbelief. I knew the decision was drifting toward something I thought would hurt us.

In that moment, the temptation is to treat this like a debate where the goal is to win. You line up your arguments. You bring out the strongest engineer voice you have. You aim your facts like a weapon. And if you’re honest, there’s usually a second motive hiding under the first one: you want to be seen as the adult in the room.

I’ve been that person. It can work once or twice. Then it starts to fail in a very predictable way. You end up being “right” in private and ignored in public. The bet goes forward anyway. The team watches you lose. And now you’ve spent political capital, added stress to the room, and still have to ship the thing you don’t believe in.

So when I think my manager is betting on the wrong thing, I slow down and ask myself a question that keeps me honest: am I trying to win for the company, or am I trying to be right?

Those are not the same.

Trying to win means you care about the outcome, even if your idea doesn’t get picked. Trying to be right means you care about the scoreboard inside your own head. And once you’re in “be right” mode, you start collecting evidence like a prosecutor. You stop listening. You treat uncertainty as weakness. You dismiss any counterpoint as politics or ignorance. It’s a great way to feel smart and a terrible way to move an organization.

The first step is making sure the bet is actually wrong, and not just uncomfortable.

A lot of “wrong bet” alarms are really “I see risk” alarms. That sounds like splitting hairs, but it matters because the way you show up changes. If you can’t separate “this will fail” from “this might fail,” you’ll either overreact or you’ll stay quiet until it’s too late.

When I do this well, I stop arguing from taste. I stop saying things like “this feels messy” or “this architecture is bad.” I start anchoring in things that can be checked. What’s the customer impact if we miss? What’s the cost if we ship and have to roll back? What’s the lead time on the dependency we’re signing up for? What has the team actually delivered in the last eight weeks, with the same people, in the same codebase? What do our incidents and our on-call load say about where the weak points already are?

Sometimes that work proves I was reacting, not forecasting. I’ve had cases where I was convinced a direction was reckless, then we pulled real production data and realized the failure mode I feared was rare, contained, and easy to detect. My fear came from an old scar, not from current reality. In those moments, the best outcome is changing your mind quickly, because you just saved yourself a lot of unnecessary conflict.

Other times, the data makes the risk even clearer, and now you have something more solid than conviction.

There’s another uncomfortable truth: smart people can be “right” about the bet being wrong and still be wrong about what to do next. If your manager is making a call under pressure, they might be choosing between two bad options. You can’t show up with “don’t do this” and expect the conversation to end there. You have to show that you understand the constraint they’re operating under, and you have to offer a path that still meets the goal.

That’s where the “trying to win” mindset shows up. Winning is not “my plan gets chosen.” Winning is “we hit the goal with the least risk and the least wasted time.”

If you want your disagreement to land, you need to tie it to the goal in plain language. I’ve watched disagreements die because they were framed as personal preferences dressed up as certainty. “This is the wrong design” rarely moves anyone. “This path makes it hard to pass the audit in six weeks because it adds a new failure point we can’t test in time” is a different conversation.

I also learned to be explicit about what would change my mind. That one habit shifts your posture from “I’m here to fight” to “I’m here to reason.” It’s a small thing, but it has a calming effect on the room. It signals you’re not trying to corner anyone. You’re trying to get to a better decision.

Then there’s the part nobody likes talking about: culture.

I used to believe that if you brought enough facts and stayed professional, you could change how an organization makes decisions. Over time, I got more cautious about that belief. Companies don’t run on logic alone. They run on incentives, history, and whatever behaviors leadership rewards when nobody is watching.

Some places really do value disagreement. You can challenge a plan, and the system treats it as a gift. In those places, dissent is a normal part of work. People argue hard, then they leave the meeting and get on with it. Nobody carries grudges, because the disagreement wasn’t personal.

Other places want agreement. They might say they value candor, but what they reward is alignment. The meeting is less about finding the best answer and more about showing you’re on the right side. If you treat that environment like a merit-based debate club, you’ll get burned. Not dramatically. Quietly. You’ll stop getting invited early. You’ll lose access to the real conversations. Your influence will shrink while you’re still telling yourself you’re being principled.

You can usually tell which culture you’re in by watching what happens to the last person who pushed back. Not what leadership said about them. What actually happened to their scope, their opportunities, and their reputation.

If you’re in a place where politics and appearance are the primary currency, you have a decision to make. You can play that game if you want. Some people are good at it and don’t mind it. If you hate it, don’t lie to yourself and think you’ll change it from the middle by sheer force of reason. You can improve how your team operates. You can protect your people. You can create a pocket of sanity. Changing the organization’s culture without being the one who runs it is a long, bruising road, and most of the time it ends with you exhausted and disappointed.

I’m not saying “quit at the first sign of politics.” Every company has politics. I’m saying: if the system consistently punishes healthy dissent, and that clashes with how you want to work, consider moving to a different team or a different company before you spend years grinding yourself down.

Assuming you’re in an environment where disagreement is possible, or at least tolerated, then you have to do the hard part well: disagree clearly, without making it personal, and without turning it into a public power struggle.

I’ve found that the timing matters as much as the content. Surprising your manager in a big meeting rarely goes well unless the culture is unusually direct. If you think the bet is wrong, bring it up early and privately first. Give them a chance to react without an audience. Some managers will still bulldoze you, but many will at least explain the constraint you’re missing. And when the disagreement goes public later, it won’t feel like an ambush.

When I’m preparing to disagree, I force myself to separate opinion from evidence. Opinion is allowed. Experience is allowed. Gut is allowed. But if all you bring is “I don’t like this,” you’re making your manager do all the work of defending the bet and all the work of inventing alternatives. That’s a losing dynamic.

What tends to work is bringing a small set of facts and one concrete alternative. Not five alternatives. Not a menu. One realistic option that still hits the goal, with trade-offs stated plainly. That keeps the conversation grounded. It gives your manager somewhere to go besides doubling down.

And then, once the decision is made, you commit.

This part is where a lot of people misunderstand what “commit” means. It doesn’t mean you pretend you love the decision. It doesn’t mean you stop noticing risk. It means you stop undermining the decision through sarcasm, passive resistance, or quiet “I told you so” energy. You put your effort into making the chosen path succeed, and you do it in a way that preserves the team’s trust.

One of the cleanest ways I’ve seen to make this real is to make the bet testable. If you’re committing, you want clarity on what success looks like and how you’ll know early if things are going sideways. If your organization doesn’t do that naturally, you can still do it yourself by writing down the assumptions you heard in the decision discussion. Not as a gotcha. As a record. Then you can check reality against those assumptions as the work unfolds.

This is also where data matters again. If you push back, then commit, and the bet starts failing, you need to be able to speak in facts, not frustration. “This is going badly” is emotional. “We expected vendor integration in two weeks and we’re at week four with no test environment and three unresolved contract questions” is concrete. Nobody has to agree with your interpretation to agree with the reality.

There’s a moment that separates high-trust leaders from everyone else: the moment the bet proves wrong.

If you’ve been the person raising concerns, you have two very human impulses at that moment. One is to spike the football. The other is to disappear and let someone else take the heat.

Both are poison.

When a bet fails, the best move is to be the first person to raise the flag calmly, with evidence, and with a next move that still serves the goal. You don’t do it to embarrass anyone. You do it because the longer the organization clings to a failing bet, the more expensive it gets, and the cost rarely lands on the person who made the call. It lands on the team doing the work and the customers living with the fallout.

I once watched a team spend an extra two months on a direction everybody privately knew was failing because nobody wanted to be the person who said it out loud. The work dragged. Morale dropped. The best engineer on the team started taking “dentist appointments” twice a week. When we finally called it, we weren’t relieved. We were tired and annoyed that we hadn’t done it earlier.

In a healthier situation, someone raises the flag early. They say, plainly, that the bet isn’t producing the results we expected, they show the signals, they connect it back to the goal, and they propose the next move. Then the organization moves on without turning it into a blame festival.

If you can be that person, your credibility goes up, even if you were the one who disagreed in the first place. People learn that your dissent is in service of outcomes, not ego.

There’s also a short window after a wrong bet where teams are willing to learn. It’s one of the few times you can change how decisions get made without a big fight, because the pain is fresh and nobody wants to repeat it. You can suggest writing down assumptions next time. You can suggest agreeing on early signals before committing. You can suggest smaller tests before large commitments. If you wait three months, the story will get rewritten, and the same habits will quietly return.

One more thing I’ve learned the hard way: when the bet is wrong, don’t treat it as proof that your manager is bad. Managers are people making calls with incomplete information, pressure from above, and constraints they might not fully share. If you want to keep working with them, separate the bet from the person. Call the bet wrong when the evidence says it’s wrong, and stay respectful. If you turn it into a character judgment, you’ll lock the relationship into a defensive posture, and everything after that gets harder.

Sometimes, even if you do all of this well, you end up with a clear answer that’s uncomfortable: your manager keeps making bets that don’t work, the culture keeps rewarding those bets, and your ability to influence the direction is limited. At that point the question is not “How do I win this argument?” It’s “Is this a place where I can do good work without becoming someone I don’t like?”

I’ve stayed too long in that situation before. I told myself I could outlast it, or that the next reorg would fix it, or that being the voice of reason was its own reward. What happened instead was that I started saving my best energy for outside the job, and that’s a slow way of admitting you’ve already left in your head.

If you’re there, moving out can be a quiet decision. It can be a team change. It can be a scope shift. It can be leaving the company. The mature part is seeing the system clearly and choosing accordingly, without making it a crusade.

When I think back to that Tuesday “Direction Check,” the ending wasn’t dramatic. I asked my manager for fifteen minutes after the meeting. I brought two pages of notes: what the goal was, what assumptions the new bet depended on, what data we had that supported those assumptions, and what data we didn’t have yet. I offered an alternative that still hit the milestone, with a smaller blast radius. We argued. We were both tense. Then we agreed on a simple checkpoint two weeks later where we’d look at a few signals and decide whether to continue or cut bait.

Two weeks later, the vendor still didn’t have an environment we could test against. The timeline was already sliding. We called it. We moved back to the boring plan. We shipped. The audit went fine. And the most valuable part was not that I “won.” It was that we made the bet testable, so reality could speak before the cost got too high.

That’s what I aim for now. When you think your manager is betting on the wrong thing, the goal isn’t to embarrass them or to protect your ego. It’s to raise the quality of the decision, commit once the call is made, and be the first person willing to say “we learned something” when the bet doesn’t work. Then you move to the next idea that still gets you to the goal.