If you played PlayStation 2 online in the UK in the early 2000s — if you plugged in that chunky broadband adapter and connected to a lobby for Twisted Metal or SOCOM — you were using something I built. I say that not to be grandiose but because it represents something I've spent the last twenty years trying to understand: the gap between designing well and shipping well.

The role was network architect for PS2's UK infrastructure, around 2000. The broadband adapter was coming. Someone had to design the network. I was in my late twenties, had been playing games since childhood, and suddenly I had diagrams and real Sony hardware and the task of making online PlayStation work across the British patchwork of ADSL coverage.

The technical work I loved. The design was clean. The UK's fragmented broadband situation — BT's uneven rollout, cable in certain cities, the need to gracefully degrade for connections that were barely functional — that was an interesting constraint. I thought about authentication, matchmaking, load balancing, the whole stack. I tested it. I would have used it myself.

And then something broke. Not the technology. The organisation.

Corporate dysfunction has a particular texture. It's not usually malicious. It's more like a cascade of locally rational decisions, each one protecting someone's position, collectively maddening. Priorities shifted. Work I'd designed got handed to different teams to implement in different ways. More meetings. Deliverables blurred. I spent more time explaining my own architecture to people brought in to second-guess it than I spent building.

There was a colleague — I'll call him Dave — who caught something worse than politics. At some point management decided he'd been accessing accounts on the platform that weren't his. The accusation was never clearly articulated, which should have been obvious signal. Dave went through weeks of formal process. He was cleared eventually, but the mark never went away. He left not long after.

Here's what I learned from watching that happen: **access logs without context are noise.** Dave had been doing exactly what his job required. It looked unusual to someone who didn't understand the architecture. That gap — between "this is what happened in the system" and "this is what it means" — is where organisations fail. Not because people are malicious but because visibility without understanding creates false positives. Dave was defending himself against an accusation that made sense only if you didn't know how the system worked.

This applies everywhere. In security research, an anomalous function call might be the engineer testing something, not a bug. In open source, a strange commit pattern might be legitimate refactoring, not malicious code. You need context. You need to know the architecture. You need to understand intent, not just trace the evidence.

I stayed long enough to see the network go live. It worked. I'm told people played games. That part was real.

The burnout arrived gradually, as it always does. Not a sudden collapse but a draining — the weight of meetings that replaced decisions, of work being cited in documents with my name subtly wrong, of caring deeply about something the organisation had started treating as a checkbox. When I left, I was exhausted in a way a holiday wouldn't touch.

What I didn't understand at the time: the organisation's failure modes were independent of the technology's quality. Good design doesn't protect you from broken systems. It might even make it worse — because you're paying attention to things no one else is tracking. The love for the work makes the politics hurt more, not less.

The network shipped. Dave moved on. I learned something about the difference between designing systems and shipping them inside systems, which is a different problem altogether.