7 ms·

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

114 points by jonaldomo 7y ago

Dayshine 7y ago
"Process improvements" is a bit weird. You measure software engineering performance by their dev ops skills? It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge or how familiar they are with your specific system. Similarly, the explanation for "Debugging and troubleshooting complicated issues" 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's not really measuring skill but familiarity. The other two measures are just "Do they complete tasks" and "Do they follow code review guidelines", neither of which are very good measures beyond pass/fail. The conclusion is: > 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 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/test processes not actually developing the product? :)
- AstralStorm 7y ago
  You'd find a cushy job in a few corporates by doing just that. Someone else then gets to do hard tasks and gets bad reviews because they're slower at this and the numbers do not tick up.
- sanderjd 7y ago
  Your comment seems to fall into a common fallacy, that "developing the product" is entirely done by writing the code. That isn't true, there is no product if it is not built, tested, deployed, and debugged. Lots of programmers consider this "pointless" grunge work, but there is a reason it tends to be picked up by the more senior engineers on the team. This sort of work has more foundational impact than just writing feature code; it benefits all features written in the future.
  - Dayshine 7y ago
    No, of course other things are important. But if you measure only ancillary things, that's a pretty bad measure. I don't expect every one of my team members to understand the entire build system, testing setup, logging system. That's a waste of their time. They should know some, and perhaps one of the areas in depth.
    - sanderjd 7y ago
      My point is: Those things aren't ancillary. They aren't a waste of time. Good developers can figure out how to use logs to debug issues. They can figure out how to fix the build and deployment system when it's broken. They can figure out how to set up testing environments. If not them, then who? Managers look for people who are self sufficient. All of this stuff is a necessary and important part of the job.
- eropple 7y ago
  > It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge In my experience, this skillet being measured is the critical indicator for high-quality development talent at a healthy shop. You might need one deep-magic wizard for a particular area. You need breadth everywhere. You need to kill "that's not my job" stone dead when you see it. Writing code is easy. And it's usually an additive process, even when the code is subtractive. All the other stuff, the being-a-person-in-a-community stuff (because that's really what it is), is multiplicative. So I pretty unashamedly hire for curiosity and for breadth. When it's necessary, I contract out hard expertise until curious people can develop it internally.
- jimbokun 7y ago
  > You measure software engineering performance by their dev ops skills? Absolutely! That is the "dev" in dev ops. I think there are few things that increases the productivity of a dev team more than improved processes. > Why is knowing where the log files are, and knowing how to do complicated test setups for your specific environment a performance measure. Because if you don't know those things you are much less helpful to your product team.
weliketocode 7y ago
> 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. what? Please don'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. Even if he/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.
- lnsru 7y ago
  This!!! Nobody gained any skill from writing vanilla code or “hello world” type programs. Experience comes from spending days and sometimes weeks on ugly bugs. Bugs are perfect to level-up juniors quickly and find ones with weak motivation. Because having no progress for hours is really really frustrating. Went recently through this cycle teaching colleague. Found out, there is no motivation at all.
  - z3t4 7y ago
    I was very fortunately that my skill level followed the complexity of problems, only several years into my career I had to deal with systems level complexity and scaling issues, working as a high level web developer. Some things are just magic for a beginner. As a manager you should make people feel confortable, and some people do not have the mindset for constant self improvement. And some people you need to protect or they would over-work themselves. The trick is to have a load/capacity balance. Take games for example you usually progress the difficulty, you do not start with the end boss, or most players would quit, and those that pass would find the rest of the game boring.
  - bitL 7y ago
    Some people thrive when bugs are assigned to them early, some people thrive when whole new functionalities are assigned to them. Usually intersection of sets of these two kinds of people is close to empty and the worst mistake is to assume bugs first are good or new stuff first is good automatically.
caymanjim 7y ago
> Be a better management with transparent performance reviews and quick feedback with on focus areas. This article contains dozens of grammatical errors (starting right off with the title). Whenever I read something like this, I'm so distracted by the errors that I can't even focus on what the author is trying to say. The English language is dying.
- jolmg 7y ago
  It's not just English. :(
  - deleted 7y ago
    [deleted]
- techslave 7y ago
  i took it to be ESL author and gave some slack in that regard.
guitarbill 7y ago
> 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. Ugh, not this again. Obviously don't hire people who aren't good at their job. But most improvements come from investing in your team. > are they putting their code up for review [...] Missed one: Are their code reviews/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?
- srikbs8095 7y ago
  "Most improvements come from investing in your team" Very well said. Completely agree. Which is why I think the ability to "learn" as you go is so valuable. You don't want to hire a Know-it-all. You want to hire a Can-learn-it-all.
