My origin
I didn't learn how organizations break from books or frameworks. I learned inside them — under pressure, when things were already moving too fast to stop.
Early in my career at PTC, I brought new technology into live organizations. I mapped it to real business needs, pushed it into production, and drove it to first results. What used to take days suddenly happened instantly. And I watched teams struggle to keep up with the speed I'd just introduced.
They didn't fail because they were weak or under-skilled. They failed because their coordination couldn't keep up. Decisions stacked up. Handoffs broke. Errors compounded faster than people could see them.
That's when it hit me: when capability gets ahead of structure, systems don't bend — they break.
Later, running live operations and supply chains, I had to rebuild while the engines were still turning. Revenue couldn't pause. Delivery couldn't halt. There was no room for trial runs or theory. The fixes had to hold under load — or nothing else mattered. That's where I learned the difference between analyzing systems and being responsible for them.
Since then, I've been on both sides of that break. At Autodesk and Deloitte, I drove technology adoption and transformation programs. For clients, I ran operations and rebuilt execution systems under load. The pattern repeated regardless of which side I was on: growth, competition, or new capability pushes the system past what it was built to carry — and the break happens the same way every time.
That's where my lens comes from. I've introduced transformative capability that exposed structural limits, and I've rebuilt the architecture when it buckled. When you've been on both sides of the break for three decades, you learn what actually has to change for transformation to hold.
Start a conversation →