Every time I've gone to a CIO with a request to hire more junior developers, I get some version of the same answer: they'll be a drain on the team, they'll pull time from the senior engineering staff, the math doesn't work.
In practice, I've found the opposite. Hiring juniors and rotating them through a dedicated app support role is the best way I know to develop strong in-house engineers — and once you account for what that role does for the rest of the team's productivity, it ends up making practical financial sense as well.
The Distributed Support Tax
When app support is shared across the team, every developer becomes a partial stakeholder in every issue. A user reports something weird, and now an engineer who was three hours into a complex feature has to drop their context, evaluate the report, decide whether it's worth investigating, and either fix it, escalate it, or push it back. That mental swap doesn't cost twenty minutes. It costs the rest of the afternoon.
Multiply that across a team of six engineers, each fielding two or three of these a week, and you've quietly carved a meaningful percentage off your team's effective output. None of it shows up in a project plan. No one writes a postmortem about "the feature shipped two weeks late because we kept dropping into Slack threads about a bug from another team's deployment." But that's where the time goes.
A dedicated app support role solves that problem before it starts. Stakeholders have one front door. Defects route to one person whose job is to triage them. The rest of the team gets to keep its head down on the work it was scoped to deliver. Focus is preserved, deadlines hold up better, and the constant low-grade context-switching tax goes away.
That alone justifies the role. Everything that follows is a bonus.
The Front Line, on Day One
App support is the front line — wherever an issue first lands when a user reports it. Bug triage. "The report is wrong." The integration broke. The data looks weird. Whatever it is, it shows up in app support, and someone has to sit with it long enough to understand what's actually happening before it can be assigned, escalated, or fixed.
When I bring a junior developer into the team, that's where I put them. Not because I think it's the right place for someone "too inexperienced" to write features. Because it's the right place for someone who's going to spend the next decade of their career engineering complex systems and would benefit from understanding how those systems actually behave in production.
The hands-on exposure is unmatched. A new developer in app support will touch the most sensitive parts of the codebase faster than someone assigned to a single feature team ever will. They'll see the integrations that break under load. They'll learn which modules are well-engineered and which are held together with prayer. They'll discover the edge cases nobody documented because nobody else had to deal with them.
Six months in app support produces a different kind of developer than six months in a feature team. Not better in every dimension — but different in ways that matter.
Code-Trained vs. User-Trained Developers
Here's the part I think most engineering leaders miss.
When developers learn a product by reading code, they build a mental model of the system from the inside out. They understand classes, methods, data flows, architectural boundaries. They can navigate the codebase with confidence and reason about how a change will propagate.
That's necessary, but it's not sufficient. Because there's a second mental model — the one users have — and code-trained developers tend to build that second model slowly, if at all.
App support flips the order. A developer who starts in support builds the user's mental model first, because that's the model the tickets are written in. They learn the product the way users actually experience it: as a set of workflows, expected outcomes, and frustrations when those outcomes don't match expectations. The code becomes the second mental model — the explanation for why the user is stuck, not the starting point.
Developers who come up through app support ask product-shaped questions. Why is the user trying to do this? What were they expecting? What's the workaround they've already tried? Those instincts are extremely hard to teach later. By the time someone has spent two years writing greenfield features without ever fielding a support ticket, they've baked in a different way of thinking, and retrofitting empathy for the user is uphill work.
The pipeline produces engineers who think about software as something used by people, not just something built by people. That distinction is worth the cost of training a junior, and then some.
The Twelve-to-Eighteen Month Rule
I had a support engineer who was excellent — the kind of hire who justifies the whole approach. Deep system knowledge, strong product instincts, calm under pressure. Exactly the engineer I wanted to graduate into the team and build features other people couldn't.
I took too long to make it happen. The headcount didn't open up when it should have. The promotion took longer than it should have. And eventually he found another opportunity and left.
I'm still annoyed about it, mostly at myself. The support → engineer pathway only works if the destination is real. If a junior developer can see the on-ramp but not the off-ramp, they will eventually make their own off-ramp by leaving the company. If you don't have the room to get them off of support in twelve to eighteen months, they will move on. And it will make you very sad.
The mechanic I rely on now: ideally, hire the backfill around the nine-month mark. The current support engineer trains them, so by month twelve — when the role-holder graduates to the development team — the new person is already up to speed and ready to take over. Senior engineers never get pulled into onboarding the support hire. The role trains itself. That nine-month backfill is also the organizational commitment that tells the current role-holder the off-ramp is real: you're already paying for their replacement.
If you can't make the off-ramp happen by month eighteen, you've broken the deal — and the people you've trained will know it long before you do. Your best ones will leave first.
The pattern needs to be visible. Junior developers entering app support should see, on day one, the people who came before them and are now writing features. Without that visible pathway, you're not running a developer pipeline — you're running an attrition factory with extra steps.
The Bench You Didn't Know You Had
The final benefit is the one I rarely see written about, and it might be the most underrated.
Developers who came up through app support are the most flexible engineers on the team. They know the codebase end-to-end because they had to. When a critical incident hits a part of the system nobody else has touched in a year, they're often the only ones who remember how it works. When a new project kicks off, when a new product needs a development team, when a vacancy needs to be filled in a hurry — you've got people ready to step up and move into the role.
That bench depth is institutional value that doesn't show up on any dashboard. You don't realize you have it until the day you need it — and by then, if you didn't build it, it's too late. The cost of a dedicated app support hire is meaningful but bounded. The cost of needing a flexible, deeply-knowledgeable engineer at short notice and not having one is unbounded.
Step back from this and the value stack is unusual. Most engineering investments deliver one benefit. A dedicated app support role gives you three: your existing team gets uninterrupted focus, your codebase gets someone who understands it from both the inside and the outside, and over twelve to eighteen months you produce an engineer who can step into almost any role you need filled.
Just don't trap them in support. They'll leave, and they should.