Early in my career, I built something that saved $2.5 million annually. It was a BYOD mobile device management platform — technically solid, enterprise-wide rollout, strong adoption numbers. By the metrics that matter, it worked.
What I remember most about that project isn't the architecture. It's the conversation I had to have before a single line of code was written.
The Problem
I was a Senior Infrastructure Engineer at a major financial services company, inside the Digital Workplace organization. BYOD adoption was growing whether the company had a management strategy for it or not. Employees were connecting personal devices to corporate systems. IT had limited visibility into what was accessing the network. Security had exposure they couldn't quantify. And the cost of managing a mix of corporate-issued and personal devices under fragmented policies was bleeding money nobody had officially counted.
The technical solution was clear to anyone who understood the space: a unified MDM platform with device enrollment, policy enforcement, and remote management. I could design it. My team could build it. The hard part wasn't the platform.
The hard part was the conversation about why it was worth building.
The Approach
I'd watched infrastructure projects die in budget review before. The failure mode was always the same: an engineer presents a technically compelling case to a finance or executive audience, using language designed for engineers, and gets told to come back with a business case.
I decided to write the business case first. Before I designed any architecture, before I briefed my manager, before I wrote a single requirement.
I spent two weeks with finance to understand how mobile device costs were currently tracked and what the actual annual spend looked like across corporate-issued hardware, support tickets, and security incident remediation. I talked to legal to understand the liability exposure from unmanaged personal devices accessing corporate systems. I talked to HR about the employee experience friction that came from the current device policies.
What came out of those conversations was a business case that didn't lead with technology. It led with three numbers: current annual cost, projected cost under a unified MDM model, and the difference. Executives don't need to understand MDM. They need to understand the delta.
Once the business case was approved, the technical work was the easier part. The architecture I chose was designed around the constraints I'd uncovered in those early conversations — security policies that legal had flagged, enrollment flows that HR needed to support, reporting capabilities that finance required for ongoing cost attribution. The business conversations shaped the technical decisions, not the other way around.
Rollout was phased: pilot with a single business unit, measure adoption and friction, adjust, expand. Each phase had a stakeholder review before the next phase kicked off. This made the rollout feel managed and low-risk to leadership, which kept organizational support intact through the full deployment.
The Results
- $2.5M in annual cost savings delivered through the unified MDM platform
- Enterprise-wide BYOD rollout — full organizational coverage
- Security posture strengthened across all employee mobile devices
- Platform became the foundation of the Digital Workplace mobility strategy for years after launch
The Real Lesson
Early in my career I thought the skill that mattered most was technical depth. Build the right thing, built it well, and the organization would recognize its value.
The BYOD project taught me that's only half the equation. The other half is understanding the business deeply enough to translate technical capability into language that moves decisions. Numbers that resonate with finance. Risk framing that resonates with legal. Employee experience language that resonates with HR. None of those are technical conversations. All of them were necessary to ship something that lasted.
The engineers I've seen stall in their careers are almost always technically excellent. What they haven't built is the ability to operate in the business half of the room as comfortably as the technical half. That's the skill that turns good infrastructure into organizational outcomes — and organizational outcomes into careers.
I spent a lot of years building both halves simultaneously. The $2.5M project is where I first understood why both were necessary.
