21–30 of 86 posts
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 cru…
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.
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 prid…
> 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.
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 ju…
I don’t see myself doing any real coding at least for the next six months.
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 cru…
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.
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 cru…
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.
> 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.
You know what killed the dinosaurs, right? Impact.