A team of one that grew to fifty
Southam / CanWest The problem
In the early 2000s, Southam Newspapers, soon part of CanWest, needed to run dozens of newspaper sites without rebuilding each one from scratch. The industry standard was one big monolithic CMS locked to a single front end. I thought content should live in one place and be presented anywhere. The industry didn't have a name for that yet. We'd call it headless now.
The honest fix
I architected the platform, and then the harder job started. The team grew from one person, me, to more than fifty as it became the backbone of what grew into Canada's largest digital media network. I learned to define roles clearly, to set up a real review loop, and to know when to delegate and when to step in. I got a few of those wrong before I got them right.
Why this one matters
Leading agents is a leadership problem before it's a technical one. An agentic AI team needs the same things a human team does: clear roles, real review, and someone who knows when to step in. Most AI consultants have never had to learn that by running a real team first. I learned it at CanWest, twenty years before I needed it.
A platform the team had given up on
Postmedia The problem
After a major acquisition, Postmedia ended up with a legacy platform running at 100% capacity, with chronic outages. The team had been close to the system for so long they'd stopped seeing it. Their honest belief was that they'd hit a hard limit, and the only path forward was a multi-year, multi-million-dollar rebuild.
The honest fix
I sat with the system for a few weeks before doing anything. Reading code. Talking to people. There was a caching configuration the team had written off as too risky to change. I thought it was worth trying, so we piloted it in a low-stakes corner first, where we could roll it back in minutes if it broke. Utilization dropped 40% almost overnight. Postmedia got about eighteen months of breathing room to plan the real migration on its own terms.
Why this one matters
The team closest to a problem is often the least able to see it. That's not a failure, it's just how proximity works. I don't dress up what's wrong. I find the honest answer, then fix it. And most of the time, the fix is simpler than the thing everyone was afraid of.
A national campaign sold before it was built
Labatt The problem
Labatt had a national designated-driver campaign on the calendar. The media was booked, the partnerships signed, and the creative announced, including a feature that let people put their faces on superhero costumes. They had fourteen days. The plan was native iOS and Android apps, which weren't going to clear app store review in time. Everyone on the team knew it. Nobody wanted to be the one to say it.
The honest fix
I said it. Then I offered the simpler plan in the same breath: drop the apps and build a high-performance web app instead. We did. I built a custom head-detection feature so the superhero piece worked right in the browser, years before AI tools would have made that easy. We launched on time, with zero downtime through the LCBO event and the national rollout.
Why this one matters
Most disasters in technical projects aren't surprises. They're things people know and can't make themselves say. Part of the job is being the person who says them, with a real plan ready, so it lands as a course correction instead of a criticism.
A portal that had failed for a year
Anheuser-Busch The problem
Anheuser-Busch wanted a global employee portal on Salesforce Lightning. They'd been at it for a year and it still didn't work. The team was demoralized, the executives were frustrated, and corporate IT and the project team were talking past each other across several time zones. Nobody had both the authority to decide and the willingness to talk to everyone.
The honest fix
The platform was new to me too. I learned it on the way in. The real problem was political, though, not technical. I took the role of the person who could make calls and talk to everyone, on every continent, in their own time zone. I brokered alignment between IT and the executives and got a remote global team pointed in the same direction. Then we built it. The portal launched within months and became a flagship piece of internal infrastructure.
Why this one matters
Failed for a year rarely means impossible. Usually it means nobody had the standing to make a call. That's a leadership problem, and it's the same one that sinks most AI rollouts. The tools work. Someone still has to decide what they're for.
A global event with no margin for error
Autodesk University The problem
Autodesk University needed to host more than 100,000 people at the same time across 200+ countries. They wanted personalization (who you are, what you're attending, what's relevant to you) and they wanted caching, which is what makes a site fast around the world. Those two usually fight each other.
The honest fix
We decoupled them. Personalization lived in one layer and caching in another, so they didn't trip over each other. It wasn't a standard architecture at the time, but it wasn't exotic either. Just deliberate. Zero performance degradation, anywhere on the planet, for the whole event.
Why this one matters
Big global numbers usually come down to one or two architectural decisions made early. The job is to find those decisions before the event, not after. Simple on purpose beats clever by accident.
A stack built for a slower world
A startup pivot The problem
A startup I worked with was trying to find product-market fit in the Shopify ecosystem. That takes iteration speed: daily releases, fast feedback, the freedom to try things and see. They'd inherited an enterprise architecture that assumed a slower world. They were doing everything right by the old playbook and moving through molasses anyway.
The honest fix
We didn't rewrite. We re-tooled. We stripped out the parts of the stack that assumed enterprise pace, kept what was durable, and swapped what was heavy for lighter equivalents. They went from monthly releases to daily ones, found product-market fit within months, and grew from there.
Why this one matters
The right way to build depends on the market you're in, not the one you came from. Right now a lot of good teams are doing everything correctly by a playbook written before AI-native competitors showed up. Recognizing that mismatch is half the work.