The support seat
Supporting people teaches you how many different ways something can fail. At that level the big decisions were out of my hands. My job was to triage, support people as well as I could, and pass what I learned up the ladder.
It also taught me to see trends. One or two reports of something odd might be one-offs. When support keeps hearing about the same behavior from different people, something is very wrong, and support is usually the first place in a company that can see it.
The builder’s seat
Building things changed how I look at what other people build. When I build something I take real pride in it. I nitpick, I stress over whether it works the way I intended, and I want the experience to be right.
That doesn’t switch off. Using someone else’s product, I can’t help noticing the little things: annoyances that aren’t a big deal on their own but tell you how much care went into the whole thing. And I’ve ended up with a firmer view of how things should work, and a habit of checking whether something actually works the way it claims to on paper. That habit is most of how I evaluate a vendor API.
The director’s seat
As a director, it became very clear how many different reasons there are for something to fail or succeed. It also became clear that, whatever I brought to it, some things were still out of my hands.
I’d known that feeling from the support desk. What I hadn’t fully appreciated was that it doesn’t go away as you move up. Being out of your hands isn’t only a problem at the bottom of a company. It’s a problem at the top too.
Where the seats meet
It’s happened more than once that I could see a problem from several seats at the same time. Two examples.
At an MSP, as the solutions engineer on the Projects team I helped build, I was the one talking to companies that wanted something done, and then I had to work out how to make it happen. That meant a deep dive into their systems for context, researching solutions across different vendors and service providers, and talking those vendors through it, sometimes with the customer in the room and sometimes without. Nobody else had that whole view, not even the customer. That’s what let me put a cohesive plan together, propose it, and then implement it.
At a global payments platform, I was usually the first technical person to get my hands on a provider’s API, and the first to get access to their engineers. That gave me a head start: understanding how it worked, checking it matched what had been promised, finding the issues mixed in, troubleshooting them with the vendor’s engineers, and passing all of it on to everyone else. In practice it meant understanding the integration early, and sometimes better than the vendor did.
The cost of one lane
When someone has only ever had one seat, it’s hard, sometimes impossible, for them to see the other perspectives or the bigger picture. That isn’t a criticism. Nobody can be expected to deliver much beyond their own lane, and in practice that’s fine.
But somebody has to put the lanes together. It takes someone who has actually sat in those seats to see the whole thing in a way that works for everybody in the room, not just the person asking.
Where this goes
That experience is where the Foundation Layer came from: a way to work out which layer of a company is actually failing, rather than the one where the problem happens to show up. Most diagnoses are made from a single seat, and they mistake where a problem surfaces for where it lives.
The longer version of my career story is on the About page. If you need someone who can connect the seats around a problem of yours, that’s the work.