For most of my early career, I was solving the wrong problem. Not in the technical sense: the fixes were usually correct, the tickets closed cleanly. But I would resolve an incident, build a workaround, document the root cause, and then discover three weeks later that nobody upstream had changed the process that created the problem in the first place. The work disappeared into the queue and left no trace.
It took me a while to understand that the gap wasn't in my technical ability. The gap was in my language.
The Ceiling Most Technical People Hit
There is a pattern I have watched repeat in IT and support careers across every organization I have been part of. Someone is genuinely good at the technical work. They close tickets fast, their fixes stick, their documentation is thorough. Then they plateau. They are not getting worse. The organization is not dissatisfied. But the decisions are made one level above them, the bigger projects go to someone else, and the title stays the same for another year.
When I have asked people in that situation what they think is holding them back, the answers tend to be the usual suspects: the org is slow, the manager isn't advocating for them, there isn't budget. Sometimes those things are true. But more often, the real answer is simpler and more uncomfortable: they can diagnose the system, but they cannot explain why the diagnosis matters to anyone who isn't already looking at the same screen.
Technical skill gets you through the door. The ability to translate that skill into organizational terms is what gets you the room.
What Business Fluency Actually Is
Business fluency is not an MBA. It is not soft skills or stakeholder management as a buzzword. It is one specific, learnable thing: knowing how to connect what you are working on to what the person across from you actually cares about.
That sounds obvious. In practice it is hard, because the translation requires you to know what the other person cares about before you open your mouth. A finance manager cares about cost and exposure, not uptime percentages. A country director cares about whether their staff can do their jobs, not whether the VPN is running on IKEv2. A customer success lead cares about whether the ticket gets resolved, not which part of the stack delayed it.
The technical answer to a question is often accurate and completely useless to the person asking. Business fluency is the habit of giving the accurate answer and then immediately answering the question behind it: what does this mean for us?
The Conversation That Changed How I Work
I learned this the hard way at a large international NGO where I worked for several years across more than 30 countries. I was preparing a proposal for a server infrastructure upgrade and my first draft was technically thorough: specs, protocols, patch levels, failure scenarios. I had done the work. I might as well have written it in a language nobody in the room spoke.
A more senior colleague looked at it and said: you need to tell them what breaks if you don't do this, what it costs when it breaks, and what the fix costs in comparison. Stop writing for yourself. Write for the person who has to approve it.
I rewrote it. Not "we need a firewall upgrade." Instead: right now, a single misconfigured device in any of our country offices can expose donor records that took years of trust to collect. Closing that gap costs less than one percent of the annual IT budget. Not closing it has cost organizations in comparable situations their donor relationships entirely.
Same technical reality. Completely different conversation. The proposal moved forward in the next review cycle. And more importantly, I started getting included in budget conversations I had never been in before, because I had demonstrated that I understood what those conversations were actually about.
Three Practices Worth Building
Finish the technical answer with the organizational consequence. When someone asks why something failed, give the root cause and then immediately add what it means: "The API rate limit was hit because we are sending roughly three times the expected volume. That means any ticket submitted in the last two hours may not have routed correctly, so I am re-running the queue now." One extra sentence. Most people never say it.
Know what your stakeholders lose sleep over before you walk in. Before any significant conversation with someone outside IT or support, spend two minutes thinking about what they were already worried about before you showed up. Not what you are bringing to them, but their actual problem. The answer shapes how you open. A proposal that begins with their concern and then explains how your work addresses it lands completely differently from one that begins with your work and asks them to care about it.
Use the two-sentence test. Can you explain what you are building in two sentences to someone who does not know what an API is? If not, you do not yet have a clear enough picture of your own project to defend it in a meeting. This is not about simplifying until it is wrong. It is about understanding your own work well enough to state its purpose plainly. The technical detail lives underneath that, available when someone asks for it.
What Changes When You Apply It
The automation work I do now, routing logic, triage flows, CRM enrichment, onboarding integrations, could have stayed quietly in the background forever. A lot of similar work does. It would have shown up in closed-ticket counts and faster first replies, but nobody would have connected those outcomes to the work behind them.
What changed was framing. Not "I built a routing workflow." Instead: "First-reply time on payment-related tickets dropped by roughly 40 percent because they now route on submission instead of sitting at manual triage. That is roughly 60 to 80 fewer escalations per month, and the CSAT on that ticket category is consistently above the team average for the first time."
Suddenly the work has stakeholders. People start asking what else is possible. The scope expands, the projects get larger, and yes, the title eventually catches up. Not because you asked for it, but because the organization can now see clearly what you have been doing.
Where to Start
Most IT and support professionals I know are significantly better at the technical side of their role than at explaining why that technical work matters. That gap is not a character flaw. The incentives of early-career work push you hard toward solving the problem in front of you, not naming its organizational cost. The ticket queue rewards speed and resolution. It does not reward narration.
But at some point the ceiling is real, and the skill that breaks through it is rarely more depth in the technical direction.
Pick one conversation in the next two weeks where you would normally give a purely technical answer and add one sentence after it: what does this mean for the person asking? Not for you. For them. That is where the translation habit starts, and it compounds faster than almost any other career investment I have made.
If you are thinking through this for your own role and want a second set of eyes, reach out. Happy to talk through what the framing might look like in your specific context.
Comments