High Agency in Software: What Makes an Engineer Truly Valuable

1

I recently read George Mack’s essay High Agency, and it made me think about how differently people approach problems at work, especially in software and startups.

In software, the hard part is often not writing the code. It’s everything around it. Requirements are incomplete, documentation is outdated, nobody is completely sure why a system behaves the way it does, and sometimes even the problem itself is poorly defined.

This is where agency becomes valuable.

Imagine an engineer gets a message saying, “Checkout is broken for some users.” One response is to wait for a proper ticket, reproduction steps, expected behavior, and someone to clarify whether the issue belongs to frontend or backend. Another response is to start digging. Which users are affected? When did it start? Can we reproduce it? Did something recently change? Is the problem actually in the frontend, or is the UI only where the problem becomes visible?

The second person is not necessarily a better programmer. They just treat ambiguity differently.

To me, high agency in software means taking responsibility for moving a problem forward even when the path is not clearly defined. It doesn’t mean doing everything yourself or ignoring other people’s responsibilities. It means not treating every missing piece of information as a reason to stop.

There is a big difference between saying, “Backend doesn’t support this,” and asking, “Backend doesn’t support this, so what are our options?” Maybe the backend can change. Maybe the requirement can change. Maybe there is another API. Maybe the product does not actually need the thing we originally thought it needed.

The important part is continuing the thought process instead of stopping at the first constraint.

I think the best engineers do this constantly. They reduce uncertainty.

“Users say the page is slow” becomes “most of the delay comes from this API request.”

“This flow feels confusing” becomes “users are dropping at this specific decision point.”

“We can’t build this” becomes “we can’t build it under these two assumptions, but if we change one of them, we have three possible approaches.”

That ability is extremely valuable in startups because startups are basically uncertainty machines. The product changes, priorities change, people change, technical decisions made six months ago suddenly stop making sense, and there usually isn’t enough time to create perfect processes around everything.

A startup therefore needs people who can keep moving when the instructions run out.

This is also why I don’t think high agency should be confused with working harder or longer. It is not about staying online until 2 AM or trying to become the hero who solves everything alone.

Sometimes the most high-agency thing you can do is ask someone for help. But there is a difference between saying, “I’m blocked, what should I do?” and saying, “I tried these two approaches, here is what I found, I think the issue is here, and I need your context on this specific part.”

One transfers the problem. The other moves it forward.

Managers also have a role in this. Companies often say they want ownership, but then create environments where every decision requires approval. If people get punished every time they make a reasonable decision without asking first, they eventually learn to wait.

You can’t ask people to behave like owners while treating them like task executors.

The best environments I’ve worked in or observed give people the context behind the work. What are we trying to achieve? Why does it matter? What are the real constraints? Once those things are clear, the exact path does not always need to be prescribed.

That gives engineers room to think.

Since reading High Agency, there is one question I’ve started to like:

If nobody was coming to solve this for me, what would I do next?

It does not mean nobody should help you. It just forces you to notice when you are waiting unnecessarily.

Maybe the next step is reading the source code. Maybe it is sending a message to a customer. Maybe it is building a small prototype. Maybe it is asking a much better question. Maybe it is realizing that the thing you thought was a blocker is not actually a blocker at all.

Software changes quickly. Frameworks change, tools change, companies change, and the problems we work on change.

Because of that, I think one of the most durable skills an engineer can have is being comfortable saying:

“I don’t know yet, but I can figure out what to do next.”

That is what high agency means to me in software.

Inspired by George Mack’s essay, “High Agency.”