Crushing Jira tickets is a party trick, not a path to impact
seangoedecke.com
seangoedecke.com
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.
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.
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.
* 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.
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.
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”.
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.
and this type of advice is precisely why the whole industry completely lost its ability to produce usable things.
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.
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.
https://www.levels.fyi/blog/swe-level-framework.html
It was more of a hypothetical question. I haven’t been in that position - ever. But I’ve heard horror stories.
As a mid level developer (I’m now a staff software architect at a consulting company, I design and lead implementations from the ground up), do you really have that kind of autonomy to choose the tickets you work on outside of what was put in the sprint? I didn’t when I was a ticket taker a decade ago.
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.
I write a ticket describing the work (takes no more than five minutes), open a PR, and get someone on my team to review.
The engineers on my team dictate the process because we've repeatedly earned our manager's trust (and he's a great manager).
Impact.
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.
I would guess that bloat at Spotify is a direct result of empire building by the numbers.
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.
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.
The problem with this is that because of salary compression, it’s usually better to job hop.
- 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
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.
https://www.forbes.com/sites/bryanrobinson/2024/11/05/64-of-...
Let’s talk about the raises I have gotten from job hopping since 2014. I have been working a lot longer.
But if the company could pay me more and thought I was worth more, then why didn’t they offer me that in the first place?
2012 I was working for a then F10 company (GE) after two years of across the board 3% raises, I left for a 25% raise in 2014. The manager couldn’t push for larger raises at GE. The entire team of 15 left within 6 months.
Stayed at the next medium size company for 2 years and no raises. Left for another medium sized company for a 20% raise.
Stayed there for two years and did a vertical move to get the chance to be on the ground floor when a startup hired a new CTO who wanted to bring all of the development in house and wanted to be “cloud native”.
Two and half years later a job at BigTech fell into my lap - a 40% increase in comp.
I was at BigTech for 3 years and took a pay cut when I left. But by then, I valued piece of mind and work life balance over money. Within a year of me working at the company, my current employer reached out to me. Pay was the same. But it was more aligned to what I wanted to do, better benefits and most importantly, unlimited PTO and I fully expect to take 30 days off this year.
None of the HR departments at any of the companies were going to be willing to go from 4% raises to 20-40% raises.
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).
Getting a product manager to write technical tickets is generally a mistake, I would say.
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.
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.
It's not good for the psyche.
This is obviously not something everyone can do, but if you can, maybe it's worth it.
You do that by being able to communicate about the trade offs between the holy trinity of projects - on time, on budget and meets requirements.
I'm incredibly burnt out currently, and I'm consistently at under 40 hours at my job.
If either of us at anytime decides that the labor for money transaction is no longer needed. I get another job.
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.
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.
If you follow this blog post's advice, the move in the cases I've described would be "bring it up with your manager/skip and then absolutely do not do anything until they say 'wow that's a big deal and it's important that you fix that.'" Or you wait for it to take down the company and then you get to play the hero in that big incident call mentioned by the OP. I'll be explicit: if you feel you need to do this at your job, you are working in a dysfunctional organization. If you can't independently and proactively take action to improve things for your customers without gaining some "minimum amount of glory", you are working in a dysfunctional organization. I recommend not working there. Or I recommend cynically gaming the system.
What I do not recommend is writing blog posts all about how your job is to be a sycophant who only ever does what your boss thinks is important right now and nothing else. Have some humility and try to make a difference to actual people and the bottom line, not just the latest gilded crown to command the land.
All large companies are dysfunctional. If you want to maximize your compensation, you play the game. The top end of enterprise dev is around the entry level of BigTech.
While at 50 I don’t want to play that game (been there done that), I would definitely give someone younger the same advice as the author.
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.
If you look at sprint histories, and went purely off of tickets, you might think they did nothing at all! And maybe they don’t!
But, they’ve shipped a few key projects and features that totally improved our product so much that now everyone has less work to do because everything just works so well most of the time.
I think of these guys as the big guns, we just keep them around on payroll in case we have something really difficult to do.
I don’t see myself doing any real coding at least for the next six months.
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”
If you ship a project and your management chain begins talking about the next thing, stop improving that project. In my experience, continuing to work on an already-shipped project is a very common mistake. Declare victory and walk away!
Take some pride in your craft sheesh
True but what if you're stuck in a job where crushing Jira tickets is the metric?