Driver, Not Doer

Across pipeline after pipeline, the same profile keeps arriving at the senior stage: technically competent, credible on paper, fluent in the stack, and entirely unable to point at a problem they owned rather than a task they completed. Ask what they built and the answer is confident. Ask why it was built that way and the room gets quiet.

These are not weak engineers. Most of them are good at the thing they were trained to be good at. They have spent their careers inside well-scaffolded teams, where a lead broke the work down, wrote the ticket, drew the boundary, and handed over something already decided. They filled in the code, and they filled it in well. Nobody ever asked them to make the call, so they never built the muscle, and now the interview is the first time anyone has.

The tell is almost always the same. Accomplishments get listed rather than reasoned through. "I built the payments service" arrives as a credential rather than a story. Push once and you get a slightly longer version of the same sentence. Push twice and you find out whether there was a decision underneath it or whether they were downstream of one.

I want to be careful here, because this is a systemic outcome rather than a character flaw. We spent fifteen years optimizing engineering organizations to break work into small, unambiguous, independently shippable units. It worked. It also manufactured a generation of extremely capable executors and then removed most of the situations where they could learn to decide.

Here is the uncomfortable part, and I would rather say it directly than let people discover it during a layoff.

"I can do that" was a strong claim when doing it was hard. Implementation was the constraint, so being fast and reliable at implementation was a career. That constraint is gone. A well-directed agent will take a clearly specified task and produce a clean, tested, documented implementation of it, at a cost that does not resemble a salary. If your professional identity is "hand me a spec and I will execute it," you have described the part of the job that got automated first, and you have described it accurately.

Notice what an agent cannot do. It cannot decide the thing is worth building. It cannot tell you the requirement is incoherent, or that the real problem is two teams disagreeing about who owns a boundary. It cannot weigh a two-year maintenance cost against a two-week deadline, because it does not carry the consequence. It cannot walk into ambiguity and come back with a defensible position, and it certainly cannot own the outcome when the position turns out to be wrong.

Every one of those is a driver behavior. So the scarce and appreciating skill is judgment: deciding what to build, deciding how to architect it, and owning the result when it does not go to plan. Everything below that line is getting commoditized on a schedule nobody controls.

If you read the section above and recognized yourself, that is useful information rather than a verdict. Driving is a set of habits, not a personality type, and every one of them can be practiced inside your current job without waiting for a promotion or permission.

• Ask what problem the ticket is solving before you start it. Not to be difficult. Because roughly one ticket in five is a proposed solution to a problem that has a better solution, and you cannot see that from inside the implementation.
• Write the decision down before you write the code. A short paragraph naming what you are building, what you are deliberately not building, and what you are trading away. This single habit converts more executors into drivers than any training program I have seen.
• Volunteer for the ambiguous work. The vague, under-scoped, slightly political project that nobody wants is the only place ownership is actually available. Clean tickets are where do-ers are made, because someone else already did the hard part.
• Use agents for the doing so you can spend your attention on the deciding. Direct the tool, review its output critically, and refuse to merge anything you could not defend in a design conversation. Delegating implementation is leverage. Delegating judgment is how you become optional.
• Disagree in public, with a reason. Once. On something that matters. Being the person who says "I think this is the wrong boundary and here is why" is worth more than six months of flawless ticket closure, and it is remembered far longer.
• Stay attached after the merge. Watch what your change does in production. Drivers know how their decisions aged, and that feedback loop is the only way judgment is ever built.

The engineers I have watched grow fastest are not the ones who could do the most. They are the ones who kept quietly moving upstream, toward the place where the decision gets made, until one day they were the person making it.