Sebastian Teh

Open to conversations · UK

Operational diagnosis

Operations don't break loudly.

They break in the gap between two people who each assumed the other had it. I find those gaps, draw the system underneath and build what closes them.

Start a conversation

Unresolved

The work is not building the system. It is seeing the one already there.

  1. Every business already runs on a system. It is usually undocumented, held between a few people and visible to nobody.
  2. So I start by drawing it. Who knows what. Where work waits. What nobody owns.
  3. Then it can be built on. Automate before that and you just make the mess faster.

001 / Diagnosis

What I
look for

Three questions. All of them asked before anyone mentions a tool.

What nobody can see

Most operational failure is not incompetence. It is information that exists somewhere, in someone's inbox or head or spreadsheet, and never reaches the person who needed it to decide.

The first question is never which tool to use. It is what should be visible, to whom and at what moment. Answer that and most of the software chooses itself.

Where it stops being anyone's job

Every messy operation has a seam: the point where one person assumes another has it, and nobody does. Work falls through the seam quietly and is usually found by a customer.

Automation does not fix an accountability gap. It industrialises it. So the seam gets named first. Only then does anything get built across it.

What should trigger what

A system is mostly a set of answers to one question, asked repeatedly: when this happens, what should happen next and who needs to approve it?

Written down, that question is an operating model. Left unwritten it is tribal knowledge and it walks out of the building at five o’clock.

002 / Background

I came to this through operations, not software.

Revenue operations first, then chief of staff. The job underneath was always the same. Find where information, ownership and decisions were breaking down, then build something around the failure.

The tools have changed a lot since. n8n, AI and small pieces of custom software make the building quicker than it has ever been. Knowing what to build is still the hard part.

003 / A worked example, on myself

I built an operating system for my own admin.

Email, calendars, documents, commitments and follow-ups, running as one system. Each kind of information has a single home. Agents draft, file and reconcile. Anything they should not decide alone waits in a queue for me.

It is not a product and I am not selling it. It is the clearest way I have of showing how I think about an operation: what should be visible, what should trigger what and where a person still has to say yes.

Four rules it runs on

  • 01Sources of authorityOne per kind of information. Never two.
  • 02Human approvalAnything outbound stops and waits.
  • 03FailureArrives as a message. Never a silent log.
  • 04RecoveryHeld work stays on disk until it is replayed.

004 / Open to conversations

If something in your operation keeps going wrong, describe it to me.

No pitch and no proposal on a first conversation. I would rather understand the problem properly and tell you honestly if it is not one I should take.

Or write to me directly

seb@sebteh.com

0 / 3 traced

Goes to my inbox by way of Web3Forms. This site stores nothing.