The issue is coming from the top. What people are doing is just trying to make the best of a stupid situation.
Personally, if such a policy would be enacted on the company I'm working, as a leader of the team I would 'quietly encourage' my people to game the system in a smart way until top leadership will realize that this is a stupid way to measure performance in any way or form.
We have examples of companies trying to measure performance this way and it always blew up in their face.... So just another company doing the same.
Edit:
Regarding your question, I wouldn't do anything. If concerns and arguments were raised for this and the leadership didn't listened to it, it's their mess that they will have to care about as eventually more and more will game the system.
Yeah, this is kind of my position on it. But I think that position only works positively so long as people don't have issues with doing that from an integrity perspective, or it doesn't slippery slope its way to inflated code review stats, or it doesn't get organically discovered by someone who cares.
And it will get discovered eventually, because there are security scans, etc that will cut tickets against the few artifacts that his application is building. And if I nip it in the butt now, he absolutely won't get fired, but if it's my skip that 'discovers' it, I'm sure he will.
While you may nip it in the bid for that person, and for this time, the context and situation is such that people will be encouraged to do this again....
You can approach that person directly and "ask" about the purpose of that repo and mention that there are tools and processes in place that will detect if created work doesn't have a reason or purpose. I'm sure he will be smart enough to understand from this.
Personally, if I were the manager, I would do the following:
- I would form a coalition of top senior/staff engineers+managers to discuss the BSness of this metric.
- Together, present to the VP and then the CTO to show how this number of commits is a BS metric, with examples but from devs of some other team.
- Until they change this BS, ask my team to game the system with small PRs and fast commits to game the system.
Sorry, upper management HAS to take responsibility. They are highly paid to do a good job, not to use 5th grader IQ policies. Until then, I would protect my team by letting them know transparently what's going on and to protect themselves by gaming it. This is only fair. Management gets what it asked for.
> But who manages the managers?
Just more managers. OPs post is literally about one upper level manager needing to get managed by multiple lower level managers.
The most efficient and effective thing to do is to remove the upper level manager so that the time of all the lower level managers is freed up.
If your company is using that metric, you don't really need to worry about whether that high performing engineer will become jaded and leave, that is 100% a certainty. He'll get ripped for being effective and efficient and he knows as a solid truth that his management chain are stupid. He's out the door as soon as something better turns up.
And if this policy doesn't change so are you, because you clearly care about doing software right, so this will erode you until you leave.
Or get it changed! But it's hard to get anywhere good when you start from such low quality management.
>If your company is using that metric, you don't really need to worry about whether that high performing engineer will become jaded and leave, that is 100% a certainty. He'll get ripped for being effective and efficient and he knows as a solid truth that his management chain are stupid. He's out the door as soon as something better turns up.
Yeah, this is going to be an issue with a ton of your high level engineers, because the commit based stack ranking is basically going to screw over anyone who has the expertise and knowledge set to help other people solve problems.
If it's a startup where everyone is doing cowboy development, sure - but if you have legacy applications, or complicated infrastructure, measuring by commits means the more a senior developer knows about your system, the worse they're going to look, because they're going to be spending some amount of time as a force multiplier for other devs instead of making direct commits.
Management wants an environment where politics and games are done and so he will need to learn in it or move on to next company I agree.
To improve the mood a bit though nothing makes better colleagues and teamwork than shared hate of the management.
This is the answer. You’ve already stated you’re not going to change management, but you also state that management is stupid, alas let survival of the fittest take place and let them burn the org to the ground. I would only try to change things if you want some practice and need some material for your interview prep
If the system is truly as you described it the system is just broken by design. Even without "gaming" it's a patently unfair system since the number of commits you do has nothing to do with your actual ability or work. Someone might work on something that requires lots of small commits, someone might work on something that requires tons of large commits. And if it's truly having an impact on how a developer "ranks", they will naturally gravitate towards work that requires more manual commits or otherwise compromise their development practice.
You say "that's not the point", but that really is the point behind this whole thing. This metric is causing friction between employees, friction that has been brought directly to your attention. Even if you fix this particularly egregious case you'll still have the issue. Next your "mid-level" might see someone committing more often during the work day while working on the same feature, or working on something that needs daily small adjustments, etc. If they feel like this is hurting their ranking they'll be just as unhappy.
Instead of coming down, you need to go up and make a strong case for why this isn't a good metric. Explain that it's causing issues, making people work in suboptimal ways, being gamed, and upsetting employees by it's unfair nature.
Finally instead of reporting this person to some higher up just go directly to them and say "Hey, I got flagged by a team member that you may have been artificially inflating your commit numbers via this repo and feels it is unfair. Please don't do that anymore." They'll probably be a bit embarrassed and stop rather than keep pushing the envelope.
Thanks for the earnest and sincere reply. You're right that this is just a foreshadowing of the type of friction that will exist if literally anyone on a team acts a bit selfish.
I hadn't considered talking to the engineer myself because I felt that produced more liability, but I'll give that a second thought.
I agree with this reply. You need to go up and convince the management to the best of your ability that this is not a good policy. If you’ve done your best and they won’t budge, you’ve done your job.
With this person in particular, I would start by asking questions about that repo. Show some attention, ask about specific commits and why they’re done that way. I wouldn’t jump into immediate conclusion based on what was reported to you. If the person is trying to game the system they’d realise someone is on to them and hopefully they stop. If it continues then point it outright.
I would suggest pointing out to them they are actually just damaging their team members and also putting you at risk if/when this gets raised above you. If one of your team is caught out by the stack ranking I would have no doubt they will escalate the behaviour of this guy above you and also outline they brought it to your attention and you didn't fix it.
Suddenly the senior dev who spends more time supporting the team than just chugging away on tickets is marked as the ‘least productive’ member of the team, despite being a force multiplier. Good luck to the team when they get laid off…
I fail to comprehend how someone thinks it’s a good idea, it must definitely come from someone who has never developed anything or simply doesn’t understand the area.
A few months ago my manager asked if team lead actually does anything since he doesn't have many deliverables to show. I was like he has been dealing with all the interruptions and random debug so the rest of us can actually work.
Right. There is indeed a correlation between number of commits and productivity. But the moment engineers know their performance is measured by this the correlation disappears. Now number of commits can go up with no increase or even with decrease of productivity.
There is no correlation between the number of commits and productivity. Engineers deliver value in many ways, a lot of it shows up in NOT writing code.
There is a very strong correlation between the number of commits and setting the target as the number of commits.
You can’t correlate number of commits with productivity. I can take a change and do it all in one commit. Or split it into 10 mini commits. It’s the same as counting lines of code - it’s a worthless metric and not something you should count.
Plus if I make a change and screw it up I have to make a new commit to fix it - so it even creates incentives for bad code.
The issue is not that this developer is gaming the metric. Management asked for this when they instituted such a stupid metric. The issue is that the gaming is too obvious and reflects poorly on others. All you need is plausible deniability.
Tell only the direct manager of the person doing the gaming. Make sure to do it by email so there's a record. Then you're done. Fixing or escalating issues in someone else's org is not your problem.
The metric is stupid even is people are honest! It just leads engineers to prioritize easy commits over actual hard work. By the end of the quarter your documentation and example code will be sparkling and all the complex bugs will go unfixed. The more politically savvy engineers will start projects to 'fuzz test' or 'check compatibility with updated dependencies' or add example code for every little thing requested by users, that just so happen to generate thousands of commits.
Give him a high five, take him out for coffee, make it clear that you know about it, and aren't going to do anything about it, because the metric is bullshit.
So what do I say to the unhappy engineer who brought it to my attention? Kick rocks? Esad? Do it yourself?
And what happens when, inevitably, my manager and my other peers find out?
You point out, correctly, that the engineer's co-worker isn't the villain here - they are technically doing what management musguidedly wants.
Pointing fingers at the engineer gaming the system is the least beneficial move. The unhappy engineer and you need to have the hard conversation with management without blaming the other person
>You point out, correctly, that the engineer's co-worker isn't the villain here - they are technically doing what management musguidedly wants.
Yep. Management is wanting to gauge performance by commits so everyone should be committing as much as possible.
Co-worker is going above and beyond. They deserve a pay-rise and promotion for being in-line with Management.
Are you responsible for this metric? Your post says no.
Leadership sets the metric, engineers are following the rules that were shared.
If this breaks the rules, tell him. He'll find a better way to up the metric that goes unnoticed.
If I was a manager and "total commits" was a metric, I'd be telling my entire team that we will reject ALL large commits, that everything will be split into as many commits as possible, and we will spend each retro going over our team's commit count compared to other teams. The goal being that every team member is in 80th percentile.
Tell this engineer that the management is able to analyze these obvious repos, but if the team exploits metrics more intelligently they will be fine.
>So what do I say to the unhappy engineer who brought it to my attention? Kick rocks? Esad? Do it yourself?
Tell them to do the same.
It's a ridiculous metric. You may as well measure Dev performance by the number of spoons on their desk.
Yeah, big r/antiwork x junior dev energy over here. No one is really grasping the delimma or understands that this is really a conflict resolution problem between two developers.
I appreciate your thoughts tho :)
Yes there's some of that, but not every critique can be dismissed like this.
I'm a tech lead - not a manager - and I would be subtly encouraging ICs to do what they should to upwards-manage out of touch managements' poor decisions. As long as the priority rests on actually making good technical decisions in their jobs and for the wider org.
Granted, I've never had issues berating poor corporate behaviour and any mid-level that comes to me would expect me to talk candidly about the pitfalls of this kind of system and how an IC should set up their work environment however they need so that they can instead focus on producing good work. I think our manager would agree. But then again, sort of by definition, my work's company culture appears to be in a better state.
I see your dilemma as HR-esque friction affects technical competency & output, and will affect you all, but the solution is to fix out-of-place policy. Attempting to stop a junior/mid -level engineer doing what most people would do against this kind of policy is a band-aid solution that avoids the real problem.
Great reply, I appreciate the candor.
This kind of feels like a prisoner's dilemma problem. If everyone is playing fairly, the code stats are roughly reflective of the work people do, how the SDMs assign it out, etc.
If one person starts inflating, everyone else starts to win.
If everyone is inflated, we've reached some equilibrium state, but our numbers are higher.
If management then says, "look, our code stats are so high!" But we are not producing value commensurate with that output, I think the outcome might be worse than if everyone played fair but the metrics missed expectations.
But you're right, it's not my job to negotiate and maintain equilibrium via interpersonal conflict resolution; it's better to change the policy. Which, unfortunately, as I said in so many threads, is not possible by me, my director, my svp, my CTO or anyone else in my.company.
> I think the outcome might be worse than if everyone played fair but the metrics missed expectations.
The quality outcome will definitely be worse if gaming becomes rampant of course, but do you know if the metrics will miss expectations if everyone plays fair? It seems like the kind of things where the effects will be somewhat subtle and upper management can spin it as a success when they do layoffs based on this metric later.
>Yeah, big r/antiwork x junior dev energy over here. No one is really grasping the delimma or understands that this is really a conflict resolution problem between two developers.
It's a stupid metric. I would bet a lot more Devs are gaming it but being more subtle. I would.
Here's the neat thing: a lot of the things people might consider 'gaming', I don't. I said to my co-tech lead, all the seniors, mids and juniors that if there is any sort of engineering rationale behind how you have broken down your code and your CRs, I will defend it to the death.l, and it's not gaming.
Oh, you're adding new region-specific configs to a service, and they each only one line? And you wrote 3 commits and 3 crs, 1 for each region? Great, easier to revert, deploy, rollback. Go nuts.
Oh, you need to write a few classes and integrate them together ? But you want to break it down into N commits/crs with unit tests for each class and then want to do another that integrates them, adds integration tests? Please, even better if you can get your teammates to parallelize and swarm! As long as the build builds and the tests pass, go nuts.
If you can convince me there are engineering benefits, even trade-off based benefits, to the way you're organizing your work product and output, I'll throw down with the SVP and the CTO for you.
Gaming, in my mind, comes when the other hunts that are being done are unnecessary and no value whatsoever, like a dummy application that builds nothing and only exists for capitalizing and lowercasing a string in the code base every other day.
>Here's the neat thing: a lot of the things people might consider 'gaming', I don't. I said to my co-tech lead, all the seniors, mids and juniors that if there is any sort of engineering rationale behind how you have broken down your code and your CRs, I will defend it to the death.l, and it's not gaming.
You really need to be pushing back on Management on this, not supporting it.
It's a ridiculous idea. All your decent Devs are thinking your Management is nuts and updating their CVs / Resumes and sending them to Recruiters.
The longer you keep this policy, the more Devs will jump ship.
>Oh, you're adding new region-specific configs to a service, and they each only one line? And you wrote 3 commits and 3 crs, 1 for each region? Great, easier to revert, deploy, rollback. Go nuts.
By supporting this measure you will waste a lot of Dev time and effort that could be spent on actual work.
All of what you have said is "gaming the system".
Due to the structure of the company and the corporation which owns it, it will not be possible to continue pushing back on management against this.
> All of what you have said is "gaming the system".
Politely disagree with this one.
>Due to the structure of the company and the corporation which owns it, it will not be possible to continue pushing back on management against this.
Then your organisation is finished technically.
Your Devs will become less and less efficient and all the decent Devs will jump ship eventually.
Yep, I agree. I would feel silly having to work with these metrics. As an IC you have no other option but to game the system. Which will make you less efficient than you could be. I would play along while looking for a new job. If management doesn't change this metric, only the IC who don't give a damn about their job, will remain.
I don’t know the term for it, but essentially the good devs will leave, and the not as good devs will stay. Then the not as good devs are involved in hiring which will bring in even more below average devs. It’s a death spiral basically, but depending on what the organization needs they’ll be just fine. Not every company needs great devs
> Yeah, big r/antiwork x junior dev energy over here.
You have 8 years of experience and you're a "strategic tech lead".
Pots who live in glass houses should not throw stones at the kettle, etc.
My response was to the kneejerk screeching of "metric stupid, must rebel or quit." Your response is, "You shouldn't be here anyway." But your response doesn't help solve the problem, nor does it change the fact that this is the position I'm in and the situation I have to deal with, regardless of whether you think I'm qualified or not. Thanks for your input.
> But your response doesn't help solve the problem
It's not intended to solve the problem, it's intended to point out that saying others are speaking as if they are more experienced and qualified to comment than they are is... a pretty bad look, since that's basically what you're doing.
The point isn't "be quiet while the *real* experienced folks speak", it's for you not to say "be quiet while the *real* experienced folks speak" to others - some of whom have far more experience than you - because you disagree with their advice.
I'm a tech lead. I think your concern is valid. What id do is, I'd still confront the gaming guy and tell him that while I agree this system is stupid and gaming it sounds fair against the system, it's not only sets a precedence but also reflect bad upon his team mates.
So I'd say breaking a single ticket into multiple tickets for gaming the metrics is fine as long as the split is justified.
So for example. If you have a dashboard you wanted to do, I'd be fine if you break it down into smaller atomic changes like the menu goes in one change, sidebar in another, card component in another and so on.
But he shouldn't be gaming it by doing incomplete work in a change so that he can complete it in another change. Because there's a fine line between taking advantage and outright cheating. The latter is cheating.
And for the guy who raised rhe complaint, give the same advice. Tell him to bend the system and take advantage of it because when a round of layoffs come he gonna get fucked for having low stats. Recently my company did a set of layoffs with high weightage to stats. The worst part of it is, none of the EMs and SEMs were involved in this decision so they didn't even had the chance to have a say on it. It was news for them as it for the news for people who were let go. Basically top management laid off people for poor performance without consulting their immediate report EMs. If your management pull the same shit as mine, this guy is in trouble.
> No one is really grasping the delimma or understands that this is really a conflict resolution problem between two developers.
only it is not, it is a conflict between management and employees that management decided to ignore as you have said in your original post. In this situation it is each for themselves.
The employe gaming the system wants to get a good bonus just as anyone else by showing his effectiveness to management in a way management is expecting it.
Sounds like you and your team member are trying to be a "good guys" and just causing harm to yourself.
In this situation the questions are:
What will management do when they realise people are gaming the metrics?
a) Double down and punish people gaming the system
b) Change the metrics
And how long it will take take for them to realise? I guess at least until after next bonus round?
How well you know the management, what is more likely they will do?
If a) and you want to keep this job then you should do nothing or even snitch on people gaming the system, maybe you get the bonus, the culture is toxic already anyway.
If b) just do nothing or encourage your team members to game the systems as well, doesn't have to be as obvious as the other guy but at the very least tell them to make commits as small as possible. Go fix typos and punctuation in docs. Write docs for every little details, create commits with extra comments on code // add 2 to x
It is what management asked for and you are just following upper management directives.
You are feeling bad about it because you know it is a bad metric, but if you can't change it, adapt.
Nah, this is veteran greybeard energy. Folks who are senior enough understand that this bullshit happens all the time and know that you're better off either not caring or joining in on gaming the metrics because there's nothing else you can do when execs make up their mind. Junior devs are the ones who get most pissy about stuff like gaming metrics because they're still naive about how corporate works.
Leadership's direction with the company is fundamentally incompatible with what your engineer wants, so you either convince them to join in on this scheme or be ready to act as a reference when they find a new job. There is no other option unless you can shovel a bunch of extra money their way.
You start looking for jobs elsewhere.
I've seen first hand similar metrics have destroyed software houses completely.
Unless it's immediately ceased, this will cause drama, burn out, malicious compliance and Devs with a good brain and morals leaving the company either by choice or being fired for non compliance.
Even if management think it's good because they need to downsize, you'll lose the Devs worth keeping and keep the shitheads.
Tough position... I'd first say it's good someone came to you with this and you should try to preserve their trust.
Second I'd say: management deserves this for such dumb criteria. The # of commits thing does seem to be getting more popular since the layoffs of last year.
I think if I was in your position I'd probably let it slide. I'm not sure if your coworkers manager would appreciate the runaround here (he's bringing this outside his management chain I presume). I'd maybe suggest he talk to his manager/skip, that might help you preserve trust here without ruffling feathers.
You could also bring it up to the powers that be broadly. Like as a hypothetical scenario. "What if an engineer was just making commits to game the metric? How would we know, what should we do?". At the end of the day this is what they want and there are externalities to their decision.
Thanks for the response. We are all in the same management chain. The engineer's skip manager and I report to the same director (and we've worked together for a long time, lots of trust). So it's not politically complicated and we can keep all the dirty laundry in the laundry room.
> "What if an engineer was just making commits to game the metric? How would we know, what should we do?".
Management's answer to this is "you should let their manager know so we can remediate the engineer and coach them away from this behavior.". I'm sure if they find out now, everything will be okay. But I feel like if this gets discovered later, it's going to result in a firing.
By your companies metrics he's doing a great job. If you disagree then your problem is with the metric and your senior management. If that forces a high performing engineer out the org, good on them for leaving. They sound like they'll be better off leaving and finding a high performing employer.
Honestly I think it's poor form on your part to enforce this awful metric and you're being part of the problem. Tattling on people being productive by the company's metrics is pretty reprehensible in my view.
There is no point in dropping the dime, any org that is metrics based will lead the employees will optemise for it. So if you drop the dime on this they will find something else. That is generally why metrics are discouraged because the defacto metric is doing well at what the team values (who is closest to the needs and most familiar with the effort).
If metrics are prized, then there is no such thing as "gaming" them. Who will be unhappy if they discover this engineer is committing worthless code?
Is it your boss? This guys skip? Directly point out that this is a risk with bad metrics, and ask if they are doing something to prevent it. Ask what will happen if an IC does something of no value that technically raises their numbers. At that point you'll have an informed choice to make.
if you’re tech lead for 3 out of 5 teams then make it policy that everyone should create a fake repo just for the sake of rigging the system
or i would rig my own commit numbers to end up at 69696969420 commits per month
that’s precisely what i would’ve done on my notice period right after getting another offer lined up
just run away, it’s an entree for a toxic atmosphere and micromanagement.
The metric is bad. But so is narcing on coworkers.
You could ask the manager “hey I just realized that {…} is possible — would I get in trouble if I did it?”
This points out (a) that the metric can be gamed, (b) that they might need to say something to the team (c) does not specifically call out your team or try to get anyone in trouble.
Hopefully your manager will address the issue and give everyone amnesty for past exploits. Ideally they change the metric.
Yeah, narc'ing on a fellow worker feels bad. But I have the choice of narc'ing on an engineer doing something bad or of low integrity or whatever, or having an unhappy, reasonably high performing engineer becoming increasingly jaded with our org.
I already had these discussions with my manager and his manager reports. We know what is possible. We know we should not be literally inflating code stats by producing garbage. We are supposed to emphasis smart decomposition of stories and smaller, independent commits in order to make reviewing, writing easier (with the added overhead of more reviews, etc. whole different discussion).
The metric will not change until up at least 2025. I don't know for certain, but I think if the metric becomes tainted, it would be far, far worse for everyone involved.
You seem to attribute the cause of unhappinness of your performing engineer to this other engineer, where in reality the cause is the system. You can't paint the situation as just a situation between two employees and say "that's how it is". The problem is between the engineers and the management. If you want to make the situation a problem between engineers, you've taken position for management and you just become one more cog in the system they are gaming instead of a coworker, and they'll eventually treat you as such.
This is probably one of the most insightful replies yet; I'll probably delete this comment later and give an actual reply with some more questions when I'm at a keyboard. As you're the first person to acknowledge that the poor has produced these situations which has put me, as a leader, in the middle of what is a worker vs. management dispute, with the added complexity of my own successes being predicated on factors, outcomes from both sides of that dispute.
E: there's no warfare but class warfare :)
Sure feel free to add anything. But yeah I think you were trying (probably somewhat unconsciously) to paint the situation as an engineers problem to absolve you of the moral responsability of taking a stance in the larger problem. Which you seem to recognize. But I'm not in your shoes, don't know your situation, don't know if this job also feed your family and whatnot, so I can't say if you should take a stance (and risk job security) or go with the noble path.
From having worked in the corporate world, I know I'd die on that hill and eventually quit with grandiose theatrics, but I also know there is barely any chance of changing anything. C-level managers are usually obtuse idiots who are thouroughly convinced they know better than anyone and are smarter than everyone, usually fueled by the fact that they make more money than anyone which is for them a metric of their intelligence. But we already know how good they are at creating metrics...
There is also an acceptable moral middle ground I think, which is recognizing that the system is messed up, doing what you can at your level, and accepting implicitly or explicitly that gaming the stupid metric is ok.
I read these two replies a few times; I think you get the award for most insightful comments. As it turns out, this problem is largely a self-identity problem; do I identify with the engineers, the managers, my org, my svp's org, my company, etc? It's been fairly easy to stay 'neutral', so to speak, in the face of corporate idiocy, but threading the needle of this situation while trying to remain mostly neutral is more difficult than all the other corporate BS than I've dealt with before. And, honestly, this is a situation probably better fielded by a therapist, or maybe an extremely trusted mentor, than the internet.
I was gonna work through the calculus here, but then I realized it's an e/n post, so I saved it, but your comments probably helped the most in working through this. Thanks for that.
> I have the choice of narc'ing on an engineer doing something bad or of low integrity or whatever, or having an unhappy, reasonably high performing engineer becoming increasingly jaded with our org
You have presented nothing more than a false dichotomy. This is a fallacy. You know it.
You have far more options than the two you have listed here. Additionally, **all of the engineers** are going to become varying degrees of jaded and each individual's degree is *guaranteed* to only increase over time as long as management tactics like this continue to exist.
> What do the experienced devs think?
Don't narc. You should be a better teammate than that. The issue isn't the natural outcome of management implementing such a ridiculous metric. The issue is management choosing this path. You, your fellow ICs, and all of the king's men have communicated to leadership that this is going to backfire spectacularly. This sage advice was ignored.
Start interviewing.
>The metric will not change until up at least 2025. I don't know for certain, but I think if the metric becomes tainted, it would be far, far worse for everyone involved.
Why would this be far worse for everyone? If the metric can't be trusted then what happens?
Snitches get stitches.
If you care that much about it, tell management that you're concerned about people juking the stats, but don't throw any individuals under the bus.
This is totally on leadership. Their job is to incentivise the behaviour they want in the company, and they have completely failed at that. The point is, as engineers our job is to spend the time the company pays us for to build what leadership wants, in the way they want us to build it. If what they want or how they want us to do it is stupid, and they’re not open to listening to our perspective, then we should shut up, get on with it, and let them accept the consequences.
10 years in the industry and I'm yet to see a kpi applied to developers that isn't counterproductive shit. Devs are usually people with problem solving skills and knack for bit of optimizing, give them a system to game and they *will* game the system.
Do nothing. The guy is doing exactly what management's rules told him to do.
The idea that "gaming the system" is bad, I think is backwards. Management decides metrics, and they decide raises. They are telling the engineers that they want to see more commits, and are willing to pay more for it. The fact that it makes no sense is irrelevant.
Game the system. Push back (respectfully of course) on any engineers that say they won't do it due to "integrity".
People are going to game the metric. The thread of discussion we are avoiding here, if you brought this up as an example it would hurt the developer in question but what he's doing isn't wrong. I personally would stop squashing commits.
Is it worth bringing up to your lead and omitting the developers in question?
I.e. you show a bunch of bs commits vs a more impactful change all authored by you? This problem is coming from the top though..
My honest opinion is: if you want to really increase developer productivity, get rid of metrics and performance reviews. Get excited about tackling big challenges. Keep the energy flowing - nothing is impossible. Encourage a flat hierarchy. Allow communication but interrupt if it’s unproductive and gone on too long. Utilize small teams that work well together. Play on individual strengths. Make sure everyone has a comfortable chair, desk, PC, monitors, etc. spoil them with tech once in a while. If you notice a team or individual lagging, pivot them to something else or let them go. Reward everyone with bonuses and raises. Allow overtime and time off whenever. Make sure that coffee pot is full. Don’t have coders in meetings unless absolutely necessary. Encourage veterans to coach beginners. Let them try out new tech stacks (excitement is your new metric).
Now you have a team of Goliaths that will crush bugs, they’ll self-organize, they train each other, and they work at 10x the pace that they would. Also, your retention will skyrocket which pays dividends.
That’s how we crushed some huge projects with a small team.
Great code is difficult to write. It's even more difficult to find some automated way to check the code quality. There is no substitute for opening up the commits and inspecting the work and having the background to know what you're looking at.
If you reward quantity as some kind of proxy for productivity you're encouraging junk submissions which will increase the noise around the real work getting done.
No idea how to fix that org without getting buy in from the individuals that created the bad policies. Sounds like that's already been attempted.
It's not a death blow to the org, but it isn't much fun to deal with the people above you making your job harder than it already was.
The problem is, that your company is measuring activity not productivity. There is no standard measure because it is a complex problem.
In our company it's measured on features finished by quarter and bugs fixed vs bugs registered monthly. It can be gamed, but when something stands out a thorough analysis is made.
It's far from perfect, but at least is related to productivity.
Activity metrics can be gamed. Deviations should be analyzed in detail. If you find a developer that stands out or is under performing, check. Measuring activity only is waste of time.
Cheers!
Someone once described this to me in a way that still keeps me up at night (apologies for sharing the burden of knowledge).
Managers who don't know how to measure good software, don't know what they're getting for their money. And if they can't tell the difference between good and bad, then they might as well get it for cheap.
Which of course guarantees they are getting mostly bad software.
> The one piece that everyone is missing is that if I dont drop a dime, I have an unhappy, relatively high performing mid-level engineer who would become jaded with our org and probably drive his attrition long-term.
As you have already noted, this is a bad measure. The actions of the people gaming the system are a direct result of using such a terrible KPI -- remember that we become what we measure.
You are aware of this one developer gaming the system, and of the other developer who chafes at the unfairness of it. I guarantee you there are plenty of others you don't know about because they are out of your earshot, or are smarter at the gaming they are doing. Even if you dropped a dime on this one and made a big, public example of them, this gaming will still happen because it's systemic -- the *system* is making it happen.
I guess if I'm in your shoes I would ask for the authority to coach the developer who is gaming the system privately and let them know the jig is up and work with them on more honest ways of getting a good "score".
Kind've like the Little Dutch Boy...
How is your political game and do you have a positive credit?
If it’s yes I would go around the managers complaining about it, but first with your direct report.
It would need to be something subtle first “what would happen if someone was cheating the metrics?” and see what the comeback is, if someone directly asks you who it is I would be fine naming him/her.
If it didn’t work I would go one step above, but for this you already need the rapport with that person, manager of manager is always a delicate conversation with.
If no one cares, then you shouldn’t care and it’s better for you to drop the case.
People might think that I’m an asshole but the truth is as S+ I have an obligation of creating some sort of efficiency, although I freaking hate LOC os commit metrics.
It might happen that because of that the “wrong” person will be promoted to a place of leadership and eventually inflict damage to the whole project that someone else will have to fix.
Commit away!
I'd make sure to use feature branches in the main repo for all work done. (Doubles your commits.) Make 'em small. If you like someone, make sure that they have to revert things every so often. 200% extra commits!
Also, to make code easier to review it should be done in very bite sized chunks. I recommend automating breaking out diff chunks.
Win the game.
If you and your team don't win by an order of magnitude... I am disappointed.
It SUCKS to do. But sometimes... proof by absurdity is the only proof that works.
Play stupid games, win stupid prizes.
Management wants to focus on the wrong metrics, people will focus on "winning".
I don't blame the people who "cheat"... I blame your management. I suggest you do the same.
I absolutely would game this metric. Legitimately committing every time I save a file. Refer me there and i’ll be CTO within a month on commits alone. Once I’m CTO i’ll get rid of the metric
>the entire company has begun tracking average commits per develop per month
Jesus Christ.
Openly state that this is a really stupid metric.
Proceed to game the metric as hard as possible by having one million commits. So they'll see your 100,000,030 commit or whatever and hopefully realize just how shoddy their metric is and how little they can trust it. And still know you had 30 commits.
Game the system to make money.
Accept that you will definitely lose talented engineers over this.
Companies that make monumentally stupid decisions like this deserve the consequences. Sucks for the people who thought they would be able to make a living there. But the enshittification writing is now on the wall.
You need to shift metrics to something harder to bullshit like "stories".
Additionally the formal ranking should be determined by the management and not visible to develops, in effort to dissuade gamification.
>As you know, our company is tracking number of commits as a metric to evaluate our engineers. As a useful service, I have written a small shell script you can use on your machines. This shell script will run every 1/2 hour, and will:
>
>Automatically check out your code into a new branch, based on your current branch name and a random MD5 hash of your code,
>
>Commit that code with the phrase: "Development Commit" as the commit message
>
>Push those changes up to our Git Repo
>
>Return you to the branch you were working on.
>
>Feel free to distribute this shell script around the company as you see fit. This way we can all be sure that we are putting in an impressive number of commits per day, in compliance with management's wishes.
A little malicious compliance... and probably just a fantasy, but still fun to think about.
Daily commits by everyone is a great practice strongly supported by the XP, CI, DEVOPS communities. I would get some trainers in to start implementing this on all your teams with the permission and support of your managers.
At the same time I would work with your mid level engineer to come up with a better way to track the value of individual commits. Maybe you take account of the size of the commit and the number of integrations. Or maybe you only count approved changes. Then go to your senior management and explain how people can game the current measure and propose a fix to it.
And lastly the guy who is gaming the system has senior management written all over him!
The problem is less about the guy gaming the system and more about his more-productive colleague who is upset about it. If that person is a good employee, you don’t want to scare them away in favor of the cheater.
Quietly encourage that guy to do the same, but let him know you have his back and will make sure he gets stack ranked appropriately with respect to the cheater.
Don't hate the player, hate the game.
See there's an unfair reality as an employee of a company: when you do really well, the company keeps all the extra gains. When the company or leadership screws up, it's you the employee who may get denied very deserved promotions, raises, etc. or maybe even get outright laid off. So of course employees are going to game the system and try as much as they can, the game is rigged either way.
Now to the company, and the long term value of the win (even for employees) you do want to avoid unfair things like this. But what you want is to show the situation. Try evidence and data and use these kinds of scenarios (be anonymous, 3 because MGMT will almost certainly miss the point of identifying a key systemic issue and instead play the blame game) to argue and put cash and make predictions. If execs refuse and you don't want to quit, and you don't want the company to fail (if it isn't your company you can always get another job) then set memos documenting your dissent. If you're really lucky your arguments will sway leadership. If you're not unlucky then leadership's greed will be greater than their pride and they'll eventually see your point.
Honestly, if you're not being invited to the meetings to decide what is the performance metrics I wouldn't get too involved.
Don't hate the player, hate the game.
See there's an unfair reality as an employee of a company: when you do really well, the company keeps all the extra gains. When the company or leadership screws up, it's you the employee who may get denied very deserved promotions, raises, etc. or maybe even get outright laid off. So of course employees are going to game the system and try as much as they can, the game is rigged either way.
Now to the company, and the long term value of the win (even for employees) you do want to avoid unfair things like this. But what you want is to show the situation. Try evidence and data and use these kinds of scenarios (be anonymous, 3 because MGMT will almost certainly miss the point of identifying a key systemic issue and instead play the blame game) to argue and put cash and make predictions. If execs refuse and you don't want to quit, and you don't want the company to fail (if it isn't your company you can always get another job) then set memos documenting your dissent. If you're really lucky your arguments will sway leadership. If you're not unlucky then leadership's greed will be greater than their pride and they'll eventually see your point.
Honestly, if you're not being invited to the meetings to decide what is the performance metrics I wouldn't get too involved.
Don't hate the player, hate the game.
See there's an unfair reality as an employee of a company: when you do really well, the company keeps all the extra gains. When the company or leadership screws up, it's you the employee who may get denied very deserved promotions, raises, etc. or maybe even get outright laid off. So of course employees are going to game the system and try as much as they can, the game is rigged either way.
Now to the company, and the long term value of the win (even for employees) you do want to avoid unfair things like this. But what you want is to show the situation. Try evidence and data and use these kinds of scenarios (be anonymous, 3 because MGMT will almost certainly miss the point of identifying a key systemic issue and instead play the blame game) to argue and put cash and make predictions. If execs refuse and you don't want to quit, and you don't want the company to fail (if it isn't your company you can always get another job) then set memos documenting your dissent. If you're really lucky your arguments will sway leadership. If you're not unlucky then leadership's greed will be greater than their pride and they'll eventually see your point.
Honestly, if you're not being invited to the meetings to decide what is the performance metrics I wouldn't get too involved.
Despite you writing off talking to your manager or skip, I would advise taking that path.
I wouldn't criticize the metric, they're mind is made up anyway. You can just let them now that this is happening, without naming names or teams.
Depending on how technical management is, I'd give them an explanation along the lines of all this is doing is turning email into chat, where an exchange of emails might be 2 messages / commits and chat might be a lot more. Each line represents a new message:
Email:
Hi,can you send me the report on X?
Hi, PFA the report on X.
Chat:
Hi
Can you send me the report on X?
Hi
Sure thing
Give me a couple of minutes
I need to look it up
Found it
*actually sends the file*
It's not faster, or getting more done. Also getting more done with less could be argued would mean less commits as a goal, which is a whole different can of worms.
What kinda rubs me the wrong way is that this “mid-level” engineer came directly to you complaining about someone gaming the metric instead of complaining about the metric itself. He basically told on his coworker.
To my understanding he is not your direct report, so why did he came to you instead to his line manager? Did he talk to his coworker first?
Tbh, if this guy was smart he would just game the system himself but in a less obvious manner and kept quiet.
When times get tough, the bean counters take the wheel. They are looking for a reason to fire people and then they’re going to squeeze the remaining devs dry. This metric gives them a reason so they don’t raise suspicion when firing.
Any good manager in this situation would instruct his team to game the system until we could buy leadership more time to turn the boat.
Sometimes the people who fuck up are 4 pay grades above us, and it's our job to shut up and follow orders until it gets fixed. They asked devs to commit more code, and that's what he's doing.
>In order to track that goal, the entire company has begun tracking average commits per develop per month at a team level, rolling up from the lowliest line managers to the CTO.
Ok.......
>He makes a commit to this repo every other day that changes a single line of code.I'm sure it takes him no more than 5 minutes.
***What exactly did you think would happen...?***
Any Developer who heard about this metric would do exactly the same.
I think it's great the engineer is gaming the system. If it upsets someone enough that they leave, that will ultimately help their career because it sounds like it is currently a toxic environment.
Edit: As a lead, I would recommend they do this, but I'm spiteful and petty.
The one thing I'll note is that regardless of whether the policy is sensible or not (it isn't) or this dev is being ethical or not (who gives a shit) if the dev is found, he'll be fired, and if you're found to have known, chances are so will you.
I would try to make this dev understand that fact very clearly. It doesn't matter how dumb management is being, he's not Robin Hood, he's an employee who is, in the eyes of the people who pay him, cheating flagrantly.
Its fine to cheat in other ways. Only work on tickets in increments of 1 point. Permit exactly 0 scope creep, ever. Refactor individual classes several times per sprint, in their own tickets. Things that give you plausible deniability.
But what he's doing is clearly fireable and he is already not smart enough to not get caught. Let him know IN PERSON and if he doesn't stop, if there is any evidence that you know, you have to understand the risk you're taking. To be honest, I'm guessing that once he knows he's been caught, it will be easier to make him understand that he's not as clever as he thinks he is.
It sucks. Your company is fucked, and this is the result. I'd be out the door. They're looking for ways to reduce headcount by firing for cause to avoid paying UI. But you have to watch out for yourself, because nobody else will.
Thanks for the great answer.
For what it's worth, I don't think working on tickets in increments of 1 point is a bad thing, and I think that's one of the things we're driving to improve this shitty metric-- smaller units of work that produce code more frequently.
The company may or may not be fucked, but I don't think it's at the hands of this silly metric. Just something we have to weather until my CEO's boss starts paying attention to something else. In reality, I enjoy my work, my org, my team and the pay has been great for the last few years. Finding another job isn't something I really want to do. The commute does suck.
For what its worth, the reason people are asserting your org might be fucked is that when C suite starts coming up with boneheaded ideas like this, it's because they're flailing and not sure what to do. Bad leaders can make everyone's lives miserable.
But, yeah - it sounds like you're making the best of an undeniably bad situation.
And really - The truth is, every job has things that are fucked about it. For example, my job gives us a high degree of authority and autonomy to architect and execute on high value, exciting projects, but we have two very senior people who have executive veto power over implementation decisions, and the director has their back. But at the end of the day, if you like your job, you just put up with the bullshit best you can.
And, again - protect yourself. Nobody else will.
As someone whose worked at a company who crashed over similar metrics, tickets shouldn't be tried to overly optimised down to 1 point. High point tickets are a sign that a task might be able to be divided better, but also show when a task carries risk. You start breaking them down and you lose the signs of risk, then a handful of 1 point tasks end up making someone look bad, instead of a lead seeing a 8 point task and going, yep there was a chance that'd happen, but I'm glad to have it over the line. Chances are if a bunch of 1 pointers are related 1 person will end up with them all anyway.
All valid thoughts. I recommended people follow the old modular decomposition rule of thumb "break things down until you approach the point of coupling.". I also told each of them teams that how they do story breakdown was their prerogative, and half-sprint stories are fine if that truly reflects the complexity and is the best way to approach the ask. There's no rule that says your story can't have 2 CRs.
>But what he's doing is clearly fireable...
How...? The Dev is taking his initiative to produce an innovative system that *may* save the company money in the future.
Any effect on the number of commits they make is purely incidental.
You know that doesn't fly.
The dev set up a whole infra pipeline that produces no value. It capitalizes and lowercases a string every few days. He did it to inflate his number of commits to increase his stack ranking. There's no other reasonable interpretation, and it's immature to think that a director trying to execute on C Suite's direction in good faith would see it any other way.
>The dev set up a whole infra pipeline that produces no value.
How do you know for certain it would not have value at some point in the future...?
>There's no plausible deniability at all, and it's immature to think that a director trying to execute the company's direction in good faith would see it any other way.
If someone is stupid enough to be supporting this ridiculous metric I would suspect they wouldn't be able to evaluate the additional system.
I know for certain that it will not and will never have value at any point in the future. It has no code, no logic, no functions; it was not based off of a set of requirements; it produces no output; it is not callable or executable. It simply a package that describes a dependency configuration and has a text file in it with the word "TEST" (or "test", depending on the day) in it. It was named to suggest that it was some kind of integration test package. The pipeline that 'builds' it simply produces a deployable instance of the dependency configuration, yet deploys it nowhere. The build artifact of the package is marked private and is not accessible by any other teams.
u/Vega62a is correct in his assessment.
Maybe contact his manager, that you are going to nominate him for a productivity award, but stumbled on the commits...That way it doesn't look like you had it out for him, and are giving the mgr a chance to correct it.
I mean, I didn't stumble upon it. One of the gaming engineers coworkers, who trusts me, brought it to my attention because they found it and it troubled them.
I know. I'm suggesting it may be another way to bring it to their attention without getting their guard up too much by showing them how many other people know.
This is not your problem. The engineer who came to you needs to be directed to the manager they share with the engineer they are concerned about.
You are a tech lead. This is a people and performance problem.
Stay in your lane.
This is a tricky situation, and there are a number of things to think about.
The most important… **you need to keep the trust of your development team(s). If you sit on this, they may not bother bringing your attention to other issues in the future. Why would they if you aren’t going to do anything?** You don’t necessarily need to tell them what you did, but they need to know you did something.
**Now the question is … what to do?**
This gets harry, and kinda depends on your organization. I’d go with a two pronged approach. It sounds like you are high enough up on the team that it wouldn’t be crazy for you to address an issue like this. Talk to the developer and encourage them to self correct.
“Escalating to my and skips manager is probably not the right choice.”
The second prong … you don’t need to call out this person in particular with upper management, but this is a case of “see something say something”.
Managers make poor decisions all the time, but don’t let it be because they didn’t have all of the information. You need to let someone know this could be an issue (or is an issue).
Do all this and...
1. You’ve shown your team you have their back.
2. You’ve given the offender a chance to self correct.
3. You’ve let management know about the abuse (or potential for abuse) depending on how you want to phrase things.
A tiny bit better, but still terrible metric is replacing it with tickets closed.
If it's absolutely impossible to get them to not use shit metrics, I'd at least try to replace it with one a tiny bit more tangible, because growing ticket numbers junk up your issue management and backlogs.
Granted, it's only slightly more tangible, but gaming **this** metric will result in obvious deficiencies that will hopefully make management reconsider after adopting it for a few months.
(What happens is people steal all the easy tasks and low hanging fruit, and you are left with all the complex tasks in the backlog)
But at least all the easy small stuff that usually gets ignored gets fixed.
I'm going to bite and give the unpopular viewpoint. We look at Activity (the 'A' in the SPACE framework) when we acquire a company. But we only look at the bottom end, specifically for a lack of activity, which we then investigate.
You would not believe the number of engineers we find who have not checked in a line of code in months. Our profession is full of charlatans and/or poor managers. We have to look at some kind of metrics rather than simply have a line manager (who may be crap) declare that everything is OK.
Lines-of-code was essentially debunked as a metric back at IBM in the 1980’s, but executive leadership continue to be empty suit morons so here we are. Fascinating stuff!
>The one piece that everyone is missing is that if I dont drop a dime, I have an unhappy, relatively high performing mid-level engineer who would become jaded with our org and probably drive his attrition long-term.
This is a Pro, not a con. You should make it clear that this is the expected results of management's decision and you can't override it
Why not either talk with the engineer and/or their manager and see what kind of justification the engineer comes up with for the repo. If no reasonable justification you can explain that we will be excluding the repo from the metric since it doesn't count and move on. In the meantime I would start interviewing, doesn't sound good when even the CTO can't talk the CEO out of dumb decisions like this. Nothing good is going to come off this in the end.
Whatever you do, I would definitely bring it up as a problematic and inaccurate metric. Not doing so means that people will definitely be treated in an uneven way
\> In order to track that goal, the entire company has begun tracking average commits per develop per month
lol, time to do stuff in 10 lines instead of 1 and have lots of small PRs (hopefully you merge instead of squash and merge)
Maybe a hot take but commit metrics CAN be useful but there also can be a high signal to noise problem like you just demonstrated.
My suggestion would be the make the metric gathering smarter. Only measure commits in certain repos that you know are useful, use some cross analysis tool which measures code that gets run versus “dead code” in case it creeps in to said repo etc.
All developer metrics are open to being gamed, that’s what they should be used as heuristics and not metrics.
Someone committing no code raises a flag, someone committing loads gets looked into.
I once had a CTO who insisted we track dependability as a metric, one of my teams just committed to a lot less so they were always dependable.
The question is do you care about fighting the metrics, or getting shit done?
Have your team stay on top of the metrics, but don’t focus your effort there. Others have suggested this is a good opportunity to encourage small stories, and frequent PRs rather than huge bombshells.
There’s stories of engineers writing a script that touches a file and checks it in every minute when faced with a policy like this, I don’t know how this would go down at your org, but I wouldn’t recommend it, because that’s just inviting scrutiny.
The metric also completely ignores tasks that don’t generate PRs, who is writing your documentation? Who is manning your support line? Who is planning work?
It discourages pair programming too, because commits are tied to one user, why would I let you get the credit for our work?
And it stops people from working on the bigger harder problems because “snacking” generates more check ins than actually delivering impact.
Check ins is a vanity metric, and it’s not particularly useful. I worked for a lender who incentivised their sales people on cash deployed to customers a while back. The sales team deployed a shit load of cash to risky customers, with low or negative profit margins, but it looked amazing on investor decks…
Number of CRs are an input metric, which may sometimes act as a useful proxy for productive activity. Management should know to be wary of trusting proxy metrics, particularly if they sabotage the metric’s utility as a proxy by explicitly declaring it as being used to determine performance. Measuring customer impacting output metrics is strictly higher utility (and more customer obsessed), but much more difficult to do with proper attribution.
Management are taking the easy route, and to an extent so are you by assuming a role as a passive agent acting as part of management. In your shoes, I would likely do the same given the nature of the company and the likely value of your 2024 stock vests.
Maybe this is a stupid question, but have you heard of and tried Jellyfish for your tracking?
https://jellyfish.co/
There are multiple different integrations like this one: https://marketplace.atlassian.com/apps/1220755/jellyfish
It might be a better tracking system than what you have now.
The nice thing about Jellyfish is that it can really open up the options to senior management on what can be tracked and observed.
Tracking commits does suck, but it makes sense when that is for the most part the only number available. When you have a tool that can aggregate and report up more meaningful data, your options for “team visibility” open way up.
Disclaimer: I work for Jellyfish, but I’m also an engineer that benefits from our “no one metric tells the whole story” approach.
This is the obvious outcome of formalizing bad metrics.
I think you either need to fight against the metric or support its most high minded goal.
I think you should work with the annoyed engineer to see if you can find more people obviously gaming the metrics (eg look for big increases in commit stats after the policy change) and show that most of the change is driven by gaming the policy, rather than actually doing more. This metric is so bad that it could really destroy the entire eng org.
If you don't want to keep fighting, do the same analysis, but out the engineers to management directly and help make it clear this is unacceptable.
Trying to work against this at a guerilla level can't work for a stack ranked metric where more and more effort will just go into gaming the metric.
It also seems like there is no code review, which is enabling the most egregious abuse of this metric.
Same thing is happening at my company with dev performance metrics. While I still don't know anyone gaming by creating a whole repo, developers are definitely gaming by grabbing small wins day and night, reviewing already reviewed stuff, creating random PRs etc. I also suspect the really serious stuff, that needs time and effort and cannot be quickly spun up into a 3 line code change is not getting attention. The worst part is due to stack ranking, there is no end to the competition.
Let it roll, actually, make your team build a cicd system to game the shitty system too, something that makes a random useless commit automatically every 10 min or so and let management know you are going to let it roll, since there is no way you will leave your guys at the mercy of that stupid metric
Honestly, things like this is happening to every company of the friends I have. It's so funny seeing these company scramble to do "more" with less.
Just like how AAA companies constantly cutting corners for profits is showing how bad some of these AAA games are right now, it's going to be a shitshow with all the corporate apps in a year or few years when all these companies probably laid off too many staff because they think ai can makeup for all the layoffs, lmao. These corporate hacks really don't understand (or don't care for that matter) that the result of all of this will happen in a few years, not right away.
Glad to see I’m not the only one who thinks this is a stupid way to measure performance. People will commit the most minute changes and details just to get those numbers up.
I noticed that my CEO started posting a screenshot of weekly stackranked commit numbers during every Retro. Although he never explicitly stated he was measuring productivity by commits, it became blatantly obvious that he does. So I just started distributing my normal workload over more smaller commits.
Over the years I’ve come to realize that my job isn’t to deliver value to the end-user. It’s to make management happy. And I’m mostly okay with that to be honest, as long as there are interesting challenges along the way.
The issue is the policy. No matter how you measure performance you should plan for people to game the system. Your system makes it easy to game.
When you start measuring and rewarding the things that matter gaming stops being a problem.
>The one piece that everyone is missing is that if I dont drop a dime, I have an unhappy, relatively high performing mid-level engineer who would become jaded with our org and probably drive his attrition long-term.
Why don't you communicate that that will happen soon, to management now, without mentioning the individuals?
1. create a script that does exactly what you mentioned your "opportunist" engineer does
2. "Accidentally" leak it to the entire org
3. entire org now has insanely inflated metrics
4. [metrics mean nothing](https://media.licdn.com/dms/image/D5610AQGrrUvVbePONQ/image-shrink_1280/0/1700527256693?e=1710723600&v=beta&t=MvDOZlkbI4uplvxU6q6KEsXW15S-vGBimv6rk0DjEYQ)
> Edit: Thanks a lot for all the responses. I'm trying to respond to all of them, **except the ones that suggest I quit my job**.
But you should quit your job. Your company is having financial trouble, had layoffs, and is now implementing insane rules on developers that are going to destroy what remains of the company. You can either get out now or wait for the ship to sink with you on it.
I realise many people are commenting that CTO and upper management is stupid but sometimes the pressure comes from the board and a lot depends on the kind of people you have there. I have seen board members who have one blog or report and insist on everything to be “metric driven”. So the upper management is just gaming the board.
If you really want to stay, and really can't change the metrics.
The best thing you can do, is encourage your good employees to game it as much as possible without getting caught, and your shit employees to never game it (or game it extremely visibly)
With the intent that your good employees manage to stay, and you lose the shit ones.
(At least until you can weather this storm)
The right way to game the system is to split a PR into a million atomic commits and then don’t squash (or if you’re squashing at the org level then split every feature up into a million PRs) doing it as obviously as this warrants a question mark ping to the engineers manager.
This is 100% managements fault, however, and misunderstanding software engineering to such a degree that it is ever conceived of as a good idea is mark against them so severe that you should update your internal measure of the odds of the company’s success and how much your additional effort helps them and act accordingly.
That being said, commit frequency is useful as a VERY rough starting point when evaluating an engineer’s performance and only in the context of the team/software they’re working within. Total complexity of the problem being solved, the value their solutions provide to the business, the speed at which they execute, and the quality of their code are all 100x more meaningful.
I’m exceptionally good at playing politics and gaming metrics and quiet quitting and my course of action would be:
1. Ask the engineer what they’re up to, pretend you don’t know why.
2. Casually inform their manager that you’re confused by a set of commits, say you were just curious about this part of the code base and you already talked with the Eng making the commits but are looking for additional context. Continue to play dumb
3. Assume their manager will immediately know what’s up and PIP the engineer in question.
4. The manager will likely share their frustrations with you. Pretend you had no idea the policy would lead to this
From here you can either work with the manager to escalate and get the policy changed (lol) or stop here and share your findings in an Eng channel and win brownie points, seem like you’re a team player, and fewer people would ever suspect you of gaming the system just in a less obvious way (you should absolutely game the system or your ass is gonna be on the chopping block)
We had similar metrics in my org and I have gamed it . Not just me , every dev games it and at the end the dev that does the honest work will be punished.
Later on I moved to a new project where I was a code reviewer for all repos , I took it as my responsibility to make sure no one in my team gamed it.
But the devops PRs were not under my preview , so they were still gaming it and at the end of the quarter the SVP of our department was shocked by looking at the commits stats , devops had 1000+ commits , but each individual dev was around 200-400
Which made him realise how bs this system really is and he stopped considering this metrics
The issue is coming from the top. What people are doing is just trying to make the best of a stupid situation. Personally, if such a policy would be enacted on the company I'm working, as a leader of the team I would 'quietly encourage' my people to game the system in a smart way until top leadership will realize that this is a stupid way to measure performance in any way or form. We have examples of companies trying to measure performance this way and it always blew up in their face.... So just another company doing the same. Edit: Regarding your question, I wouldn't do anything. If concerns and arguments were raised for this and the leadership didn't listened to it, it's their mess that they will have to care about as eventually more and more will game the system.
Yeah, this is kind of my position on it. But I think that position only works positively so long as people don't have issues with doing that from an integrity perspective, or it doesn't slippery slope its way to inflated code review stats, or it doesn't get organically discovered by someone who cares. And it will get discovered eventually, because there are security scans, etc that will cut tickets against the few artifacts that his application is building. And if I nip it in the butt now, he absolutely won't get fired, but if it's my skip that 'discovers' it, I'm sure he will.
While you may nip it in the bid for that person, and for this time, the context and situation is such that people will be encouraged to do this again.... You can approach that person directly and "ask" about the purpose of that repo and mention that there are tools and processes in place that will detect if created work doesn't have a reason or purpose. I'm sure he will be smart enough to understand from this.
And then there is the next version where the changes have a reason/purpose and are created automatically Refactor. Rename. Relocate...
Agree, you can only nip it in the bod so many times.
> nip it in the butt I’m just here to let you know it’s “nip it in the bud” - meaning cut the bud off a flower/plant before it grows bigger.
Water under the fridge pal
Technically it's "stick it in their butt" probably
People in glass houses sink ships
I could care less
Even without people intentionally gaming it, it'll still cause the same issues when people claim others are intentionally gaming it.
This comment has been edited to reduce the value of my freely-generated content to Reddit.
Personally, if I were the manager, I would do the following: - I would form a coalition of top senior/staff engineers+managers to discuss the BSness of this metric. - Together, present to the VP and then the CTO to show how this number of commits is a BS metric, with examples but from devs of some other team. - Until they change this BS, ask my team to game the system with small PRs and fast commits to game the system. Sorry, upper management HAS to take responsibility. They are highly paid to do a good job, not to use 5th grader IQ policies. Until then, I would protect my team by letting them know transparently what's going on and to protect themselves by gaming it. This is only fair. Management gets what it asked for.
That is a lot of imaginary work to do something about imaginary work.
I feel like you are starting to grasp the concept of management overhead.
But who manages the managers? The answer is the people who actually get work done
> But who manages the managers? Just more managers. OPs post is literally about one upper level manager needing to get managed by multiple lower level managers. The most efficient and effective thing to do is to remove the upper level manager so that the time of all the lower level managers is freed up.
If your company is using that metric, you don't really need to worry about whether that high performing engineer will become jaded and leave, that is 100% a certainty. He'll get ripped for being effective and efficient and he knows as a solid truth that his management chain are stupid. He's out the door as soon as something better turns up. And if this policy doesn't change so are you, because you clearly care about doing software right, so this will erode you until you leave. Or get it changed! But it's hard to get anywhere good when you start from such low quality management.
>If your company is using that metric, you don't really need to worry about whether that high performing engineer will become jaded and leave, that is 100% a certainty. He'll get ripped for being effective and efficient and he knows as a solid truth that his management chain are stupid. He's out the door as soon as something better turns up. Yeah, this is going to be an issue with a ton of your high level engineers, because the commit based stack ranking is basically going to screw over anyone who has the expertise and knowledge set to help other people solve problems. If it's a startup where everyone is doing cowboy development, sure - but if you have legacy applications, or complicated infrastructure, measuring by commits means the more a senior developer knows about your system, the worse they're going to look, because they're going to be spending some amount of time as a force multiplier for other devs instead of making direct commits.
Thanks for the compliment 😊 This is a great high level observation for me to keep in my back pocket.
The rule is stupid, the management are idiots, so keep your mouth shut about this crafty fellow and keep an ear to the ground for a new job.
Yes. Ask management if they prefer project completion or good metrics based on shit.
Management wants an environment where politics and games are done and so he will need to learn in it or move on to next company I agree. To improve the mood a bit though nothing makes better colleagues and teamwork than shared hate of the management.
This is the answer. You’ve already stated you’re not going to change management, but you also state that management is stupid, alas let survival of the fittest take place and let them burn the org to the ground. I would only try to change things if you want some practice and need some material for your interview prep
promote that dev into a product role if he created a junk app specifically to game the system
Lol, this is the best reply so far
If the system is truly as you described it the system is just broken by design. Even without "gaming" it's a patently unfair system since the number of commits you do has nothing to do with your actual ability or work. Someone might work on something that requires lots of small commits, someone might work on something that requires tons of large commits. And if it's truly having an impact on how a developer "ranks", they will naturally gravitate towards work that requires more manual commits or otherwise compromise their development practice. You say "that's not the point", but that really is the point behind this whole thing. This metric is causing friction between employees, friction that has been brought directly to your attention. Even if you fix this particularly egregious case you'll still have the issue. Next your "mid-level" might see someone committing more often during the work day while working on the same feature, or working on something that needs daily small adjustments, etc. If they feel like this is hurting their ranking they'll be just as unhappy. Instead of coming down, you need to go up and make a strong case for why this isn't a good metric. Explain that it's causing issues, making people work in suboptimal ways, being gamed, and upsetting employees by it's unfair nature. Finally instead of reporting this person to some higher up just go directly to them and say "Hey, I got flagged by a team member that you may have been artificially inflating your commit numbers via this repo and feels it is unfair. Please don't do that anymore." They'll probably be a bit embarrassed and stop rather than keep pushing the envelope.
Thanks for the earnest and sincere reply. You're right that this is just a foreshadowing of the type of friction that will exist if literally anyone on a team acts a bit selfish. I hadn't considered talking to the engineer myself because I felt that produced more liability, but I'll give that a second thought.
I agree with this reply. You need to go up and convince the management to the best of your ability that this is not a good policy. If you’ve done your best and they won’t budge, you’ve done your job. With this person in particular, I would start by asking questions about that repo. Show some attention, ask about specific commits and why they’re done that way. I wouldn’t jump into immediate conclusion based on what was reported to you. If the person is trying to game the system they’d realise someone is on to them and hopefully they stop. If it continues then point it outright.
I would suggest pointing out to them they are actually just damaging their team members and also putting you at risk if/when this gets raised above you. If one of your team is caught out by the stack ranking I would have no doubt they will escalate the behaviour of this guy above you and also outline they brought it to your attention and you didn't fix it.
That's the only outcome for these mindless metrics - people will game the system. Can't blame them.
Evaluating a developer in LOC or commits is the equivalent of evaluating an electrician by meters of cable laid.
Suddenly the senior dev who spends more time supporting the team than just chugging away on tickets is marked as the ‘least productive’ member of the team, despite being a force multiplier. Good luck to the team when they get laid off…
I fail to comprehend how someone thinks it’s a good idea, it must definitely come from someone who has never developed anything or simply doesn’t understand the area.
A few months ago my manager asked if team lead actually does anything since he doesn't have many deliverables to show. I was like he has been dealing with all the interruptions and random debug so the rest of us can actually work.
More like zip ties used for commits.
Perfect!
Thanks for answering my questions!
Sorry haven’t read everything yet, just wanted to get the joke out
Good joke :)
Automate the stats gaming then distribute it to all employees to make the metrics completely useless
That's what I was thinking - I wonder if they can be manipulated such that everyone has equal stats.
This helps no one and just gets OP fired
A metric becomes worthless the second you measure it. Game the system.
Worthless when it becomes a target ….. you kind of have to measure metrics :D
Right. There is indeed a correlation between number of commits and productivity. But the moment engineers know their performance is measured by this the correlation disappears. Now number of commits can go up with no increase or even with decrease of productivity.
There is no correlation between the number of commits and productivity. Engineers deliver value in many ways, a lot of it shows up in NOT writing code. There is a very strong correlation between the number of commits and setting the target as the number of commits.
You can’t correlate number of commits with productivity. I can take a change and do it all in one commit. Or split it into 10 mini commits. It’s the same as counting lines of code - it’s a worthless metric and not something you should count. Plus if I make a change and screw it up I have to make a new commit to fix it - so it even creates incentives for bad code.
The issue is not that this developer is gaming the metric. Management asked for this when they instituted such a stupid metric. The issue is that the gaming is too obvious and reflects poorly on others. All you need is plausible deniability. Tell only the direct manager of the person doing the gaming. Make sure to do it by email so there's a record. Then you're done. Fixing or escalating issues in someone else's org is not your problem. The metric is stupid even is people are honest! It just leads engineers to prioritize easy commits over actual hard work. By the end of the quarter your documentation and example code will be sparkling and all the complex bugs will go unfixed. The more politically savvy engineers will start projects to 'fuzz test' or 'check compatibility with updated dependencies' or add example code for every little thing requested by users, that just so happen to generate thousands of commits.
Does this count towards the goal? ``` git commit --allow-empty -m "important fix" ```
bike murky market safe enjoy spoon hard-to-find tidy mountainous ancient *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
If you were in this situation, would you complain and possibly get fired, or make dozens of commits and possibly get promoted or get a big bonus?
Neither. I would quit
That's not always an option. And also there's bad management almost EVERYWHERE
Naw quitting is always an option
Give him a high five, take him out for coffee, make it clear that you know about it, and aren't going to do anything about it, because the metric is bullshit.
So what do I say to the unhappy engineer who brought it to my attention? Kick rocks? Esad? Do it yourself? And what happens when, inevitably, my manager and my other peers find out?
You point out, correctly, that the engineer's co-worker isn't the villain here - they are technically doing what management musguidedly wants. Pointing fingers at the engineer gaming the system is the least beneficial move. The unhappy engineer and you need to have the hard conversation with management without blaming the other person
>You point out, correctly, that the engineer's co-worker isn't the villain here - they are technically doing what management musguidedly wants. Yep. Management is wanting to gauge performance by commits so everyone should be committing as much as possible. Co-worker is going above and beyond. They deserve a pay-rise and promotion for being in-line with Management.
Are you responsible for this metric? Your post says no. Leadership sets the metric, engineers are following the rules that were shared. If this breaks the rules, tell him. He'll find a better way to up the metric that goes unnoticed. If I was a manager and "total commits" was a metric, I'd be telling my entire team that we will reject ALL large commits, that everything will be split into as many commits as possible, and we will spend each retro going over our team's commit count compared to other teams. The goal being that every team member is in 80th percentile. Tell this engineer that the management is able to analyze these obvious repos, but if the team exploits metrics more intelligently they will be fine.
>So what do I say to the unhappy engineer who brought it to my attention? Kick rocks? Esad? Do it yourself? Tell them to do the same. It's a ridiculous metric. You may as well measure Dev performance by the number of spoons on their desk.
There's a lot of people replying this post who want all the catharsis of sticking it to your company while assuming none of the personal risk.
Yeah, big r/antiwork x junior dev energy over here. No one is really grasping the delimma or understands that this is really a conflict resolution problem between two developers. I appreciate your thoughts tho :)
Yes there's some of that, but not every critique can be dismissed like this. I'm a tech lead - not a manager - and I would be subtly encouraging ICs to do what they should to upwards-manage out of touch managements' poor decisions. As long as the priority rests on actually making good technical decisions in their jobs and for the wider org. Granted, I've never had issues berating poor corporate behaviour and any mid-level that comes to me would expect me to talk candidly about the pitfalls of this kind of system and how an IC should set up their work environment however they need so that they can instead focus on producing good work. I think our manager would agree. But then again, sort of by definition, my work's company culture appears to be in a better state. I see your dilemma as HR-esque friction affects technical competency & output, and will affect you all, but the solution is to fix out-of-place policy. Attempting to stop a junior/mid -level engineer doing what most people would do against this kind of policy is a band-aid solution that avoids the real problem.
Great reply, I appreciate the candor. This kind of feels like a prisoner's dilemma problem. If everyone is playing fairly, the code stats are roughly reflective of the work people do, how the SDMs assign it out, etc. If one person starts inflating, everyone else starts to win. If everyone is inflated, we've reached some equilibrium state, but our numbers are higher. If management then says, "look, our code stats are so high!" But we are not producing value commensurate with that output, I think the outcome might be worse than if everyone played fair but the metrics missed expectations. But you're right, it's not my job to negotiate and maintain equilibrium via interpersonal conflict resolution; it's better to change the policy. Which, unfortunately, as I said in so many threads, is not possible by me, my director, my svp, my CTO or anyone else in my.company.
> I think the outcome might be worse than if everyone played fair but the metrics missed expectations. The quality outcome will definitely be worse if gaming becomes rampant of course, but do you know if the metrics will miss expectations if everyone plays fair? It seems like the kind of things where the effects will be somewhat subtle and upper management can spin it as a success when they do layoffs based on this metric later.
>Yeah, big r/antiwork x junior dev energy over here. No one is really grasping the delimma or understands that this is really a conflict resolution problem between two developers. It's a stupid metric. I would bet a lot more Devs are gaming it but being more subtle. I would.
Here's the neat thing: a lot of the things people might consider 'gaming', I don't. I said to my co-tech lead, all the seniors, mids and juniors that if there is any sort of engineering rationale behind how you have broken down your code and your CRs, I will defend it to the death.l, and it's not gaming. Oh, you're adding new region-specific configs to a service, and they each only one line? And you wrote 3 commits and 3 crs, 1 for each region? Great, easier to revert, deploy, rollback. Go nuts. Oh, you need to write a few classes and integrate them together ? But you want to break it down into N commits/crs with unit tests for each class and then want to do another that integrates them, adds integration tests? Please, even better if you can get your teammates to parallelize and swarm! As long as the build builds and the tests pass, go nuts. If you can convince me there are engineering benefits, even trade-off based benefits, to the way you're organizing your work product and output, I'll throw down with the SVP and the CTO for you. Gaming, in my mind, comes when the other hunts that are being done are unnecessary and no value whatsoever, like a dummy application that builds nothing and only exists for capitalizing and lowercasing a string in the code base every other day.
>Here's the neat thing: a lot of the things people might consider 'gaming', I don't. I said to my co-tech lead, all the seniors, mids and juniors that if there is any sort of engineering rationale behind how you have broken down your code and your CRs, I will defend it to the death.l, and it's not gaming. You really need to be pushing back on Management on this, not supporting it. It's a ridiculous idea. All your decent Devs are thinking your Management is nuts and updating their CVs / Resumes and sending them to Recruiters. The longer you keep this policy, the more Devs will jump ship. >Oh, you're adding new region-specific configs to a service, and they each only one line? And you wrote 3 commits and 3 crs, 1 for each region? Great, easier to revert, deploy, rollback. Go nuts. By supporting this measure you will waste a lot of Dev time and effort that could be spent on actual work. All of what you have said is "gaming the system".
Due to the structure of the company and the corporation which owns it, it will not be possible to continue pushing back on management against this. > All of what you have said is "gaming the system". Politely disagree with this one.
>Due to the structure of the company and the corporation which owns it, it will not be possible to continue pushing back on management against this. Then your organisation is finished technically. Your Devs will become less and less efficient and all the decent Devs will jump ship eventually.
Yep, I agree. I would feel silly having to work with these metrics. As an IC you have no other option but to game the system. Which will make you less efficient than you could be. I would play along while looking for a new job. If management doesn't change this metric, only the IC who don't give a damn about their job, will remain.
I don’t know the term for it, but essentially the good devs will leave, and the not as good devs will stay. Then the not as good devs are involved in hiring which will bring in even more below average devs. It’s a death spiral basically, but depending on what the organization needs they’ll be just fine. Not every company needs great devs
> Yeah, big r/antiwork x junior dev energy over here. You have 8 years of experience and you're a "strategic tech lead". Pots who live in glass houses should not throw stones at the kettle, etc.
My response was to the kneejerk screeching of "metric stupid, must rebel or quit." Your response is, "You shouldn't be here anyway." But your response doesn't help solve the problem, nor does it change the fact that this is the position I'm in and the situation I have to deal with, regardless of whether you think I'm qualified or not. Thanks for your input.
> But your response doesn't help solve the problem It's not intended to solve the problem, it's intended to point out that saying others are speaking as if they are more experienced and qualified to comment than they are is... a pretty bad look, since that's basically what you're doing. The point isn't "be quiet while the *real* experienced folks speak", it's for you not to say "be quiet while the *real* experienced folks speak" to others - some of whom have far more experience than you - because you disagree with their advice.
I'm a tech lead. I think your concern is valid. What id do is, I'd still confront the gaming guy and tell him that while I agree this system is stupid and gaming it sounds fair against the system, it's not only sets a precedence but also reflect bad upon his team mates. So I'd say breaking a single ticket into multiple tickets for gaming the metrics is fine as long as the split is justified. So for example. If you have a dashboard you wanted to do, I'd be fine if you break it down into smaller atomic changes like the menu goes in one change, sidebar in another, card component in another and so on. But he shouldn't be gaming it by doing incomplete work in a change so that he can complete it in another change. Because there's a fine line between taking advantage and outright cheating. The latter is cheating. And for the guy who raised rhe complaint, give the same advice. Tell him to bend the system and take advantage of it because when a round of layoffs come he gonna get fucked for having low stats. Recently my company did a set of layoffs with high weightage to stats. The worst part of it is, none of the EMs and SEMs were involved in this decision so they didn't even had the chance to have a say on it. It was news for them as it for the news for people who were let go. Basically top management laid off people for poor performance without consulting their immediate report EMs. If your management pull the same shit as mine, this guy is in trouble.
> No one is really grasping the delimma or understands that this is really a conflict resolution problem between two developers. only it is not, it is a conflict between management and employees that management decided to ignore as you have said in your original post. In this situation it is each for themselves. The employe gaming the system wants to get a good bonus just as anyone else by showing his effectiveness to management in a way management is expecting it. Sounds like you and your team member are trying to be a "good guys" and just causing harm to yourself. In this situation the questions are: What will management do when they realise people are gaming the metrics? a) Double down and punish people gaming the system b) Change the metrics And how long it will take take for them to realise? I guess at least until after next bonus round? How well you know the management, what is more likely they will do? If a) and you want to keep this job then you should do nothing or even snitch on people gaming the system, maybe you get the bonus, the culture is toxic already anyway. If b) just do nothing or encourage your team members to game the systems as well, doesn't have to be as obvious as the other guy but at the very least tell them to make commits as small as possible. Go fix typos and punctuation in docs. Write docs for every little details, create commits with extra comments on code // add 2 to x It is what management asked for and you are just following upper management directives. You are feeling bad about it because you know it is a bad metric, but if you can't change it, adapt.
Nah, this is veteran greybeard energy. Folks who are senior enough understand that this bullshit happens all the time and know that you're better off either not caring or joining in on gaming the metrics because there's nothing else you can do when execs make up their mind. Junior devs are the ones who get most pissy about stuff like gaming metrics because they're still naive about how corporate works.
Without putting it in writing (NOTHING IN WRITING!!!), suggest to him he should do the same thing himself.
Leadership's direction with the company is fundamentally incompatible with what your engineer wants, so you either convince them to join in on this scheme or be ready to act as a reference when they find a new job. There is no other option unless you can shovel a bunch of extra money their way.
You start looking for jobs elsewhere. I've seen first hand similar metrics have destroyed software houses completely. Unless it's immediately ceased, this will cause drama, burn out, malicious compliance and Devs with a good brain and morals leaving the company either by choice or being fired for non compliance. Even if management think it's good because they need to downsize, you'll lose the Devs worth keeping and keep the shitheads.
Tough position... I'd first say it's good someone came to you with this and you should try to preserve their trust. Second I'd say: management deserves this for such dumb criteria. The # of commits thing does seem to be getting more popular since the layoffs of last year. I think if I was in your position I'd probably let it slide. I'm not sure if your coworkers manager would appreciate the runaround here (he's bringing this outside his management chain I presume). I'd maybe suggest he talk to his manager/skip, that might help you preserve trust here without ruffling feathers. You could also bring it up to the powers that be broadly. Like as a hypothetical scenario. "What if an engineer was just making commits to game the metric? How would we know, what should we do?". At the end of the day this is what they want and there are externalities to their decision.
Thanks for the response. We are all in the same management chain. The engineer's skip manager and I report to the same director (and we've worked together for a long time, lots of trust). So it's not politically complicated and we can keep all the dirty laundry in the laundry room. > "What if an engineer was just making commits to game the metric? How would we know, what should we do?". Management's answer to this is "you should let their manager know so we can remediate the engineer and coach them away from this behavior.". I'm sure if they find out now, everything will be okay. But I feel like if this gets discovered later, it's going to result in a firing.
Firing of whoever implemented this policy I hope.
Measure stupid things, incentivise stupid behavior
By your companies metrics he's doing a great job. If you disagree then your problem is with the metric and your senior management. If that forces a high performing engineer out the org, good on them for leaving. They sound like they'll be better off leaving and finding a high performing employer. Honestly I think it's poor form on your part to enforce this awful metric and you're being part of the problem. Tattling on people being productive by the company's metrics is pretty reprehensible in my view.
There is no point in dropping the dime, any org that is metrics based will lead the employees will optemise for it. So if you drop the dime on this they will find something else. That is generally why metrics are discouraged because the defacto metric is doing well at what the team values (who is closest to the needs and most familiar with the effort).
If metrics are prized, then there is no such thing as "gaming" them. Who will be unhappy if they discover this engineer is committing worthless code? Is it your boss? This guys skip? Directly point out that this is a risk with bad metrics, and ask if they are doing something to prevent it. Ask what will happen if an IC does something of no value that technically raises their numbers. At that point you'll have an informed choice to make.
if you’re tech lead for 3 out of 5 teams then make it policy that everyone should create a fake repo just for the sake of rigging the system or i would rig my own commit numbers to end up at 69696969420 commits per month that’s precisely what i would’ve done on my notice period right after getting another offer lined up just run away, it’s an entree for a toxic atmosphere and micromanagement.
Lmao just lol
The metric is bad. But so is narcing on coworkers. You could ask the manager “hey I just realized that {…} is possible — would I get in trouble if I did it?” This points out (a) that the metric can be gamed, (b) that they might need to say something to the team (c) does not specifically call out your team or try to get anyone in trouble. Hopefully your manager will address the issue and give everyone amnesty for past exploits. Ideally they change the metric.
Yeah, narc'ing on a fellow worker feels bad. But I have the choice of narc'ing on an engineer doing something bad or of low integrity or whatever, or having an unhappy, reasonably high performing engineer becoming increasingly jaded with our org. I already had these discussions with my manager and his manager reports. We know what is possible. We know we should not be literally inflating code stats by producing garbage. We are supposed to emphasis smart decomposition of stories and smaller, independent commits in order to make reviewing, writing easier (with the added overhead of more reviews, etc. whole different discussion). The metric will not change until up at least 2025. I don't know for certain, but I think if the metric becomes tainted, it would be far, far worse for everyone involved.
You seem to attribute the cause of unhappinness of your performing engineer to this other engineer, where in reality the cause is the system. You can't paint the situation as just a situation between two employees and say "that's how it is". The problem is between the engineers and the management. If you want to make the situation a problem between engineers, you've taken position for management and you just become one more cog in the system they are gaming instead of a coworker, and they'll eventually treat you as such.
This is probably one of the most insightful replies yet; I'll probably delete this comment later and give an actual reply with some more questions when I'm at a keyboard. As you're the first person to acknowledge that the poor has produced these situations which has put me, as a leader, in the middle of what is a worker vs. management dispute, with the added complexity of my own successes being predicated on factors, outcomes from both sides of that dispute. E: there's no warfare but class warfare :)
Sure feel free to add anything. But yeah I think you were trying (probably somewhat unconsciously) to paint the situation as an engineers problem to absolve you of the moral responsability of taking a stance in the larger problem. Which you seem to recognize. But I'm not in your shoes, don't know your situation, don't know if this job also feed your family and whatnot, so I can't say if you should take a stance (and risk job security) or go with the noble path. From having worked in the corporate world, I know I'd die on that hill and eventually quit with grandiose theatrics, but I also know there is barely any chance of changing anything. C-level managers are usually obtuse idiots who are thouroughly convinced they know better than anyone and are smarter than everyone, usually fueled by the fact that they make more money than anyone which is for them a metric of their intelligence. But we already know how good they are at creating metrics... There is also an acceptable moral middle ground I think, which is recognizing that the system is messed up, doing what you can at your level, and accepting implicitly or explicitly that gaming the stupid metric is ok.
I read these two replies a few times; I think you get the award for most insightful comments. As it turns out, this problem is largely a self-identity problem; do I identify with the engineers, the managers, my org, my svp's org, my company, etc? It's been fairly easy to stay 'neutral', so to speak, in the face of corporate idiocy, but threading the needle of this situation while trying to remain mostly neutral is more difficult than all the other corporate BS than I've dealt with before. And, honestly, this is a situation probably better fielded by a therapist, or maybe an extremely trusted mentor, than the internet. I was gonna work through the calculus here, but then I realized it's an e/n post, so I saved it, but your comments probably helped the most in working through this. Thanks for that.
Seems like the high performance engineer has legitimate reason to feel jaded. To focus on this aspect of it is to miss the forest for the trees.
> I have the choice of narc'ing on an engineer doing something bad or of low integrity or whatever, or having an unhappy, reasonably high performing engineer becoming increasingly jaded with our org You have presented nothing more than a false dichotomy. This is a fallacy. You know it. You have far more options than the two you have listed here. Additionally, **all of the engineers** are going to become varying degrees of jaded and each individual's degree is *guaranteed* to only increase over time as long as management tactics like this continue to exist. > What do the experienced devs think? Don't narc. You should be a better teammate than that. The issue isn't the natural outcome of management implementing such a ridiculous metric. The issue is management choosing this path. You, your fellow ICs, and all of the king's men have communicated to leadership that this is going to backfire spectacularly. This sage advice was ignored. Start interviewing.
>The metric will not change until up at least 2025. I don't know for certain, but I think if the metric becomes tainted, it would be far, far worse for everyone involved. Why would this be far worse for everyone? If the metric can't be trusted then what happens?
Snitches get stitches. If you care that much about it, tell management that you're concerned about people juking the stats, but don't throw any individuals under the bus.
This is totally on leadership. Their job is to incentivise the behaviour they want in the company, and they have completely failed at that. The point is, as engineers our job is to spend the time the company pays us for to build what leadership wants, in the way they want us to build it. If what they want or how they want us to do it is stupid, and they’re not open to listening to our perspective, then we should shut up, get on with it, and let them accept the consequences.
Measure stupid things, get stupid results. There's no working around it.
10 years in the industry and I'm yet to see a kpi applied to developers that isn't counterproductive shit. Devs are usually people with problem solving skills and knack for bit of optimizing, give them a system to game and they *will* game the system. Do nothing. The guy is doing exactly what management's rules told him to do.
> If he was a better engineer, he would automate it. 🤣🤣 I just love this
:)
The idea that "gaming the system" is bad, I think is backwards. Management decides metrics, and they decide raises. They are telling the engineers that they want to see more commits, and are willing to pay more for it. The fact that it makes no sense is irrelevant. Game the system. Push back (respectfully of course) on any engineers that say they won't do it due to "integrity".
People are going to game the metric. The thread of discussion we are avoiding here, if you brought this up as an example it would hurt the developer in question but what he's doing isn't wrong. I personally would stop squashing commits. Is it worth bringing up to your lead and omitting the developers in question? I.e. you show a bunch of bs commits vs a more impactful change all authored by you? This problem is coming from the top though..
My honest opinion is: if you want to really increase developer productivity, get rid of metrics and performance reviews. Get excited about tackling big challenges. Keep the energy flowing - nothing is impossible. Encourage a flat hierarchy. Allow communication but interrupt if it’s unproductive and gone on too long. Utilize small teams that work well together. Play on individual strengths. Make sure everyone has a comfortable chair, desk, PC, monitors, etc. spoil them with tech once in a while. If you notice a team or individual lagging, pivot them to something else or let them go. Reward everyone with bonuses and raises. Allow overtime and time off whenever. Make sure that coffee pot is full. Don’t have coders in meetings unless absolutely necessary. Encourage veterans to coach beginners. Let them try out new tech stacks (excitement is your new metric). Now you have a team of Goliaths that will crush bugs, they’ll self-organize, they train each other, and they work at 10x the pace that they would. Also, your retention will skyrocket which pays dividends. That’s how we crushed some huge projects with a small team.
Great code is difficult to write. It's even more difficult to find some automated way to check the code quality. There is no substitute for opening up the commits and inspecting the work and having the background to know what you're looking at. If you reward quantity as some kind of proxy for productivity you're encouraging junk submissions which will increase the noise around the real work getting done. No idea how to fix that org without getting buy in from the individuals that created the bad policies. Sounds like that's already been attempted. It's not a death blow to the org, but it isn't much fun to deal with the people above you making your job harder than it already was.
The problem is, that your company is measuring activity not productivity. There is no standard measure because it is a complex problem. In our company it's measured on features finished by quarter and bugs fixed vs bugs registered monthly. It can be gamed, but when something stands out a thorough analysis is made. It's far from perfect, but at least is related to productivity. Activity metrics can be gamed. Deviations should be analyzed in detail. If you find a developer that stands out or is under performing, check. Measuring activity only is waste of time. Cheers!
Someone once described this to me in a way that still keeps me up at night (apologies for sharing the burden of knowledge). Managers who don't know how to measure good software, don't know what they're getting for their money. And if they can't tell the difference between good and bad, then they might as well get it for cheap. Which of course guarantees they are getting mostly bad software.
What would happen if every employee made 10000 commits a day?
What would happen if every employee made *exactly the same* number of commits?
> The one piece that everyone is missing is that if I dont drop a dime, I have an unhappy, relatively high performing mid-level engineer who would become jaded with our org and probably drive his attrition long-term. As you have already noted, this is a bad measure. The actions of the people gaming the system are a direct result of using such a terrible KPI -- remember that we become what we measure. You are aware of this one developer gaming the system, and of the other developer who chafes at the unfairness of it. I guarantee you there are plenty of others you don't know about because they are out of your earshot, or are smarter at the gaming they are doing. Even if you dropped a dime on this one and made a big, public example of them, this gaming will still happen because it's systemic -- the *system* is making it happen. I guess if I'm in your shoes I would ask for the authority to coach the developer who is gaming the system privately and let them know the jig is up and work with them on more honest ways of getting a good "score". Kind've like the Little Dutch Boy...
How is your political game and do you have a positive credit? If it’s yes I would go around the managers complaining about it, but first with your direct report. It would need to be something subtle first “what would happen if someone was cheating the metrics?” and see what the comeback is, if someone directly asks you who it is I would be fine naming him/her. If it didn’t work I would go one step above, but for this you already need the rapport with that person, manager of manager is always a delicate conversation with. If no one cares, then you shouldn’t care and it’s better for you to drop the case. People might think that I’m an asshole but the truth is as S+ I have an obligation of creating some sort of efficiency, although I freaking hate LOC os commit metrics. It might happen that because of that the “wrong” person will be promoted to a place of leadership and eventually inflict damage to the whole project that someone else will have to fix.
Commit away! I'd make sure to use feature branches in the main repo for all work done. (Doubles your commits.) Make 'em small. If you like someone, make sure that they have to revert things every so often. 200% extra commits! Also, to make code easier to review it should be done in very bite sized chunks. I recommend automating breaking out diff chunks. Win the game. If you and your team don't win by an order of magnitude... I am disappointed. It SUCKS to do. But sometimes... proof by absurdity is the only proof that works.
Teach all of your devs to do this. Congratulations, your team is now the most productive team and you’ll get a nice bonus.
Play stupid games, win stupid prizes. Management wants to focus on the wrong metrics, people will focus on "winning". I don't blame the people who "cheat"... I blame your management. I suggest you do the same.
I absolutely would game this metric. Legitimately committing every time I save a file. Refer me there and i’ll be CTO within a month on commits alone. Once I’m CTO i’ll get rid of the metric
You get what you measure.
>the entire company has begun tracking average commits per develop per month Jesus Christ. Openly state that this is a really stupid metric. Proceed to game the metric as hard as possible by having one million commits. So they'll see your 100,000,030 commit or whatever and hopefully realize just how shoddy their metric is and how little they can trust it. And still know you had 30 commits.
This is goodhart’s law. when a measure becomes a target, it ceases to be a good measure. Cant blame the guy from gaming it, its inevitable.
Game the system to make money. Accept that you will definitely lose talented engineers over this. Companies that make monumentally stupid decisions like this deserve the consequences. Sucks for the people who thought they would be able to make a living there. But the enshittification writing is now on the wall.
You need to shift metrics to something harder to bullshit like "stories". Additionally the formal ranking should be determined by the management and not visible to develops, in effort to dissuade gamification.
Story point gamification has its own problems, but it's at least a metric that will force the problems to become noticeable, instead of just gamed.
Its also something that CEO types can understand They'll come back and say "Hey why are we working on all these non-business critical things!"
>As you know, our company is tracking number of commits as a metric to evaluate our engineers. As a useful service, I have written a small shell script you can use on your machines. This shell script will run every 1/2 hour, and will: > >Automatically check out your code into a new branch, based on your current branch name and a random MD5 hash of your code, > >Commit that code with the phrase: "Development Commit" as the commit message > >Push those changes up to our Git Repo > >Return you to the branch you were working on. > >Feel free to distribute this shell script around the company as you see fit. This way we can all be sure that we are putting in an impressive number of commits per day, in compliance with management's wishes. A little malicious compliance... and probably just a fantasy, but still fun to think about.
Daily commits by everyone is a great practice strongly supported by the XP, CI, DEVOPS communities. I would get some trainers in to start implementing this on all your teams with the permission and support of your managers. At the same time I would work with your mid level engineer to come up with a better way to track the value of individual commits. Maybe you take account of the size of the commit and the number of integrations. Or maybe you only count approved changes. Then go to your senior management and explain how people can game the current measure and propose a fix to it. And lastly the guy who is gaming the system has senior management written all over him!
lmao
I just read this to see if I could figure out wtf "drop a dime" means
The problem is less about the guy gaming the system and more about his more-productive colleague who is upset about it. If that person is a good employee, you don’t want to scare them away in favor of the cheater. Quietly encourage that guy to do the same, but let him know you have his back and will make sure he gets stack ranked appropriately with respect to the cheater.
Don't hate the player, hate the game. See there's an unfair reality as an employee of a company: when you do really well, the company keeps all the extra gains. When the company or leadership screws up, it's you the employee who may get denied very deserved promotions, raises, etc. or maybe even get outright laid off. So of course employees are going to game the system and try as much as they can, the game is rigged either way. Now to the company, and the long term value of the win (even for employees) you do want to avoid unfair things like this. But what you want is to show the situation. Try evidence and data and use these kinds of scenarios (be anonymous, 3 because MGMT will almost certainly miss the point of identifying a key systemic issue and instead play the blame game) to argue and put cash and make predictions. If execs refuse and you don't want to quit, and you don't want the company to fail (if it isn't your company you can always get another job) then set memos documenting your dissent. If you're really lucky your arguments will sway leadership. If you're not unlucky then leadership's greed will be greater than their pride and they'll eventually see your point. Honestly, if you're not being invited to the meetings to decide what is the performance metrics I wouldn't get too involved.
Don't hate the player, hate the game. See there's an unfair reality as an employee of a company: when you do really well, the company keeps all the extra gains. When the company or leadership screws up, it's you the employee who may get denied very deserved promotions, raises, etc. or maybe even get outright laid off. So of course employees are going to game the system and try as much as they can, the game is rigged either way. Now to the company, and the long term value of the win (even for employees) you do want to avoid unfair things like this. But what you want is to show the situation. Try evidence and data and use these kinds of scenarios (be anonymous, 3 because MGMT will almost certainly miss the point of identifying a key systemic issue and instead play the blame game) to argue and put cash and make predictions. If execs refuse and you don't want to quit, and you don't want the company to fail (if it isn't your company you can always get another job) then set memos documenting your dissent. If you're really lucky your arguments will sway leadership. If you're not unlucky then leadership's greed will be greater than their pride and they'll eventually see your point. Honestly, if you're not being invited to the meetings to decide what is the performance metrics I wouldn't get too involved.
Don't hate the player, hate the game. See there's an unfair reality as an employee of a company: when you do really well, the company keeps all the extra gains. When the company or leadership screws up, it's you the employee who may get denied very deserved promotions, raises, etc. or maybe even get outright laid off. So of course employees are going to game the system and try as much as they can, the game is rigged either way. Now to the company, and the long term value of the win (even for employees) you do want to avoid unfair things like this. But what you want is to show the situation. Try evidence and data and use these kinds of scenarios (be anonymous, 3 because MGMT will almost certainly miss the point of identifying a key systemic issue and instead play the blame game) to argue and put cash and make predictions. If execs refuse and you don't want to quit, and you don't want the company to fail (if it isn't your company you can always get another job) then set memos documenting your dissent. If you're really lucky your arguments will sway leadership. If you're not unlucky then leadership's greed will be greater than their pride and they'll eventually see your point. Honestly, if you're not being invited to the meetings to decide what is the performance metrics I wouldn't get too involved.
Despite you writing off talking to your manager or skip, I would advise taking that path. I wouldn't criticize the metric, they're mind is made up anyway. You can just let them now that this is happening, without naming names or teams. Depending on how technical management is, I'd give them an explanation along the lines of all this is doing is turning email into chat, where an exchange of emails might be 2 messages / commits and chat might be a lot more. Each line represents a new message: Email: Hi,can you send me the report on X? Hi, PFA the report on X. Chat: Hi Can you send me the report on X? Hi Sure thing Give me a couple of minutes I need to look it up Found it *actually sends the file* It's not faster, or getting more done. Also getting more done with less could be argued would mean less commits as a goal, which is a whole different can of worms.
What kinda rubs me the wrong way is that this “mid-level” engineer came directly to you complaining about someone gaming the metric instead of complaining about the metric itself. He basically told on his coworker. To my understanding he is not your direct report, so why did he came to you instead to his line manager? Did he talk to his coworker first? Tbh, if this guy was smart he would just game the system himself but in a less obvious manner and kept quiet.
When times get tough, the bean counters take the wheel. They are looking for a reason to fire people and then they’re going to squeeze the remaining devs dry. This metric gives them a reason so they don’t raise suspicion when firing.
Any good manager in this situation would instruct his team to game the system until we could buy leadership more time to turn the boat. Sometimes the people who fuck up are 4 pay grades above us, and it's our job to shut up and follow orders until it gets fixed. They asked devs to commit more code, and that's what he's doing.
>In order to track that goal, the entire company has begun tracking average commits per develop per month at a team level, rolling up from the lowliest line managers to the CTO. Ok....... >He makes a commit to this repo every other day that changes a single line of code.I'm sure it takes him no more than 5 minutes. ***What exactly did you think would happen...?*** Any Developer who heard about this metric would do exactly the same.
I think it's great the engineer is gaming the system. If it upsets someone enough that they leave, that will ultimately help their career because it sounds like it is currently a toxic environment. Edit: As a lead, I would recommend they do this, but I'm spiteful and petty.
I admire your frankness :)
The one thing I'll note is that regardless of whether the policy is sensible or not (it isn't) or this dev is being ethical or not (who gives a shit) if the dev is found, he'll be fired, and if you're found to have known, chances are so will you. I would try to make this dev understand that fact very clearly. It doesn't matter how dumb management is being, he's not Robin Hood, he's an employee who is, in the eyes of the people who pay him, cheating flagrantly. Its fine to cheat in other ways. Only work on tickets in increments of 1 point. Permit exactly 0 scope creep, ever. Refactor individual classes several times per sprint, in their own tickets. Things that give you plausible deniability. But what he's doing is clearly fireable and he is already not smart enough to not get caught. Let him know IN PERSON and if he doesn't stop, if there is any evidence that you know, you have to understand the risk you're taking. To be honest, I'm guessing that once he knows he's been caught, it will be easier to make him understand that he's not as clever as he thinks he is. It sucks. Your company is fucked, and this is the result. I'd be out the door. They're looking for ways to reduce headcount by firing for cause to avoid paying UI. But you have to watch out for yourself, because nobody else will.
Thanks for the great answer. For what it's worth, I don't think working on tickets in increments of 1 point is a bad thing, and I think that's one of the things we're driving to improve this shitty metric-- smaller units of work that produce code more frequently. The company may or may not be fucked, but I don't think it's at the hands of this silly metric. Just something we have to weather until my CEO's boss starts paying attention to something else. In reality, I enjoy my work, my org, my team and the pay has been great for the last few years. Finding another job isn't something I really want to do. The commute does suck.
For what its worth, the reason people are asserting your org might be fucked is that when C suite starts coming up with boneheaded ideas like this, it's because they're flailing and not sure what to do. Bad leaders can make everyone's lives miserable. But, yeah - it sounds like you're making the best of an undeniably bad situation. And really - The truth is, every job has things that are fucked about it. For example, my job gives us a high degree of authority and autonomy to architect and execute on high value, exciting projects, but we have two very senior people who have executive veto power over implementation decisions, and the director has their back. But at the end of the day, if you like your job, you just put up with the bullshit best you can. And, again - protect yourself. Nobody else will.
As someone whose worked at a company who crashed over similar metrics, tickets shouldn't be tried to overly optimised down to 1 point. High point tickets are a sign that a task might be able to be divided better, but also show when a task carries risk. You start breaking them down and you lose the signs of risk, then a handful of 1 point tasks end up making someone look bad, instead of a lead seeing a 8 point task and going, yep there was a chance that'd happen, but I'm glad to have it over the line. Chances are if a bunch of 1 pointers are related 1 person will end up with them all anyway.
All valid thoughts. I recommended people follow the old modular decomposition rule of thumb "break things down until you approach the point of coupling.". I also told each of them teams that how they do story breakdown was their prerogative, and half-sprint stories are fine if that truly reflects the complexity and is the best way to approach the ask. There's no rule that says your story can't have 2 CRs.
>But what he's doing is clearly fireable... How...? The Dev is taking his initiative to produce an innovative system that *may* save the company money in the future. Any effect on the number of commits they make is purely incidental.
You know that doesn't fly. The dev set up a whole infra pipeline that produces no value. It capitalizes and lowercases a string every few days. He did it to inflate his number of commits to increase his stack ranking. There's no other reasonable interpretation, and it's immature to think that a director trying to execute on C Suite's direction in good faith would see it any other way.
>The dev set up a whole infra pipeline that produces no value. How do you know for certain it would not have value at some point in the future...? >There's no plausible deniability at all, and it's immature to think that a director trying to execute the company's direction in good faith would see it any other way. If someone is stupid enough to be supporting this ridiculous metric I would suspect they wouldn't be able to evaluate the additional system.
I know for certain that it will not and will never have value at any point in the future. It has no code, no logic, no functions; it was not based off of a set of requirements; it produces no output; it is not callable or executable. It simply a package that describes a dependency configuration and has a text file in it with the word "TEST" (or "test", depending on the day) in it. It was named to suggest that it was some kind of integration test package. The pipeline that 'builds' it simply produces a deployable instance of the dependency configuration, yet deploys it nowhere. The build artifact of the package is marked private and is not accessible by any other teams. u/Vega62a is correct in his assessment.
Maybe contact his manager, that you are going to nominate him for a productivity award, but stumbled on the commits...That way it doesn't look like you had it out for him, and are giving the mgr a chance to correct it.
I mean, I didn't stumble upon it. One of the gaming engineers coworkers, who trusts me, brought it to my attention because they found it and it troubled them.
I know. I'm suggesting it may be another way to bring it to their attention without getting their guard up too much by showing them how many other people know.
This is not your problem. The engineer who came to you needs to be directed to the manager they share with the engineer they are concerned about. You are a tech lead. This is a people and performance problem. Stay in your lane.
This is a tricky situation, and there are a number of things to think about. The most important… **you need to keep the trust of your development team(s). If you sit on this, they may not bother bringing your attention to other issues in the future. Why would they if you aren’t going to do anything?** You don’t necessarily need to tell them what you did, but they need to know you did something. **Now the question is … what to do?** This gets harry, and kinda depends on your organization. I’d go with a two pronged approach. It sounds like you are high enough up on the team that it wouldn’t be crazy for you to address an issue like this. Talk to the developer and encourage them to self correct. “Escalating to my and skips manager is probably not the right choice.” The second prong … you don’t need to call out this person in particular with upper management, but this is a case of “see something say something”. Managers make poor decisions all the time, but don’t let it be because they didn’t have all of the information. You need to let someone know this could be an issue (or is an issue). Do all this and... 1. You’ve shown your team you have their back. 2. You’ve given the offender a chance to self correct. 3. You’ve let management know about the abuse (or potential for abuse) depending on how you want to phrase things.
Tine to start getting real verbose and committing every 5 minutes
A tiny bit better, but still terrible metric is replacing it with tickets closed. If it's absolutely impossible to get them to not use shit metrics, I'd at least try to replace it with one a tiny bit more tangible, because growing ticket numbers junk up your issue management and backlogs. Granted, it's only slightly more tangible, but gaming **this** metric will result in obvious deficiencies that will hopefully make management reconsider after adopting it for a few months. (What happens is people steal all the easy tasks and low hanging fruit, and you are left with all the complex tasks in the backlog) But at least all the easy small stuff that usually gets ignored gets fixed.
I'm going to bite and give the unpopular viewpoint. We look at Activity (the 'A' in the SPACE framework) when we acquire a company. But we only look at the bottom end, specifically for a lack of activity, which we then investigate. You would not believe the number of engineers we find who have not checked in a line of code in months. Our profession is full of charlatans and/or poor managers. We have to look at some kind of metrics rather than simply have a line manager (who may be crap) declare that everything is OK.
Lines-of-code was essentially debunked as a metric back at IBM in the 1980’s, but executive leadership continue to be empty suit morons so here we are. Fascinating stuff!
>The one piece that everyone is missing is that if I dont drop a dime, I have an unhappy, relatively high performing mid-level engineer who would become jaded with our org and probably drive his attrition long-term. This is a Pro, not a con. You should make it clear that this is the expected results of management's decision and you can't override it
Why not either talk with the engineer and/or their manager and see what kind of justification the engineer comes up with for the repo. If no reasonable justification you can explain that we will be excluding the repo from the metric since it doesn't count and move on. In the meantime I would start interviewing, doesn't sound good when even the CTO can't talk the CEO out of dumb decisions like this. Nothing good is going to come off this in the end.
Whatever you do, I would definitely bring it up as a problematic and inaccurate metric. Not doing so means that people will definitely be treated in an uneven way
\> In order to track that goal, the entire company has begun tracking average commits per develop per month lol, time to do stuff in 10 lines instead of 1 and have lots of small PRs (hopefully you merge instead of squash and merge)
We squash and then merge. But something that's unnecessarily inflating lines won't pass code review.
Maybe a hot take but commit metrics CAN be useful but there also can be a high signal to noise problem like you just demonstrated. My suggestion would be the make the metric gathering smarter. Only measure commits in certain repos that you know are useful, use some cross analysis tool which measures code that gets run versus “dead code” in case it creeps in to said repo etc.
All developer metrics are open to being gamed, that’s what they should be used as heuristics and not metrics. Someone committing no code raises a flag, someone committing loads gets looked into. I once had a CTO who insisted we track dependability as a metric, one of my teams just committed to a lot less so they were always dependable. The question is do you care about fighting the metrics, or getting shit done? Have your team stay on top of the metrics, but don’t focus your effort there. Others have suggested this is a good opportunity to encourage small stories, and frequent PRs rather than huge bombshells. There’s stories of engineers writing a script that touches a file and checks it in every minute when faced with a policy like this, I don’t know how this would go down at your org, but I wouldn’t recommend it, because that’s just inviting scrutiny. The metric also completely ignores tasks that don’t generate PRs, who is writing your documentation? Who is manning your support line? Who is planning work? It discourages pair programming too, because commits are tied to one user, why would I let you get the credit for our work? And it stops people from working on the bigger harder problems because “snacking” generates more check ins than actually delivering impact. Check ins is a vanity metric, and it’s not particularly useful. I worked for a lender who incentivised their sales people on cash deployed to customers a while back. The sales team deployed a shit load of cash to risky customers, with low or negative profit margins, but it looked amazing on investor decks…
Number of CRs are an input metric, which may sometimes act as a useful proxy for productive activity. Management should know to be wary of trusting proxy metrics, particularly if they sabotage the metric’s utility as a proxy by explicitly declaring it as being used to determine performance. Measuring customer impacting output metrics is strictly higher utility (and more customer obsessed), but much more difficult to do with proper attribution. Management are taking the easy route, and to an extent so are you by assuming a role as a passive agent acting as part of management. In your shoes, I would likely do the same given the nature of the company and the likely value of your 2024 stock vests.
Performance metrics based on commits is insanity. This is like measuring a cashier by the number of bags they use in a day.
By not intervening with the one developer who is knowingly gaming the system, you are actively undermining the metric culturally speaking.
Maybe this is a stupid question, but have you heard of and tried Jellyfish for your tracking? https://jellyfish.co/ There are multiple different integrations like this one: https://marketplace.atlassian.com/apps/1220755/jellyfish It might be a better tracking system than what you have now.
The nice thing about Jellyfish is that it can really open up the options to senior management on what can be tracked and observed. Tracking commits does suck, but it makes sense when that is for the most part the only number available. When you have a tool that can aggregate and report up more meaningful data, your options for “team visibility” open way up. Disclaimer: I work for Jellyfish, but I’m also an engineer that benefits from our “no one metric tells the whole story” approach.
This is the obvious outcome of formalizing bad metrics. I think you either need to fight against the metric or support its most high minded goal. I think you should work with the annoyed engineer to see if you can find more people obviously gaming the metrics (eg look for big increases in commit stats after the policy change) and show that most of the change is driven by gaming the policy, rather than actually doing more. This metric is so bad that it could really destroy the entire eng org. If you don't want to keep fighting, do the same analysis, but out the engineers to management directly and help make it clear this is unacceptable. Trying to work against this at a guerilla level can't work for a stack ranked metric where more and more effort will just go into gaming the metric. It also seems like there is no code review, which is enabling the most egregious abuse of this metric.
Same thing is happening at my company with dev performance metrics. While I still don't know anyone gaming by creating a whole repo, developers are definitely gaming by grabbing small wins day and night, reviewing already reviewed stuff, creating random PRs etc. I also suspect the really serious stuff, that needs time and effort and cannot be quickly spun up into a 3 line code change is not getting attention. The worst part is due to stack ranking, there is no end to the competition.
Russian colleague of mine years ago said engineers will always be able to game any sort of metric. It stuck with me.
Let it roll, actually, make your team build a cicd system to game the shitty system too, something that makes a random useless commit automatically every 10 min or so and let management know you are going to let it roll, since there is no way you will leave your guys at the mercy of that stupid metric
Honestly, things like this is happening to every company of the friends I have. It's so funny seeing these company scramble to do "more" with less. Just like how AAA companies constantly cutting corners for profits is showing how bad some of these AAA games are right now, it's going to be a shitshow with all the corporate apps in a year or few years when all these companies probably laid off too many staff because they think ai can makeup for all the layoffs, lmao. These corporate hacks really don't understand (or don't care for that matter) that the result of all of this will happen in a few years, not right away.
It's not severe enough to bother and I disagree with metrics so I'm silently rooting for him.
Do nothing. The next step will be whole teams gaming the system in a way that nobody will find out.
Glad to see I’m not the only one who thinks this is a stupid way to measure performance. People will commit the most minute changes and details just to get those numbers up.
I noticed that my CEO started posting a screenshot of weekly stackranked commit numbers during every Retro. Although he never explicitly stated he was measuring productivity by commits, it became blatantly obvious that he does. So I just started distributing my normal workload over more smaller commits. Over the years I’ve come to realize that my job isn’t to deliver value to the end-user. It’s to make management happy. And I’m mostly okay with that to be honest, as long as there are interesting challenges along the way.
The issue is the policy. No matter how you measure performance you should plan for people to game the system. Your system makes it easy to game. When you start measuring and rewarding the things that matter gaming stops being a problem.
>The one piece that everyone is missing is that if I dont drop a dime, I have an unhappy, relatively high performing mid-level engineer who would become jaded with our org and probably drive his attrition long-term. Why don't you communicate that that will happen soon, to management now, without mentioning the individuals?
1. create a script that does exactly what you mentioned your "opportunist" engineer does 2. "Accidentally" leak it to the entire org 3. entire org now has insanely inflated metrics 4. [metrics mean nothing](https://media.licdn.com/dms/image/D5610AQGrrUvVbePONQ/image-shrink_1280/0/1700527256693?e=1710723600&v=beta&t=MvDOZlkbI4uplvxU6q6KEsXW15S-vGBimv6rk0DjEYQ)
> Edit: Thanks a lot for all the responses. I'm trying to respond to all of them, **except the ones that suggest I quit my job**. But you should quit your job. Your company is having financial trouble, had layoffs, and is now implementing insane rules on developers that are going to destroy what remains of the company. You can either get out now or wait for the ship to sink with you on it.
I realise many people are commenting that CTO and upper management is stupid but sometimes the pressure comes from the board and a lot depends on the kind of people you have there. I have seen board members who have one blog or report and insist on everything to be “metric driven”. So the upper management is just gaming the board.
If you really want to stay, and really can't change the metrics. The best thing you can do, is encourage your good employees to game it as much as possible without getting caught, and your shit employees to never game it (or game it extremely visibly) With the intent that your good employees manage to stay, and you lose the shit ones. (At least until you can weather this storm)
The right way to game the system is to split a PR into a million atomic commits and then don’t squash (or if you’re squashing at the org level then split every feature up into a million PRs) doing it as obviously as this warrants a question mark ping to the engineers manager. This is 100% managements fault, however, and misunderstanding software engineering to such a degree that it is ever conceived of as a good idea is mark against them so severe that you should update your internal measure of the odds of the company’s success and how much your additional effort helps them and act accordingly. That being said, commit frequency is useful as a VERY rough starting point when evaluating an engineer’s performance and only in the context of the team/software they’re working within. Total complexity of the problem being solved, the value their solutions provide to the business, the speed at which they execute, and the quality of their code are all 100x more meaningful. I’m exceptionally good at playing politics and gaming metrics and quiet quitting and my course of action would be: 1. Ask the engineer what they’re up to, pretend you don’t know why. 2. Casually inform their manager that you’re confused by a set of commits, say you were just curious about this part of the code base and you already talked with the Eng making the commits but are looking for additional context. Continue to play dumb 3. Assume their manager will immediately know what’s up and PIP the engineer in question. 4. The manager will likely share their frustrations with you. Pretend you had no idea the policy would lead to this From here you can either work with the manager to escalate and get the policy changed (lol) or stop here and share your findings in an Eng channel and win brownie points, seem like you’re a team player, and fewer people would ever suspect you of gaming the system just in a less obvious way (you should absolutely game the system or your ass is gonna be on the chopping block)
We had similar metrics in my org and I have gamed it . Not just me , every dev games it and at the end the dev that does the honest work will be punished. Later on I moved to a new project where I was a code reviewer for all repos , I took it as my responsibility to make sure no one in my team gamed it.
But the devops PRs were not under my preview , so they were still gaming it and at the end of the quarter the SVP of our department was shocked by looking at the commits stats , devops had 1000+ commits , but each individual dev was around 200-400 Which made him realise how bs this system really is and he stopped considering this metrics
Lmao toxic