Two Operating Modes

I did not set out to run a company. I set out to build software, and then the software needed a company around it, and then the company needed someone to run it, and the room was empty.

Nobody warns you that these are two different modes of thinking, and that you will be expected to switch between them several times a day.

Mode one: the engineer

The engineer’s instinct is to find the correct answer.

Not a good answer. The correct one. There is a right data model, a right boundary, a right failure mode. Ambiguity is a bug in the requirements, and the fix is more information.

This instinct is excellent. It is why systems stay up. It is also why an engineer, handed a business question, will try to gather enough information to make the answer obvious — and will keep gathering, because the answer is never going to become obvious.

Mode two: the operator

Business problems do not have correct answers. They have decisions with different failure modes.

Should we take this customer? Should we hold this much inventory? Should we hire now or in three months? There is no test suite. You will not find out whether you were right for a year, and by then six other variables will have moved, so you will never be able to attribute it cleanly anyway.

The engineer’s response to this is to want more data. The operator’s response is to ask a different question: if this is wrong, how bad is it, and can we find out cheaply?

That reframing was the single most useful thing I learned. It is the business version of “make it observable.”

What actually transfers

The good news is that most engineering instincts survive the switch, if you translate them.

Systems thinking transfers completely. A company is a system with queues, bottlenecks, and feedback loops. If you have debugged a distributed system, you already have the right intuitions for why a team is slow. The bottleneck is rarely where people are complaining.

Interfaces transfer. A badly defined responsibility between two teams behaves exactly like a badly defined API between two services: everything looks fine until load arrives, and then nobody owns the failure.

Observability transfers. “We think sales are fine” is console.log debugging for a business.

Reversibility transfers. Engineers already sort changes into “easy to roll back” and “not”. That is the most valuable prioritisation tool in business and almost nobody outside engineering frames it that way.

What does not transfer

Determinism. The same input does not produce the same output, because the input includes people.

Refactoring. You cannot pause a company to clean up its architecture. Every restructure ships to production while it is running, with no staging environment and no rollback.

Edge cases. In a codebase, edge cases are finite and you can enumerate them. In a company they are generated continuously by reality, and reality is not going to stop to let you handle them. Companies have considerably more edge cases than codebases.

Switching

The honest part: I do not switch modes cleanly.

I have caught myself in a supplier negotiation thinking about retry semantics, and in an architecture review thinking about unit economics. Sometimes that cross-wiring is exactly the useful thing. Sometimes it means I have spent forty minutes optimising something that does not matter.

Mode switching is automatic and occasionally unstable. I have stopped trying to fix that and started treating it as the actual job.