A Question That Gets Skipped
Walk into most design reviews and you will hear the same questions. Does it meet the requirement? Does it pass the test? Is it on schedule? Those are fair questions. But there is one I rarely hear anyone ask out loud: who has to live with this after we are gone?
Not “does it work.” Who has to operate it, fix it, or explain it to someone else five years from now, after the people who built it have moved to other programs.
I think that question matters more than almost any other, and I think we skip it because it does not fit neatly into a milestone chart.
Why This Gets Missed
Engineering schedules reward finishing. A design that closes out on time looks like a win. Nobody pulls money or praise for asking how painful the thing will be to sustain once it leaves the building.
So the incentive runs one direction: build it, prove it works, hand it off. The people who inherit it, operators, maintenance crews, the next engineer who has to troubleshoot it at 2 a.m., are rarely in the room when the key decisions get made.
I have sat in reviews where a part was chosen because it was cheaper or easier to source that quarter, with no one in the room who would ever have to replace it in the field. That is not a failure of talent. It is a failure of who gets asked, and when.
What Changes When You Ask It Early
When I bring up the sustainment question early in a design, it changes the conversation in a specific way. People stop optimizing only for “does this meet spec” and start asking “does this stay fixable.”
That shows up in small, unglamorous choices. Using a connector that a technician can reach without removing six other components. Writing a procedure that assumes the person reading it was not in the room when the system was designed. Choosing a sensor with a documented failure mode instead of one that is slightly more accurate but fails silently.
None of that shows up on a requirements matrix. All of it shows up eighteen months later, when something breaks and someone has to find out why without calling the original designer.
A Habit, Not a Rule
I do not think this needs a formal review step or a new checklist. Checklists get satisfied and forgotten. What works better, in my experience, is a habit: before a design gets locked, someone asks the question out loud, in the room, where it can shape a decision instead of showing up as a lesson learned afterward.
It is a simple habit. Who inherits this, and what do they need from us now so that inheriting it does not become a problem? Asking it once, early, costs almost nothing. Not asking it costs someone else a bad week, a year or two down the road.
Why It Is Easy to Forget
Part of the reason this question gets skipped is that the people doing the early design work are rarely the people who will operate the finished system. There is a gap between the team that builds and the team that lives with the result, and that gap is where the question falls through.
I have found the fix is not organizational, it is personal. I try to picture the specific person who will be stuck troubleshooting the thing I am designing, not an abstract “end user.” A real person, with a real level of patience, working with the documentation and tools they will actually have. That picture is more useful than any process document, because it makes the cost of skipping the question concrete instead of theoretical.
The Short Version
Most reviews ask whether something works. Fewer ask whether it keeps working, and fewer still ask what it takes from someone else to make that happen. I think that second question deserves a seat at the table from the start, not a mention after the first failure report comes in. It is a cheap question to ask early and an expensive one to answer late.