Note: This essay discusses my approach to challenges using synthetic examples. Real detailed STAR examples are in a private markdown resource shared selectively under NDA. I learn more from difficult situations than from smooth operations. The decisions that teach me most are the ones where multiple stakeholders have competing interests,
My relationship with technology spans four distinct phases, each informing how I think and what I can do today. As a Technical Support Specialist at Microsoft UK I learned how technology actually fails. I supported Visual Studio, SQL Server, and COM at the product level, debugging customer issues under pressure
Philosophy, how I think. Character and Patina I believe people are shaped by pressure, not despite it. Character isn't built in comfort, it's built in difficulty, failure, and the choice to stay and learn rather than retreat. When I look for people to work with, I&
Resources are downloadable supporting artefacts, sometimes markdown files designed for both AI processing and human adaptation, sometimes as word documents when specifically targeted for human use. Perspective Markdown Files These are markdown files that describe how I show up, my history, my experiences etc. I use them as inputs into
Perspectives are explanatory content that define how I operate, think, and approach key areas of technology leadership. Unlike Field Notes (observations from the ground) or Essays (thinking on what's coming), Perspectives are foundational descriptions of my philosophy, values, and decision-making frameworks. Perspectives form the "how I think&
Agents are AI Agents I have built to help in performing my role. Not overhype and overused, just simple helpful agents that can do things repeatably in a fraction of the time I could. Agents published on the CTO Operating Systems are used for mainly research / analysis and information gathering.
The leader of leaders. The person who gives me day to day confidence, who builds, grows and optimises our engineering function, and when I take time off, seamlessly steps into day to day CTO operations and shields me. When I want to vent has an ear, and when who needs
Easily the most important people in the building. Language aside, the Principal Engineers are the IC7. The gold dust and in many many years of leading technology companies are the 10x over all. Why? Because they are the engineers of the engine. They design the engine and as a CTO
Roles is not about a JD, it's about the scope, authority level and what I expect from the people in these roles and why. What I expect from a VP of Engineering or a Principal Engineer and why. In plain English, what do they do and why. It&
I've spent the last 20 years building and scaling SaaS platforms. The first half was enterprise integration, learning how complex systems talk to each other at scale. The second half has been about taking that foundation into multi-tenant SaaS, leading listed and high-growth companies through international expansion, platform
I'm a scale-up CTO with 20 years of technology leadership experience, focused the last 15 years specifically on SaaS platform scale and transformation. I've held CTO roles at four NZ-headquartered scale-ups, Loyalty NZ, Plexure, Serko, and EROAD, building platforms used by hundreds of millions of people
Everything flows from character. It's the one thing you can't train, and it's non-negotiable. I don't compromise on hiring people with high integrity, and I expect the same standard throughout the organization. Beyond that, transparency, direct communication, the willingness to escalate bad