Same talent. Different system.
2 engineers. Same talent. Different system.
Engineer 1 is buried in ops and support and fixed project deadlines.
A queue that never empties. A Friday deadline. Constant context switching.
He might be doing some of the most important work in the company.
But he has almost no opportunity to start anything that isn't already on fire.
Engineer 2 owns the whole project.
High autonomy. Multiple worktrees. Agents running in parallel.
The moment he notices an opportunity, he can explore it.
No planning meeting. No approval process. No waiting for next quarter.
He just starts building.
The interesting part is that these can be the same person.
The difference isn't talent. It's the system around them.
This isn't about commits, PRs, or lines of code. It's about long-term motivation, balance and productivity.
To me: Engineer 1 makes critical impact but could burn out from constant outside triggers and context switching — unless they like to be in such a framework. I've noticed that some engineers genuinely prefer it, because their cognitive load is narrower and focused on the (mostly) predefined tasks.
Engineer 2 has big freedom but takes many shots that fail. I expect them to enjoy the journey more — the sense of building something is stronger — although some find it hard to navigate and can get lost without product guidance.
The common thread: engineers are naturally drawn to creating things. The people who can act on what they notice stay engaged. The people who spend years only reacting to queues, tickets, and deadlines often don't — some leave, some disengage, some stop looking for opportunities altogether. That feeds directly back into productivity.
So every engineering organisation is setting two ceilings:
- How many meaningful experiments can happen.
- How motivated its builders remain over time.
Both are influenced more by the system than by raw talent.
Of course, neither extreme works.
- Unlimited exploration produces unfinished projects.
- Unlimited process prevents new ones from starting.
- Every company sits somewhere between those poles.
So: how many shots on goal can your engineers actually take? Was the balance designed between the two extremes for them? Did you decide it on purpose, by accident, or let the framework do it without realising?
I spend a lot of time thinking about these questions while building AI systems and working with engineering organisations on autonomy, engineering leverage, and AI adoption.
If this topic resonates, I'd be happy to compare notes: maros@marosjanco.com.