Back to Insights

The Job AI Never Sped Up

Your engineers ship twice as fast. Your meetings, backlogs, and 1:1s take exactly as long as they did two years ago. That gap has a name.

6 min readBy The Bushido Collective
Engineering LeadershipManagementAI StrategyOrganizational DesignFractional CTO
Share:LinkedInX
Ten engineers. Full AI stack, coding assistants, custom agents wired into every internal system, an AI suite bolted onto the wiki. The manager running that team watches the assistants shave real hours off the engineers’ week. Then he opens his own calendar. Meeting prep still takes as long as it did in 2024. Backlog grooming still takes as long. The incident review still eats an afternoon. He tried feeding the AI his meeting notes, his backlog, his postmortems. None of it stuck.

He’s not alone. A ten-person engineering manager posted the same complaint this week and it drew the kind of recognition that only shows up when a lot of people have been quietly wondering if it’s just them. Meeting prep, dead end, the tools lose every nuance about who’s in the room and why. Meeting summaries, dead end, no useful sense of what actually needs following up. Backlog prioritization, dead end. Incident root cause, dead end, cleaning up the AI’s version takes as long as writing it from scratch would have. Communication, dead end, and this one has teeth: the emails written by AI read as AI, and the people who send them anyway are the ones everyone in the thread quietly resents.

Contrast that with what’s happening one floor down. The same company’s engineers are shipping code at a pace that would have needed twice the headcount two years ago. The manager isn’t imagining the gap. His organization bought one tool and got two different results depending on which desk it landed on.

Two Kinds of Work, One Kind of Tool

Coding compresses because a pull request is, underneath the syntax, a closed problem. The requirements exist somewhere, even if they’re a half-finished ticket. The constraints are checkable: it compiles, it passes the test suite, it matches the pattern used three files over. An AI model trained on a few billion examples of exactly this kind of closed problem is going to be good at it, because the problem has an answer that doesn’t depend on who’s asking.

A 1:1 doesn’t have that shape. Neither does a backlog call, or the version of an incident review that actually changes how the team works afterward. The value of those isn’t in the document that gets produced. It’s in what happens after: whether the engineer walks out of the 1:1 believing the manager actually heard the thing they were nervous to say, whether the team trusts the prioritization enough to stop relitigating it in Slack, whether the postmortem lands as a real account of what went wrong instead of a document everyone signs to make the meeting end. None of that gets decided by the quality of the prose. It gets decided by whether the person on the other end trusts the person who wrote it, and trust isn’t a token in a context window. It has to be built, in person, over time, by someone who was actually there.

Call that half of the job second-order work: work whose value only exists once someone else acts on it, believing it, not just reading it. Coding is mostly first-order. The artifact does the job by itself; the test suite either passes or it doesn’t, and nobody’s trust is a precondition. Management is almost entirely second-order. The artifact, the summary, the prioritized backlog, the postmortem, is worthless the moment the reader senses it wasn’t really considered on their behalf. That’s why the AI-written email lands as slop. It’s not that the sentences are bad. It’s that the reader can tell nobody weighed their situation before hitting send, and the entire value of that email was supposed to be exactly that weighing.

Coding is mostly first-order work. Management is almost entirely second-order. AI compresses the first kind and can’t touch the second, because the second kind’s bottleneck was never typing speed.

This explains the manager’s specific list of failures better than a general complaint about AI limitations would. Meeting prep fails because the tool doesn’t know which two people in the room are quietly not speaking to each other. Backlog prioritization fails because the ranking isn’t really about the tickets, it’s about which stakeholder will escalate if their thing slips again, information that lives in the manager’s head and nowhere the model can read it. Incident reviews fail because the useful version names whose call created the gap and how the team changes as a result, and a model has no standing to make that call land. Every one of those tasks was never bottlenecked on drafting speed. It was bottlenecked on context and trust that only exist inside a relationship, and AI can generate a draft of the artifact without generating either.

The Flattening Bet

Some companies are trying a different fix: remove the desk instead of speeding it up. One widely shared survey of engineering org structures found Telnyx running two hundred engineers under a single VP and zero engineering managers, and smaller “AI-native” shops cutting product manager and QA roles on the theory that AI-abundant engineers can absorb the coordination work themselves.

That bet has a real chance of working for the parts of the job that were first-order to begin with, status updates, ticket breakdowns, spec drafts. It has no chance of working for the second-order half, because removing the manager doesn’t remove the need for someone to notice the two people who stopped talking, or to make a prioritization call stick without a title behind it. It just hands that work to engineers who weren’t hired for it, weren’t trained for it, and are already spending their newly-freed hours on more first-order output because that’s the half the org knows how to measure. The tax doesn’t disappear. It moves onto people with no slack built in to pay it.

Why This Is the Argument for Fractional, Not Against It

The honest reading of the manager’s post isn’t “AI failed at management.” It’s that his organization spent a year buying more first-order capacity and calling it a transformation, while the second-order work that actually determines whether the team functions sat exactly where it was, untouched, because no tool was ever going to touch it.

We built our engagement model around that distinction on purpose. The coaching lane isn’t a lighter version of the building lane, it’s the second-order half of the job, priced and staffed as its own thing rather than squeezed into whatever’s left of a manager’s week after the first-order work is done. You don’t buy more of it by buying more AI seats. You buy it by bringing in someone who’s spent the reps building the judgment and the standing to make a prioritization call stick, or a postmortem land, without needing six months to earn the room’s trust first.

If your team’s output chart is up and to the right while the meetings, the backlog fights, and the postmortems still feel exactly as heavy as they did two years ago, that’s not a tooling gap. It’s the second-order half of the job, still waiting for someone who can actually do it. Talk to us about where that person fits in your organization, or see how the lanes work on our services page.

Not ready to talk? Stay sharp anyway.

We send insights like this to technical leaders every week or two. The thinking we bring to our engagements, no fluff, no spam.

Keep reading

Share:LinkedInX