It's 3 a.m., your wife wakes you up and mumbles something about your phone. It was ringing, but you were too exhausted to hear it. It's Simon, your best engineer, calling to ask you to jump on the incident call. He sounds exhausted too.
There was another production incident that was caught by your overseas customers. The good news is that Simon and the team were able to pinpoint the problem. They disabled the feature and have a good idea on how to patch it in the morning. "Amazing work guys, get some sleep" is forced out of your mouth as you reach desperately to press the 'Leave call' button.
The next day you start rooting through the incident data and conversations. Why did this happen and why were our customers catching this issue instead of our systems? You pull Simon into a call, and tell him you want him to be candid. You don't have time or patience left to beat around the bush. He tells you Dave, one of your front-end developers, must have missed testing the feature fully because the test plan was not filled out when he looked this morning. You thank Simon for this information and leave the call. How could Dave have missed something like this?
His manager has mentioned that he hasn't been pushing as hard as normal, but Dave has always pushed to make sure he and his team complete the system testing. The team loves Dave. He has grown a lot and even joins incident calls to help put out the fires. So, you invite Dave for a coffee and a chat. He has already heard that the incident last night was due to the feature his team pushed out last week. When he arrives, you can see that Dave isn't his normal self. The Dave you know always asks about your weekend and proceeds to dump his thoughts about his newest theory on why President Trump is ruining the world.
Today, he is quiet, soberingly quiet. You ask him how he is doing, and he turns to stare off for a few seconds before answering. You can see the frustration in his jawline. He turns back and says "I can't do this anymore". Your gut drops, you've been here before and you immediately recognize this as a resignation conversation. You stay professional and give Dave the space to speak, but he doesn't give you a lot of substance. At the end, it's almost as if you can see his shoulders sitting higher, like by finally resigning, a physical weight has been lifted off his shoulders. You thank Dave for his service and resign yourself to your office.
You didn't get the answer from Dave as to why he is leaving. But you expected that. Now, you are desperate to figure out what led to this. You weren't planning to fire Dave because of the incident. The team has been attending to a lot of incidents. Maybe testing is the problem! We have been forcing testing to bend under pressure to hit our commitments on feature delivery. Maybe, we need to take a step back, and take some extra time on testing. We should probably build that new test suite the team has been pushing for. It's not a full plan, but you know what to do tomorrow. You put together a job description to find someone to replace Dave, build a revised roadmap with more time for testing, and draft emails to key customers to let them know that delays in upcoming features are expected. In your mind, your engineering practices just need a little modification. Change the testing process, add a few automated test cases, and increase the estimated effort buffer, and you'll soon be overcoming all of these obstacles.
Honestly, it's a good plan. It's what you might expect any good engineering leader to do. A new test suite, more buffer, backfill the role, and warn the customers of delays. Reasonable and responsible.
But it won't fix the problem. None of it touches what actually broke.
Dave wasn't the failure. The failure was treating Dave like a box in your engineering pipeline's flow chart. For months your system had been drifting from where you envisioned and planned it would be. Testing was being foregone to appease velocity demands. Commitments were made without deep review of estimations. The voices who raised concerns were noted and set aside. You even noticed that you "have been forcing testing to bend under pressure" for a while. Every time a new engineering gap came up, you treated it like a process problem. For which, you implemented a process solution. What you failed to realize is that Dave was standing in the gap holding the whole thing together. Dave didn't stop pushing. The failures of your engineering model just pushed past the load that Dave could bear. His body knew long before your dashboards did, which is why his shoulders raised when he finally let go.
Engineers can't be treated as components in a linear workflow. They are the most complex and non-linear systems involved in your engineering pipeline. Read that again. They are systems within your system, not just another component. No amount of training, performance management, or bonus incentives is going to linearize them for best use in your engineering model. You should be very fortunate to have good engineers, as they absorb so much of the failures of your model.
This isn't a story about a missed test. This is a story about how we engineer. We take the most complex non-linear piece of the puzzle and expect it to fit nicely into our linear engineering model. We expect it to scale, recover, and absorb linearly. If I just request twice as much testing from Dave, he will produce twice as much testing. No, Dave was at capacity before the request, has a daughter who is sick, and is going through a divorce. In this equation, two times the test effort equals Dave finding a new engineering team. One who understands this principle.
But you might think, maybe this is a good thing. We'll just replace Dave's work with some AI agents. It seems to be the expectation in the industry, right? Wrong. You will just be replacing one complex non-linear system with another, and with one that is not nearly as versatile, caring and robust as Dave was.
None of this makes you a bad leader. It makes you a leader using the only model anyone ever handed you, a linear one. The problem is that we live in a nonlinear world. Every organization you've worked in ran on the same assumption. That's why this is so expensive. It's invisible and it's everywhere. It's the standard.
But here's what changes the moment you see it. The engineers absorbing your model's failures aren't a liability, they're your most important detection mechanism. Dave was reporting that the system was unstable and drifting for months before that 3 a.m. call. You just had no way to read him. Learn to read the nonlinear signals in your pipeline, and you won't just stop losing your best people, you'll get the earliest signals that your model needs to change.
Before you post that job description, look at your team. Somewhere on that team, another Dave is standing in a gap, holding the system together. The only question that matters is whether you'll read the signal and adapt before he sets the weight down for good.