Comment by motorest
1 month ago
> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on.
I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by any metric.
In the end you're building up a system where everyone participating in it knows it's a fraude but just keep gaming it because they become too heavily invested in it.
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).
7 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)
I have managed a team in an organisation that used Jira heavily to measure velocity and having all contributors record time on tickets, even if they were just supporting, did actually help lots:
1. It allows for more accurate estimations (ie this is not a multi-day task but it is a multi-person task)
2. It showed where knowledge transferring was happing
3. It showed that people were busy so that it meant we were making accurate estimates to begin with.
I do think Agile can get overly prescriptive. But if you do happen to work in a company that operates that way, pushing back might be impossible. So having multiple participants record their effort against the same ticket then allows a more organic way for the team to operate despite the rigid structure of a stricter scrum dynamic.
Or in other words: sometimes you cannot change the system entirely so you’re next best option is to tweak it so it at least better works for you. And that’s what the GPs suggest achieves.
While a number measuring productivity may not work, I read the GP as simply recording contributions.
I like that approach. Now you can not only have peer recommendations, but also tangible records.
In large org, i saw people quietly move up the ladder this way by being visibly effective even if their outright contributions may have been difficult for nontechnical or understaffed management teams can see. it’s an essential survival skill, not making any case whether or not it’s right to begin with - I often navigate these systems because I have to.
you will of course have people gaming the system but peers tend to realize what is happening there, and that’s a management problem IMHO
More like bug/case tracking is crap on this. All the ones I've ever used only support one assignee, so even in equal pair programming you have to choose who officially gets the case.
They're suggesting working around the case tracker, not around the metric.
> This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work
It's just like in physics: "all models are wrong, some are useful". All metrics are wrong, but some are useful when they are correctly applied.
In a company or any business you need to deliver something, if you are being paid X amount of money, the payer needs to know they are getting something in return, and it's not a management problem that they ask what was done this week.
GP is orking off the assumedly common premise of peopel raising complaints of metrics and getting shrugs from management or Product. Who have their own incentives to keep them up.
if you can't throw out the game you may as well adjust the rules.