Comment by bberenberg
1 month ago
I don’t think anyone is saying it’s a good solution. It’s one amongst many bad ones that are used because that’s what we have. For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels. One of the reasons is to see who’s spending a lot of time lending a hand. Guess what, devs refuse to do that. So what am I supposed to do?
I have a person who I highly suspect isn’t doing much work, and is basically rotating through other team members to help him get unstuck. Not a bad guy, but probably not up to our standards. Just ask people you say? Many cultures don’t allow for someone to say bad things about their coworker even if it would help to improve the team.
I’m not arguing for any one solution because I don’t know of any magical solution. 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.
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.
One of the members of the team is barely doing anything and survives by constantly asking others to help with doing the job. This reducea productivity of other employees.
A known archetype in many jobs, not only programming.
Yet we get comments like this:
> you don´t have the necessary competence to validate your suspicion about one of them not getting work done, coasting off of others
Wow.
In any other job, a manager ir HR will just read your chats, emails + demand to document calls - and guess what. It can be found. In a very not very subtle way.
Also the problem above is like managememt 101? For all the talk about "no technical competence" you dont seem to have any managerial competence.
Also the agile idea that developers keep each other to professional standars is a nice fairy tale (like whole agile in general).
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.
6 replies →
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.
No offense, but it sounds like you have jumped to a conclusion (which you can't even prove) and are trying to change the process so that you could nail the poor guy.
What is your purpose? Making the team perform great, I hope. Will you achieve that by picking on someone? Hell no. Others will protect him, because they know they will be next in line. Do you think the "underperformer" (if he really is that, even) is doing that because he is lazy? It is more difficult to ask for help all the time than just to do something.
How about you try to find a way to help him achieve the level that others are at? THAT is what should be your goal. Instead of spying on them, award team members who help others, so that they won't feel the need to hide. And make weak members feel safe. Currently it sounds like the environment is pretty toxic with regards to admitting to any problems.
If, after all the genuine effort, you still fail and need to let go of the guy, because he is really bringing productivity of the team down and you can't motivate him to change, then you should know that this is still primarily your own failure. Which is ok, everyone is allowed to fail from time to time. But it is a signal that you should try harder.
(speaking as someone who had to let someone go because I wasn't good enough to make them better... on two separate occasions... so I'm not judging)