Technical expertise gets you into leadership. It is not what keeps you there.
I’ve watched technically strong engineers step into IT management roles and struggle — not because they couldn’t architect the systems, but because the job changed and they didn’t realize it. The problems that mattered most weren’t architecture problems. They were people problems, budget problems, communication problems, and operational discipline problems.
I’ve also watched people with less technical depth succeed at the manager and director level because they understood something essential: at some point, your value shifts from your own output to the output of the organization you lead.
This post is about that shift — what it actually looks like, why it’s hard, and what it means for anyone building toward executive-level IT leadership.
What Changes When You Lead a Team
When you’re an individual contributor, your output is largely under your control. You design the system, write the script, configure the service. When you have a productive day, you know it.
When you’re leading a 12-person IT organization — as I did in a healthcare environment — your output is the team. You move at the speed of other people’s growth, which is slow, non-linear, and only partially under your influence. The feedback loop on your decisions stretches from weeks to years.
This is uncomfortable if you’re used to the fast feedback of technical work. The instinct is to drop into the technical problems because that’s where you can see immediate impact. You know the answer. You can fix it faster than explaining it to someone else.
That instinct is worth resisting.
Every time you solve a problem that someone on your team could have solved — even more slowly, even less elegantly — you’ve chosen your own short-term productivity over their long-term capability. Do that consistently and you’ve built a team that waits for direction instead of developing judgment.
The shift to make: from being the best technical resource in the room, to being the environment in which good technical decisions get made without you.
The Problems That Actually Consume Your Time
Nobody tells you how much of IT leadership is non-technical.
In a healthcare environment, I spent significant time on:
- Vendor management — negotiating contracts, holding vendors accountable under BAAs, managing relationships when something goes wrong
- Budget ownership — building and defending the annual budget, explaining variances, making the case for investment
- Compliance accountability — owning the organization’s HIPAA posture, not just the technical controls but the policies, the training, the audit documentation
- Stakeholder communication — translating technical risk into language that means something to clinical leadership and finance
- Personnel decisions — hiring, performance management, having difficult conversations, developing people toward their next level
None of that is architecture work. But all of it directly determines whether your IT organization earns the trust and resources it needs to do good technical work.
The leader who is only comfortable with technical problems will treat everything else as distraction. The leader who understands that these are the job will develop the operational and organizational skills that define executive effectiveness.
Budget Ownership Changes How You Think
Owning a budget is clarifying in a way nothing else is.
When you have budget accountability, cost stops being an abstract concern and becomes a concrete one. You stop thinking “that’s expensive” and start thinking “is that the best use of these dollars compared to the alternatives?” You develop instincts about where money gets wasted, what vendors actually deliver value, and how to make a business case that leadership will approve.
Managing cost in a healthcare IT environment taught me that the discipline of cost optimization is almost entirely operational, not technical. Most waste exists because no one owns the outcome. Licenses accumulate because there’s no process to reclaim them. Environments stay up because decommissioning requires effort and no one has assigned the work.
When I eliminated a $79K annual Azure Virtual Desktop environment and documented $48K in licensing savings through a rigorous audit, the technical work was straightforward. What made it possible was having the organizational authority to own the outcome, the budget visibility to identify the waste, and the stakeholder relationships to make the change without friction.
Technical skill got me to the point where I could identify those opportunities. Budget ownership and operational authority are what let me capture them.
Translating Between Technical and Executive
One of the most undervalued skills in IT leadership is the ability to move fluently between technical detail and business framing.
Most technical people can explain what they built. Fewer can explain why it matters to someone who doesn’t care about the technology.
When I presented the case for a cloud analytics platform at Premier Health, the conversation with clinical leadership wasn’t about the underlying architecture. It was about: clinical staff currently wait [X amount of time] to generate reports that inform patient care decisions. This solution reduces that to [Y amount of time]. Here’s what that’s worth to the organization.
The technical architecture enabled the outcome. The business case got the investment approved.
This translation capability — understanding the technical depth well enough to be credible with engineers, and understanding the business impact well enough to be credible with executives — is what separates IT leaders who get resources from those who complain about not having them.
The discipline to develop: every significant technical initiative should have a clear answer to “what business problem does this solve, and how will we know we solved it?”
Building a Team That Outlasts You
The most durable thing a leader builds is a team with the judgment to operate effectively without constant direction.
This means investing in people in ways that don’t pay off immediately:
- Taking time to explain the reasoning behind decisions, not just the decisions
- Giving people problems that stretch them before they’re fully ready
- Letting people make mistakes in controlled contexts and learn from them
- Creating explicit development paths so people can see where the work leads
In a healthcare IT environment, this also means building the operational documentation and processes that survive personnel transitions. A 12-person team running HIPAA-compliant operations cannot be dependent on any individual’s knowledge. The organization needs to be able to function when someone leaves, gets sick, or moves on.
That kind of institutional durability is an executive concern, not a technical one. It requires thinking about the organization as a system — one that needs to be reliable and resilient, just like the infrastructure it manages.
The Mindset Shift That Matters Most
The engineers I’ve seen struggle in leadership roles tend to have one thing in common: they still measure their own value by their personal technical output.
The leaders I’ve seen succeed at the manager and director level share a different orientation: they measure their value by the outcomes the organization achieves, and they’re willing to do whatever the organization needs — technical or otherwise — to drive those outcomes.
That’s a mindset shift, not a skill upgrade. And it’s one worth making deliberately, before a leadership role forces the issue.
The technology is usually the easy part. The operational and organizational work is where it gets hard — and where the real leverage is.
I write about technology leadership and cloud architecture from the perspective of someone building toward operational executive roles — connecting technical decisions to business outcomes, and sharing what I’ve learned along the way. Get in touch if you’re navigating a similar path.
Discussion
Comments are powered by GitHub Issues via utterances. A GitHub account is required to comment.