$100M mechanical contractor — Pacific Northwest
They Knew the Story. They Had Forgotten What It Meant.
A second-generation owner of a $100M mechanical contractor reached out to a trusted contact after two extended network outages. Email servers had gone down. Data had been lost. His IT team had spent days getting the network back up. If this continued, He believed the business was at risk.
When I walked into that first meeting with the owner, CFO, and IT Manager, the IT Manager had a defeated posture. He cared deeply. He was simply out of ideas. There was no operating model beneath him, no structure to absorb the chaos, and no path forward he could see clearly.
The systems engineer I partnered with walked into the MDF and identified the technical problem immediately. The entire network was in series. No redundancy anywhere. During the outages, the team had been buying switches at a local electronics store just to get back online.
We built two plans simultaneously. One for immediate stabilization. One to build a solid foundation. The necessary hardware for stabilization sat unused in the building, they had twice as much as they needed. We migrated all applications and services to the main office and built a duplicate environment in their second building as a failover site. If one building lost internet connectivity, everything failed over automatically. The construction workers were on job sites anyway. The buildings themselves were the lower risk. We staged the changes over a couple of weeks, updating systems and firmware that hadn't been touched in years, and managed the short-term disruptions which comes with this much change.
One morning the company intranet site went down because of work the night before. The receptionist let IT know at 7:40 am. IT had the site back up at 7:55 am. When I followed up with the receptionist, the owner was standing at the front desk. She commented we had an outage. I said: "Not an outage. This is a side effect of last night's work. We had it back up before most people could notice."
That's what good looks like. Most organizations have never seen it because they've never had the structure that makes it possible.
While the architecture work was underway, I identified a summer intern who was managing the IT ticket queue and punching well above her role. I gave her a project with real stakes: evaluate an IT ticketing system, build a weighted scorecard, and present a recommendation to the CFO. She recommended Zendesk in her presentation to the CFO. The CFO was more impressed with her scorecard and presentation than with the recommendation itself.
She and I ran a two-week pilot with a handful of users. Those users were getting fast responses and real fixes. They started sharing the IT service desk email with colleagues. In week two of the pilot, the intern and I called an emergency meeting to take Zendesk live across the company. The IT black hole problem had been resolved.
The 90-day plan included migrating from an on premise Exchange server to O365, a complete Wi-Fi refresh across both buildings, change management discipline to eliminate cowboy changes to the production environment, and a business case for additional IT headcount. The email migration was done department by department over a week, with field supervisors brought into the office to reset their phones. The CFO rolled up his sleeves and helped.
I had been offered a suggestion, early in the engagement, to present a formal IT domain scorecard to the owner. I built a PowerPoint for the 90-day plan instead. Then I drew on the whiteboard a picture of the business impact: the main office, the cloud, and the construction workers on job sites. Each stick figure had a hardhat, tool belt and hammer. The owner told me later that was the moment he knew I understood his business.
The exit ramp for this engagement was a stable, reliable foundation for a new Director of IT to build from. My senior partner vetted the hire. The defeated IT Manager who had walked into that first meeting left the engagement with a functioning operating model under him and a team that could actually deliver.
The summer intern went back for her senior year and got a software development job. She did not love help desk but she did love solving problems.
Hermanson was the first time I built this from scratch. Every engagement since has started the same way with a focus on the business, find out what's actually broken, and build the operating model that makes the chaos stop.
The technology is rarely the problem.