At some point during my second year working with a top US-based company, I noticed that what I was actually doing had drifted a long way from my job description. The description said something about customer support and IT operations. What I was doing, in practice, was designing automation workflows, building integrations between systems that had never talked to each other, and writing the logic that decided whether a ticket got routed, auto-resolved, or escalated to the right person. The tickets were still there. I just wasn't manually working through them anymore. I was building the systems that did.
The title still said Support Specialist.
This is a pattern I've seen enough times to think it's worth naming clearly. The work evolves before the title does, sometimes by months, sometimes by more than a year. And if you don't manage that gap deliberately, it can cost you in ways that aren't obvious until you're already in a hiring conversation or a pay review and realize you've been underselling yourself for longer than you thought.
How the Gap Opens
It doesn't usually happen in a single conversation. You solve one problem that's slightly outside your lane. Then another. Someone notices you're good at it and sends you the next one. Your manager starts including you in conversations that weren't originally yours. You write something up that gets shared more widely than expected. None of these moments is a promotion. Together, they add up to a job that is materially different from the one you were hired for.
In support and IT especially, the path from "resolves tickets" to "builds the systems that resolve tickets" is surprisingly short and surprisingly invisible. The output looks similar from the outside. The skillset required is completely different. Organizations are often slow to update their mental model of what you are, partly because they're busy, partly because updating it costs money, and partly because nobody likes to acknowledge that the job they hired you for has been outgrown.
The gap can also open from the other direction: you pick up new tools on your own, start applying them without being asked, and demonstrate results that were never in the original brief. That was my situation. Nobody assigned me to automation. I started because it was clearly the right answer to problems I kept seeing, and the work compounded from there.
Why Waiting Is a Strategy With Costs
The instinct most people have is to wait. Wait for the performance review. Wait for the manager to notice. Wait for an official scope change to arrive from above. That instinct is understandable, and it occasionally works. But waiting has a real cost that isn't always obvious until later.
The most concrete cost is in the external record. Your title is what a recruiter sees first, what a future employer anchors on in the early stages of a conversation, and often what determines which salary bands they consider for you. If your title says support and you've been doing engineering work, you will spend the first part of every external opportunity correcting that impression. Sometimes you correct it successfully. Sometimes you don't get the chance.
There is also a softer cost, which is internal. When the gap between your work and your title is large and persistent, it becomes slightly corrosive. You start explaining yourself more. You feel the need to justify your involvement in conversations you've earned the right to be in. The cognitive overhead is real even if nobody can see it.
The Documentation Step People Skip
The single most useful thing I've done in this situation is keep a running record of what I'm actually building and shipping, separate from the ticket queue and the official reporting. Not a long document. A simple monthly log: what I built, what it replaced or improved, and a rough sense of the outcome. A workflow that eliminated a class of recurring tickets. An integration that cut onboarding time from hours to minutes. A monitoring setup that caught errors before users did.
This record exists for one reason: the conversation you will eventually need to have. Without it, that conversation is vague. With it, the conversation has evidence.
The ticket queue doesn't capture this work, or it captures it poorly. A workflow that prevents 200 tickets a month shows up in the queue as fewer tickets, not as the work you did to get there. You have to be the one who makes the invisible work visible, because no reporting system does it for you.
The other part of the documentation step is translating what you've done into language that travels well. "Built automation workflows" means one thing to an engineer, something more specific to a manager looking at headcount, and something quite different to a business owner looking at outcomes. Know how to say what you've done in all three registers. "Cut manual processing time by roughly 80% on our renewal workflow" lands differently than "built an n8n workflow that calls the billing API." Both are true. Which one you lead with depends on the room.
The Conversation Itself
The conversation most people avoid is the one that makes the gap official. It doesn't have to be adversarial, and it doesn't have to be a demand. The version that tends to work is simple: "Here is what I've been doing for the last year. I want to make sure we're aligned on what this role actually looks like now and where it's heading."
Most managers are not oblivious to the scope change. They're usually aware of it in general terms. What they haven't done is formally reckon with it, partly because you haven't pushed and partly because it opens a conversation about title and compensation that costs them something. Bringing it with evidence, calmly, gives them the structure to do that reckoning.
In my experience, managers fall roughly into two categories here. The first will acknowledge the scope change, want to make it official in some form, and work with you on how to do that inside whatever constraints they have. The second will acknowledge the scope change and explain why, right now, nothing can change structurally. Both responses are useful information. The first tells you you're on the right path. The second tells you to be honest with yourself about your timeline and what you're willing to accept.
A clear, evidenced conversation about scope is almost always better than a long wait. Even when the outcome isn't what you hoped for, you now know what you're working with.
When the Title Genuinely Cannot Change
Sometimes it can't. Headcount buckets, salary bands, team structures frozen during a hiring pause. These constraints are real. If you've had the conversation and the answer is that the title isn't moving anytime soon, the work is still the work. The evidence is still the evidence.
In that case, the goal shifts to making your actual scope legible to the outside world. Public work helps: a portfolio page, documented case studies, GitHub repositories, writing like this. Your LinkedIn profile is worth updating to reflect what you've been doing, not just what you were hired to do. Most recruiters read it as a signal, not a formal record, so you have room to describe the scope accurately.
The title will catch up eventually, internally or at the next role. But you don't have to wait for the title to catch up before you start representing your actual work accurately. Build the external record now, while the work is fresh and you can describe it with specifics.
The Career Crossover Nobody Announces
There is rarely a ceremony when a support person becomes an automation engineer or an IT specialist becomes an ops lead. Nobody calls a meeting to say the transition happened. You just wake up one day and realize the old description stopped being accurate somewhere behind you.
That's fine. Most real career moves work this way. The question is whether you're managing the gap or letting it manage you. Keeping the record, having the conversation, and building the external evidence are the three things I've found that actually close it. None of them requires permission. All of them require that you take them seriously before the gap has been open long enough to become the default assumption.
If you're in the middle of this right now and want to think through how to frame the conversation or what the documentation should look like, reach out. It's a conversation worth having sooner than most people have it.
Comments