The Thing You Built Stopped Fitting You

For founders and senior leaders: you built it well, it fit for a while, and then the requirements changed. The original misalignment is rarely what breaks you. The patches you stack on top of it are.

By Peter Plötner. Aerospace engineer and Wayfinder Life Coach. More about Peter →

The Boeing 737 was designed in the 1960s to sit low to the ground, so ground crews without fancy equipment could load it by hand. That single early requirement shaped the whole airframe. Sixty years later, that same low stance is part of what led to two crashes and 346 deaths.

Nothing was wrong with the original design. It was right for what it was built to do. The problem came when the requirements changed and the design could not change with them as cleanly as everyone wanted.

If you have built a company, or a career, or a senior role, you may already feel where this is going, even before I get to the part about your life. So let me stay with the aircraft first, because the engineering is worth understanding on its own.

What actually happened

The 737 needed new engines. Modern, high-bypass, far more fuel efficient. But those engines are physically bigger, and the 737 sits too low to fit them in the old position under the wing. So Boeing mounted them larger, higher, and further forward.

That changed the aerodynamics. At a high angle of attack, the bigger engine housings, now sitting forward and high, begin to act like extra wing surface and generate lift ahead of the center of lift. The nose tends to rise on its own. The aircraft no longer handled like the 737 pilots already knew, in one narrow part of the flight envelope.

Boeing's answer was a system called MCAS. When it sensed a high angle of attack, it would automatically push the nose back down. As a concept, this is a completely legitimate piece of engineering. You compensate for a known characteristic. Aircraft do this in many ways. Adding a compensating system was not the mistake.

Here is where it went wrong, and it is worth being precise, because there is never a single cause. The first version of MCAS only triggered when two independent things agreed, a high angle of attack and a high G-force, and it could only move the tail a little. That was judged non-critical, so it did not need redundancy. Then testing showed the problem also appeared at low speed, where there is no high G-force. So they removed that second trigger. Now MCAS fired on a single angle-of-attack sensor. They also increased how far it could move the tail, by a factor of five. And the safety assessment that had called it non-critical was not re-run against the more powerful version. The warning light that told pilots the two sensors disagreed was an optional paid extra. And the pilots were not told the system existed at all.

Take any one of those links out of the chain and everyone lives. The requirement changed. The compensation was added. Its authority grew. Its redundancy shrank to a single point. The safety case was not re-examined. The people relying on it were not informed. Each step, on its own, was survivable. Stacked together, they were not.

That is the part most people miss when they tell this story as “they should have just redesigned the plane instead of patching it in software.” The patch was not the failure. The failure was adding a patch and not giving it the honesty and the redundancy that its growing authority demanded.

The same thing happens to people

Now the part you saw coming.

You build something. A company, a career, an identity. You build it well, and it fits, for a while. Then the requirements change. Sometimes the world changes them. Sometimes you change. The company gets big enough that the job you loved no longer exists inside it. The career that fit the person you were at thirty does not fit the person you are at forty-five. The thing you built stopped fitting you.

And here is what capable people tend to do, the same thing Boeing did, because it is genuinely the reasonable-looking move. We compensate. We bolt on a system. The founder who has outgrown running the company hires a COO to handle the parts that no longer fit. The leader adds structure, adds process, adds a layer. None of that is wrong. Often it is exactly right. Plenty of founders correctly decide to step back to CTO, or to sell at a certain size, rather than force themselves to keep being the CEO the company now needs. That is good engineering applied to a life.

The danger is the same as the aircraft's. We add the compensation and then quietly let its authority grow without adding the safeguards that new authority requires. We give the new arrangement more power over our life than we ever consciously scoped. We do not re-examine whether the thing we patched is still safe now that it has changed. And we do not tell the people who depend on us that anything changed at all. The original misalignment is rarely what breaks us. The unexamined chain of patches we stack on top of it, without honesty or redundancy, is.

I have done this

I will tell you when mine cracked, and I can smile about it now, because at the time I had no idea what was happening.

By the time I was at university, I had become the person who loved to learn. Genuinely loved it. It did not even matter what the subject was, if it was engineering, I wanted to understand it. That requirement, learn everything you can, ran my entire education beautifully. It got me a long way.

Then I spent six months volunteering in Honduras, where I saw what an actual problem looks like, and I came back changed without quite knowing it. A few months into my PhD that started right after, something quietly stopped working. The lectures that used to thrill me felt empty. I would sit there and think, what is the point of this. Theory for its own sake had lost its grip on me completely, and Honduras was a large part of why. I did not have words for it then. I just felt the strange, low wrongness of doing something I was good at and no longer wanted.

What had happened was simple, in hindsight. My requirements had changed. “Learn for the sake of learning” had quietly been replaced by “do something that has real impact in the world and aligns with who I am.” Same person. Completely different spec. And the life I had carefully built to satisfy the old requirement did not fit the new one at all.

