Crushing Jira tickets is a party trick, not a path to impact
84 comments
·January 25, 2025nosefurhairdo
swatcoder
With junior developers specifically, people are actively and almost desperately looking for signals for who might be ready for more responsibility.
And so at that level, crushing tickets provides one such signal of many that are possible. If you're a junior developer and you have opportunity to crush tickets, it's a chance to show off and that could mean being rewarded as you were. It's not the only way, though, and if those tickets and spurious or the work is deprioritized, it could backfire.
The heuristic changes as you move up though, as crushing tickets in not necessarily providing a lot of real value in itself and a more experienced dev that predominantly busies themselves with lots and lots of low-hanging fruit is not really making best use of their talents/responsiblities.
theamk
I think the OP's point is that "crushing the tickets" should not be your first priority.
That does not mean you should not be closing JIRA tickets, but it does mean that the number of tickets closed should not be your #1 metric.
In other words: if you have a choice of closing 10 easy tickets or 1 hard ticket this week, what should you choose? It's a trick question! You should be choosing whatever is most important for company. If those 10 tickets are required for release, by all means, crush them! But if there is a high-profile incident that VPs pay attention to, then forget about 10 tickets and do that single one to mitigate it.
ebiester
Two caveats for less-experienced engineers (whether by senority at a company or years in the industry): * As a manager, I would prefer you to crush those ten easy tickets if you aren't up to the task of the hard ticket. If that hard-for-you ticket is easy for someone with more skill, and we're in a high profile incident, I am going to steer you away from it.
* As a manager, if you show me you can crush the easy tickets, I will find a way to guide you toward harder problems. Then, if you show you can do the harder problems, and those around you are in agreement that you are tackling those, then you have the leash to start swarming to issues.
Note that you can usually prove this within 1-3 months - I'm not talking about an extensive time of paying your dues here. But make sure not to try and skip a rung.
nosefurhairdo
I made this thread's root comment: this is exactly how I was managed, including the "can prove this within 1-3 months" timeline.
Glad to see there are other good managers out there. It's a bit horrifying seeing the pessimism in these sorts of threads. Would strongly encourage folks in low-autonomy teams to seek other opportunities.
jq-r
Which reminds me of a previous discussion: Don't do easy things
scarface_74
> I'm not sure how one gets to be responsible for a project without first crushing tickets, though
I skipped the whole junior developer thing. I was hired at a company as a computer operator based on a prior years internship. I was the only one that knew how to code and they got a contract where they needed to build an entire connected double entry verification data entry system with about 10 screens and a management console. I wrote the entire thing in C in the mid 90s.
Unfortunately, after working at another company for 9 years after that, I became an expert beginner by 2008 and didn’t start learning best practices until 2012-2014 at my 4th company.
So in other words - “don’t do that”.
bashtoni
I suspect this is a very common experience.
I don't think that 'crushing tickets' is a good metric of developer competency, but it's a very visible metric regardless and is therefore probably a good way to progress in many organisations.
scarface_74
But only to a mid level developer.
kidbomb
It's not about crushing tickets. It's about crushing the right tickets.
corytheboyd
100% agree, you simply have to prove varied competencies repeatedly to level up. It’s very intuitive, and leading projects means guiding others to execute the varied competencies you’ve now demonstrated your understanding of.
5-
> If you ship a project and your management chain begins talking about the next thing, stop improving that project.
and this type of advice is precisely why the whole industry completely lost its ability to produce usable things.
scarface_74
Or in the case of Google at one point had 5 messaging apps shipping simultaneously and talked about three of them at one Google event. Shipping new products shows “impact”. Maintaining and improving existing products don’t.
nosefurhairdo
Surely there's a balance to be found. Personally, I allow myself some not-explicitly-requested improvement work when I see what I view as low hanging fruit.
I know the code and effort involved, and sometimes just doing the thing is fast enough it's not worth working it into planning. It also keeps me motivated on whatever "next thing" I'm working on when I allow myself some non-next-thing work.
However, there's definitely wisdom in aligning priorities with the business. If "next thing" is deemed more important by the people who pay you, you should probably be focused on that.
scarface_74
How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?
theamk
You work on what you think is the most important, and then you choose a closest ticket # to put into pull request description. If there is no ticket close enough, then you make one first.
Some companies like to micromanage and rob engineers from any sort of autonomy: they have non-engineers make tickets, and those tickets are very small, and they are assigned them without engineer's inputs, and managers carefully monitor that engineers only work on assigned tickets. If that's your case, then I am sorry. Also, it is not not a "senior engineers" position, even if your business card says otherwise. If you are interested in becoming a better engineers, consider a different, less disfunctional, workplace.
toast0
In such an organization, there's no low hanging fruit, because everything requires a ticket writing exercise, and a group consensus managment exercise.
Or you make up a blanket ticket, and self-approve your PRs.
Or you start probing for process in interviews, so you can find somewhere to work without oppressive process.
nosefurhairdo
I write a ticket and open a PR and ask my team for review.
pockmarked19
I agree with what John Carmack said about that.
null
ori_b
You know what killed the dinosaurs, right?
Impact.
slavik81
I was expecting "the ice age". Maybe I'm getting old...
scarface_74
It wasn’t “dealing with ambiguity”???
robertlagrant
Deep.
Artoooooor
That's exactly what I facepalmed to. But the higher-ups are still more responsible as they are the ones setting rules. And the rule is: make half-finished thing if you want to get the promotion. On the other hand - engineers should not call something done unless it's really done. Especially in presence of any manager.
bdangubic
and yet software eats the world, eh? the craziest thing to me is that each time I get close with someone in our industry (conferences, meetups, socially…) and get insights into what they do and how things are I stop doing something in my life. I sold a car of a certain brand after hearing horror stories about the code running the car and few other things like that… crazy stuff!
ripped_britches
Awesome article about how to get a promotion.
Deserves a follow up article for “how software companies should actually be run to avoid promotion seeking behaviors like projects > all else”
Most software companies just need 1 (or at most a handful) of really amazing products.
Most products are composed of a handful of “projects”.
I’ve worked at big and small tech companies where we were so busy building projects for projects for projects with no correlation to customer value. Things like a custom UI snapshot testing suite.
I do think Google, Meta, and Microsoft have the budget to work on such projects that ultimately benefit the whole tech community. And it’s a tide that raises all ships (TypeScript, React, and Basel come to mind but there are many more examples). But if you’re anybody the size of Lyft or smaller, you probably just want a small team of engineers hyper-focused on building an amazing product without all the “projects”.
For example, what all the 4k+ engineers at Spotify are working on every day, I have no earthly idea. It’s not just a waste of money, it’s an obstacle to genuine progress and innovation.
pockmarked19
Spotify is one of the worst at innovation. They pushed out the team that made discover weekly by downplaying their pioneering work while executives focused on “health integrations”, and they’ve now laid off some of their most creative people, including the guy who worked on everynoise.com.
I would guess that bloat at Spotify is a direct result of empire building by the numbers.
hyperpape
I read this and think "where are the fucking adults?"
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.
potato3732842
The most respected and well paid senior engineers and managers at my company are all ex-ticket crushers. They put in their time being the kind of people that managers could trust to get stuff done and done right and done promptly.
Trying to play games and fudge it only works in a company big enough that this sort of gamesmanship goes undetected beyond your immediate team. Or if you have a bad boss that isn't really keeping tabs on who's doing what.
Also, people don't ship shit, teams do. And teams with morale in the toilet because they've got more than a couple people acting like this don't ship the good stuff you want to be associated with.
scarface_74
> The most respected and well paid senior engineers and managers at my company are all ex-ticket crushers.
The problem with this is that because of salary compression, it’s usually better to job hop.
bdangubic
I disagree for two reasons:
- job hoppers do not realize how often they are discarded for being that. where I work this is the FIRST and most important part of the CV review. job hopper CVs are immediately thrown out (and trust me, you want to work where I work). I have numerous colleagues that work elsewhere and all but one have exact same thing going on. no one in their right mind is going to invest into someone who will obviously leave in a couple of years.
- if you are at the right place and are valuable you will get paid accordingly. it is just that this notion of “I must hop to boost my earnings” is so pervasive in our industry that people seldom just hit up their managers etc for adjustment to compensation. no sane company is going to let go an employee who is valuable to them
scarface_74
> no sane company is going to let go an employee who is valuable to them.
You say that as if companies are sane. Management may think you are valuable to them. But HR sets the salary bands. Management only has so much power over raises.
danjl
As a developer, the more you understand about the non-technical, business side of your company, the better you can prioritize and communicate about what is important. No need to "read the tea leaves" or guess at how to interpret the gestalt. Just learn what matters to your company's success and how to communicate with the people outside of development. The goal is not promotion and working less than 40 hours a week. The goal is company success. The other stuff follows.
Artoooooor
"continuing to work on an already-shipped project is a very common mistake. Declare victory and walk away!" Maybe that's why we swim in the sea of barely done apps with terrible performance. It's time to demand quality of the app vendors. Uninstall facebook until it starts in 2s and works flawlessly. Use ublock until the ads stop slowing down a site. Uninstall any messaging app that cannot show you paginated history of messages, that is easy to search and to go back to given moment. Refuse to play single player games that require constant connection to vendor server. Maybe then these managers will learn that shipping A product is not an end. Shipping POLISHED product is.
ukuina
So much low-hanging fruit is glossed over because the feature is not deemed glorious enough to invest in. It takes invested teams to care about polish; almost impossible with the engineered churn at FAANG.
coldcode
I first thought the headline was about crushing Jira itself. Many days it could be very tempting.
jvalencia
As someone who's sat on both sides of the table, getting tickets done is incredibly valuable. I don't really think an engineer is worth their salt if they can't do this. However, there's a transition that needs to happen when they hit mid-level where they need to be able to synthesize what the ticket is asking for and implement the right thing. No ticket or product manager is perfect, and awareness is often times a better driver of performance because certain tickets aren't done or are changed due to an engineer's competence.
From the flip side, management is looking at industry trends that the engineer simply doesn't see. It may be the current market is getting saturated with your product and the company really needs to pivot to remain competitive. No amount of further feature work or bug fixing will "fix" the market position. You have to do something different or you will lose sales. While fixing the existing product may make the existing customer happy, it won't continue to drive new revenue.
The only way to really make the two sides happy is to have a level of trust/communication that is rare. What engineer doesn't like to complain about management that keeps changing their mind? What manager doesn't like to complain about engineers that are out of touch with reality? Given this audience, I would say that if you're an engineer, there's an order to the skills: crush tickets, gain awareness of the product so you can do the "right" stuff, then solve your manager's market problems (not the product's).
robertlagrant
> No ticket or product manager is perfect
Getting a product manager to write technical tickets is generally a mistake, I would say.
asdasdsddd
Another way to frame this is to not get too attached to your code. Tmrw it could be the cornerstone to a new line of business or it can be burned in the dumpster.
Trasmatta
And this is one reason this industry can be so soul crushing.
You're asked to demonstrate "ownership", but at any moment some person above you can take all your work away and make you do something entirely different.
Somehow we're asked to care about our work and not care about it at the same time.
intelVISA
"Drive this car with 3 wheels and if you crash it's all on you, if we get to the destination I'll be rich and DON'T even think about stopping to add a 4th wheel. DRIVE FASTER. STOP THINKING ABOUT THE WHEEL."
Really devs should exchange labor like authors with royalties, there's no incentive to ship good software for salary so you just end up with a series of "crushed tickets" aka future work for yourself as job security.
Ancalagon
This is what bothered me so much about my last job. Thank you for saying it so succintly
Trasmatta
I think it's one of the prime causes of burnout. Feeling like you have no real control over things, but having immense responsibility anyway. Fighting learned helplessness with an internal taskmaster.
It's not good for the psyche.
bckr
A good phrase to remember is “outcomes over outputs”
hinkley
One of the soft skill tricks is building new allies out of subordinates. Almost nobody gets promoted to a level of influence until they’re a bus number in something important. And that often requires waiting for the project scope to grow enough horizontally for new domains to open up, or for someone senior to pass the torch.
If management is doing their jobs in growing the team then this all works out. But if they’re letting those with tenure get first pick of new problems, then you can play the game, carving out your share of the spoils, and then offloading other things before your head explodes. Every thing you offload is a ladder rung for someone else.
That way you end up with code that is no longer your baby but still not on the trash heap.
scarface_74
That’s not the takeaway. The author said work on “projects” not “tickets”. In other words, volunteer to be the single responsible individual for “work streams” or “Epics”. This is actually the behavior of a mid level developer at every tech company whose leveling guidelines I have seen either internally, talked to other people about or that’s publicly available - ie Drobox
https://www.levels.fyi/blog/swe-level-framework.html
https://dropbox.tech/culture/sharing-our-engineering-career-...
A senior developer should be over guiding an implementation and mentoring and coordinating mid level and junior developers.
I made it a point ny entire career not to be a “ticket taker” and be able to say I “lead” or “designed” a major feature or implementation.
fanfanfly
Thanks for sharing
neogodless
> But this is a dead end. You’ll get a pat on the head, told “nice work, don’t burn yourself out”, and no progress towards a senior promotion.
Eh, this might be accurate (for certain teams/companies) but I was on a team where I was the contractor. Everyone else was SO focused on promotion that they got zero work done ever, and I got a dozen tickets crushed each week. The whole (oversized) startup ending up failing, but the CTO ended up pulling me in to another project they helped start, one with a massively leaner team, and we crushed that project and made it truly successful. I didn't even know anything about the role (data warehouse engineer) but he knew I would work hard, learn fast, and get things done, and that was what mattered.
JoshuaRogers
The advice here is a super red flag. This isn’t what I want to see from my team at all. I’m glad this advice worked for someone but this path could easily set someone up to be seen as unreliable / untrustable.
scarface_74
Look at the leveling guidelines for any company that has a formal process. Saying “I closed a lot of tickets” at most gets you to a mid level software engineer. It doesn’t show “scope” or “impact”.
null
I was given high impact projects precisely because I crushed tickets as a junior. I demonstrated repeated mini-competencies (crushing tickets), gained credibility, then got to demonstrate macro-competency (deliver projects).
Definitely agree that "crushed many tickets" is less effective in performance review than "delivered critical project". I'm not sure how one gets to be responsible for a project without first crushing tickets, though.
Just my experience, curious what other folks have seen/experienced.