Written by Patrick Bollinger
Originally published on 2021-09-05
Net Promoter Score (NPS) is a metric used in businesses to gather how likely customers would recommend their business to others. NPS has been adapted internally by businesses via the employee NPS (eNPS) to measure how likely employees would recommend others to work there. This article is an investigation on how NPS and its designs can be applied to an engineering team within a business. There is the core engineering NPS question to get a high-level overview of the engineering team’s health, “How likely are you to recommend another engineer to work here?” We will then breakdown the engineering NPS into more detailed questions to help identify how to improve the engineering NPS. Although this article is focused on software engineering, the idea of focusing NPS onto a specific organization’s nuances could be applicable to many organizations.
- These ideas have not been tested but I will be refining them as time goes on.
- These ideas/opinions are mine alone and not representative of any organization.
- These ideas are not to be critical of nor directed at my current or prior employers.
Engineering churn is prominent in the tech industry. Although there are many reasons why people may leave a company, it also does not help when others in the industry advocate to switch companies. I am no saint when it comes to switching companies either, as I left my prior company after working there for 2 and ½ years, but it makes me wonder if leaders in the industry are focused on the right things. With eNPS, companies get a holistic view of how employees feel about a given company. However, there are many nuances in each department that is not always captured in the standard eNPS. As a hypothetical, if a tech company offered fantastic benefits but the technology stack ran off TI-BASIC, the company might have a high eNPS for all departments except engineering since the engineers may not be gaining skills that they feel are sought after. The goal of this article is to explore the facets of software engineering in the tech industry to promote engineering organizations that engineers are proud to work at.
Since the goal of NPS is to ask one question to help gather data on how likely customers would recommend a business to a potential customer, we can come up with one question to ask current engineers how likely they are to recommend the company to a potential candidate.
How likely are you to recommend another engineer to work here?
A company might be able to infer the value of the engineering NPS by how many referrals are being made. However, asking this question is a more direct way to get a pulse on how engineers feel about working at the company. As mentioned before, there are many facets that can lead to an engineer answering the question in a certain way, so next we can explore those facets.
We will focus on the following facets: people, communication, project management, code changes, deployment, security, and technology.
Most of these questions are focused on the sentiment a person feels about their organization’s processes. The responses can then be used to determine Objectives and Key Results (OKRs) and the like.
The following are questions on how an engineer feels about the people they interact with and the quality of those interactions.
- I feel that my co-workers care about me.
- I feel that my co-workers care about my work.
- I care about my co-workers.
- I care about my co-workers’ work.
- I feel that my manager cares about me.
- I feel that my manager cares about my work.
- I care about my manager.
- I care about my manager’s work.
The following are questions on how an engineer feels about visibility of what is being worked on and ability to address problems if they arise.
- My co-workers know what I am focused on.
- I know what my co-workers are focused on.
- My manager knows what I’m focused on.
- I know what my manager is focused on.
- If there is a problem, I can easily bring it up in a public forum.
- If there is a problem, I can easily bring it up to a co-worker.
- If there is a problem, I can easily bring it up to my manager.
The following are questions on how an engineer feels about the process of organizing tasks and the overall workflow for a given task.
- I understand how tasks are being prioritized.
- I trust in the method for how tasks are being prioritized.
- When I start a task, all requirements are documented.
- I understand the process of tracking a task.
- I feel the process of tracking a task is easy.
The following are questions on how an engineer feels about working on the code itself and completing a single task. These questions could be asked on a per repository/package/project basis.
- I understand the process of making code changes.
- I feel the process of making code changes is easy.
- I feel it is easy to make code changes in the code base.
- I trust in our unit tests.
- I trust in our integration tests.
- I feel code changes are sufficiently covered by code-level tests.
The following are questions on how an engineer feels about the process of getting a task they have completed in front of a customer for review.
- I understand how my changes are deployed into production.
- I feel the process of deploying is easy.
- I feel we are deploying too frequently.
- I feel we are deploying too infrequently.
- I trust in our end-to-end tests.
The following are questions on how an engineer feels about how security is handled from their perspective.
- I understand how we are keeping our product secure.
- I know how to ensure our product stays secure.
- I feel we are good at updating dependencies.
The following are questions how an engineer feels about the technology being utilized in their organization.
- I am happy with the technology stack we use.
- I am happy with the front-end technologies we use.
- I am happy with the back-end technologies we use.
- I am happy with the infrastructure we use.
- I feel I have all the tools I need to do my job well.
There have been many different questions proposed on how to start measuring detailed feelings of engineers working within an organization. However, we do not have to ask them all in one sitting. I still want to try this out myself, so following is what I plan on proposing.
- Once a quarter, ask the overall engineering NPS question, “How likely are you to recommend another engineer to work here?”
- In the survey use a scale of 1-10 per traditional NPS scoring.
- Include a required note section asking why they chose the value they chose.
- Once a month, pick # of these detailed questions based on OKRs set by the organization.
- In the survey use a scale of 1-5.
- 1-3 are detractors.
- 4-5 are promoters.
- Include an optional note section per question to allow individuals to expand upon their response.
- In the survey use a scale of 1-5.
- Once every other week, pick 5 of these detailed questions at random and ask them in an anonymous survey.
- In the survey use a scale of 1-5 with an abstain option.
- 1-3 are detractors.
- 4-5 are promoters.
- Abstains are passives.
- Include an optional note section per question to allow individuals to expand upon their response.
- In the survey use a scale of 1-5 with an abstain option.
As an example of how this can be used for OKRs, instead of setting a key result of achieving 100% code coverage for unit tests, we can set a goal of 100% NPS for “I trust in our unit tests” with a combination of always increasing code coverage per pull request. The reason for this is 100% code coverage is not important if none of the engineers trust in the unit tests themselves.
I hope this article has been helpful in giving a different perspective on how to think about engineers and promoting a culture of care for where they work. As an engineer myself, please take this for what it is worth to you. There are many nuances to people and organizations that cannot be captured in a single article. For instance, if engineers are churning at an organization because the compensation is not competitive, then even if that organization has the best engineering practices in place, engineers will not want to stay for long.
As a closing thought for engineering leaders, you may feel you have a grasp on how the engineers feel through one-on-ones and other meetings. I would advocate though that if you do not have data to support how sentiment is improving, how certain can you be that the engineers you are working with are likely to recommend your organization as a place for other engineers to work?