In 2020, Executech decided to scale, and the goal was right. The model we had wasn't scalable. Every new client roster worth 40 hours a week required a new hire, and the tech pool was drying up. Something had to change.
So they changed it. They shifted day-to-day support to a help desk that wasn't fully trained. They rolled out a new ticket system that added an hour or more to an already nine-plus-hour workday. They cut communication lines between teams and the people in leadership who had the authority to adjust course. Changes were pushed through before client expectations were reset, before the team understood the new model, before anyone had verified that the new approach actually worked.
The result: five years of significant client and employee churn.
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. The company looked different when I returned, and so did the mandate: build the technical alignment function from scratch. The governance layer that didn't exist the first time around. In the first 45 days, my team of three and a half people identified $1M in foundational projects — 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.