The part you cannot hire

By ·

Two senior engineers. Costed, checkable, waiting for a signature. Salary, employer contributions, pension, a start date. It is a good page, and every number on it is true.

There is a point where two people knowing the system stops being enough. That is when the req gets written.

What it does not price is how long it takes to become useful here.

Not the onboarding. The part after it: learning what the system does, and then learning why. Which parts somebody chose, and which parts just ended up there. The code holds both and does not tell you which is which.

You can hire someone to go and find out. What you cannot hire is not having to.

Say it goes well. Say they are good, and they read it end to end, and they learn the business too, which is rarer than any of us admit. Eighteen months later they can tell you which is which, every time.

By then pricing has changed twice, you have opened a second country, and the part they cleaned up is not the part that matters now.

That is not a failure of the hire. It is what a moving business does to a system that has no way of telling you where it moved.

So you sign again.

I have been on the other side of that signature. I approved systems I could not read, and I was right to trust the people who built them, and I still never had a way to check.

Hiring buys time. It does not buy a system that can tell you where it moved.

That is what we built Ficus to do, and describing it is not how you show it. So: we ran ours against our own backend, and it came back red. It certified the layers it had measured, and it named the ones it had not. It is published, red and all. That is the only kind of green I would sign.

You would still write the req. The system would still move. What would stop repeating is the eighteen months — and the part where the answer walks out with the person who found it.