The quiet trap of doing two engineering jobs at once, and why your company quietly hopes you never notice.
Our engineering team was small enough that I was the only person who knew why we built the system the way we did. I was also the person building it. Every sprint, I was writing tickets and closing them. Running architecture reviews and shipping the features they described. Debugging production issues while also being the one responsible for the decisions that caused them.
Nobody called this a problem. The work got done. The product moved forward. In a small team, that’s the only metric that feels real.
It took me a while to see that “the work gets done” was exactly the issue.
The Two Jobs That Cannot Share a Brain
The technical lead role and the senior engineer role are not just different in scope. They require incompatible modes of attention.
Leading architecture means holding a mental model of the whole system across weeks and months. You need to think about what the API contract will cost you in eighteen months when the product pivots. You need to notice that the caching strategy that works at 1,000 users will become a maintenance crisis at 100,000. This kind of thinking requires extended, uninterrupted blocks of time. Not two hours, but half a day. Minimum.
Writing production code requires a different kind of focus entirely. You are implementing a specific decision within specific constraints. The goal is to move the ticket from “in progress” to “done” without introducing new failure modes. The scope is narrow by design.
Paul Graham wrote about this in 2009. He called them the maker’s schedule and the manager’s schedule. Makers need half-day blocks or nothing useful gets done. A single meeting can ruin an afternoon by splitting it into two pieces that are each too small for real work. (The manager schedule runs on one-hour units. The manager doesn’t feel this the same way.)
Most technical leads who also code are running both schedules simultaneously. Not alternating between them in a planned way. Simultaneously. Every context switch between “architect” mode and “engineer” mode costs more than the task itself. Research from the University of California, Irvine found it takes an average of 23 minutes to fully regain focus after an interruption. When you’re context-switching between two fundamentally different types of thinking multiple times a day, the math gets ugly fast.
The Invisible Subsidy
Here’s the part nobody in your company will ever say out loud.
When you fill both roles, you remove the pressure that would normally force a hiring decision. The pain that should be visible gets absorbed. Invisibly. By you. The architectural drift from decisions made in the gaps between tickets. The mentoring that never happens because you’re always shipping. The technical debt that accumulates in the code you wrote while also thinking about the roadmap.
From your company’s perspective, things are fine. The product ships. The architecture holds. The engineer who “understands the whole system” is still showing up every day.
There’s no forcing function.
In a larger engineering organization, the technical lead who never has time to do architecture work properly becomes visible quickly. There are other engineers watching. There is a manager whose job is to notice when a lead is burning out or when system decisions are getting made ad hoc. Those signals reach leadership and eventually force a conversation about headcount or structure.
In a small team, the signals are yours to notice. And if you’re the one responsible for both the work and the oversight of the work, you are the last person to see clearly what’s happening.
What Suffers First
It’s not the code quality. You’ve been writing code long enough that the code holds up, even under pressure.
What suffers first is the architectural thinking that should be happening before the code gets written.
Real architecture decisions (the ones that shape a system for the next two years) don’t happen during sprint planning. They happen in quiet time. In the space where you’re not context-switching between three conversations and a pull request review. When you’re also the person shipping features, that quiet time disappears. Decisions that needed three hours of uninterrupted thinking get made in the fifteen minutes before a standup.
Those decisions accumulate. Not as obvious bugs or immediate failures. As a system that works fine under current conditions but is structurally fragile under conditions you haven’t hit yet.
The second thing that suffers is mentoring. Not because you don’t want to do it. Because when you’re already covering two full-time jobs, every hour spent bringing a junior engineer up to speed is an hour that doesn’t exist anywhere. You help them when they’re blocking. You review their PRs when the queue gets long. You don’t have the capacity to do the slower, harder work of making them systematically better.
After two or three years of this, you have a team where everyone can execute on defined tasks and nobody except you can design the next one. Which is, to be clear, the kind of thing that only becomes a crisis the moment you need to go on leave or consider leaving the company.
That’s not a team. That’s a dependency.
The Career Trap
There’s a personal cost that compounds alongside the organizational one.
When you consistently fill both roles, you become known for something specific: handling whatever needs handling. That reputation feels good. It is good in some ways. It means people trust you, the work gets done, and you are visibly useful.
But “visibly useful” and “ready for the next level” are not the same thing.
Senior engineering leadership roles (staff engineer, principal engineer, VP Engineering) require demonstrating impact through multiplication. Not through direct contribution, but through making other engineers and systems better. If you spend three years as the person who handled everything directly, your demonstrated skill is execution. Your demonstrated leadership experience is thin.
The companies that would give you a senior leadership role want evidence that you multiplied the output of an engineering team, not that you were the team’s most reliable individual contributor.
Being good at both roles simultaneously, paradoxically, can make you look like neither.
What Actually Changed
I started treating architecture time as a separate workstream that I protected the same way I protected a critical production system. It went on the calendar with explicit blocks. It didn’t move for sprint meetings. Other engineers knew that during those blocks I was not available for pair programming or ad-hoc debugging.
This felt selfish for the first two weeks. Then the code review comments I was leaving started getting more specific. The technical decisions I was making started going further than the current sprint. The junior engineers on the team started getting substantive feedback instead of quick approvals.
The second thing I changed was borrowed from Paul Graham directly. I stopped making myself available for pair programming on demand and started holding two scheduled office hours per week instead. Engineers who needed help knew when to come. I could group context switches instead of having them arrive randomly throughout the day.
Neither of these changes required organizational approval or new headcount. They required acknowledging that doing both jobs poorly was not the same as doing both jobs.
The architectural debt from the years before didn’t disappear immediately. It probably took another year to fully surface and address. But the rate of accumulation stopped.
The Thing Worth Knowing
If you are in a small team and you are both the technical lead and the most productive engineer, your company is getting a good deal. You may not be.
That’s not a reason to leave or to resent the situation. It’s information. The question worth asking is whether the work you’re doing right now is building the kind of experience that moves your career where you want it to go. The context-switching, the ad-hoc decisions, the heroic coverage. Or whether it’s building a very specific set of muscles that are highly valued inside one particular team and not particularly transferable anywhere else.
The code will still get written without you doing all of it. The architecture will not design itself. Those are different problems. Treating them as the same one is where the cost starts.
