Comment by JohnMakin
1 month ago
Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team against obtuse velocity metrics like this.
productivity metrics aren’t entirely worthless. if I come into a team, for instance, and I see they have 1 PR mapped to roughly every 1 jira ticket, and I see a guy on a 3 person team that’s got 70% of the PR’s in a year, that isn’t a clueless piece of info. he’s probably the lead. not always, and people game stuff like this, but it is a data point you can make note of.
> 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?
9 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.
1 reply →
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.
3 replies →
> 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.
That's how you get individuals who insist that you attach their name to your ticket (or better yet, do it themselves) after they helpfully inform you about an automated test failure in your commit. "Relentlessly mentoring team members on culture of quality" et cetera.
Exactly. If you don’t consider how people might game the system, you are in trouble. Little fixes like this open other possibilities for gamesmanship and now people fight over whether their contribution was good enough to be included in the ticket.
I mean, all of this is gamable by those who want to minmax. But this is a workplace and those kinds of abuses can be solved with a slap on the wrist 80% of the time.
You're absolutely right, but some people just refuse to play silly games. It's odd that the manager isn't ever in the room with the team and doesn't understand his team's dynamics. Giving the benefit of the doubt, he must have been new, but any manager worth his salt will ask people on their team what the team dynamics are.
My understanding is that metricizing like this is a tangible way for managers to defend "underperforming" team members to upper management. Your manager can always say you're a valuable member of the team and that will certainly go quite a way, but it's even more powerful if your manager can say, XYZ is an I valuable team member, if you need evidence of that, they provide a lot of value in supportive roles like on these tickets. [Listing tickets].
Agree on silly games, but this is simply acknowledging others' contributions. I think this should be encouraged in general, metrics or not
I agree. I think it's pretty absurd that the manager was all set to fire him just based on metrics. There's a quote that I'm going to horribly paraphrase that goes like, "when you can measure something, that ends up being the only thing that matters."
At least he asked the author his opinion first.
Having said all that, if he took it upon himself to be a mentor to other developers and didn't do any tickets himself, that seems a bit odd, unless it was explicitly decided/communicated that would be his role. I would think roles like that are half time mentoring and half time doing tickets, but I don't know enough about the team to judge it. Like I said, I'm assuming the manager was new to the team.
I'm actually shocked that Tim, himself, knowing the metric exists and was going to be used in firing decisions, did not attach himself to all these tickets in the first place. Talk about a lack of self-preservation. Everywhere I've seen that measures performance by some metric, everyone instinctively tries to pump that metric all by themselves. No other motivation required.
Not everyone will play the metrics games.
Some people will just find the metrics dumb and depressing, and avoid them. (As might've happened in the article.)
Some assume it will go away in time, or that their manager will cover for them. (As eventually happened in the article.)
Some have behind-the-scenes talks with managers+execs+HR, to end bad metrics.
Some will melt the metrics with the intensity of their look of disapproval. (Management ProTip: this level of will is better harnessed to solve business and engineering problems.)
Yup, I didn't play the metrics game, and I got burned because my metrics don't look as good against the co-worker who plays the game. The cost is having to remind everyone how much work you actually get done and how much you actually support the team when those "your metrics tell us you're not doing enough" talks come up.
2 replies →
That's a very personality and culture related phenomenon. A lot of folks will, but also a lot of folks won't.
Pointedly not playing the game when you have the political power to do so is often the most effective way to point out issues in the system that folks are being evaluated under. It can be a very wise move in some cases, as well.
Tim probably realizes that if he tries to get on tickets he’s helped with, he’ll probably end up on maybe 30-50%. If he never asks for credit, and yet is seen constantly working, people will inflate the zero to hallucinatory levels of productivity.
I consider myself a Tim here. My value is not primarily in my individual contributions, but how I eleveate the rest of the team.
If my manager demanded this type of bean counting, I'd just take my talents elsewhere. I'm not interested in that kind of game. I'd take the severance and go find a new team to make better.
Sounds like Tim's in a position where he knows he's appreciated by his team and enjoys his work, and is more than skilled enough to jump ship the second upper management decides to upend that. He has no reason to play the silly metrics games
Yeah, Tim would be poached in days if he leaves for whatever reason. People with that kind of genuine talent or passion to just help make everyone around them be a better version of themselves don't worry about being out of work long.
Play the game and any number of management fuckends will prop themselves upon your shoulder. Unless youre into that sort of thing.. no judgment..
Both "trivially" and "fixed" are doing an incredible amount of heavy lifting here.
That doesn't work with automated metrics, whomever is assigned the work item gets all the points.
Tim's problem is that he has a bad manager. One of a manager's core jobs is to communicate upwards the value that each team member is providing (or not providing). His job was to ensure that Tim's contribution were reflected and visible.
According to TFA, that's exactly what the manager did.
In football you track not only the goal scorers but also the assist (the person who passed the ball to he goal scorer). That still does not cover all contributions, but maybe that's a way to create more transparency for Tims case ?
That's an intersting point. I don't recall ever seeing a ticketing system where you could assign a ticket to multiple people.
In one of the systems I worked with each ticket had an "assignee" (who did most of the work), a "tech lead" (who knew what's going on and could provide status and guidance), and an "executive owner" (the person you'd escalate to if needed). I suspect those were custom fields and schema could be extended further if desired.
Ah, the "Quentin Tarantino presents" pattern. Nice.
[dead]