A few years into the role I hold now, an engineer on a cross-functional project asked me, with genuine curiosity rather than any edge in it: "Are you the support person or the technical person on this call?" I said I was both. There was a brief pause. Then we moved on.
That pause is the thing I keep thinking about. Not because the question stung, but because I recognized it. Careers in tech come with a quiet pressure to specialize, to be clearly one thing, to fit cleanly into the org chart box that everyone around you already understands. Pick a lane. Deepen it. The advice is genuinely right for a lot of paths. For others, following it too early closes off something more interesting before it has a chance to compound.
What the pressure to specialize actually does
Specialization advice is mostly aimed at the early-career problem of being too generalist, of saying "I can do a bit of everything" when what employers really want is depth somewhere. That advice is correct and I am not arguing against it.
The version I push back on is the one that treats hybrid careers as a permanent compromise, as if staying across two disciplines means you never got good at either. The people who push that version have usually not spent much time at the seam between a customer-facing role and a technical one, because if they had, they would have noticed that the seam is where a particular kind of expertise grows that neither side can develop on its own.
When you have spent years in support, you have a very specific kind of knowledge: where the product actually breaks in practice (not in theory), what confuses real users at the exact moment they least expect to be confused, which processes look fine on paper and fail every other Thursday. That knowledge does not come from reading documentation. It comes from sitting in the queue, handling the escalations, and doing the post-mortems on the things nobody predicted.
When you also build automation and integrations, you develop a different kind of knowledge: how to look at a workflow and see where it will fail six steps later, how to design something that humans can maintain, how to trace a silent error in a system that reports success. And you develop an instinct for what is actually possible to automate versus what will always need a person, because you have tried both.
The overlap between those two knowledge sets is not the average of them. It is something qualitatively different.
The problems only the hybrid sees
Early in my time at a top US-based company I work with, I was handed an automation that the engineering team had built to reduce support load. On paper it was sensible: detect a class of common issues, auto-respond with instructions, close the ticket if there was no reply within 48 hours. In practice, it was quietly damaging relationships with the customers it was supposed to help.
The engineers who built it had never sat in a queue. They did not know that the customers who submitted that particular type of ticket were, on average, less technically confident than typical users, that a jargon-heavy automated reply would often confuse them rather than help them, and that closing the ticket when they did not reply was not the same as resolving their problem. They were working from aggregate ticket-type data. I was working from the actual conversations.
Fixing it required both halves. I had to understand the automation well enough to modify it, and I had to understand the customer experience well enough to redesign the response logic. Neither the pure support agent nor the pure engineer on that team could have done both. The problem lived at the seam, and the person at the seam was the one who could see it clearly.
I have run into variations of this pattern repeatedly. The knowledge base article that is technically accurate but written in a way nobody in crisis will understand. The escalation workflow that routes correctly but strips out the context the next agent actually needs. The SLA metric that looks healthy and is measuring the wrong thing. The automation that fires correctly and makes the customer feel unheard. These are not engineering failures and they are not support failures. They are seam failures, and they stay invisible until someone is standing at the seam.
How each side makes the other better
The compounding effect is real, and it runs in both directions. Having a support background makes you a better builder because you are allergic to elegant systems that break at the edges. You know that users will find the edge cases. You have already been on the phone with the person who found one at the worst possible time. That experience installs a kind of stubborn humility about what production actually looks like versus what the happy path assumes.
Having an engineering and automation background makes you a better support professional because you stop accepting friction as the cost of doing business. A recurring ticket category is not just something to handle better. It is a signal that something can be fixed, automated, or preempted. You start looking at the queue not just as work to clear but as a map of where the product is failing its users, and you have the skills to do something about that map beyond filing it as feedback.
Over time, the gap between how you think about problems and how a pure specialist thinks about them widens, not narrows. And that gap, framed correctly, is not a liability. It is the actual career asset.
Staying at the seam on purpose
This does not happen by accident, or at least it did not for me. It required choosing work that crossed the line, even when there were easier options available. A ticket that turned out to have a fixable upstream cause. An automation project that required sitting with the support team for two weeks to understand the actual workflow before touching a single node. A process improvement that started as a support observation and ended as a tool change. None of those were the most obviously "technical" or "strategic" choices. All of them taught me something that staying inside one lane would not have.
If you are early in a career that has some of this shape, the practical move is to look for the projects that sit at the junction between the thing you already know well and the thing the other team knows well. Not to abandon depth. Not to try to be everything at once. But to let each side of your experience interrogate the other, and to take seriously the problems that neither side can fully see on their own.
The specialization advice is right: go deep. The version nobody says out loud is that "deep" can mean depth in the overlap itself, and that overlap can be a place where genuine expertise accumulates over years in a way that neither pure lane produces.
What it actually looks like from outside
People who have worked with you for a while will stop asking which kind of person you are. They will just call you when something does not fit cleanly into either bucket. That is the role. It does not have a clean title and it often does not have a clear performance review category. But it is one of the more valuable positions to occupy on a team that has both technical complexity and human-facing operations, which is most teams in most companies right now.
The honest answer to "are you the support person or the technical person?" is: "I understand both well enough to know where they fail each other." That answer is harder to give at a career fair. It is also much harder to replace.
If you are navigating a similar junction in your own career, drop me a line. I am always curious to hear how other people have handled the pressure to pick.
Comments