For a long time I treated it as a personal failing. Why am I not grateful. Why can I not just be happy doing this prestigious thing. That framing is a trap, and it is the most important thing I want you to take from this. As long as you think the problem is you, you keep trying to fix yourself, and you keep treating symptoms. The moment you see it as a requirements problem, something changes. You can stop beating yourself up, and start working on the actual thing.

Changing one requirement changes everything downstream

There is one more piece of engineering worth borrowing, and it is the reason this matters so much.

In any complex system, requirements are not independent. They sit at the top, and everything below is derived from them. Change one requirement late in the process and the change does not stay put. It propagates. Every subsystem that was built to reference the old requirement now has to be reconsidered. This is exactly why late requirement changes are so expensive in engineering, and why people resist making them.

It works the same way in a life, which is both the warning and the good news. When I finally accepted that my requirement had changed, it did not stay neatly in the box marked “career.” It propagated. It pushed me toward aerospace, toward flying things to space, which is one of the few things that satisfied both “real impact” and “pays the bills.” It pushed me, eventually, toward coaching. It changed how I spend my evenings, what I read, how I think about my own children's learning. One requirement changed at the top, and it is still trickling down through every part of my life years later.

That is what makes questioning your requirements feel so dangerous, and why people avoid it. On some level you know that if you change the spec at the top, you do not get to keep everything below it exactly as it was. The change will propagate. That is precisely why it is worth doing, and precisely why it is worth doing on purpose, with your eyes open, rather than letting a chain of unexamined patches do it to you by accident.

Try this week

Here is something I have noticed, and I am curious whether it lands for you.

When you do not have much money, your requirements are answered for you. You do things out of survival, and survival is a clear, loud spec. It chooses for you.

When you have enough, that outside voice goes quiet. And then you are left with the harder question, the one a lot of successful people quietly avoid, which is, what do I actually require of my life, now that nothing is forcing the answer. People with more than enough still work, still build, still strive, because doing nothing does not satisfy any real requirement. But if they have never consciously chosen the spec, the life can feel subtly, persistently wrong, and they cannot say why.

So, whatever your situation: what requirement is your life currently optimized for? Who chose it, you, or a version of you that no longer exists, or someone else entirely? And if it has quietly changed, what are you still trying to patch instead of re-specify?

I would love to hear where this shows up for the people who build things.

Frequently asked questions

What does “the thing you built stopped fitting you” mean?

You build something, a company, a career, an identity, and it fits the person you were when you built it. Then the requirements change. The world changes them, or you do. The company outgrows the job you loved; the career that fit you at thirty does not fit you at forty-five. The thing itself is not broken. It is just solving for a spec that is no longer yours.

Isn't adding structure or hiring help the right move when you outgrow something?

Often, yes. Stepping back to CTO, hiring a COO, selling at a certain size, all of that can be good engineering applied to a life. Compensation is not the mistake. The danger is letting the compensation's authority grow without the safeguards new authority requires: giving the new arrangement more power over your life than you ever consciously scoped, never re-checking whether it is still right, and not telling the people who depend on you that anything changed.

How is a “requirements problem” different from just being ungrateful or burned out?

Treating it as a personal failing (why am I not grateful, why can I not just be happy doing this prestigious thing) is a trap, because as long as you think the problem is you, you keep trying to fix yourself and keep treating symptoms. Seeing it as a requirements problem moves the work to the actual thing: the spec your life is solving for has changed, and the life built for the old spec no longer fits. That is fixable. Self-blame is not.

Why does changing one requirement feel so disruptive?

Because requirements are not independent. They sit at the top and everything below is derived from them, so changing one late does not stay put, it propagates. Every part built to reference the old requirement has to be reconsidered. That is why late requirement changes are expensive in engineering and why people avoid them in life. It is also exactly why it is worth doing on purpose, with eyes open, rather than letting a chain of unexamined patches do it to you by accident.

I have more than enough and the life still feels subtly wrong. Why?

When money is tight, survival is a loud, clear spec that answers your requirements for you. When you have enough, that outside voice goes quiet, and you are left with the harder question most successful people avoid: what do I actually require of my life now that nothing is forcing the answer? If you have never consciously chosen the spec, the life can feel persistently wrong without an obvious cause. The fix is to choose the requirement on purpose.

Questioning the requirement, instead of patching the life built for the old one, is the whole method. The full five-step version is in Stop Optimizing Your Life. Start Specifying It. And the requirements you never chose in the first place, the ones you inherited, are the subject of Don't Build an SLS. If you want a place to start, the Essential Self Diagnostic is fifteen questions that take about sixty seconds, a quick read on which parts of your life are still solving for a spec you have outgrown.