Nothing That Sank That Project Was an Engineering Problem

A project you worked on came in six months late.

You know the one. Pick whichever it was. Now do the thing you were probably never given time to do properly, which is walk it backwards.

The slip showed up in integration. Integration went badly because two subsystems had been built against different readings of the same requirement. The requirement was ambiguous, and it was ambiguous because it had been written by someone summarising a conversation nobody minuted. It went through review, and review passed it, because review was six people who had each read it that morning. The person who would have caught it was the one who had built the previous version of that interface, and they had moved teams in March, and the handover was a folder.

Keep going and you eventually reach a decision that was made in a corridor.

Now the question. Of all the causes on that chain, how many were engineering?

The layer engineers throw away

None of it was technical. And when engineers describe what they know, that entire chain gets classified as something else — process, communication, politics, project management. Overhead. The stuff that gets in the way of the work.

That classification is doing enormous damage to your assessment of your own value.

The technical knowledge you are proud of has two problems as an asset. It is documented — there is a specification, a manual, a reference, a paper — so anyone determined can go and get it. And it is narrow, because it belongs to a particular domain, toolchain, and generation of practice.

The layer you discarded has neither problem. It is not documented anywhere. It is not narrow. And it is what actually determines whether a project lands.

Why nobody can look it up

Here is the structural reason it stays scarce, and engineers resist it, because engineers assume anything real can be written down.

You cannot write the procedure before you have run the process. Every attempt produces a document that is either generic enough to be useless or specific to a situation that never recurs. The knowledge is empirical. It comes from having watched the same failure arrive from four different directions and finally seeing what the four had in common.

I have watched people try to shortcut this in business — writing the full operating manual before launch, which is about the least useful thing you can do, because you do not know how the thing runs until you have run it. The procedures worth having are the ones you write down after you have done the task enough times to know which step is the one everybody gets wrong.

Your process knowledge is that, accumulated across fifteen years and never once written down.

Which means the engineer six years behind you cannot obtain it. Not from a book, not from a certification, not from a search. They can only obtain it by being near someone who has it, for years, and getting lucky about who that someone is.

What that is worth to them

Be concrete about who is hurting.

The engineer who has just been made technical lead and is discovering that the job is nothing they have practiced. The one who owns a design review for the first time and does not know what a review is supposed to catch. The one moving from a mature domain into a new one, where their instincts are calibrated for the wrong failure modes. The one who has been asked to estimate and has never been taught how estimates actually go wrong.

Every one of those people has a specific, expensive problem, and their employer has usually decided it is not a training problem because it does not look like a skills gap on paper.

And notice what none of them is asking for. Nobody needs another explanation of the technical fundamentals. That is exactly the course an engineer's instinct produces, and it goes straight up against the entire documented record of the field.

What to build

One problem. One kind of person. Something that goes wrong repeatedly and expensively.

The strongest material you have is the autopsy — the failure walked backwards, in full, with the decisions named and the alternative at each branch. Not a list of principles. Principles are free and nobody applies them. The walk-back is the thing, because it teaches the shape of the failure rather than the moral of it, and shape is what transfers.

Two constraints worth stating. Change the identifying details of anything you did not build yourself; you are teaching a pattern, not publishing an employer's history. And say plainly which parts of this are judgment calls where reasonable engineers differ — an audience of engineers will respect that far more than confidence, and will notice immediately if you fake it.

The part that makes this awkward

You will resist all of this, because the process layer does not feel like the thing you are good at. You went into engineering for the technical work. The process material is what you had to learn in order to keep doing the technical work at scale, and some of it you learned resentfully.

That is precisely why it is worth something. You did not choose to acquire it. It cost you projects to get. And it is sitting in your head, in a category labeled "not really engineering," where you have never once considered selling it.

Six months late. Nothing on that chain was an engineering problem. You worked out why, and nobody has ever asked you to write it down.