A software engineering manager guide to measuring an engineer’s performance

&gt; It is not realistic to give an early software engineer defects within the first few months of a project assignment. So this skill area might not apply until a little later in their career.<p>what?<p>Please don&#x27;t listen to this. Give junior engineers bugs right away. It forces them to set up their environment for debugging and begin to understand the flow of the project.<p>Even if he&#x2F;she needs to be guided to the solution, this is a GREAT litmus test for the standards of your documentation, and ease of environment setup.

&gt; The Lake Wobegon Strategy famously coined by Google and Peter Norvig claims that you should always hire above your team average. Doing so increases the quality of your team.<p>Ugh, not this again. Obviously don&#x27;t hire people who aren&#x27;t good at their job. But most improvements come from investing in your team.<p>&gt; are they putting their code up for review [...]<p>Missed one: Are their code reviews&#x2F;pull requests high quality? I.e. do they go out of their way to document how they tested it? Reproduction steps? Do they invest time in making code reviews as easy to review for other people as possible? Or does their code reviews always take multiple rounds of review due to sloppiness?

&gt; Code reviews are probably the first thing a new engineer can start doing in a new role.<p>That really depends on what you want the code review to achieve.<p>Catch typos? Yes, a new engineer can do that.<p>Check if code fits into the existing architecture, adheres to the invariants of the code base, uses base libraries idiomatically etc? I don&#x27;t think a new engineer can contribute that from the start.<p>&gt; Creating metrics through issue trackers and time sheets<p>Which metrics? It&#x27;s far too easy to create metrics that are easy to measure, rather than metrics which actually increase the business when optimized for (and developers <i>will</i> optimize for &#x2F; game a metric when it&#x27;s used to assess their performance).

&quot;Process improvements&quot; is a bit weird. You measure software engineering performance by their dev ops skills?<p>It&#x27;s a completely different skillset, and you&#x27;re probably only measuring how eager people are to have breadth of knowledge or how familiar they are with your specific system.<p>Similarly, the explanation for &quot;Debugging and troubleshooting complicated issues&quot; is a bit odd. Why is knowing where the log files are, and knowing how to do complicated test setups for your specific environment a performance measure. Again, that&#x27;s not really measuring skill but familiarity.<p>The other two measures are just &quot;Do they complete tasks&quot; and &quot;Do they follow code review guidelines&quot;, neither of which are very good measures beyond pass&#x2F;fail.<p>The conclusion is: &gt; Once a set of skill areas for a role is landed and agreed upon you will want to make sure your team knows in advance what they are being measured on<p>So, to do well in your business, I need to pick easy tasks, snipe code reviews, make pointless CI tasks and spend all my time learning the build&#x2F;test processes not actually developing the product? :)

It seems to me there are two sides to engineer&#x27;s performance: the ability and the productivity. Ability measures how complex tasks can an engineer solve and how well can he&#x2F;she execute, and the productivity measures the actual amount of work done. Able programmer is not necessarily productive, and productive programmer might not be able to do tasks of high complexity.<p>As a technical lead, I feel that I&#x27;m able to judge the ability of individual team members, but I&#x27;m having a hard time objectively judging productivity. Simple count of PRs doesn&#x27;t really tell the whole story, and some tasks look simple in hindsight, when in reality it took a lot of effort to find a good solution. There are also a lot of other complications I&#x27;m not going to dive into, but the end result is that it&#x27;s hard to have an objective productivity evaluation based on the engineer&#x27;s output only.<p>I&#x27;d be interested to know how other people evaluate individual productivity?

&gt; Be a better management with transparent performance reviews and quick feedback with on focus areas.<p>This article contains dozens of grammatical errors (starting right off with the title). Whenever I read something like this, I&#x27;m so distracted by the errors that I can&#x27;t even focus on what the author is trying to say. The English language is dying.

&gt; Ability to write source code that adheres to specifications<p>This article reads like a series of bad advice from 1990s.<p>- No, engineers shouldn&#x27;t be writing code that &quot;adheres&quot; to specifications. They should study, understand, question and contribute to problem statement and approach at all times (also called &quot;requirements&quot; in pre-2000s).<p>- Manager shouldn&#x27;t be at center of evalauting performance but rather establishing process, standards and collecting feedback and metrics.<p>- 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.<p>- Large part of performance feedback shouldn&#x27;t come from managers but peers<p>- Performance reviews should never be entirely metrics-driven. No finite set of metrics tell the full story and all metrics are susceptible at gaming.<p>- Don&#x27;t treat new comers as incapable of fixing bugs or do X but not Y. Don&#x27;t create class system of seniors vs juniors. Titles cause more troubles then they are worth.

I think there&#x27;s only one metric that is really effective for measuring and evaluating software teams.<p>Tie their compensation to the product&#x27;s financial success.<p>This means, to the greatest extent possible, everything relevant to the product&#x27;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 product team, but those should be rare and require a strong justification.<p>This will have an amazing effect of clarifying prioritization of what to work on and figuring out how to deliver it as quickly and reliably as possible. Suddenly the whole team will be in the loop about what features are most important to the customers. Suddenly the things blocking new features demanded by the customers from shipping will be cleared away.<p>I think for any other metric you can devise, either intentionally or unintentionally, employee behavior will be optimized for satisfying the metric, and not customer satisfaction with the product.

I think of software developers having multiple qualities:<p>- coolness (cooperation, proactiveness, professionalism)<p>- carefulness<p>- integrity (ethics)<p>- morale<p>- cadence (speed) of work<p>- skills competencies (matrix)<p>- grit (badassery)<p>- estimated time to completion multiplier

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.

Lake Woebegon is a horrifically bad strategy under even the most basic of assumptions. There are not enough engineers in the world available for hiring to create a single large tech company under such a strategy even with zero turnaround. A fixed level of achievement can give you similar quality (assuming you do have some level of attrition) but at a much faster rate.<p>The best strategy after looking at various strategies under simulation is to focus on developing the people you already have since fixing your quality through hiring is very difficult and expensive.

I know how to fix most problems with measuring an engineer&#x27;s performance. The best solution is to remove &quot;manager&quot; 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.<p>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.

Yikes.

Are we really going to pretend that managers in sillycoin valley even bother to be objective like this?