All I see here is a bit of advice on what to measure, and nothing on how to measure it. The problem with measuring software engineer performance has always been in the how, not the what, so this article is just noise, IMO.
A software engineering manager guide to measuring an engineer’s performance
81–90 of 113 posts
Re: A software engineering manager guide to measuring an engineer’s performance
#82Earlier quoted context omitted.
Debugging requires an extremely thorough understanding of the project, so much that you can not only find each responsibility in the code, but anticipate their emergent properties, what mistakes might have been made, and how their interactions might go wrong. Debugging a system successfully is the culmination of successful on-boarding, not a starting point. Doing the actual code changes to fix a bug which has already…
> an extremely thorough understanding of the project Right - so no time like the present to get started understanding!
Right. But sometimes this clashes with new developers expectation of actually being able to produce an acceptable solution and getting it merged within a reasonable amount of time.
Have those expectations never clashed for you?
Re: A software engineering manager guide to measuring an engineer’s performance
#83I think there's only one metric that is really effective for measuring and evaluating software teams. Tie their compensation to the product's financial success. This means, to the greatest extent possible, everything relevant to the product's success must be owned by the team and become their responsibility. Maybe there are some cross cutting concerns that should be the responsibility of a group separate from any pro…
Very bad idea. This almost always incentivizes to exploit for short term financial results at the expense of long term sustainability. For example, you can cut down customer support department to save money which would increase your profit (and therefore bonus for an employee who made that decision). In longterm you probably won't have customers. Executive pays often follow this rule and you can find vast number of stories how they ruined companies for short term gain and bonus cashouts.
Re: A software engineering manager guide to measuring an engineer’s performance
#84I know how to fix most problems with measuring an engineer's performance. The best solution is to remove "manager" from measurement. Lead developer would speak with all team members to assess performance of colleagues. Those are those who know exactly who makes their work harder and who helps them everyday whether by wise advice or by leaving clear code and thought through architecture.
Managers will argue that they have so much responsibilities that they cannot code together with teh team, but I again would say that the problem may be reduced with reduction or higher management. Bussiness part shall talk with engineers on feasibility of their vision and ideas without proxies who are so in the middle that they neighter understand bussiness nor technology.
Re: A software engineering manager guide to measuring an engineer’s performance
#85> Ability to write source code that adheres to specifications
This article reads like a series of bad advice from 1990s.
- No, engineers shouldn't be writing code that "adheres" to specifications. They should study, understand, question and contribute to problem statement and approach at all times (also called "requirements" in pre-2000s).
- Manager shouldn't be at center of evalauting performance but rather establishing process, standards and collecting feedback and metrics.
- Bonuses are inherently evil and would always motivate individuals to exploit short term gains at the expense of long term sustainibility. Any performance evaluation strategy must keep this issue front and center at all times.
- Large part of performance feedback shouldn't come from managers but peers
- Performance reviews should never be entirely metrics-driven. No finite set of metrics tell the full story and all metrics are susceptible at gaming.
- Don't treat new comers as incapable of fixing bugs or do X but not Y. Don't create class system of seniors vs juniors. Titles cause more troubles then they are worth.
Re: A software engineering manager guide to measuring an engineer’s performance
#86Yikes.
Re: A software engineering manager guide to measuring an engineer’s performance
#87I think there's only one metric that is really effective for measuring and evaluating software teams. Tie their compensation to the product's financial success. This means, to the greatest extent possible, everything relevant to the product's success must be owned by the team and become their responsibility. Maybe there are some cross cutting concerns that should be the responsibility of a group separate from any pro…
This doesn’t solve the issue of individual team member performance evaluation, even if it improved the overall performance of the team, you still wouldn’t know who are under and over-performers.
Because that is counter productive to increasing productivity.
Having team members focused on getting themselves ranked higher than their teammates, means incentivizing them to not help each other or do something they might not get credit for, even if it's in the best interest of the product or the team.
Re: A software engineering manager guide to measuring an engineer’s performance
#88I think there's only one metric that is really effective for measuring and evaluating software teams. Tie their compensation to the product's financial success. This means, to the greatest extent possible, everything relevant to the product's success must be owned by the team and become their responsibility. Maybe there are some cross cutting concerns that should be the responsibility of a group separate from any pro…
> Tie their compensation to the product's financial success. This is an atrocious idea in anything much larger than a start-up. It leaves the engineering team beholden to bad decisions made in other facets of the company (sales, marketing, upper management). It's exceedingly frustrating to write a solid, stable, performant program only to have marketing or sales push it as something that it is not and nosedive the co…
> It leaves the engineering team beholden to bad decisions made in other facets of the company (sales, marketing, upper management).
I mean, you're screwed anyways if those people can't do their jobs. No sales means no revenue means engineers taking a pay cut or getting laid off.
So the sales and marketing and product management responsible for your project, need to be on the same product team as the engineers, and have their compensation tied to the product's success.
If the engineers see themselves as the natural enemies of sales and marketing, the product is probably already doomed.
Re: A software engineering manager guide to measuring an engineer’s performance
#89I think there's only one metric that is really effective for measuring and evaluating software teams. Tie their compensation to the product's financial success. This means, to the greatest extent possible, everything relevant to the product's success must be owned by the team and become their responsibility. Maybe there are some cross cutting concerns that should be the responsibility of a group separate from any pro…
Very bad idea. This almost always incentivizes to exploit for short term financial results at the expense of long term sustainability. For example, you can cut down customer support department to save money which would increase your profit (and therefore bonus for an employee who made that decision). In longterm you probably won't have customers. Executive pays often follow this rule and you can find vast number of s…
OK, but if you substitute "product's long term financial success" for "product's financial success", I think the point still stands.
Could add in factors for customer retention and customer satisfaction, for example.
Everyone on the team should share responsibility for figuring out what will make the customer's happy with the product and how to deliver on those things.
Re: A software engineering manager guide to measuring an engineer’s performance
#90Earlier quoted context omitted.
Very bad idea. This almost always incentivizes to exploit for short term financial results at the expense of long term sustainability. For example, you can cut down customer support department to save money which would increase your profit (and therefore bonus for an employee who made that decision). In longterm you probably won't have customers. Executive pays often follow this rule and you can find vast number of s…
OK, but if you substitute "product's long term financial success" for "product's financial success", I think the point still stands. Could add in factors for customer retention and customer satisfaction, for example. Everyone on the team should share responsibility for figuring out what will make the customer's happy with the product and how to deliver on those things.
The criteria "product's long term financial success" doesn't have a lot of meaning. Does it mean my bonus is withheld until 5 years? What if something else goes wrong in such long time frame (like economy tanks) which wasn't my fault? What if someone unrelated contributes to 5-year success and I get to share the glory?
The point is that measuring performance off of single metric is incredibly tricky. In the field of reinforcement learning this is known as reward function engineering and its one of the hardest thing to get right for even well specified problems. Employee actions would need to have short term as well as long term focus (exploitation vs exploration). Most actions have consequences that won't reveal itself completely until sometime in future. The current "state of the art" technique is to use stock vest schedule with hope that employee would care to grow his/her future stock vest.