Crushing Jira tickets is a party trick, not a path to impact

Why are juniors just tripping over dumb tickets, when management has projects they want done?

If you want your projects done, assign a team (or multiples) to them, have senior folks on the team and someone who's willing to do project management work[0], and have them prioritize the work. Have the team meet daily and divide the highest priority tasks (individually, pairing or mobbing, as appropriate). The team does not work on other things, unless there's a collective decision they're more important than project work, and the fact that the team is interrupted is communicated to the people who want the project done.

If something comes up that isn't prioritized (and it will, you're not psychic), then discuss it. Slot it in near the top if it's important, start on it right away if it's blocking high priority work. Put it in a deep backlog of "things we'll do someday" if it's low priority.

Make sure there are always high priority tasks to pull, otherwise a junior might trip over a low priority ticket in your backlog. Ideally, the high priority tickets are already on your Jira board with a status like "Ready".

Realistically, the danger is that you overfocus on project work, in a way that's frustrating to your employees, and loses you the opportunity to have people do high-impact non-project work.

But the premise here is that you're the kind of manager who doesn't care about that sort of thing, and only wants to reward employees for shipping projects. So grow up and start telling people what to do.

[0] This person might not be a project manager per se, depending on the project, it might work a lot better if they're a former developer. We did a database migration for my company (7 figure annual savings that were very time sensitive, because a certain database vendor likes to negotiate multi-year contracts), and a developer who moved into management worked well because she knew enough about what we were doing to participate in the prioritization discussions.

That said, it's still better if the project manager role is not dictating what tickets go first. If the team says "we really gotta do X", you need to defer when you have a healthy team. The project manager's job is to make sure everyone's in agreement about how to prioritize, and there's no better way to coach that than by having the whole team make decisions together.

It’s half and half. I come in right after sales gets the customer and work with the customer to do an assessment (https://www.linkedin.com/advice/3/how-do-you-conduct-consult...).

They pay for this and either they can take it back and do the work themselves or pay us to do the work. If they want us to do the work, I work with sales again to come up with hours and resourcing and the customer signs another contract and then I become a technical lead over the actual implementation.

But even if you look at how most tech companies work - I worked in AWS Professional Services for three years as a hands on keyboard mid level consultant (full time direct hire) - if you spend too much time doing hands on keyboard coding, you are working “below your level” this was true for SDEs too.

It’s impossible for 95% of developers to even be 2x that of an average developer doing hands on keyboard work and you definitely don’t get promoted at any tech company because you code well. You have to be able to lead initiatives and work with “the business”