I built an app to get the knowledge out of my head

I was the single point of failure on my own team and I hadn't noticed. Which, I've since realised, is the defining feature of being one. Single points of failure don't feel like failure from the inside. They feel like being useful.

Here's what it looked like. Every time we needed to scope a new page request, someone would ask me. Not because there wasn't a process. There was a process, a perfectly reasonable one, written down and everything. But the logic behind how I broke a request down, what subtasks were needed, what the dependencies were, that lived in my head. Not in a document. Not in a tool. In my head.

And the system quietly organised itself around that fact. If I was on annual leave, things slowed down. If I was at capacity, things queued. The team was capable, genuinely capable, but the knowledge wasn't accessible. They didn't lack ability. They lacked access to a database that happened to be walking around inside my skull and occasionally going to Tenerife.

How to spot one (possibly in the mirror)

The diagnostic signs are easy to list and strangely hard to see when you're the subject:

The queue test. Does work stack up behind one person's availability even though other people could theoretically do it? That's not a workload problem. That's a knowledge problem wearing a workload costume.

The annual leave test. When a specific person is off, does a category of work slow down rather than just their work? Congratulations, you've located the SPOF.

The quick-question test. Count who receives the most "quick question" messages, and what those questions have in common. Mine were all variations on the same theme: how would you break this down? I was fielding them daily and interpreting the volume as evidence of my value. It was actually evidence of a missing system.

That last mistake is the one worth dwelling on, because it's the reason nobody fixes this. Being the person everyone asks feels like job security. It's flattering. It looks, from the inside, like being indispensable. But indispensable and bottleneck are the same fact described in two tones of voice, and the project doesn't care which word you prefer.

Why the process didn't save us

We had a process, so why didn't it help? Because processes capture steps, and the thing my team needed wasn't steps. It was judgement. A process document tells you what to do. It almost never tells you how someone decides. The sequence was written down; the reasoning that turned "vague client request" into "these seven subtasks, in this order, because of these dependencies" was not, because reasoning is exactly the part that's tedious to write down and easy to postpone forever.

That gap, between documented procedure and undocumented judgement, is where most single points of failure live. It's why they survive audits, handover documents and "we should really write this up" conversations. The steps are covered. The thinking isn't.

So I built an app

Nothing particularly complex. I used Lovable, a vibe-coding tool, to build a page request scoping app that captures the decision logic I'd been carrying around for years. You enter the page type, the parameters and the context, and it outputs a structured breakdown of the subtasks required, and why.

That "and why" is doing the heavy lifting. A list of subtasks would have been a checklist, and we already had checklists. The reasoning attached to each one is what turned it from a document into something closer to a colleague.

The first thing someone said when I showed it to the team was, "Oh, so that's how you think about it."

Exactly. That sentence was the actual deliverable. The app is just the container. What the team got wasn't software; it was access to a decision-making pattern that had been privately mine for years without any of us agreeing it should be.

And the honest, slightly uncomfortable footnote: building it took an afternoon. The knowledge had been locked in my head for years, causing queues and slowdowns the whole time, and the eventual cost of fixing it was one afternoon and a vibe-coding tool. The barrier was never effort. It was that I'd misfiled the problem under "how I add value" instead of under "risk".

Liability or asset: pick one

Knowledge in someone's head is a liability. Knowledge in a system is an asset. That's the whole lesson, and it reframes what I now think the PM job actually is. It isn't just to make good decisions. It's to make those decisions scalable, observable and independent of you being in the room. A brilliant decision-maker who has to personally make every decision hasn't built a capability. They've built a dependency with a salary.

If there's something your team regularly comes to you for that lives only in your head, that's worth fixing, and the fix is more available than it's ever been. It doesn't require a team of engineers. It might just require an afternoon and the right AI tool. Start with whatever generates your highest volume of quick questions, because that's your reasoning being requested on a loop, and a loop is just a system nobody's built yet.

So, the question I ended the original version of this with, and the one I'd still ask: what would you build to get the knowledge out of your head? Whatever your answer is, notice how quickly one came to mind. You already know where your bottleneck is. Most of us do. We're just enjoying being flattered by it.