I was Head of Operations for eight weeks at an AI startup going from eleven to forty people. I am writing down what I found, what I did, and what I would do differently.
Two reasons. First, the kind of startup I describe moves very fast and almost every operations function is born in worse conditions. Second, eight weeks is too small a sample to draw conclusions from, and saying so is part of the story.
What I found
Nine people in the company, none in operations. In other words: the functions existed, but nobody was looking at them. Every operational decision went up to the founder and came back out as a decision.
The thing that struck me, and which I have found in every startup since: people were more capable than the organisation admitted. The work was there, and it was good. What was missing was the layer above.
The risk in a situation like that is not that things go badly. It is that they go well for as long as the right person is there, and nobody finds out in time.
What I did in the first two weeks
I wrote down who decided what. One page, not a process. For each recurring decision: who makes it, within what time, and what happens if it never arrives. It came to twelve rows and removed half the escalations.
I measured two numbers. Cycle time from request to delivery, and time to restore when something broke. They had never measured either, so they had never improved either. The second was worse than they feared.
I removed a meeting. The weekly alignment, which had become the place where things already written got repeated. I replaced it with a written update. Nobody complained, and the time went back to whoever should have had it.
The four weeks in the middle
These were the hard ones, because the organisation was changing faster than the process was.
Four things I learned, which I would expect anyone in this position to see.
New people have no process to follow. They arrive and work out what to do from whoever sits near them. In a startup growing by ten people a month, for some weeks you have more new people than procedures. That is normal and it needs managing; it is not a failure.
The bottleneck moves every week. I cleared the code review queue and two weeks later it had moved to the staging environments. You do not "solve the problem": you manage the current one, and accept that the next one will be different.
Every decision you do not write down is a decision that will be made again. That is the hidden cost of growth, and nobody sees it until it happens twice.
The founder stops being the bottleneck only if you tell him. The moment decisions route through him stops being normal and becomes the bottleneck. If nobody says it, the bottleneck stays and shows up as "we do not have time".
What I would do differently
Three things, in order of impact.
I would write the numbers down before I arrived. I wasted two weeks measuring, and those two weeks were spent doing work I could have delegated. I could have asked three people for three data points and started with the baseline already done.
I would have spoken to the non-founders first. I spent my first week with the people who decide, which is the wrong half of the organisation. The people who knew where things jammed were the others.
I would have written less. I produced four process documents that nobody opened. What worked was the one-row-per-decision sheet. Four pages of procedure, zero readers. A table of twelve rows, two meetings saved a week.
On the sample size
Eight weeks is not enough to judge an organisation, and it is certainly not enough to judge a person who in those weeks did work nobody had done before in that company.
What stays with me: in a department that does not exist, the first job is not to build processes. It is to stop the founder being the pass-through for every decision, and then to measure two numbers. The rest is execution, and anyone can execute, well or badly.
What cannot be delegated, and in those eight weeks made the difference, is saying the uncomfortable thing in the right meeting.