How is “quickly find ways to make beneficial changes that are achievable and worthwhile” distinct from resolving tickets?
That seems like a perfect description of doing a good job at resolving tickets to me. Because if the change was beneficial, it was presumably not just navel gazing architecture astronauting, it was solving an existing problem, right?
General expectation for Senior engineers in the orgs I've been a part of is that they are great problem finders, as well as problem solvers and implementers. If you have a significant backlog of useful improvements that are relatively straightforward to implement, then it's likely better to bring on a few junior engineers to tackle those rather than Seniors. If you're looking to turn the large backlog into a small backlog thanks to innovative solutions or break into new areas, Seniors tend to handle it better.
The red flag in the ramp up curve is really for Senior engineers. If I didn't have a solid understanding and demonstrated ownership of my problem domain within six months along with meaningful projects getting pushed through - my manager would likely be starting an awkward conversation with me.
Part of problem finding is also taking vague inputs "that subsystem is kinda wonky" and transforming it into "that system has these specific problems, which can be fixed with this approach, which will take roughly this long, and help out this much".
The existing group may not have made tickets for something because they think "it'll take six months" or "we'll have to change x,y and z before that idea is gonna help us", because they don't have the time to analyze a known pain point for how painful it is, or even because they haven't thought of the improvement. Then someone realizes that those assumptions are wrong, and finds a big improvement.
If it doesn’t solve a problem the existing team already acknowledged, or at least very directly accelerate the fix for one of those problems, that doesn’t sound like a good outcome from a new hire to me.
I can't decide whether to agree with you or not. On the one hand, I think a lot of the changes I'm talking about changes that should accelerate the fix for problems you have (what team doesn't think "it's too hard to work with x" at some point?).
On the other hand, I feel like you're coming at this from the perspective that your existing team is omniscient, or at least always knows better than someone new. We used to have that dynamic, and I think it's better that we're now more open to new ideas (onboarding is still way slower than I'd like, but it's improved).
Current team certainly isn’t omniscient. Just that you’re liable to make enemies, not friends/develop career, by coming in and proposing brand new, undesired/unforeseen changes and winning the argument with management.
Brand new not-desired-by-team features/changes often end up owned and maintained by the existing team for a long time, often long after you’re gone. You, as a new person, probably aren’t shouldering much maintenance burden yet, bad to be perceived as adding more rather than reducing load.
Much better to fix a generally acknowledged problem, reducing maintenance burden for the existing team.
A sizable fraction of people who have many years of experience aren’t good at making you have fewer problems after 6 months of hard work. Those people still think of themselves as senior, so we have to be careful we’re talking about the same pool of people.
But assuming my high performing senior matches your definition of senior, my experience doesn’t really match your approach with “likely better to bring on a few junior engineers to tackle those rather than Seniors”. The people I think of as high performing seniors will do wonders at making a collection of desired bug fixes and required improvements get done and leave the system with, net, fewer bugs. So it’s never better in my book to assign such problems to juniors.
Some juniors do this, at a lower fix rate. Others introduce as many bugs as they fix. Those either get better fast, or get managed out. So in my world, juniors are a resource (“the future!”) we carefully husband, but try not to have many of them on any given team, because the variance in outcome is so much higher.
That seems like a perfect description of doing a good job at resolving tickets to me. Because if the change was beneficial, it was presumably not just navel gazing architecture astronauting, it was solving an existing problem, right?