I got fired for being too productive–so I built the DOGE for engineering teams | Hacker News Reader

I got fired for being too productive–so I built the DOGE for engineering teams

8 pointshardworkonly15 comments

A few years ago, I was one of the top performers on my engineering team, shipping high quality code fast, reviewing PRs, and unblocking teammates. But instead of being rewarded, I started getting pushback from low performers who felt “pressured” by my output. The engineer manager, instead of looking at the actual data, sided with the complainers ( they all were more “Senior” ).

That’s when I realized: engineering performance is judged on gut feelings, politics, and who uses the most sophisticated words. So I built PerfPerf, an AI-powered tool that automatically tracks engineering productivity with real, objective data. No more guessing, no more biased reviews. It’s just clear insights on who’s actually delivering.

Note: Because I can’t handle 1 million users yet I’m only launching in private beta for now.. if you’re tired of corporate politics, go join the waitlist! (link: https://perfperf.dev/)

Do you work with someone who barely does anything but still gets the same recognition as you? Please be patient, I’m coming to clean the workforce DOGE style

I reeeaaaallllly don’t want this tool to create unnecessary pressure on regular engineers. Any ideas on how to prevent that? I want the bad energy directing in exposing slackers, not adding stress to everyone else.

Sounds dystopian. Some of the biggest contributions might take days of investigative work and result in one single line of committed code once the issue is found... it's not a good proxy for team contribution.

If my team started using this tool, I'd quit immediately. I'd be much more concerned about bad management (which this enables) than another dev putting out a little less work.

I don't agree that we should be optimizing teams for maximum productivity; that needs to be balanced against human needs. "Politics" isn't always good, but I'd prefer that to becoming just another assembly line widget.

OP really captured the sheer hubris and inexperience of DOGE though. My teams success is measured by customer impact. That could be a single line change, an updated document or walking a customer through something on a call. PRs, sizes of diffs are not a good metric for individual contributions or performance. What OP described is just absent/bad management. Tools can't really fix that. It takes a cultural change.

Who said I'm measuring PR sizes and lines of code? lol

To clarify, the tool is not meant to measure "success". In that case, you are absolutely right, it cannot be used for that. And I don't think a tool can measure those things.

The tool only is only meant to track important producitivty metrics. PerfPerf is here to check that there isn't someone "playing the game" and doing the bare minimum. AND to praise the ones doing more!

Example: When someone on a team, always approves PR's without never requesting changes. If that behavior is not standard in the team, it's gonna be flagged if happening for a full month.

Example2: Someone on the team, review only 20% of the PRs when requested as reviewer compared to the average of that team that review 60%. that's also gonna be flagged for review.

Let me know if that makes sense.

Lines of code is just an example (as are your other metrics). But the thing is that metrics without context drive poor decisions. And lazy managers will often rely on metrics as a poor proxy for actual performance when they don't have the time or skill or empathy to actually get to know their subordinates and their work well enough. It happens all the time already, not just in coding teams but also in marketing, national politics, etc.

Evidence driven decision making is wonderful when the evidence is actually meaningful. But the onus is on you to prove that your methodology is sound enough to do so, rather than just providing other poor metrics that are easily gamed by devs and/or misunderstood by managers.

Just as a counter-example, in the teams I've been in, typically many people will be asked to review code, but the bulk of the work is done by peers. The senior reviewers will wait until a few others have already requested changes, and then give the final approval with minor changes. Does your tool account for that? I dunno. I'm sure it could, but teams are full of everyday idiosyncrasies like that.

A good manager is already aware of that because they take time to understand the team dynamics and each person's duties, strengths, and weaknesses and adjusts accordingly, placing the person before the metric. They are able to look at data when they need to, but also use their soft skills to improve morale and performance in various ways. It is a skill set like any other, and metrics are only a small part of that.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

I wonder how you would address bias and intrusiveness such tools often have.

And also such tools imho just equip bad actors to whip the workforce into submission even more.

I'm thinking about only surfacing data when there is a huge gap between someone's performance and the average/median in a team.

I'd like to have metrics that would keep managers in check. I was thinking about adding team metrics, and attributing drops to the managers. Espetially now that I have data coming several teams from different companies, I can safely attribute that to managers when it deviates too much from the "global average".

Let me know if that makes sense.

How to judge someones performance without analyzing absolutely everything they do to most minute detail? What if someone has a great idea they share near water cooler that doubles company's profit but they haven't committed code as much as the next average person in the company? What is someone is a great team player helps the team and is always there to resolves someones blockers? Is this captured by metrics?

I think a tool providing constructive feedback and offers suggestions on how to improve performance in specific areas focusing on technical metrics (code quality, quantity, code churn) might be useful too, with less potential for misuse.

"DOGE style" as in "firing everybody, regardless of merit and often because of it, starting with whoever is easiest to fire"?

Perhaps you should be going about this from the other direction: offering your "real, objective" process to DOGE.

Sounds like maybe you got fired for being insufferable, not for being good, and not because other people were bad.

I truly do understand your viewpoint haha I would have thought the same thing if I read that post myself. But I'm just a cool dude unfortunetly lol And! I have recommandation from several colleagues regarding my work ethic AND the good energy I bring in the office.

Life and career is about soft skills, not metrics. Perhaps you were toxic and they just did not like you?

Well, I can safely say that I'm not toxic. All my recomandation mention the good vibes I bring to the teams I was part of. But to be fair... I would have said the same thing reading what I posted above lol

"Politics" but "DOGE"

>I reeeaaaallllly don’t want this tool to create unnecessary pressure on regular engineers. Any ideas on how to prevent that? I want the bad energy directing in exposing slackers, not adding stress to everyone else.

Then destroy it. It will ultimately be used as a surveillance tool to cow the masses (of engineers, in this case), as all surveillance tech ultimately becomes.

Reply on news.ycombinator.com