As the VP of Engineering at a rapidly growing software company, one of your primary responsibilities is to build your engineering team. Initially, this is primarily a recruiting function. As your team expands, though, you want to ensure that the engineers you have hired stay with the company. There is nothing more costly to organizational development than to have a new engineer leave after 6 months.

Granted, you shouldn’t expect engineers to stay on your team forever. I think a good target in a competitive hiring market is four years.  Beyond four years at a company, an engineer will start to feel that there is an opportunity cost to remaining. Outside recruiters will reinforce this perception, as they dangle other offers in front of the engineer and warn them about being pigeonholed.

The way I measure retention is based on the number of employees who voluntarily depart the company in a trailing 12 month period as a percentage of total employees. I don’t include terminations in this number. As an example, if you have 100 engineers on the team, and 50 quit in the last year, then you have a 50% retention rate. Using the four year engineer longevity target, then a good retention rate is 75%. Of course, you can strive for higher than this, and may do so occasionally. I passed the 80% retention rate during one 12 month period at a pre-IPO company in San Francisco. But, that isn’t sustainable over the long term in a tight hiring market.

In this post, I will offer some tactics to improve your engineering team’s retention levels.

Company Mission

First, we should consider engineers as employees. Think of why an employee would want to work for your company. Often it boils down to your company’s mission and how that contributes to the greater good. Is the company delivering a product or service that benefits other people or makes the world a better place? Is it something that employees can feel passionate about? Most companies have a compelling mission, or they wouldn’t be in business. You want to articulate your company’s mission in a way that excites your employees. Generally, the marketing or HR team will have this messaging worked out and available in presentable sound bytes. You should promote it to new hires and reinforce the message during group meetings.

As an example, at Zoosk, where I led engineering for several years, we went through this process. On the surface, Zoosk could be described as a dating app. The service allows individuals to discover and communicate with other members, often resulting in a date. However, after receiving notes of gratitude from married couples, we realized that our mission was broader than helping members get a date. Zoosk helps people find their life partner, perhaps the most significant event of their lives. Painted in this way, it was very easy to embrace the mission of the company. We reinforced that mission through internal company messaging. We even printed photos of happy couples with the text of their testimonials, and posted them on the office walls for all employees to see.

As another example, you may have noticed GE’s latest ad campaign in which a developer describes getting a job at GE, which will allow him to write software that makes hospitals run more efficiently.  This is contrasted with another developer’s job at “Zazzies”, where his app puts fruit hats on animals. The point is clear – that developers, as employees, want to work somewhere in which they feel their contribution has a positive impact.

Company Progress against Goals

Employees want to see that their company is moving forward. This measure of forward motion is usually represented as progress against goals. Engineers generally care about two types of goals – product usage and company financials.

Product usage goals reflect the number of users of a product and the activities they perform.  Examples might be user sessions per day, messages sent, photos uploaded, items purchased, etc. Engineers like to work on a product that is being used, as it gives meaning to their work. They also like to take ownership over the performance of their product – having frequent updates on performance against goals is very motivating.

Another significant set of metrics is the company’s financials.  These represent items like revenue, expenses, income, etc. Financial metrics are important because they provide feedback on whether the company is viable as a business. Engineers care about these because they want to work at a successful company. Also, they generally will have an equity stake in the company and want to ensure their equity will be worth more in the future.

For these reasons, I think it is important to share product usage metrics and financial results with the engineering team. I realize this requires a bit more trust than some companies are comfortable with, but the transparency goes a long way. If the company is exceeding all of its goals, that’s great. The team will be very excited. If the company is not meeting its goals, then you have the opportunity to provide perspective on why and how the company will fix that. Engineers are generally solution-oriented. By sharing the company’s challenges with them, I often find that they will make suggestions. Even if these aren’t good ideas, problem solving reflects positive thinking, which is good for morale.

You can share these product and financial metrics at team meetings. I usually summarize them at quarterly engineering all-hands. For timely updates, though, I will grab 5 minutes at the end of recurring team meetings, like sprint retrospectives or even stand-ups. This openness is very important and the engineers will appreciate the candor. I realize that a publicly traded company can’t disclose detailed financials regularly outside of the quarterly reporting cycle. If that is the case, at least try to spend some time reviewing the financial information after it is public. If your company is private, then I would share as much as possible, with the appropriate admonitions to not disclose the information outside the company.

Engineering Team Culture

Much is made about building engineering team culture in our industry. A lot of that focus is often on social factors, like having a “no a-holes” policy, providing snacks or encouraging participation in volunteer activities. I think building a strong engineering culture is more foundational. Like any team in a competitive space, the participants want to feel like they are “winning”. While we don’t have direct competitions between engineering teams at technology companies, a measure of “winning” can at least be translated into doing work that is noteworthy in the industry.

