4 ms·

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

89 points by scarface_74 2y ago

asdasdsddd 2y ago
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.
- scarface_74 2y ago
  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://www.levels.fyi/blog/swe-level-framework.html https://dropbox.tech/culture/sharing-our-engineering-career-framework-with-the-world 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 2y ago
    Thanks for sharing
- Trasmatta 2y ago
  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.
  - Ancalagon 2y ago
    This is what bothered me so much about my last job. Thank you for saying it so succintly
    - Trasmatta 2y ago
      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.
      - scarface_74 2y ago
        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.
        Trasmatta 2y ago
        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.
        scarface_74 2y ago
        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.
      - strken 2y ago
        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.
- hinkley 2y ago
  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.
5- 2y ago
> 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 2y ago
  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.
- deleted 2y ago
  [deleted]
- nosefurhairdo 2y ago
  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 2y ago
    How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?
    - theamk 2y ago
      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.
neogodless 2y ago
> 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.
nosefurhairdo 2y ago
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.
- kidbomb 2y ago
  It's not about crushing tickets. It's about crushing the right tickets.
- bashtoni 2y ago
  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 2y ago
    But only to a mid level developer.
- scarface_74 2y ago
  > 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”.
- theamk 2y ago
coldcode 2y ago
I first thought the headline was about crushing Jira itself. Many days it could be very tempting.
deadbabe 2y ago
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.
- scarface_74 2y ago
  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.
  - codingdave 2y ago
    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.
    - scarface_74 2y ago
      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-consulting-needs-assessment-consulting-advice 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”
JoshuaRogers 2y ago
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.
- deleted 2y ago
  [deleted]
- scarface_74 2y ago
  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”.
syndicatedjelly 2y ago
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! Got it. Shipped = Victory. Take some pride in your craft sheesh
- scarface_74 2y ago
  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”
  - khana 2y ago
    [dead]
  - syndicatedjelly 2y ago
    Why are you so conditioned to think that fancier titles and more and more money is the end goal of it all?
    - scarface_74 2y ago
      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.
      - robertlagrant 2y ago
        Your apparent "need" for food and shelter is a social construct! Get out there! And by "out there", I mean out in the cold!
    - hobs 2y ago
      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).
ripped_britches 2y ago
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 2y ago
  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.
khana 2y ago
[dead]
jvalencia 2y ago
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 2y ago
  > No ticket or product manager is perfect Getting a product manager to write technical tickets is generally a mistake, I would say.
potato3732842 2y ago
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 2y ago
  > 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 2y ago
    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 2y ago
      > 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 2y ago
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.
pockybum522 2y ago
Then why should any company even use/have jira
- tikhonj 2y ago
  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!
- intelVISA 2y ago
  You'd obsolete 30% of tech 'work' without it. Unless you're a shareholder why would you want to cut bloat?
lelandbatey 2y ago
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.
- scarface_74 2y ago
  > 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.
  - 2y ago
hyperpape 2y ago
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.
Artoooooor 2y ago
"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 2y ago
  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.
cratermoon 2y ago
> 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?
- scarface_74 2y ago
  “Either change the environment or change the environment”
rurban 2y ago
Thanks for the advice to shipping bugs and unstable software with a lot of features. Thanks, no
kledru 2y ago
well, projects are a party trick too

89 points by scarface_74 2y ago

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.

scarface_74 2y ago
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://www.levels.fyi/blog/swe-level-framework.html https://dropbox.tech/culture/sharing-our-engineering-career-framework-with-the-world 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 2y ago
  Thanks for sharing
Trasmatta 2y ago
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.
- Ancalagon 2y ago
  This is what bothered me so much about my last job. Thank you for saying it so succintly
  - Trasmatta 2y ago
    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.
    - scarface_74 2y ago
      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.
      - Trasmatta 2y ago
        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.
        scarface_74 2y ago
        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.
    - strken 2y ago
      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.
hinkley 2y ago
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.

5- 2y ago

> 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 2y ago
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.
deleted 2y ago
[deleted]
nosefurhairdo 2y ago
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 2y ago
  How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?
  - theamk 2y ago
    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.

neogodless 2y ago

> 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.

nosefurhairdo 2y ago

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.

kidbomb 2y ago
It's not about crushing tickets. It's about crushing the right tickets.
bashtoni 2y ago
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 2y ago
  But only to a mid level developer.
scarface_74 2y ago
> 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”.
theamk 2y ago

coldcode 2y ago

I first thought the headline was about crushing Jira itself. Many days it could be very tempting.

deadbabe 2y ago

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.

scarface_74 2y ago
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.
- codingdave 2y ago
  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.
  - scarface_74 2y ago
    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-consulting-needs-assessment-consulting-advice 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”

JoshuaRogers 2y ago

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.

deleted 2y ago
[deleted]
scarface_74 2y ago
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”.

syndicatedjelly 2y ago

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! Got it. Shipped = Victory. Take some pride in your craft sheesh

scarface_74 2y ago
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”
- khana 2y ago
  [dead]
- syndicatedjelly 2y ago
  Why are you so conditioned to think that fancier titles and more and more money is the end goal of it all?
  - scarface_74 2y ago
    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.
    - robertlagrant 2y ago
      Your apparent "need" for food and shelter is a social construct! Get out there! And by "out there", I mean out in the cold!
  - hobs 2y ago
    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).

ripped_britches 2y ago

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 2y ago
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.

khana 2y ago

[dead]

jvalencia 2y ago

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 2y ago
> No ticket or product manager is perfect Getting a product manager to write technical tickets is generally a mistake, I would say.

potato3732842 2y ago

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 2y ago
> 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 2y ago
  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 2y ago
    > 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 2y ago

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.

pockybum522 2y ago

Then why should any company even use/have jira

tikhonj 2y ago
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!
intelVISA 2y ago
You'd obsolete 30% of tech 'work' without it. Unless you're a shareholder why would you want to cut bloat?

lelandbatey 2y ago

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.

scarface_74 2y ago
> 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.
- 2y ago

hyperpape 2y ago

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.

Artoooooor 2y ago

"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 2y ago
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.

cratermoon 2y ago

> 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?

scarface_74 2y ago
“Either change the environment or change the environment”

rurban 2y ago

Thanks for the advice to shipping bugs and unstable software with a lot of features. Thanks, no

kledru 2y ago

well, projects are a party trick too