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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
I agree completely. I’ve been posting about leveling guidelines based on “scope”, “impact” and “dealing with ambiguity” here a lot over the past couple of days.
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.
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.
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.
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!
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.
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.
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.
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.
- 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
> 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.
I don’t disagree. however, I also think lots of people just don’t know how to negotiate. lots of people is complacent with “company policy, we do X% raise per year and no more” - however, if you go to your boss and say “hey, my performance is not up to par with my fair market value etc…” I think you’ll be pleasantly surprised what managers can pull with the HR. and if they can’t, that is unlikely a place you should stay
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.
I think the way your career fantastically progressed is majority of people - 100%. my career has been the exact opposite of yours :) 17 years at same place then independent contractor last 9. at a place I stayed 17 years my ending compensation was 4.7 times my initial compensation (which was not small, I got my Master’s during dotcom boom). when I left to go solo route I was offered close-to-6-figure bump in salary to stay…
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.
"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.
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.
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).
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.
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.
That's the nature of the job, we're not growing food to feed people. We tinker with with code in the hope that it helps someone else and sometimes it doesn't.
"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.
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.
I've started to think the solution to burnout is to just up and quit your job wherever anyone tries to force you to do anything without a good explanation.
This is obviously not something everyone can do, but if you can, maybe it's worth it.
Well, make them fire you, so that you get severance. And keep a papertrail documenting how you were told over and over to do things that made no sense to the company’s bottom line.
I disagree with this. You can burn out when working less than 40 hours. You can not burn out when working way more than 40. It has a lot more to do with other factors, it's just that those factors will burn you out even quicker if you're working too many hours.
I'm incredibly burnt out currently, and I'm consistently at under 40 hours at my job.
In that case you probably see your job as more than just a paycheck. I go to work for one reason - to exchange my labor for money. The company gets all of my skills and experience during work hours. But when off of work. I’m off of work
If either of us at anytime decides that the labor for money transaction is no longer needed. I get another job.
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.
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
This is cynical and accurate, and may crush your soul if you're not careful. Just don't get too caught up in mistakenly confusing "urgent" and "important" as this blog post (and many executives) seem to do. If you want to actually deliver value then that'll mean doing some amount of thankless and un-asked for work because nobody has noticed that if X/Y/Z isn't addressed/fixed/maintained then a major part/all of the company and/or it's products will grind to a halt. Similarly, if you can see that actual customers worth lots of money really want something that management is totally uninterested in doing, if you care about delivering actual value and not just being a sycophant, you'll do that work/make a lot of noise for those customers because your customers are the real boss.
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.
> 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.
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.
I would too, but I'd point out that what you are doing is playing the game, not actually delivering value. My annoyance is with the parent blog post which seems to imply that delivering value == sycophantic behavior, which just isn't true.
> 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.
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.
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”.
Yup. The people on my team who are the most respected and influential, getting steady promotions and good reviews, hardly crush tickets.
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 have been working at my current company for six months and haven’t wrote a line of code even though my title is “staff software engineer”. I have worked with sales and the customer to close two major deals…
I don’t see myself doing any real coding at least for the next six months.
Sounds like you got yourself promoted right up into a sales role. I mean, if you like that and are happy with it, I'm happy for you. But some people enjoy coding, so I'm not sure your success story is as strong of an anecdote as you might think.
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”
This guys’ posts read like someone put Paul Graham in a tumble dryer and interviewed him immediately afterwards on a topic pulled from a hat
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!
Because that's how the entire reward system is structured - ask management why they care about that stuff (money) and you will understand why people do it (money).
Jira/etc is not necessary, sufficient or even particularly effective for managing engineering work... but I've never had real success convincing managers of this unless they already thought like this. Changing somebody's fundamental approach to leadership is hard!
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.
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.
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.
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.
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.
Which reminds me of a previous discussion: Don't do easy things
https://news.ycombinator.com/item?id=27988260
> 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”.
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.
But only to a mid level developer.
It's not about crushing tickets. It's about crushing the right tickets.
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.
> 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.
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.
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.
How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?
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.
I agree completely. I’ve been posting about leveling guidelines based on “scope”, “impact” and “dealing with ambiguity” here a lot over the past couple of days.
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.
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.
I'm in such an organization, but this does not echo my experience.
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).
I write a ticket and open a PR and ask my team for review.
I agree with what John Carmack said about that.
https://news.ycombinator.com/item?id=26170052
You know what killed the dinosaurs, right?
Impact.
I was expecting "the ice age". Maybe I'm getting old...
It wasn’t “dealing with ambiguity”???
Deep.
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.
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!
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.
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.
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.
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.
> 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.
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
> 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.
I don’t disagree. however, I also think lots of people just don’t know how to negotiate. lots of people is complacent with “company policy, we do X% raise per year and no more” - however, if you go to your boss and say “hey, my performance is not up to par with my fair market value etc…” I think you’ll be pleasantly surprised what managers can pull with the HR. and if they can’t, that is unlikely a place you should stay
First, statistics back me up.
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.
I think the way your career fantastically progressed is majority of people - 100%. my career has been the exact opposite of yours :) 17 years at same place then independent contractor last 9. at a place I stayed 17 years my ending compensation was 4.7 times my initial compensation (which was not small, I got my Master’s during dotcom boom). when I left to go solo route I was offered close-to-6-figure bump in salary to stay…
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.
"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.
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.
I first thought the headline was about crushing Jira itself. Many days it could be very tempting.
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).
> No ticket or product manager is perfect
Getting a product manager to write technical tickets is generally a mistake, I would say.
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.
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.
That's the nature of the job, we're not growing food to feed people. We tinker with with code in the hope that it helps someone else and sometimes it doesn't.
"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.
This is what bothered me so much about my last job. Thank you for saying it so succintly
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.
I've started to think the solution to burnout is to just up and quit your job wherever anyone tries to force you to do anything without a good explanation.
This is obviously not something everyone can do, but if you can, maybe it's worth it.
Well, make them fire you, so that you get severance. And keep a papertrail documenting how you were told over and over to do things that made no sense to the company’s bottom line.
The prime cause of burnout is not saying “no” to being pushed to work extra hours.
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 disagree with this. You can burn out when working less than 40 hours. You can not burn out when working way more than 40. It has a lot more to do with other factors, it's just that those factors will burn you out even quicker if you're working too many hours.
I'm incredibly burnt out currently, and I'm consistently at under 40 hours at my job.
In that case you probably see your job as more than just a paycheck. I go to work for one reason - to exchange my labor for money. The company gets all of my skills and experience during work hours. But when off of work. I’m off of work
If either of us at anytime decides that the labor for money transaction is no longer needed. I get another job.
A good phrase to remember is “outcomes over outputs”
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.
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.
Thanks for sharing
This is cynical and accurate, and may crush your soul if you're not careful. Just don't get too caught up in mistakenly confusing "urgent" and "important" as this blog post (and many executives) seem to do. If you want to actually deliver value then that'll mean doing some amount of thankless and un-asked for work because nobody has noticed that if X/Y/Z isn't addressed/fixed/maintained then a major part/all of the company and/or it's products will grind to a halt. Similarly, if you can see that actual customers worth lots of money really want something that management is totally uninterested in doing, if you care about delivering actual value and not just being a sycophant, you'll do that work/make a lot of noise for those customers because your customers are the real boss.
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.
> 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.
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.
I would too, but I'd point out that what you are doing is playing the game, not actually delivering value. My annoyance is with the parent blog post which seems to imply that delivering value == sycophantic behavior, which just isn't true.
> 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.
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.
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”.
Yup. The people on my team who are the most respected and influential, getting steady promotions and good reviews, hardly crush tickets.
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 have been working at my current company for six months and haven’t wrote a line of code even though my title is “staff software engineer”. I have worked with sales and the customer to close two major deals…
I don’t see myself doing any real coding at least for the next six months.
Sounds like you got yourself promoted right up into a sales role. I mean, if you like that and are happy with it, I'm happy for you. But some people enjoy coding, so I'm not sure your success story is as strong of an anecdote as you might think.
Calling me sales? You don’t have to be mean (kidding, I appreciate sales more than most developers).
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”
This guys’ posts read like someone put Paul Graham in a tumble dryer and interviewed him immediately afterwards on a topic pulled from a hat
Got it. Shipped = Victory.Take some pride in your craft sheesh
I can’t exchange “pride” for goods and services. The people that hold the power to give you raises and promotions don’t care about “craftsmenship”
Why are you so conditioned to think that fancier titles and more and more money is the end goal of it all?
Because that's how the entire reward system is structured - ask management why they care about that stuff (money) and you will understand why people do it (money).
I have this insatiable addiction to food and shelter. If I could get over my addiction, not only wouldn’t I care about money, I wouldn’t be working.
Your apparent "need" for food and shelter is a social construct! Get out there! And by "out there", I mean out in the cold!
[dead]
Thanks for the advice to shipping bugs and unstable software with a lot of features. Thanks, no
> Everything you could want from a company - promotions, bonuses, internal respect - comes from shipping projects
True but what if you're stuck in a job where crushing Jira tickets is the metric?
“Either change the environment or change the environment”
Then why should any company even use/have jira
Jira/etc is not necessary, sufficient or even particularly effective for managing engineering work... but I've never had real success convincing managers of this unless they already thought like this. Changing somebody's fundamental approach to leadership is hard!
You'd obsolete 30% of tech 'work' without it. Unless you're a shareholder why would you want to cut bloat?
well, projects are a party trick too
[dead]