I have a bunch of thoughts on those in general. I agree, a good manager should know who is doing what and if not, why. It could be laziness, it could be that th

I have a bunch of thoughts on those in general. I agree, a good manager should know who is doing what and if not, why. It could be laziness, it could be that the rest of the team is completely insufferable and they are only doing the bare minimum until they find a better job(I've been guilty of that one) or 20 other factors, who knows. But all the associated tooling that has been created over the years for figuring out who is doing what are insanely counter-productive. Assume you work in a large corporation and you are tasked with "implement and deploy X". Fine. But in order to deploy it, you need to rope in a dev ops, sec ops, 3 other people to sign it off and 10 other tickets being tossed around between a dozen people which are nearly impossible to track. All while your manager is sitting there, looking at this one ticket assigned to you and be like "tf?" So no only do you have to effectively manage a process involving 10 people but you also need to find a way to show that you are in fact trying your best to make progress. Keep in mind that everyone else working on your problem are also involved in 4 other things in each given time. For a manager to be able to work through that, they must be ready to put the needs and comfort of the people they manage before their own and be ready to make some internal enemies in the process. So far I've had two such manager in my whole life and it was a genuine pleasure to work with both of them - everyone was doing the absolute best they could 100% of the time. In both instances, we had 0 tools to monitor who is doing what - the only tool we used was gitlab with merge requests, even if the company enforced Jira. What the managers did was manage Jira on their own completely and not bother developers at all with it. As a tech lead, I did not even know where to access Jira. And when we got asked how come we get everything done a month and a half before anyone else, the simple answer was "f-bureaucracy". Even when it came to dev ops and stuff, we had become friends with some of them and had an internal rule: "Before sending an email, send me a message in the chat so I know what's needed and I can prepare myself, send us an email and send me the ticket id you get. We love working with you cause you come with clear instructions and no bs". This is an exact quote from a devops in Ukraine who had around 150 words in his English vocabulary. And whether it was a kubernetes cluster, network configuration, upgrades, downgrades, backups or anything else, the most we've ever had to wait was less than an hour. You don't need Jira to know when someone is slacking, whether you are a manager or someone else - you can't hide that and we've had such people on those teams, it's up to the manager to address those. This is of course large corporations. In smaller ones, it's less straightforward and even more in the hands of the managers. The first question you need to answer is whether those companies aspire to be large corporations while having 50 employees(in total, I don't mean in the tech departments). If that is the case, then it's the same as what I described above and if you pull she short straw(the way I did at my old job), end up with an absolutely insufferable, egocentric team and a manager who's policy was "don't start conflicts, no matter what, sweep any confrontation under the rug as fast as possible". The second type is the Jira(and jira-like) obsessed managers in small companies where acting as a developer, dev ops, infosec, network admin and hardware admin are the same thing for everyone involved. This is fine to my mind, but we get back to "implement and deploy X". Do you want me to log every action I do, while doing a ton of R&D, setting up a redis cluster, kafka and 3 other things or should I focus on getting it done asap because those things are mutually exclusive. And the last type, which appears to be my current job - "0 nonsense", "nothing will ever be perfect", "we know we are fixing our car while driving it" are all 100% acknowledged by everyone, management included. A small board with what is needed, "whenever you have time, figure it out". It may sound bad, but it works astonishingly well.