- tracer4201 7y ago
  > “But most improvements come from investing in your team.” I agree on this but you have to cut your losses at some point. Some people just aren’t motivated. A surprise pay raise, catering lunches, taking them to an offsite, etc whatever motivational strategies you have may provide some short term result, and that could be sufficient if your goal is just X and it’s in the line of sight, but sometimes raising the bar on your team means finding a different spot for the unmotivated folks, and if they’re not investing even in that, then cut your losses and let them go.
  - mieseratte 7y ago
    Absolutely agree. Some people are just beyond saving. Sometimes this a matter of skill, and sometimes a matter of will but the result is the same. If you're hiring pipe-hitters and grafting them onto a JV squad the results will often not be what you'd hoped for, unless you have a particularly high-tolerance for projects being over (time-)budget. Having personally burned myself down in such an environment, a good interview question to ask is if everyone has gone through the same hiring process and if not ask what the previous process was and why things have changed.
backtobecks 7y ago
Are we really going to pretend that managers in sillycoin valley even bother to be objective like this?
- dang 7y ago
  I'm sure not, but could you please stop posting unsubstantive comments here?
perlgeek 7y ago
> Code reviews are probably the first thing a new engineer can start doing in a new role. That really depends on what you want the code review to achieve. Catch typos? Yes, a new engineer can do that. Check if code fits into the existing architecture, adheres to the invariants of the code base, uses base libraries idiomatically etc? I don't think a new engineer can contribute that from the start. > Creating metrics through issue trackers and time sheets Which metrics? It'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 will optimize for / game a metric when it's used to assess their performance).
- ashishuthama 7y ago
  A new engineer can learn a lot from being on code reviews earlyon. Anything from the team coding style to the application architecture.
  - jolmg 7y ago
    A reviewer is not there to learn. If anything, they're there to teach. What good is a reviewer that can't grade others on their adherence to the coding style and application architecture of the project? They're supposed to determine what goes in or not.
    - wolco 7y ago
      They wouldn't be the only one reviewing or reviewing at all. It would help them understand the process if they see it in action.
    - stevens32 7y ago
      Reviewers not willing to learn anything during a code review is probably an easy tell for a crappy code review culture
      - jolmg 7y ago
        This discussion is about newcomers that know basically nothing of the project. When I say they're not there to learn, I mean their primary function as reviewers isn't to learn from what gets submitted. They can learn depending on what gets submitted, but if 90% of the time their ignorance doesn't permit them to properly determine if what's submitted to them is good or not, then what's the point of their review?
januzis 7y ago
It seems to me there are two sides to engineer's performance: the ability and the productivity. Ability measures how complex tasks can an engineer solve and how well can he/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. As a technical lead, I feel that I'm able to judge the ability of individual team members, but I'm having a hard time objectively judging productivity. Simple count of PRs doesn'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'm not going to dive into, but the end result is that it's hard to have an objective productivity evaluation based on the engineer's output only. I'd be interested to know how other people evaluate individual productivity?
- JamesBarney 7y ago
  This is especially tough because one important development skill is the ability to solve complex problems with simple solutions. This can sometimes make them look less productive because they've made a hard problem look easy. One technique I've found that helps a little is having everyone individually estimate tasks before hand. Over time you can notice who is completing tasks faster or slower than the average. Of course this is just one data point that needs to be weighed against a variety of others.
  - januzis 7y ago
    Measuring against estimates incentivizes over-estimating, especially if the team is small, and team members know roughly who will do what during the estimation process. Big complicated tasks also tend to be under-estimated, so they would be avoided, because they would usually influence the perceived productivity negatively. I would like to find a feasible approach to productivity evaluation using the output only (PRs, reviews, basically all the data points the article mentions), because I feel that’s the only way of creating an environment, where team members can proactively take a bit more time when it benefits the end result, without fearing any negative repercussions.
deleted 7y ago
[deleted]
slaymaker1907 7y ago
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. 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.
- yowlingcat 7y ago
  It's a substitute for a strategy: in reality, it is a wishful thought masquerading as a strategy. It doesn't give you any strategic framework for achieving that by hiring, mentoring and retaining in a competitive landscape. I find it of limited use and anachronistic.
jimbokun 7y ago
I 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 product team, but those should be rare and require a strong justification. 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. 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.
- Rooster61 7y ago
  > 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 company due to customers calling bullshit. Start-ups are somewhat immune to this because of the lower barrier of communication between departments, as many people will be wearing multiple hats due to there being more things to do than people to do them. This is very visible when executives begin choking off benefits across the board. Nothing kills morale quite like losing your bonus because another department isn't doing its job properly. I've seen more than one mass exodus from a company as a result of this.
  - jimbokun 7y ago
    > 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.
