“Communicate, communicate, communicate” ranks with “location, location, location” and “always be closing” as advice that sounds wise until you try to act on it. Changing an organization means changing not only hearts and minds but also perceived context: what people believe, what they know to be true, and what they experience day to day. The third is what most makes the first two stick.
People always do the right thing for their read of the situation. Perceived context does not change on facts alone, and beliefs do not survive a structure that contradicts them. The three work together or none of them stick.
At UBS, I took over half the team and half the responsibilities of my manager. Unlike him, I had neither the positional authority nor the track record to lead by declaration. My opinion alone was not going to align ten cross-functional teams delivering across three continents.
I needed to get it right but could not rely on being right. So I worked backward through the delivery chain: from a colleague in India publishing the latest version of our mobile app, through every handoff, all the way to my direct reports, product managers who until recently had been project managers. I documented just enough of how we worked together to bring everyone into decision-making before changing it.
As CIO of Basler Kantonalbank, I inherited 75 engineers split along the classic dev/ops line: developers shipped code, operations caught the fallout in overtime and weekend firefighting. I reorganized them into product and platform teams, each owning their own delivery. Overtime dropped 25% within six months.
At SonarSource, the division had built its sprints around stable teams and cycles of one to three weeks, with work scoped to avoid dependencies. At 15 teams and 200 engineers, that was no longer realistic. We played Battleship at an off-site to simulate the alternatives, and the division moved to a fixed two-week cadence with dependencies managed between teams. On-time completion recovered to where it had been at half the headcount.
I have researched AI since 2012. In every leadership role since, documents have gone through round after round of revision, each one rearranging the same facts for a different audience. Large language models handle this well, provided the input is structured. I founded CraftFinal on the old “garbage in, garbage out” observation: it generates documents from a curated, evolving fact repository instead of unstructured text.
Building CraftFinal with AI agents showed that they write code fast but lose coherence as the codebase grows. That led to Outcome Engineering, an open-source methodology that anchors AI-generated code to business outcomes through a git-native specification tree. The agent skills and spx CLI are on GitHub.
Writing as a way to think
I write about leadership and transformation because explaining why something worked, or failed, exposes reasoning I wouldn’t otherwise examine. The book reviews and articles on this site are part of that process.
If something here is useful to you, or if you disagree with it, [Personal information, requires JavaScript] .