[thrownaway954]

My manager _constantly_ will shout out, "does anyone know what X is working on?" It pisses me off to high hell that a manager has to ask his workers what another worker is working on.

I honestly think that EVERYONE should be using a ticket tracking system and just put assignments in a person's queue. I don't see why this is such a big deal or looked down upon. It's so easy to see what everyone is working on, run reports to see how long things took, have a place to keep track of notes which builds a knowledge base, the benefits are limmitless.

Not to mention the fact that if all you have to do is look at the reports to know what is going on, you don't physically need the person there which will allows them to work from anywhere.

[quadrifoliate]

> I honestly think that EVERYONE should be using a ticket tracking system and just put assignments in a person's queue. I don't see why this is such a big deal or looked down upon.

As I see it, none of the queuing stuff is really controversial.

> It's so easy to see what everyone is working on, run reports to see how long things took

This, on the other hand is usually what's controversial, and the reasoning behind that is that it often leads to management using past data as a stick to drive "faster" future development, with silly statements like “Well, the average plugin took 2 days to write, why is this one taking 7 days? Oh it must be that the person doing it is lazy. Better give them negative feedback on it and tell them it can affect their promotions”.

The example is contrived, but the motivations and behaviors are very real. Competent developers tend to leave companies where they are constantly badgered about stuff like this by managers who have never developed software. In the extreme case (very few organizations are this bad, but they do exist), all you end up with is the remaining ones who know how to show that they are doing a lot of work, but are generally afraid to show their lack of knowledge in any area for fear of being dinged by the data-equipped management for it.

Since this is not conducive to the technical health of a software development team, estimation practices that purport to be unrealistically accurate are what's looked down upon.

[krageon]

> management using past data as a stick to drive "faster" future development

Of course bad management is bad, but the idea that the type of metrics available to them make any material difference is not one that has any merit to my mind. A bad manager will always make your life hell, regardless of what measuring tools they have available.

[quadrifoliate]

> A bad manager will always make your life hell, regardless of what measuring tools they have available.

Correct. That's why developers with bad managers strive to make as few measuring tools available to them as possible. In other words, if you're a manager and your employees seem to resent and fight against more ways of measuring "velocity" and the like, you should probably consider that your usage of this data and how you express the results might need some work.

[siffland]

A huge problem with ticketing systems is then management uses it to track all productivity.

We had a ticketing system and one guy in our group had between 60% and 80% more tickets than the rest of us. So it would seem we were all slackers, however he took the tickets that took like 2 minutes to do (password resets, account unlocks, etc...), meanwhile i would get stuck troubleshooting a production performance issue that would consume hours. Management didn't care what the ticket was, they liked to see pretty numbers of tickets completed.

I might be the only one who had this experience, and i am not saying ticketing systems are bad, they are extremely useful, as long as everyone knows how they work.

[garettmd]

You're definitely not the only one to have this experience.

Honestly, I think the problem is structural with regard to management. Just changing the process or tool (ticketing vs constant communication with manager) isn't enough. It probably needs to be combined with smaller teams (i.e. Amazon's pizza rule) and management defining goals and "success" as more than meeting some narrow KPIs (MTTR on tickets, for example)

[thrownaway954]

On the flip side... At my previous job, cause of the ticket tracking system, it was shown that I handled 40% of all tickets that came into our team of 7 people. And this wasn't 2 minute tickets either, these were projects also.

Sorry you had that experience, but to me the justification of those types of system are solid.

[taurath]

All you need is a 10 minute standup to solve that problem every day. You can even do it async and have people post it on slack or something. If people aren't saying it in enough detail, then ask for more detail.

[RhodesianHunter]

Take the ticket backlog one step further, have a scrum board with to do, in progress, blocked, done columns and then management can't get an excellent high level view at any time