You Can't Simplify What You Can't See

Watch an engineer work on a single part for long enough and you'll see how reasonable decisions can lead to overengineering. Take a bracket on a jet engine, a small part, holding a length of sensor wiring in place against the engine's outer housing. The engine vibrates constantly, so a rib gets added to kill resonance. It sits close to the hot section, so mass gets added to handle the thermal load. The wiring needs slack for thermal growth, so a slot replaces the fixed hole. None of these are bad decisions. Each one, on its own, is completely defensible. And yet six months later the bracket is heavier, more expensive to machine, and harder to inspect than it needs to be, and nobody can point to the moment it went wrong, because there wasn't one. It was death by a hundred reasonable choices.

Here's the thing I keep coming back to: Complexity doesn't necessarily come from bad instincts. It comes from an incomplete picture.

If the only thing in front of you is the part, every feature you add looks justified, because it is justified locally. You're solving a real problem. What you can't see is whether that problem is actually yours to solve. Whether another component, three assemblies over, already handles it. Whether the "requirement" you're designing against is a symptom of a decision someone made upstream that never got questioned. Without the full assembly in view, you have no way to tell the difference between a feature that's necessary and a feature that's just absorbing someone else's unresolved problem.

So what does designing with simplicity mean? It's not about cutting features for the sake of it. It means starting from the right question. Not "What could this part do?" but "What's left for it to do?" That's a smaller question, because most of what a part could plausibly take on has already been handled by another part nearby. Once you can name the problem that's actually unclaimed, you can look at ways to solve it. Usually, there are only a few.

The catch is that this only works if you can clearly see the fundamentals. And seeing the fundamentals requires seeing the whole assembly.

No part solves the assembly's problem alone. Each one works in tandem :) with the others, and its design has to reflect that: not just what the part does, but what it's doing alongside everything else.

Zoom out to the full jet engine assembly and the bracket's story changes. Maybe the vibration at that location is already an order of magnitude lower than assumed, because there's a damper two components upstream doing exactly that job. Maybe the thermal load is already being managed by a shield the bracket sits behind, so the extra mass is solving a problem that doesn't reach this part. Maybe the slack built in for thermal growth is redundant with a flex joint elsewhere in the line. None of that is visible from inside the part. All of it is visible from the vantage point of the assembly.

So, the real question is: “What is this bracket's job in the context of everything around it?” Surviving the jet engine on its own was never the ask, but you can only get to that real question if you can see the rest of the engine. Otherwise, you default to over-designing for a set of conditions that's already spoken for.

And this isn’t a discipline problem, either. Engineers don’t lack the instinct for simplicity; most good engineers want the simple version. What they usually lack is live access to all the information that would let that instinct act: the requirements sitting one level up, the constraints that were decided in a meeting six weeks ago, the reason a tolerance was tightened that one time and was never loosened back. That context exists. It's just not in front of them. It's in someone's head, an old thread, a review nobody wrote down. So, the simplicity instinct gets starved of the one thing it needs to fire: perspective.

This is a visibility problem dressed up as a design problem. Give someone the full assembly (the actual requirements, the actual rationale, the actual shape of the thing they're contributing to) and simplicity stops being a discipline you have to force yourself into. It becomes the obvious move, because the alternative, tunnel vision on your one part, is the move that takes more effort to justify.

But that's rare. Most people never get handed the full assembly. They get handed a part file and a deadline, and they're expected to make good calls without the context that would make those calls obvious.

The engineers I've watched do this well aren't doing anything mystical. They're just constantly zooming out… or they've been responsible for the entire assembly from concept to production. They have access to the bigger picture, and they understand it well. And yes, you can have one brilliant engineer take over your entire project (solving your knowledge-layer gap single-handedly) but at the risk of slowing progress or suppressing diversity of opinion. But this can be done well on a team, too. There just needs to be a web of constraints, requirements, and goals that remain visible to everyone. Not one hero holding the whole assembly in their head, but each engineer working off the same picture. With this, design stops depending on who happens to be in the room and becomes a well-oiled machine, because nobody's working blind anymore. The simplicity was there all along. It just needed somewhere to be seen from.

-Army