A Student Published a Failure. Six Engineers Showed Up.
Some people read books to be entertained. Some go to movies. I get entertained by thinking out solutions. That is the whole hobby. It has been for fifty years, and it is why I stopped scrolling last week.
A note before I start. I post on LinkedIn, but I am first and always a reader there. Most of what I know about what engineers are actually doing right now, I learned from people who posted it before I asked. This piece came from one of them.
The number
A student opened a post by telling everyone his thrust vector controller ran 43 percent slower when it moved under load.
That is not a triumphant sentence. It is not a sentence anybody writes to look good. It is a measurement, offered flat, and it was the first thing in the post.
Braxton Herold is trying to land a model rocket on its own thrust. A recent static fire gave him three numbers he needed: how far the gimbal can move, how fast it moves, and how long it takes to start moving. Authority, slew rate, latency. He wanted them to tune his software-in-the-loop simulation. What he got instead was an explanation for why the previous week’s flight had failed.
Braxton Herold’s Thrust Controller. Images captured from LinkedIn
The chain
Read the next part as an accident report, because that is what it is.
Through a series of conversion and scaling errors, his TVC system was producing roughly 60 percent of its intended control authority. Take that alone and it is survivable. Reduced margin, not lost margin. The vehicle would have flown.
Then he removed the landing legs for that test.
Mass came down. Velocity went up. Aerodynamic instability rose with the velocity. Near the end of the burn, the aerodynamic moment finally exceeded the restoring moment the degraded TVC system could still produce, and the rocket began to tumble.
Nothing broke. No component failed. A configuration change that nobody re-analyzed moved the vehicle into a regime where the remaining margin was no longer sufficient — and the margin had already been quietly spent by errors upstream that were individually tolerable.
I have spent eight years writing that same paragraph for attorneys, about aircraft, with different nouns. It is the most common accident architecture there is: several small deficiencies, each defensible on its own, and one change of configuration that pushes the stack into a corner where the reserve is gone. The student named it himself. He wrote that the failure was not one catastrophic problem but the interaction of several small errors that only surfaced when the vehicle entered a regime the available control authority could not cover.
He is right, and most working engineers I know would not have written it that cleanly.
What came back
Here is the part that made me sit up.
Within about a day, the comment section had assembled a design review panel.
An aerospace and quality engineer asked what the vector was responding to — accelerometer, altitude, waypoint navigation — and then told him to stay with the small motors and scale up later. A mechanical engineer flagged the center of mass as looking tail-heavy and told him to get it as far toward the nose as possible. An intern at Woodward asked whether his software loop accounts for thrust-to-weight ratio changing during the burn, from both propellant mass loss and grain geometry. Another mechanical engineer told him which Estes booster variant to use and to put an eighth of an inch of five-minute epoxy over the motor to keep the burn from ending energetically. Someone else told him brushless servos exist.
Add up the experience in that thread and you are well past a century. None of it was billed. None of it required an introduction, a referral, a conference badge, or a job offer. It arrived because a nineteen-year-old published a problem with numbers attached.
And it kept arriving because of what he did next. He answered every single one of them, specifically, with data. He explained he plans per-batch static thrust curve characterizations to fit the descent motor curve. He explained he measured servo latency frame by frame off video, using a buzzer as the command timestamp, and called the method a little sketchy but adequate for the purpose — which is exactly the right judgment about measurement, made without a lab. And when the brushless servo comment came in, his answer was ”I didn’t know those were a thing.”
That sentence is the price of admission, and it is the one most engineers will not pay.
The rule
Publishing a finished result is a closed post. Humbly seeking help is the ask that opens the door.
Nobody can help with an accomplishment. There is nothing to grab. The only move available to a reader is applause, and applause is the crowd talking to you. Everybody wants to help with a stated, quantified problem — because now there is a handle, and the reader can join instead of watch.
Run the counterfactual. Same rocket, same photo, same day, and the caption reads successful static fire. He collects the likes and he learns nothing. The epoxy trick stays in a stranger’s head in another state. The TWR question never gets asked. The tail-heavy call never gets made, and it costs him the next flight instead of this one.
A win gets applause. An unfinished effort gets company.
Leave room for the improvements
There is a timing rule underneath the openness rule, and it is the one that keeps you out of the corner.
Feedback has a shelf life, and the clock is set by how many degrees of freedom you have left. Braxton got the CG correction, the servo advice, and the motor sealing technique while all three were still actionable. Post the identical failure analysis after the vehicle is built, flown, filmed, and finished, and every one of those comments becomes trivia. The comments do not change. Their value does, because the room to use them is gone.
The corner you paint yourself into is rarely built out of bad decisions. It is built out of reasonable ones that quietly consumed all the remaining space.
Which is the same thing his rocket did. The scaling errors were tolerable. Pulling the legs was reasonable for a static test. Neither one was the failure. Spending the margin before knowing what it would be needed for was the failure.
So: design margin and editorial openness are the same discipline pointed in different directions. Reserve room deliberately, and know the date it closes. He does — there is a static-margin module coming in a few weeks that will roughly double the vehicle’s length and move the parachute mass away from the center of gravity. He is collecting input against a known freeze point, not drifting.
Thirty years of asking
Do not be embarrassed to ask in order to learn. I asked, every working day, for more than thirty years.
It did not get easier. It got harder. A student asking questions is expected, and nothing is at stake. Asking after the title, after the license, after sixty-two patents, in a room where everyone assumes you already know — that is when the ask costs something, because it is also an admission. That is the version worth defending, and it is the one that quietly stops happening to most engineers right around the time they become senior enough to be embarrassed.
Braxton found in his teens the thing it took me a career to keep doing. I am not holding him up as an example for young engineers. I am holding him up as a correction for the rest of us.
The part I do not know
This piece would fail its own rule if I ended it closed, so here is my open problem, and I would like the help.
The mechanism works beautifully for a student. Nobody loses status by teaching a nineteen-year-old, and nobody suspects a motive. I do not know whether it survives seniority. When a principal engineer with grey hair publishes a real unsolved problem under his own name, does the same panel show up — or does the room read it as decline, and go quiet out of politeness?
I have a guess. I would rather have your evidence.
Tell me about a time you asked publicly, late in your career, and it worked. Or the time it did not. I am collecting the data before I decide whether to spend the margin.
Braxton Herold’s original post and the full comment thread are on LinkedIn. Go read the comments. That is where the engineering is.
Herbert Roberts, P.E. — 30+ years in aviation R&D across two companies. 8+ years analyzing accidents for attorneys under my P.E. license.