dfeojm-zlib 7y ago
I think of software developers having multiple qualities: - coolness (cooperation, proactiveness, professionalism) - carefulness - integrity (ethics) - morale - cadence (speed) of work - skills competencies (matrix) - grit (badassery) - estimated time to completion multiplier
pmiller2 7y ago
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.
gorzynsk 7y ago
I 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.
sytelus 7y ago
> 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.
alexbanks 7y ago
Yikes.

114 points by jonaldomo 7y ago

"Process improvements" is a bit weird. You measure software engineering performance by their dev ops skills? It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge or how familiar they are with your specific system. Similarly, the explanation for "Debugging and troubleshooting complicated issues" 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's not really measuring skill but familiarity. The other two measures are just "Do they complete tasks" and "Do they follow code review guidelines", neither of which are very good measures beyond pass/fail. The conclusion is: > 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 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/test processes not actually developing the product? :)

AstralStorm 7y ago
You'd find a cushy job in a few corporates by doing just that. Someone else then gets to do hard tasks and gets bad reviews because they're slower at this and the numbers do not tick up.
sanderjd 7y ago
Your comment seems to fall into a common fallacy, that "developing the product" is entirely done by writing the code. That isn't true, there is no product if it is not built, tested, deployed, and debugged. Lots of programmers consider this "pointless" grunge work, but there is a reason it tends to be picked up by the more senior engineers on the team. This sort of work has more foundational impact than just writing feature code; it benefits all features written in the future.
- Dayshine 7y ago
  No, of course other things are important. But if you measure only ancillary things, that's a pretty bad measure. I don't expect every one of my team members to understand the entire build system, testing setup, logging system. That's a waste of their time. They should know some, and perhaps one of the areas in depth.
  - sanderjd 7y ago
    My point is: Those things aren't ancillary. They aren't a waste of time. Good developers can figure out how to use logs to debug issues. They can figure out how to fix the build and deployment system when it's broken. They can figure out how to set up testing environments. If not them, then who? Managers look for people who are self sufficient. All of this stuff is a necessary and important part of the job.
eropple 7y ago
> It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge In my experience, this skillet being measured is the critical indicator for high-quality development talent at a healthy shop. You might need one deep-magic wizard for a particular area. You need breadth everywhere. You need to kill "that's not my job" stone dead when you see it. Writing code is easy. And it's usually an additive process, even when the code is subtractive. All the other stuff, the being-a-person-in-a-community stuff (because that's really what it is), is multiplicative. So I pretty unashamedly hire for curiosity and for breadth. When it's necessary, I contract out hard expertise until curious people can develop it internally.
jimbokun 7y ago
> You measure software engineering performance by their dev ops skills? Absolutely! That is the "dev" in dev ops. I think there are few things that increases the productivity of a dev team more than improved processes. > Why is knowing where the log files are, and knowing how to do complicated test setups for your specific environment a performance measure. Because if you don't know those things you are much less helpful to your product team.

weliketocode 7y ago

> 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. what? Please don'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. Even if he/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.

lnsru 7y ago
This!!! Nobody gained any skill from writing vanilla code or “hello world” type programs. Experience comes from spending days and sometimes weeks on ugly bugs. Bugs are perfect to level-up juniors quickly and find ones with weak motivation. Because having no progress for hours is really really frustrating. Went recently through this cycle teaching colleague. Found out, there is no motivation at all.
- z3t4 7y ago
  I was very fortunately that my skill level followed the complexity of problems, only several years into my career I had to deal with systems level complexity and scaling issues, working as a high level web developer. Some things are just magic for a beginner. As a manager you should make people feel confortable, and some people do not have the mindset for constant self improvement. And some people you need to protect or they would over-work themselves. The trick is to have a load/capacity balance. Take games for example you usually progress the difficulty, you do not start with the end boss, or most players would quit, and those that pass would find the rest of the game boring.
- bitL 7y ago
  Some people thrive when bugs are assigned to them early, some people thrive when whole new functionalities are assigned to them. Usually intersection of sets of these two kinds of people is close to empty and the worst mistake is to assume bugs first are good or new stuff first is good automatically.

caymanjim 7y ago

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

jolmg 7y ago
It's not just English. :(
- deleted 7y ago
  [deleted]
techslave 7y ago
i took it to be ESL author and gave some slack in that regard.

guitarbill 7y ago

> 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. Ugh, not this again. Obviously don't hire people who aren't good at their job. But most improvements come from investing in your team. > are they putting their code up for review [...] Missed one: Are their code reviews/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?

