Oracle and the burnout
Oracle in Reading, then San Francisco. The burnout that sent me back north. And the thing I wish I'd known about myself before it got that far.
The burnout didn't arrive because I was weak or lazy or not trying hard enough. It arrived because I was a system under resource exhaustion and I had no metrics to understand my own bottlenecks.
Oracle in Reading, starting in the late 1990s, was my first real exposure to how large organisations operate at scale. The UK office, enterprise software, the rhythms of a company that's made peace with the fact that it doesn't need to be liked. I learned something there — mostly about the difference between how you want systems to work and how they actually work when they get large enough.
San Francisco was the promotion. Better job title, higher visibility, the particular flavor of American tech company that genuinely believes in its own importance. I arrived with high expectations of myself and the assumption that performing at that level was a matter of working hard enough.
What I didn't understand: I was neurodivergent, undiagnosed, operating in an environment optimised for a specific type of cognition and social performance I don't have. The open-plan offices with their ambient noise, the networking events, the constant implicit pressure to perform not just the work but the manner of doing the work — all of it was consuming resources I didn't know I had limited amounts of.
Here's the systems thinking angle: **burnout isn't weakness, it's resource exhaustion.** Think about it like a monitoring problem. You run a server, you allocate memory, CPU, network bandwidth. If you consistently overallocate load, the server degrades. You don't blame the server for being poorly designed — you look at your capacity metrics and you fix the load or you add resources.
I had no metrics for myself. No observability into my own system. I was treating my energy and attention like infinite resources that could be oversubscribed indefinitely, and then I was confused when the system became unresponsive. Not failed — unresponsive. Still technically online, still technically executing tasks, but returning garbage because the load had exceeded capacity.
The burnout, when it fully manifested, wasn't dramatic. It looked like someone still showing up, still delivering, but gone very quiet and flat. Running on something closer to inertia than engagement. I knew something was wrong. I couldn't name it. In a 2009 American tech company, "I'm running out of capacity in a way I don't understand" isn't a sentence that lands well.
I came back to the north of England. The decision wasn't made in one moment — more like a slow calculation that the cost of staying had exceeded the benefit. What I wish I'd known earlier: the undiagnosed neurodiversity wasn't the root cause. It was just the constraint I didn't know about. Like a system running with a silent resource limit that nobody told you existed.
If I'd understood earlier, would I have managed it differently? Probably. Maybe I'd have built in different protections, recognised the warning signs, made different choices about where to work. But understanding a constraint is not the same as removing it, and in some cases it's not removable at all — you just have to design around it.
I've been independent for years now, working in ways that actually fit how I function. Bursts of deep focus, control over my environment, no commute, no open-plan offices. Not a perfect solution to everything. But a workable accommodation arrived at through understanding my own system constraints instead of just fighting them.
San Francisco was beautiful. I just couldn't afford the resource cost of being there.