Hiring engineer number three when you can barely keep engineer number one from burning out
I posted a job listing for our third engineer while privately wondering if our first hire was about to quit. What I got wrong about workload distribution.
In mid-November 2024 I was sitting in a coffee shop drafting a job description for our third software engineer while simultaneously reading a Slack message from our first engineer, Raj, asking whether he could take a week off because he had not had a day off in two months. I told him of course, take the time. Then I stared at the job listing and wondered if I was solving the wrong problem.
This phase is where the title finally started to feel expensive. It also builds on what I learned earlier in “What Payload CMS 3.0 taught me about choosing frameworks that grow with you.” Hiring, planning, founder conversations, and bad weeks in production all piled into the same calendar. A lot of the systems thinking I kept in lifeos and flowscape showed up here too: clarity is not paperwork, it is how you stop uncertainty from leaking into people.
The Assumption That More People Fixes Everything
My instinct was that we needed more hands. The backlog was growing faster than we could ship. Feature requests from sales were stacking up. Bug reports were getting triaged but not fixed. Infrastructure improvements kept getting pushed to next sprint, which kept getting pushed to the sprint after that. The obvious answer was hire another engineer.
But Raj was not burned out because we were short-staffed. He was burned out because of how the work was distributed. He owned the entire reconciliation engine, the most complex and most critical part of our system. Every production incident in that area went to him. Every feature request for reconciliation went to him. Every question from compliance about how the matching algorithm worked went to him. He had become a single point of failure not because we planned it that way but because he was the one who built it and nobody else had the context to work on it safely.
Hiring a third engineer would not fix this. Even if the new person was brilliant, they would need months to ramp up on the reconciliation engine. In the meantime, Raj would still be the bottleneck, and now he would also be spending hours each week onboarding the new hire. More people can make a burning-out engineer burn out faster if you do not address the structural problem first.
What I Should Have Done First
Before posting that job listing, I should have done three things I was avoiding because they felt slower than hiring.
- Document the reconciliation engine architecture so someone besides Raj could understand it
- Break Raj’s monolithic ownership into smaller domains that could be handed off incrementally
- Rotate Raj off on-call for reconciliation incidents for two weeks to force the team to develop alternative knowledge paths
The documentation work was something Raj had been asking for time to do but I kept prioritizing feature work over it. The domain splitting required architectural decisions I had been deferring. The on-call rotation required me to personally handle reconciliation incidents during the transition, which I was subconsciously avoiding because that code scared me.
I was choosing to hire because hiring felt proactive. The real work felt uncomfortable. Writing documentation does not show up in sprint demos. Splitting ownership means admitting your current architecture has a bus factor of one. Handling incidents in unfamiliar code means being the one who stays up until 3 AM not knowing what went wrong.
How It Actually Played Out
I did end up hiring that third engineer, but not until January. The two months between November and January were spent on the structural work I had been avoiding. Raj spent a week documenting the reconciliation engine. I paired with him on three different subsystems to build my own understanding. We split the reconciliation domain into matching, reporting, and exception handling, and I took ownership of reporting.
By the time our third engineer started, there was actually an onboarding path. There were documents to read, smaller domains to take ownership of, and two people instead of one who could answer questions. The new hire was productive within three weeks instead of the three months it would have taken with the old structure.
The lesson was painful but clear: “we just need more people” is almost never the first thing you should fix. It is usually the second or third thing, after you have addressed the knowledge silos, the documentation gaps, and the ownership concentration that made the existing team feel understaffed in the first place.
Signs Your Team Needs Structure Before Headcount
- One person owns an entire critical subsystem and nobody else can work on it safely
- New engineers take more than a month to make their first meaningful contribution
- The most experienced engineers spend more time answering questions than writing code
- Production incidents always route to the same person regardless of who is on call
- Knowledge transfer happens through Slack messages and screen shares, not documentation
- The team says they need help but cannot describe what the new person would own
This is where the role stopped feeling like senior-engineer-plus. Every decision had a human system wrapped around it: founders, customers, auditors, tired teammates. The same systems thinking bled into lifeos and bisen-apps, where defaults matter more than heroics.
If you cannot write a clear ownership scope for the new role that does not overlap entirely with someone who is already overwhelmed, you are hiring a dependency, not a contributor.
Raj did take that week off in November. When he came back, I had already started the documentation sprint and had committed to pairing on reconciliation code three afternoons a week. He later told me that was the moment he decided to stay. Not the time off. Not the promise of a new hire. The fact that someone was finally taking the structural problem seriously instead of just throwing headcount at it.