Job titles in enterprise tech are terrible at describing jobs. Mine have included Customer Engineer, Solutions Architect, Principal Consultant, Cloud Solution Architect, and Principal Solution Engineer. Functionally, they were all versions of the same seat: the person in the room who has to turn “what should we do?” into an architecture, and an architecture into a decision someone will actually fund.

This thread of the blog is about that seat. Consider this the origin story post.

The long road version, compressed

I started in network closets, in healthcare IT, pulling cable and keeping small hospital systems alive. Went to HP and worked my way through mission-critical support into presales architecture for big compute deals. Did a stretch at Ericsson designing carrier-grade virtualized network functions, where “five nines” stops being a slide and starts being a contract (with penalty clauses). Landed at HPE architecting hosted cloud for service providers right as the industry was deciding what “private cloud” even meant. Then nearly a decade at Microsoft, with the last six-plus years in the Global Black Belt organization, the specialist overlay that works the hardest migrations and the most skeptical accounts.

The through-line isn’t a technology. It’s altitude-shifting: being able to talk to the CIO at nine, the storage admin at ten, and mean the same thing in both rooms. That skill (not any certification) is the job.

What the seat actually teaches you

A few things the briefing rooms and datacenter floors have taught me that I never got from a course:

Trust compounds faster than expertise. The most valuable sentence in my vocabulary has always been “honestly, our product isn’t the right fit for that.” I’ve told customers to stay on a competitor. Some of those accounts came back years later and bought more than they ever would have the first time around, because when I said something was a fit, they believed me.

The technical answer is maybe forty percent of the job. The rest is sequencing, budget reality, org politics you’re polite about, and finding the one person in the customer’s shop who actually knows where the bodies are buried. Most of the failed projects I’ve watched had a perfectly fine architecture diagram.

Writing is a superpower in a slideware industry. The architects who get listened to are the ones whose documents survive being forwarded. If your recommendation can’t be understood without you in the room, it isn’t really a recommendation yet. You were just presenting.

The part where the org chart gets deleted

In early July, Microsoft eliminated our entire Infrastructure GBB organization. It wasn’t performance-based; it was structural. The whole org went away at once, my seat included.

I’m not going to dress that up, and I’m also not going to perform grief about it. It’s the industry we work in. The same forces that made my last several years fascinating (cloud economics, AI capital reallocation) draw the org charts, and sometimes they erase yours. If it happens to you, my early field notes: file the paperwork the same week, tell your network plainly and without shame, and get specific fast about what you want next. Vague availability helps nobody, including you.

So, what do I want next? The short answer is: a place doing serious infrastructure work (cloud, hybrid, AI platforms) where I can spend a good long while, ideally the kind of tenure I’ve had before. The longer answer is a post of its own. The conversations are happening. In the meantime, I have a garage full of projects and years of field notes to publish, which is what this site is.

More in this thread: how executive briefings actually work, what competitive bake-offs look like from the inside, and the unreasonable career value of being the person who writes things down.

Thanks for reading!