4 ms·
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
by theamk 2y ago
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.
- jq-r 2y agoWhich reminds me of a previous discussion: Don't do easy things https://news.ycombinator.com/item?id=27988260 https://news.ycombinator.com/item?id=27988260
- ebiester 2y agoTwo caveats for less-experienced engineers (whether by senority at a company or years in the industry): * As a manager, I would prefer you to crush those ten easy tickets if you aren't up to the task of the hard ticket. If that hard-for-you ticket is easy for someone with more skill, and we're in a high profile incident, I am going to steer you away from it. * As a manager, if you show me you can crush the easy tickets, I will find a way to guide you toward harder problems. Then, if you show you can do the harder problems, and those around you are in agreement that you are tackling those, then you have the leash to start swarming to issues. Note that you can usually prove this within 1-3 months - I'm not talking about an extensive time of paying your dues here. But make sure not to try and skip a rung.
- nosefurhairdo 2y agoI 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.