The Key to Burning Out
I’ve been thinking about burnout a lot lately, but not in the way it usually shows up in blog posts or performance reviews. It’s topical for me since I’ve been feeling the embers of burnout after many long nights this year building genuinely awesome software. And though burnout can arrive in many forms, I haven’t been thinking about it as exhaustion, or stress, or some personal failure to “manage energy” better. The more I watch engineers around me, the more it feels like burnout comes from something obscure. It shows up when you keep doing the same kind of thinking long after it stopped teaching you anything new.
This isn’t obvious while it’s happening. You are still shipping. You are still busy. You might even be doing objectively good work. The problem is that your role and your mind drift out of alignment, and no one really tells you when that happens. You just wake up one day feeling strangely disengaged from a job you are technically succeeding at.
A framework I’ve found useful for making sense of this comes from my friend Randall Koutnik, a former colleague and a genuinely thoughtful engineer. After a recent conversation with a mentor of mine at Handshake, the shape of it finally clicked. The framework is simple, and it maps less to titles than to how you spend your attention. The proposed framework for how you progress throughout your career is as follows:
- Implementer
- Solver
- Pathfinder
Each stage is valuable and teaches you something different. Each stage also contains its own very specific way to burn out. Let’s talk about it.
I’m going to talk a lot about engineering progression here, but this framework can be applied to any industry.
Implementer
Most engineers begin as implementers. You are handed a task that has already been scoped, discussed, and approved. Your job is to build the thing and ship the thing correctly.
This is where you learn how software actually works inside a real organization. You develop judgment about code quality. You learn the shape of the codebase and the invisible rules that govern how changes get made. You start working with product and design closely enough to understand why the first version of an idea is rarely the one that ships.
Your opinions exist here, but they are still forming. They tend to be local rather than systemic. You are learning the language before you start rearranging sentences.
There is a version of this role that can last a very long time. If you stay in it, you get faster. You memorize the system, the codebase, where the bodies are buried. You develop instincts that let you move through work with very little friction. At some companies, this alone is enough to earn a senior title.
Right now, this mode of work is also heavily amplified by AI tools like Claude Code or Cursor. Implementing has become easier to scale. You can execute more tickets, move faster through reviews, and keep the backlog moving with less effort than before. We’ll start to see Cloud Agents accelerate this even more in the next year or two. Indefatigable, faceless implementers are already starting to contribute to codebases. Backlogs everywhere rejoice.
The trap for us humans shows up quietly. You spend your days executing work that arrives fully formed. You get very good at delivering other people’s decisions. Over time, your critical thinking muscles stop being exercised. You are productive, but you are no longer learning how problems are chosen or framed.
Burnout at this stage usually looks like fatigue mixed with frustration. You feel busy all the time, but stagnant. You are doing a lot, and yet you have a growing sense that none of it is compounding. The work keeps coming, and you keep finishing it, and something feels off. Your next performance review comes around and you aren’t growing as quickly as you had hoped.
What is usually missing here is not effort. It is intentional growth, visible communication about what you are learning, and the slow accumulation of domain expertise that lets you move beyond execution.
Solver
At some point, the work changes. You stop being handed tasks and start being handed problems.
A solver is expected to figure out what should be built, not just how to build it. This does not mean you stop writing code. Many solvers still do a large portion of the implementation. The difference is that you now own the framing. You decide what tradeoffs matter and which constraints are real.
This is where engineering becomes much more about language. As Wittgenstein puts it, “philosophy is a battle against the bewitchment of our intelligence by means of language.” And most problems at this level are philosophical; they are about finding the “right” way of doing something when that something is poorly specified. They arrive wrapped in ambiguity, half-formed assumptions, and competing priorities. Making progress requires translating between technical reality and real intent.
You also start to feel a different kind of pressure. It is no longer just about how good you are. It becomes about whether people know you can solve hard problems and whether they trust you to do so outside your immediate area.
Randall says that there are two important figures in your career; it’s how “good” you are, and how many people know that you’re “good”. Don’t let yourself grow in the first category without practicing the second. Build in public, ask people for help, make sure people know you and your skills.
This is where domain expertise begins to matter in a deeper way. The more parts of the business you understand, the more leverage you have when solving problems. Solvers who stay narrowly focused tend to produce narrow solutions. Solvers who pull ideas from other domains often see options that others miss. Peter Kaufman describes this in his talk “The Multidisciplinary Approach to Thinking”. He references a Japanese proverb: “The frog in the well knows nothing of the mighty ocean.” You can know everything about your specialty and still make poor decisions if that is the only context you have. Kaufman talks about reading widely, even esoteric subjects (like nanoparticles), because that is often where the best ideas come from. Patterns repeat across domains, and insight often comes from seeing how something works somewhere else.
One of the most effective solvers I have worked with spent part of his earlier career as a journalist. His experience reviewing writing shaped how he evaluated product requirements for a specific feature we’re building at Handshake AI to review specs for human data projects. He noticed these unclear narratives and hidden assumptions faster than most. To most, it wouldn’t immediately click that being a good writer and being a good programmer both require being good at communicating solutions. In practice, it was a significant advantage, and part of why this engineer sits at the Staff level today.
Burnout at this stage feels different from the implementer phase. You are no longer bored. You are often trusted and relied upon. The issue is repetition. You spend months or years solving other people’s problems, often the same shape of problem over and over again. Eventually, the work stops stretching you.
This is also the point where many engineers are nudged toward management, sometimes explicitly and sometimes by default. That path works well for some people. For others, it feels like a lateral move away from the kind of thinking they enjoy. Personally, I would love to be a manager or a professor someday, where I can work with humans on their problems and help them improve. But for now, my focus is solely on becoming a stronger engineer and communicator.
What usually relieves burnout here is not being given less responsibility, which would likely hurt the situation more than it would help. It is the chance to choose problems instead of inheriting them; the freedom to synthesize across domains and propose work that did not already exist in the queue.
Pathfinder
Pathfinders operate in a different environment altogether. They are rarely handed tasks or even clearly defined problems. More often, they are handed ambiguity, organizational friction, or a vague sense that something is not working. I will also qualify this section’s content by saying that pathfinding is a skill I am actively working towards, and it’s something I can speak to moreso through observation rather than experience.
This is the staff and principal level, regardless of title. It’s a newly minted career path in the world of software engineering, and it looks different for every person. The work here happens at the level of systems, incentives, and long-term consequences. Pathfinders look for recurring failure modes across teams and processes. They spend a lot of time diagnosing before suggesting solutions.
A core responsibility here is diagnosis. Richard Rumelt describes good strategy as a combination of diagnosis, guiding principles, and coherent action. Will Larson adds an important constraint. Many strategies fail because they describe an ideal future instead of accurately describing the present. Good pathfinders do the uncomfortable work of naming reality before suggesting change.
They will go on to create artifacts that last longer than individual features. Strategy documents. Architectural direction. Shared mental models and schemas. Their impact often comes from enabling other teams to move faster or avoid repeating mistakes that are already understood. And as you can see, many of these are also language problems.
This role only works because of accumulated credibility. People trust pathfinders because they have seen them ship, solve, and make good calls over time. Without that trust, direction feels theoretical and easy to ignore. This credibility can be accumulated either within a company through tenure or through many different work experiences. In the end, what matters is that you’ve Seen Some Shit and can reliably steer your org away from trouble.
Burnout here tends to be subtle and existential. You live in constant ambiguity. Feedback loops are slow or unclear. Your best work often prevents problems from happening, which makes it hard to point to visible wins. Context switching becomes the default. You start to feel disconnected from the systems you are meant to guide.
Avoiding burnout at this level requires active boundary setting. You have to choose problems with leverage rather than accepting everything that feels important. You need to stay grounded in real technical constraints while resisting the pull to be constantly available. You measure success by organizational learning and outcomes rather than personal output.
Across all stages, burnout follows the same underlying pattern. It appears when you outgrow the kind of thinking your role demands, and you stay there anyway. We can always continue to push ourselves to close more tickets, to solve more problems, to write more strategy docs. But none if it matters if the net force you apply isn’t in the direction of the next level of thought.
Implementers burn out when execution is more important than learning. Solvers burn out when the problem selection is never theirs. Pathfinders burn out when ambiguity becomes constant and unbounded, and their work is never enough.
Hopefully, you can recognize yourself among these stages and grow into your next role with the right amount of effort. May you always burn brightly without burning out.