When the company set out to scale, the goal was right; the model we had wasn't scalable. Every new client roster worth 40 hours a week required another hire, and the talent pool was thinning. Something genuinely had to change.
What I watched taught me the lesson the hard way: the changes moved faster than the discipline to support them. New systems and processes went out before teams were fully trained on them, before client expectations were reset, before anyone had confirmed the new approach actually worked. The intent was sound. The sequencing wasn't, and the cost of that gap showed up over the next few years, on both the client side and the team side.
I left. Not because the goal was wrong, but because the discipline wasn't there to execute it. That distinction took me years to fully articulate, but here's how I think about it now:
Governing technology means building the system that decides what happens, and why.
Management lives in the ticket queue. It's reactive by design. Something breaks and someone fixes it, a client calls and someone answers, a new tool exists and someone deploys it. The KPIs get hit, and none of it adds up to anything that lasts.
Governance is a different discipline. It starts with a framework. Not a feeling, not a best practice from a conference, not what the loudest voice in the room thinks sounds right. Something you can hold a decision up against and ask: does this make sense? What does this change before we've changed it? What do our clients need to know, and when? What does success actually look like, and can we measure it?
Today I operate from a framework that gives me something I didn't have back then: the ability to quantify disagreement. When I think a decision is wrong, I can show the impact, model the consequences, and have the conversation in terms that matter to the business rather than just terms that matter to me. And because leadership is working from the same framework, we're usually closer to aligned than I'd expect.
The other thing I learned, and this one stings a little to admit, is that I kept my concerns inside my direct reporting chain. I raised them, pointed out what was obviously breaking, and got silence back. But here's what I've had to own since then: I didn't have a solution either. I knew the approach was wrong and could show you exactly where the friction was. What I couldn't do was walk in with a better answer. I didn't have the framework that would have let me build a counterproposal that held up under scrutiny, and I didn't have the relationships with the people who actually had authority to change anything. Seeing the problem clearly is not the same as knowing how to fix it, and going in with only the first half doesn't accomplish much.
I'm back at Executech now, which is a strange full-circle to sit with, but the company I returned to had matured enormously in the time I was gone. Most of the organization was miles ahead of where I'd left it, advanced on nearly every front. What didn't exist yet was a dedicated strategic layer, and that's the mandate I came back for: build the technical alignment function from scratch, the governance layer that hadn't been there the first time around. In the first 45 days, my team of three and a half people identified $1M in foundational project opportunities, work scoped and ready for clients to budget and approve, and that was just the starting line, across a fraction of the overall client base. We now have 40 clients on 18-month technical roadmaps, with the rest of the book being onboarded behind them. None of that happens by managing technology. It happens by governing it.
If your IT function is stuck in the ticket queue, the problem usually isn't the people. It's that no one ever built the system that makes the work intentional. That's the discipline that's missing. And it's the one I'm most interested in building.