Having a “winning” culture means that the team is continually pushing itself to be better. They are looking for new ways to solve problems – better technology, improved process, skills development, etc. Working towards being better will ultimately lead to a sense of pride. And if your engineers feel proud of what they do, that will be a strong driver of culture.

Here are some ideas to build culture:

  • Continuous improvement. Encourage activities that focus on making improvements to your team’s processes, infrastructure and capabilities.  Conduct retrospectives.  Relentlessly ask if there is a better way to accomplish a task.
  • Encourage automation. The enemy of continuous improvement is complacency. One way to become complacent is to fill available development time with repetitive tasks. By automating those, time is freed up to find new ways to improve.
  • Promote yourself. You can reinforce the drive for continuous improvement by promoting the team’s accomplishments in your industry.  One output for this is through an engineering team blog. Most progressive Internet based companies have active and insightful engineering blogs. See UberSpotify and Airbnb for examples. The engineering blog provides a medium for team members to share technology accomplishments and best practices with the rest of the industry. This naturally drives improvement – if your team doesn’t have anything worth promoting to the industry, then it isn’t doing anything remarkable. Additionally, encourage your team members to speak at relevant conferences and allocate time for them to prepare. Landing a speaking engagement at a popular technology conference can generate a lot of visibility.
  • Support open source efforts. Make contributions to open source projects, or start a new one. This shows that your engineering team is advanced enough to improve the state of shared industry solutions.
  • Share wins. When an engineer accomplishes something notable, you should broadcast that to the rest of the team. This reinforces the positive behavior throughout the organization. Further, it makes the engineer feel good about what they accomplished and want to do more of it.

Professional Development

Probably the most important factor for an engineer’s job satisfaction is their professional development.  As an artisan, good software engineers value the ability to improve their skill set. This makes them more valuable in the workforce and satisfies their desire to expand their knowledge. Here are some ideas to provide engineers with professional development opportunities:

  • Training. Encourage your team members to find training opportunities that interest them and pay for these. Training can take the many forms – a 3-5 day intensive course on a particular technology or an evening class at a local university. Many of these programs are offered online.
  • Conferences. Similar to training, let your engineers attend relevant conferences. These are usually associated with the technology they focus on. Conference attendance may require travel. The company should pay for this. I usually budget for one conference for each engineer a year. I offer to pay for more than one conference if an engineer lands a speaker role.
  • Team rotations. Based on how your teams are structured, allow engineers to rotate onto different teams. This gives them exposure to new technologies and products. Rotations can be done for a short duration, like a quarter. You will want to manage the number of concurrent rotations so that productivity isn’t severely impacted by the associated ramp up.
  • Hackathons.  Conducting hackathons allows engineers to experiment with new technologies and try out product ideas. Most companies structure these as a 1-3 day event where engineers form teams and work on a new idea. I like to keep ideas focused on one of two areas – either a product feature or a productivity improvement. The teams should produce a working prototype. Ideas are then demo’ed at the end of the hackathon and prizes are awarded to the top teams. Many good product ideas will come out of these hackathons and the teams really enjoy the experience. I try to conduct at least 2 hackathons a year.
  • Independent work. Google’s 10% time is a well-known practice. I have cast this concept as “tech time” at other organizations. The idea is to allocate some regular time window for engineers to work on a technology problem outside of their normal sprint development tasks. I usually make this optional for engineers, but request that they document their independent work on a shared medium if they participate. Often this independent work allows the engineer to experiment with a new technology on their own schedule, resulting in more approaches for solving problems.
  • Feedback. Your company’s formal employee review process should include productive mechanisms to give feedback. I often try to go beyond this and ensure that managers give engineers feedback on their performance regularly. Weekly one-on-one’s are a good vehicle for this. Providing frequent, timely feedback to an engineer helps them improve.


Finally, we get to compensation. Most good engineers view compensation as being important to their decision to join or stay with a company, but it isn’t the strongest decider. My experience is that engineers need to feel that they are compensated fairly relative to their peers in the industry, but will give a company latitude if the other retention criteria are strong. I am an advocate of paying engineers generously, as the leverage that a skilled, satisfied engineer can create is immense. If budget is exerting pressure on compensation levels, then ensure that the salary for an engineer is at least within 10% of the average for your industry and company size. Your HR team can get access to data showing compensation levels by job type and location. I have used Radford for this in the past. Don’t try to get away with significantly underpaying your engineers. They will figure it out, and leave for other higher-paying companies.