6 ms·

The central point that work trackers track work is true important and jira astronauts need to be stopped, but the piece misses the bureaucratic purpose of jira:

The central point that work trackers track work is true important and jira astronauts need to be stopped, but the piece misses the bureaucratic purpose of jira: work legibility. Work tracking isn't just about figuring out what work needs to get done, it's about helping management get a picture for the state of work. Developers and other line workers don't care about obsolete vs won't do. But management does. They want to know if they're being requested for work that will be rendered useless in a few weeks. They want to know if too much work isn't getting done because work is floating up to the CEO and it's not worth his time. There's a terrible principal agent problem here where management, the principal, decides how to track work, and can put the heavy lifting of filling in values onto the developers. This happens when management's more worried about losing their job than improving their team's output.

Almad 6y ago
I do completely agree. In fact, when people asked me for JIRA, I've always said I am happy to do it since it's a software designed for me, the CTO. Yet I refuse to do it to them, the ICs.
twic 6y ago
There may be a similar legibility point about severity levels. Some boss somewhere has to put the set of tasks in priority order for the development team, and once it's in that order, severity levels are useless for the developers. But they might be useful as a way for the person submitting the issue to communicate something to the boss who does the ordering. Say there's a billing system. One of the accounts receivable clerks notices that due dates aren't properly adjusted for public holidays. As a developer, do you know how big a deal that is? Probably not. Doesn't sound like a big deal. But maybe it means we're imposing penalty charges on customers where we shouldn't be, and that's a huge legal and reputational risk. Or maybe it really isn't a big deal! The boss will need to have a conversation with the clerk to learn all this, but maybe having a severity field is an ice-breaker for that conversation.
- ydlr 6y ago
  Why not have the clerk assign the severity? Why can't the programmer and clerk discuss the problem themselves if there is uncertainty? The only problems in your scenario arise from the introduction of a boss as go-between.
  - twic 6y ago
    I am proposing that the clerk should assign the severity. You could have the programmers do the prioritisation, if they had the business understanding to do that. In that case, they're also the boss. The severity assigned by the clerk could still be a useful starting point.
karatestomp 6y ago
> There's a terrible principal agent problem here where management, the principal, decides how to track work, and can put the heavy lifting of filling in values onto the developers. This happens when management's more worried about losing their job than improving their team's output. I no longer believe a single tool is good for both a team tracking & communicating amongst themselves about the work they're doing, and communicating the same to and among management. Trying to make them both the same thing is a great way to come up with something that's terrible for one or the other of those uses (usually the former).

Almad 6y ago

I do completely agree. In fact, when people asked me for JIRA, I've always said I am happy to do it since it's a software designed for me, the CTO. Yet I refuse to do it to them, the ICs.

twic 6y ago

There may be a similar legibility point about severity levels. Some boss somewhere has to put the set of tasks in priority order for the development team, and once it's in that order, severity levels are useless for the developers. But they might be useful as a way for the person submitting the issue to communicate something to the boss who does the ordering. Say there's a billing system. One of the accounts receivable clerks notices that due dates aren't properly adjusted for public holidays. As a developer, do you know how big a deal that is? Probably not. Doesn't sound like a big deal. But maybe it means we're imposing penalty charges on customers where we shouldn't be, and that's a huge legal and reputational risk. Or maybe it really isn't a big deal! The boss will need to have a conversation with the clerk to learn all this, but maybe having a severity field is an ice-breaker for that conversation.

ydlr 6y ago
Why not have the clerk assign the severity? Why can't the programmer and clerk discuss the problem themselves if there is uncertainty? The only problems in your scenario arise from the introduction of a boss as go-between.
- twic 6y ago
  I am proposing that the clerk should assign the severity. You could have the programmers do the prioritisation, if they had the business understanding to do that. In that case, they're also the boss. The severity assigned by the clerk could still be a useful starting point.

karatestomp 6y ago

> There's a terrible principal agent problem here where management, the principal, decides how to track work, and can put the heavy lifting of filling in values onto the developers. This happens when management's more worried about losing their job than improving their team's output. I no longer believe a single tool is good for both a team tracking & communicating amongst themselves about the work they're doing, and communicating the same to and among management. Trying to make them both the same thing is a great way to come up with something that's terrible for one or the other of those uses (usually the former).