Agency

Earlier in my career, I sat in on an interview debrief for a senior product engineer role. The candidate had nine years of experience, three of them at a large public company where he'd owned a significant chunk of their payments infrastructure. His system design was clean. He could talk about distributed systems tradeoffs for hours. The panel gave him strong marks across the board.

Then the "bar raiser" on the panel asked, "Has he ever shipped something from scratch?"

Silence. Nobody could point to a moment in the interview where he'd talked about going from a blank editor to something a user could touch. He'd maintained systems, scaled systems, improved systems. He'd never started one. After a follow-up conversation, the hiring manager passed. I understand the decision now—not as a verdict on the candidate's ability, but as a judgment about what this particular role required. It needed someone who could take a vague idea and turn it into something real in weeks, not someone whose experience was primarily improving an existing system over a quarter.

I've been thinking about why that decision feels so clear to me, especially as AI lowers the cost of implementation, and I keep coming back to a single word: agency.

What I mean by agency

I don't mean "self-starter." That word shows up on every resume and means nothing. I don't mean someone who raises their hand a lot in meetings, either.

Agency is the ability to hold the entire loop in your head, notice what it needs next, and act on it. What does the user actually need? What should this feel like to use? What's the fastest way to build it that isn't embarrassing? How do we know if it worked? A high-agency person can move through that whole sequence without waiting for someone else to hand them the next step.

Many engineers I've worked with are good at a few of those stages. They can build the thing if you tell them what to build. They can architect the system if someone else has already validated the idea. Agency is what you call it when someone can keep the full loop moving. They can talk to the user, sketch a solution, build a working version, and ship it on Friday with some lightweight instrumentation to see if anyone cares.

This doesn't require being world-class at any single piece. The code doesn't have to be the most beautiful. The design doesn't have to be pixel-perfect. What matters is that the whole thing reaches a user's hands, driven forward by someone's judgment rather than a sequence of handoffs. And that it gets there quickly.

Why I'd take agency over seniority right now

I want to be clear: I'm not saying seniority is bad, or that experienced people lack agency. Plenty of senior engineers are enormously high-agency, but seniority isn't a reliable proxy for agency. The argument I'm making is narrower. For product engineering teams, especially ones doing zero-to-one work, agency should be the primary filter. Seniority should be secondary.

Product engineering is a breadth game. The problems are rarely deep computer science problems. You're usually not being asked to invent a new consensus algorithm or optimize a query planner. The hard part is bringing everything together. Can you hold the user's needs, the design implications, the technical tradeoffs, and the business context in your head at the same time? Can you make a judgment call that accounts for all of them, and then go execute on it?

That's a breadth skill. In my experience, it comes more from shipping things end-to-end than from accumulating years of writing code.

Seniority used to be a reasonable proxy because building software required years of accumulated knowledge. You needed to know the platform, the frameworks, the deployment options, the failure modes. That knowledge took time to build. Today, some of that depth work is being compressed by AI tools. The person who can write a working implementation in a few hours with the help of an LLM, and who knows whether that implementation actually solves the user's problem, can be more valuable on a product team than someone who can write the same implementation from scratch but needs the next step defined for them every time.

This is especially true in the early stages of a product, when you're still figuring out whether you're building the right thing. Deep expertise in the stack isn't always what you need most. You need someone who can move fast across every part of the problem, learn what's not working, and adjust.

How to tell if someone is high-agency

I look for one thing above all else: has this person built something that exists because they chose to drive it? I don't mean merely "contributed to." I don't mean merely "was on the team." I mean: is there a thing in the world, used by real people, that this person noticed should exist and then helped drive into existence?

A side project that actual users downloaded. A feature at a previous company that they drove from idea to production with minimal oversight. An open source tool that solved a problem they personally had. The artifact matters more than the story they tell about it.

In interviews, I now pay attention to a few things:

When they describe past work, are they the protagonist or the narrator? There's a difference between "I built a notification system that reduced churn by 15%" and "I was part of the team that worked on notifications." Both might describe the same person, and language alone isn't proof, but agency tends to show up in how people explain their involvement. High-agency people talk about what they decided, what they traded off, what they got wrong. When someone had little ownership, the project often sounds as if it happened to them.

I also ask about decisions they made without being asked to. Not "tell me about a time you showed initiative," which is a question that produces rehearsed answers. Something more specific like "tell me about a time you built something that never would have gotten built otherwise." The answer tells you a lot. Some people light up because they do this constantly. Others struggle to find an example.

What high agency isn't

I want to draw some boundaries here because "high agency" can easily become a euphemism for "cowboy engineer who ignores everyone and pushes to production whatever they want."

Agency isn't about working alone. The most high-agency people I know are often excellent collaborators. They look at the usage data or talk to customers before they start building. They pull in a designer for a second opinion. They loop in teammates when the scope grows beyond what one person should own. The difference is they don't sit and wait for collaboration to come to them. They initiate it and keep moving.

Agency isn't recklessness. Shipping fast without understanding the problem is actually low-agency behavior. If you skip the "what does the user need" step and go straight to "let me build something," you're not demonstrating ownership of the full loop. You're demonstrating comfort with burning tokens and discomfort with ambiguity.

Agency isn't heroics. Pulling an all-nighter to hit a deadline isn't agency. Making the right decisions and communicating better two weeks earlier so that the all-nighter was never necessary is.

And agency isn't ignoring process. High-agency people aren't allergic to coordination, standups, or planning. They just don't treat the absence of those things as a reason to stop moving. If the process is there, they use it. If the process is bad (more on this later), they update it. If it's not there at all, they get stuff done anyway.

How to build more of it

I think agency is part disposition and part environment. You can develop it, but you need to put yourself in the right conditions.

The most direct path is to take responsibility for closing the whole loop. Side projects work well for this because there's no safety net. No PM is going to write the spec for your weekend app. No designer is going to hand you mockups. No engineer will code it for you. You have to notice every gap, even if you eventually ask others for help, because everything you skip becomes a gap the user feels. That experience rewires how you think about work even when you're back in a team environment with all the support structures around you.

At work, volunteer for the scrappy, undefined thing over the well-scoped ticket. The well-scoped ticket will teach you how to execute. The undefined thing will teach you how to decide what matters and what to execute on. Both skills matter, but most engineers get way more practice at the first one, and AI agents are getting increasingly good at it too.

If you're a manager, your job is to build an environment where agency is possible. Every approval gate you add, every review cycle you require for small changes, every meeting that exists to "align" rather than to decide ("bad process"), is friction against agency. Some of that friction is necessary. A lot of it isn't, and it accumulates until even your most high-agency people slow down to the speed of the lowest common denominator.

Look at how long it takes for someone on your team to go from having an idea to having it in front of a user. If the answer is measured in weeks for small, reversible changes, examine where the time goes. It should often be hours, and minutes for the smallest fixes.

Agency isn't enough

Agency gets you to the point where you can just do things. You can move through the full loop, from problem to product, without getting stuck. That ability is necessary and increasingly rare. I think teams should select for it more deliberately.

But agency alone isn't enough. Two equally high-agency engineers can ship two completely different versions of the same product. One will feel right and the other won't. Both products get the job done, but one will have that quality where users immediately understand it, where every interaction feels considered, where the whole thing hangs together. The other will work fine but feel like it was built by committee even if it wasn't.

The difference is taste. It's harder to define than agency, but just as important: agency determines whether you close the loop; taste determines what you make of it.