[nabdab]

It’s a valid concern. If you don’t have transparency into ongoing work, then you aren’t ready for remote workers.

If the only method for your manager to know what people are working on is to tap people on shoulders, then doing that isn’t a “bad behavior” for the manager, it’s necessary behavior.

Of cause a better solution is to have trust and plans. (Agile, scrum, waterfall, napkin sketches or whatever it doesn’t matter as long as people align during planning and have transparency into the plan). But in the absence you still need to have management in sync with what is going on.

Naturally the best pathway forwards is to look into changing your system to include all these value adding elements. But enabling remote work while management is critically dependent on physical presence to continue operation is not a good idea. And the solution is not just for managers to “give up the mindset” of knowing what’s going on below them. Trust is great when it works, and toxic when it doesn’t. The agile mantra of increasing trust is not just supposed to advocate blind trust. It’s about building a framework and working routine where we are validated in trusting each other.

[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

[growlist]

One thing that amuses me - you can provide the very simplest tools (such as an issue tracker report) and some managers will still utterly refuse to use them, to the point of open hostility, because it somehow undermines their position to open a link and read an online report as opposed to asking a subordinate to read it to them instead ¯\_(ツ)_/¯

[sanderjd]

Yep, my biggest frustration is when people (not just managers) ask questions instead of looking things up. And it can be hard to push back against because they are "just trying to get the answer more efficiently by just asking". Which is true, it's usually more efficient to ask someone who knows something than to find something yourself. The problem is that it preempts work to be done in serial instead of doing a bit more work in parallel. There is a point at which that makes sense, there are things people know that require a lot of legwork for someone else to find out for themselves. But "what are you working on" is pretty much never in that category.

[otaviokz]

Unfortunately there's always people living in the 1800s...

[growlist]

True. The enterprise sometimes keeps going in spite of its leaders...

[100100010001]

I disagree with the “tapping on the shoulder isn’t a bad behavior”. It is counterproductive as illustrated by the linked cartoon.

https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

[vidarh]

They weren't saying it isn't a bad behavior in general, but that in the absence of visibility into what staff is doing it is a necessity. It's far worse than having proper visibility, but until/unless you have that visibility, it's a lowest-effort way of getting some visibility.

Of course the right thing to do is to work to get proper visibility, and when you have that, then the "tap" is pointless interruption.

[auiya]

Managers who tap aren't interested in work visibility. That can be achieved via a simple email. Managers who tap are only interested in hearing themselves talk at others.

[croon]

> If the only method for your manager to know what people are working on is to tap people on shoulders, then doing that isn’t a “bad behavior” for the manager, it’s necessary behavior.

It is bad behavior, for two simple reasons:

1) The tapping of the shoulder (both literal and figurative) doesn't award any information, only the question afterward. So focus on what that question is, and implement whatever information that gets you (if any) into another system that doesn't require you huffing around interrupting the flow of your employees.

2) If that is your only method, you have already failed, and anything you do in that position that is not directly related to getting out of that position, is bad behavior.