srikbs8095 7y ago
"Most improvements come from investing in your team" Very well said. Completely agree. Which is why I think the ability to "learn" as you go is so valuable. You don't want to hire a Know-it-all. You want to hire a Can-learn-it-all.
tracer4201 7y ago
> “But most improvements come from investing in your team.” I agree on this but you have to cut your losses at some point. Some people just aren’t motivated. A surprise pay raise, catering lunches, taking them to an offsite, etc whatever motivational strategies you have may provide some short term result, and that could be sufficient if your goal is just X and it’s in the line of sight, but sometimes raising the bar on your team means finding a different spot for the unmotivated folks, and if they’re not investing even in that, then cut your losses and let them go.
- mieseratte 7y ago
  Absolutely agree. Some people are just beyond saving. Sometimes this a matter of skill, and sometimes a matter of will but the result is the same. If you're hiring pipe-hitters and grafting them onto a JV squad the results will often not be what you'd hoped for, unless you have a particularly high-tolerance for projects being over (time-)budget. Having personally burned myself down in such an environment, a good interview question to ask is if everyone has gone through the same hiring process and if not ask what the previous process was and why things have changed.

backtobecks 7y ago

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

dang 7y ago
I'm sure not, but could you please stop posting unsubstantive comments here?

perlgeek 7y ago

> Code reviews are probably the first thing a new engineer can start doing in a new role. That really depends on what you want the code review to achieve. Catch typos? Yes, a new engineer can do that. Check if code fits into the existing architecture, adheres to the invariants of the code base, uses base libraries idiomatically etc? I don't think a new engineer can contribute that from the start. > Creating metrics through issue trackers and time sheets Which metrics? It'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 will optimize for / game a metric when it's used to assess their performance).

ashishuthama 7y ago
A new engineer can learn a lot from being on code reviews earlyon. Anything from the team coding style to the application architecture.
- jolmg 7y ago
  A reviewer is not there to learn. If anything, they're there to teach. What good is a reviewer that can't grade others on their adherence to the coding style and application architecture of the project? They're supposed to determine what goes in or not.
  - wolco 7y ago
    They wouldn't be the only one reviewing or reviewing at all. It would help them understand the process if they see it in action.
  - stevens32 7y ago
    Reviewers not willing to learn anything during a code review is probably an easy tell for a crappy code review culture
    - jolmg 7y ago
      This discussion is about newcomers that know basically nothing of the project. When I say they're not there to learn, I mean their primary function as reviewers isn't to learn from what gets submitted. They can learn depending on what gets submitted, but if 90% of the time their ignorance doesn't permit them to properly determine if what's submitted to them is good or not, then what's the point of their review?

januzis 7y ago

It seems to me there are two sides to engineer's performance: the ability and the productivity. Ability measures how complex tasks can an engineer solve and how well can he/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. As a technical lead, I feel that I'm able to judge the ability of individual team members, but I'm having a hard time objectively judging productivity. Simple count of PRs doesn'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'm not going to dive into, but the end result is that it's hard to have an objective productivity evaluation based on the engineer's output only. I'd be interested to know how other people evaluate individual productivity?

JamesBarney 7y ago
This is especially tough because one important development skill is the ability to solve complex problems with simple solutions. This can sometimes make them look less productive because they've made a hard problem look easy. One technique I've found that helps a little is having everyone individually estimate tasks before hand. Over time you can notice who is completing tasks faster or slower than the average. Of course this is just one data point that needs to be weighed against a variety of others.
- januzis 7y ago
  Measuring against estimates incentivizes over-estimating, especially if the team is small, and team members know roughly who will do what during the estimation process. Big complicated tasks also tend to be under-estimated, so they would be avoided, because they would usually influence the perceived productivity negatively. I would like to find a feasible approach to productivity evaluation using the output only (PRs, reviews, basically all the data points the article mentions), because I feel that’s the only way of creating an environment, where team members can proactively take a bit more time when it benefits the end result, without fearing any negative repercussions.

deleted 7y ago

[deleted]

slaymaker1907 7y ago

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. 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.

yowlingcat 7y ago
It's a substitute for a strategy: in reality, it is a wishful thought masquerading as a strategy. It doesn't give you any strategic framework for achieving that by hiring, mentoring and retaining in a competitive landscape. I find it of limited use and anachronistic.

jimbokun 7y ago

I 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 product team, but those should be rare and require a strong justification. 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. 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.

Rooster61 7y ago
> 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 company due to customers calling bullshit. Start-ups are somewhat immune to this because of the lower barrier of communication between departments, as many people will be wearing multiple hats due to there being more things to do than people to do them. This is very visible when executives begin choking off benefits across the board. Nothing kills morale quite like losing your bonus because another department isn't doing its job properly. I've seen more than one mass exodus from a company as a result of this.
- jimbokun 7y ago
  > 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.

dfeojm-zlib 7y ago

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

pmiller2 7y ago

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.

gorzynsk 7y ago

I 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.

sytelus 7y ago

> 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.

alexbanks 7y ago

Yikes.