Sounds like both a lack of trust and communication between you and the team.

> If you have better metrics or management skills than what everyone in the world has figured out, myself and many others would gladly adopt these approaches.

Oh boy...

edit: One issue might be they fear that bad news will lead to a knee jerk reaction that gets them or their teammates fired. They should feel comfortable to encounter problems and openly discuss them in the open with out fear of repercussions. In fact, I would argue this is one of the major advantages of a team; pooling collective knowledge and abilities. If people fear honest communication then the performance of the team is impacted. The manager has the greatest ability to fix this, IMHO...

First off - please do not be offended by the following comment, there is zero bad intent in it and is only meant as a way of nudging you into a correct mindset about the problem you described. Based on your public profile, you seem to not have much in the way of hands-on technical background and I suspect you manage your team based on some set of scrum/agile techniques. It can work purely for project delivery I suppose. However for the deeper analysis of your team productivity, the problem is you don´t have the necessary competence to validate your suspicion about one of them not getting work done, coasting off of others etc. There is only two ways to go about it. Either you hire (or promote) a technical lead in your team, who can then actually make that call, or you learn programming yourself, accrue at least a year of real technical experience and then try to evaluate. I am saying this because I have seen people with background similar to yours usually struggle, because they try to infer something about engineer productivity based on various proxy measures, such as who talks the most in the chat, who has most commits or even based on activity in Confluence. The way I would recommend any scrum master/PO/agile coach/MBA to think this dilemma is: you would not be able to judge the quality of work of a medical doctor, lawyer or a mechanical engineer, without having a similar background, experience and competence. So what makes you think you can evaluate software engineers without the same preconditions?

I think lots of the other comments are making wild assumptions leading to responses that don’t align with reality. Yours is actually the absolutely correct one. I agree with the solution wholeheartedly. The only difference is I have been trying to promote the tech lead from within vs hiring externally. I want the team to know that we value their contributions and that we’re going to do everything we can to promote internally. I have various challenges with this internally related to seniority, language skills, etc but I’m working to resolve that.

But in the meantime, I still have a team to manage.

Sorry but what is your point? I feel like you got offended by identifying yourself in it, but did not really understand it. My point being, as a non-engineering manager, you can be great at 1) approving holidays 2) doing a bit of project management 3) doing formal 1:1s . But it does not mean much because you don´t understand the work being done and you are just doing performative actions, e.g. busywork. Or we just say, f*ck it, let MBAs and scrum masters keep running our critical engineering businesses and at the end of the day the doors fall off of Boeing airplanes and astronauts end up spending 9 months instead of 9 days in space.

Only an engineer with 30 years of experience can tell that a Mustang is better than a Model T /s

Why the /s? You're mixing apples and oranges I am afraid. Being a consumer of some product, is not the same as engineering the product. So you have the latest iPhone, good for you - still does not make you an engineer, nor do you have a clue what goes into designing, conceptualising and building a product. And yes, those of us with a bit more experience in the field, remember the times when engineering was done by people who had passion for it, not people desperate to make a career and income upgrade through bullshitting in meetings. For engineering a great product, as we can see with the great entshittification of pretty much everything today, Boeing being the most dangerous example, it's not just that the performative workers are being a drag on productivity and profitability, they are now also endangering everyone. I sure hope some idiot MBA does not come up with an idea of a medical PO or scrum master.

One does not need 20 years of programming experience to identify and fire a shitty employee that coasts by constantly asking others for help with their job. There are tons of bad programmers just like there are tons of people bad at other jobs. Those employees are often a net negative for the team by constantly wasting someone elses' time.

On a side note, your constant whining about "MBAs" and "scrum masters"... it does not make you sound like a professional or reasonable person. This black-white view of world, that "all MBAs are bad". Whoa.

(Just because I know where you will take it: (sadly?) I dont have an MBA. I am also not a scrum master)

No, please, instead of pointing out everything that is wrong in your reasoning: Please read a referent book about managing software development teams. For example "Peopleware", or "Dynamics of Software Development". Both a bit older, but valuable classics. The second one actually written by a relatively less technical author, a product manager at Microsoft. Maybe then you'll understand a bit more. By the way - I am not the only one complaining about the MBAs. Remember when that plane door fell off? US Congress was holding a hearing about that. And a number of US Congressmen (or were they senators?), people who literally never have the discussions that you and are having, kept asking one simple question: "How come the CEO of Boeing is not an ENGINEER"? It's so natural, that even those disconnected politicians made the obvious connection. Look it up in the archives.

Well, since you cant point out anything, you point out some random books.

I will point out something else: get tested for schizophrenia.

Random books, schizophrenia? I am the one not pointing out anything? Perhaps read your own replies slowly and reflect again :) I won´t dispute your medical competence, as I don´t have any and you seem to be an expert obviously, but for your own good, the two books are classics in their category, which you´d know if you approached your managerial duties with a tiny bit of sense of responsibility towards self-development.

It sounds like your employees believe that talking to you or amongst each other, where you can read it, will get their friends laid off or bad decisions made without advice. You might want to put a layer of management between you and them, if you can find someone with the skill of trust and relationship building.

I think a competent technical lead would do wonders in this case too ;)

Formalizing a productivity metric won't help you with any of that. And I'm sure that one guy you mentioned will learn to game the metric faster than the other developers will learn to fit it.

> "I keep begging people to have conversations in public channels... Guess what, devs refuse to do that."

So, stop begging. Managerial directives come as orders, not pretty-please requests. Also, stop letting your subordinates refuse you. They are your reports, you are approving their money, that can change if they aren't doing their jobs. Fire one for ignoring policy, and their attitudes will change.

On the tech side, clarify that you want all project comms logged and searchable for onboarding and auto-generating documentation as well as identifying technical hotspots where investments in refactoring can save the team time. Whatever. What gets measured gets done, if you are trying to spy on everyone, this is a bad way. Do it if it has value.

> "Many cultures don’t allow for someone to say bad things about their coworker"

Managers in any culture, and especially across cultures, are tasked with learning those cultural sensitivities and then working around them pragmatically. You have identified a problem. That is the start of solutions, not the end of them.

> "If you have better metrics or management skills than what everyone in the world has figured out"

This kind of attitude isn't productive at finding genuine answers, and might be obfuscating the problem.

Lots of people have figured out better metrics and management skills than the local application suggests. It's not the advanced esoteric stuff that is missing, it's the basics.

> Fire one for ignoring policy, and their attitudes will change.

Yeah, the next day they'll start updating their resumes and sending out feelers to their network.

With this attitude you will grow a very specific kind of team. They will be very productive according to your metrics, fiercely loyal, and lethal to anyone who doesn't fit in. However, $diety help you if you ever need to innovate.

It's sad that you get downvoted for providing solutions.

> For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels.

No one does this because it's a bunch of bullshit noise in a channel disrupting everyone. It also opens a conversation up to bikeshedding which drags down the entire discussion.

Small ad-hoc groups can be very effective at solving problems.

1. The more intimate the group the less friction there is in conversation. There's less need/desire to put everything in "business speak" so no one gets their feelings hurt.

2. Small groups don't need to dumb down conversations for less technical participants if there's no non-technical participants.

3. Private chats mean no one is hovering over the conversation demanding some useless status update. A problem is either solved and committed or the group is still working.