I'm Christian Chicoine — solution architect, IT leader, and recovering perfectionist. I write about the decisions that define careers and cost companies millions, because someone should be honest about them.
I started as a developer. Not because it was strategic, but because I loved building things that worked — and hated things that didn't.
In the late 1990s, that meant writing code that had to run reliably on hardware that cost more than a car, for businesses that couldn't afford for it to fail. There was no Stack Overflow. No cloud. No elegant frameworks. Just the problem, the deadline, and whatever you could figure out.
That foundation — understanding the machine before managing the machines — shaped everything that came after. When I eventually moved into solution architecture, I was never the architect who had to pretend to understand what the developers were dealing with. I'd been there. That difference matters more than most people admit.
Started building software from the ground up. Learned that the gap between "it works on my machine" and "it works in production" is where careers are made or broken. First exposure to the politics of technology decisions — and how rarely the best technical choice wins on its own merits.
Watched the dot-com bubble inflate and burst from the inside. Saw companies make catastrophic technology bets that felt like obvious wins at the time. First real lessons in the difference between a technology that is genuinely transformative and one that is merely fashionable.
The transition from building systems to designing them. Discovered that architecture is less about technology and more about understanding constraints — budget, politics, organizational capability, and the gap between what a business says it wants and what it actually needs. Started working across industries: retail, insurance, manufacturing.
Expanded into finance, food, and wholesale. Started carrying accountability for decisions that outlasted the projects that produced them. Learned the hard way that a technically correct architecture and a practically implementable one are not the same thing — and that the gap between them is where most projects die. Added HEC Montréal's certificate in international affairs to understand technology strategy at a geopolitical scale.
Moved into IT management while completing a certificate in business analytics at HEC Montréal. Started writing to document what I'd learned — not to build a brand, but because too much hard-won knowledge was disappearing into meetings and slide decks. Realized the patterns I'd seen across 6 industries were genuinely rare and genuinely useful to others navigating the same terrain.
Framework porn. Buzzword cycles. Architecture diagrams that look impressive and say nothing. The gap between what gets written about enterprise IT and what actually happens inside real organizations is enormous — and it costs real people real money. I try to write the content I needed and couldn't find.
Architecture is not a technical discipline. It's a political and organizational one that uses technical tools. The architects who understand this advance. The ones who don't spend their careers being right in rooms where it doesn't matter.
The failure modes in a retail ERP migration look remarkably like the failure modes in a financial services platform modernization. The org dynamics that kill a cloud transformation in manufacturing are identical to the ones that kill it in insurance. If you've only ever worked inside one industry, you can't see this. I've been lucky enough to see it across six.
I've watched SOA, ESB, big data, agile transformation, cloud-first, microservices, and now AI follow the same arc: breathless adoption, overclaiming, painful reckoning, eventual useful application. This doesn't mean new things aren't real. It means the right question is never "is this real?" but "is this the right time and the right application for us?"
Nobody makes a catastrophic architecture decision thinking it's catastrophic. They make it thinking it's clearly correct, and that the people raising concerns are being overly cautious or insufficiently visionary. Retrospective honesty about those moments is the most useful thing a practitioner can offer — and the rarest.
Started as a developer. Spent 27 years in solution architecture and IT management across retail, insurance, manufacturing, finance, wholesale, and food. The pattern recognition that comes from seeing the same problems fail differently in 6 industries is not something you can shortcut.
A certificate in international affairs from HEC Montréal gives me a lens most architects don't have: how geopolitics shapes technology strategy. Cloud sovereignty, vendor concentration risk, cross-border data architecture — these are conversations I was having before most organizations knew they needed to.
A certificate in business analytics from HEC Montréal means I can frame architecture trade-offs in the language of financial return, risk probability, and organizational capacity — not just technical elegance. This is the translation layer that gets good decisions funded.
The knowledge I needed most in the first 15 years of my career was never in a book. It was in the head of some senior practitioner who had seen it before — and who either didn't have time to share it or assumed I'd figure it out myself.
A lot of that knowledge gets lost. People retire. Teams turn over. Organizations repeat the same expensive mistakes with slightly different technology and completely different confidence. The institutional memory of what actually happened — as opposed to what the post-project report said happened — almost never survives.
That's what I'm trying to fix, in a small way. Not with comprehensive frameworks or exhaustive guides. With honest accounts of what I've seen work, what I've seen fail, and the uncomfortable patterns that show up everywhere once you've been around long enough to recognize them.
If you're an architect, IT leader, or technical professional trying to navigate the difference between what the industry says you should do and what you should actually do — this is for you.