Operations

Keeping the company running has brought me work well beyond engineering: shared records, handovers, controls, payroll and other recurring administration. I knew I was signing up for that breadth and was happy to take it on. I am still working out how to make the recurring work dependable and easier to hand over. Technical infrastructure, such as service templates, configuration, observability and release tooling, has its own post: The Engineering Foundations I Want in Place Early.

At my first startup, a lot of context travelled across a small office. We knew why something had been built because we had been there when the decision was made. As the company grew from six people to more than four hundred, that stopped being a reasonable expectation of a new colleague. I came to care much more about what they could understand without finding one of the early employees. Building that documentation habit earlier is one of the things I wanted to do differently this time.

Where knowledge lives

Each kind of record should have one home, and it should be the place where the people who maintain it already work. Two copies of the same information drift apart, and nobody trusts either.

The test I use for any document is whether someone other than the author can act on it. That applies to a runbook, a decision record and a goal description alike.

How I do it now

GitHub holds delivery work and its status: projects, milestones, goals and the pull requests.
Notion holds durable product context, decisions, our handbook and the pages for each meeting.
The repository holds architecture decision records and runbooks, as plain Markdown. A change to one is reviewed like a change to code.
A dashboard I built brings the first two together for stand-up.

How the Notion workspace itself is laid out, area by area, is in Compliance.

We arrived at the GitHub and Notion split after keeping plans in Notion while the engineering work happened in GitHub. We were maintaining a picture of the work in one place and doing it in another. The engineers already spent their day in GitHub, so the delivery plan moved there and product documentation stayed where it was.

What belongs in a useful document

We also made a different documentation mistake. Starting from our prototype, we used AI to help describe the product in detail. The documents grew until they were difficult to read. Writing more had become easy while the product itself still had unanswered questions.

I now want the main decision near the top, followed by the reasoning someone needs to question or change it. The author has to distinguish what we have agreed from what we are assuming. If a customer requirement is still unclear, a polished explanation cannot turn it into a decision.

Before sharing a document, I should be able to explain every recommendation in it, including the parts AI helped produce. Then I need to read it as the next person: can they tell what to do, what remains open and where to ask? Editing out repetition is part of the work. So is leaving the technical detail that prevents someone from making a dangerous assumption.

For a decision that changes another person's work, I would leave the decision, its reason, who made it and the affected work together. When it changes, I would mark the old answer as superseded and point to the new one. A second explanation in a chat should link back to that record. Otherwise we recreate the same uncertainty in two places.

No single point of failure

If only one person can do something, the company stops when they are away. The fix is usually a written procedure that someone else has followed at least once.

How I do it now

A new service starts from a template with logging, health checks and telemetry already in place, so operating it does not depend on who created it.
Runbooks live next to the decision records. The check I want is that another engineer has tried the instructions without the author's local setup or memory of the last incident.
An Owner arranges any handover needed to keep a goal moving while they are away.
For my own recurring tasks, I write the instructions down so an assistant or a colleague can run them.

The UK company administration described in Beginnings still sits with me.

A handover needs a second person who can use it

A handover needs to transfer access, context and authority along with the task. The other person also needs time to take it on.

Without a product manager, product responsibilities still need named owners among the founders.

Start with the critical roles, the knowledge they hold and what someone else would need to learn to take them on. In a small company, I would work through those responsibilities directly with the people involved.

For each responsibility that cannot wait for its owner to return, I would identify a second person, establish the access they need, and have them perform it with the owner available to help. The remaining questions become improvements to the handover. Reading a runbook is useful preparation; following it exposes the steps the author forgot they knew.

That exercise belongs across the company. A service recovery procedure and a recurring administrative task need different expertise, but either can depend on one person's memory. I can reduce that dependency only if I make room for the second person to learn. Writing instructions while keeping every execution for myself would leave most of the risk in place.

The numbers we look at

The records we keep also shape what we can measure. A metric is an observation. It has several possible explanations, and the useful step is deciding what to inspect next. I keep per-person numbers out of team documents, because ranking people by an incomplete dataset starts a conversation about who looks busy. More in Measuring Agile Teams Without Weaponizing the Numbers.

How I do it now

A small service computes DORA metrics from GitHub deployments and our incident records. In one thirty-day snapshot it recorded 586 deployments across 22 repositories. Deployment frequency is the only figure I would quote so far. The failure and recovery figures need most incident records connected to the releases they relate to, and we have not done that yet.

In another thirty-day stretch we merged 854 pull requests. That number told me our review process was under strain. It did not tell me how many features we shipped or how much of the code AI wrote.

When I pulled a month of data, most merged pull requests did not close an issue. That showed me how we recorded work, and nothing about who was contributing.

Before adding a number to a regular review, I want to know which decision it might change and whether the underlying records can support that decision. With our deployment data, the next useful work is connecting incidents to releases. A more elaborate chart would still be reporting the same incomplete history.

The same discipline applies to product analytics. Installing the tool does not choose which customer behaviour matters or explain why it changed. That question sits with the people setting the product direction, including me, and remains unfinished in our setup.

Compliance

Write a control only when you can show it. Every sentence in a policy creates work someone has to do, and a plan written in the present tense misleads whoever reads it.

How I do it now

We build for finance and pursued SOC 2 and ISO 27001 in our first year. Three rules came out of it.

When I write a control, I want to be able to open the repository, run the procedure or show the record that backs it up. If I cannot, it goes on the work list.
If a control claims more than the evidence covers, we either implement it properly or retire the claim and explain how we address the risk.
Evidence has to be readable by the person checking it. We now export our corrective-action records.

We also removed a sampled post-merge review from a draft procedure, because we were not going to carry it out every month.

I had already seen at my first startup how much work customers could need before buying an AI product. They wanted the capabilities and still had questions about bias, audits and how to assess the product responsibly. We spent time on questionnaires and independent bias audits while their buying process took its course. That experience makes me want the evidence available early, in a form the customer can understand. It also reminds me that finishing engineering work does not finish the customer's decision. I wrote about that in Allow time for customers to get comfortable buying.

The inventory of what we ended up with is in Compliance: the policies, the procedures, the recurring processes and the registers that hold the evidence, laid out as checklists.

Recurring work outside engineering

Setting up the UK entity brought payroll, VAT returns, a pension provider, health insurance and an office onto my desk. I had not done those jobs in my earlier engineering role. The work needed doing, and I was the founder in the UK. That explains how it became mine; it does not tell me how it should be owned indefinitely.

In one fortnight, that work included an intercompany invoice, payroll, a VAT return, a forecast of how long our cloud credits would last and a vendor's data-processing terms.

For a recurring task, I want a record of when it comes due, where the inputs come from, who can prepare or authorise it, and where completion is recorded. I already write instructions for tasks an assistant or colleague can run. The next useful check is whether they can follow those instructions with the access and context available to them.

Some decisions need specialist advice; writing a procedure does not make me qualified to make them. I want the handover to identify who to ask and which decisions remain with the responsible founder or specialist. I still need to document the actual recurring calendar and handovers. The story of how these jobs arrived is in Nobody Handed Me a Manual.

As the company grows

In a startup, the person who remembers a decision may still be in every meeting. As more people join, I would make ownership, decision boundaries and access instructions explicit enough for a new colleague to use without that person. The first check would be whether someone can find the current answer and act on it. More documentation is useful only if it reduces the context people have to reconstruct privately.

Still to write

The recurring UK administration calendar, access arrangements and completed handovers.
Vendors: choosing them and reviewing their terms.
Product metrics. We have analytics in place, and I do not yet have a set of numbers I would run the company on.
Access: who can reach what, and how that is reviewed.