How to Motivate Your Engineers so They Don’t Leave you
A product team’s greatest fear is losing its high performing engineers with institutional knowledge. How to retain your engineers so they don’t get poached even when being offered a bigger salary?
Daniel Pink’s book “Drive” defines the four T’s of autonomy as:
The freedom to pick the task, the technique, the time, and the team.
This article focuses on providing autonomy to choose the first three: task, technique, and time.
Excitement to build things the way they want
New technologies are like shiny new toys to engineers. The ultimate dream of most engineers is to start something new and build a product from scratch. They get to design the architecture as well as choose their favourite languages and frameworks.
On the contrary, their worst nightmare is untangling the legacy code that only the original programmers understand. The legacy system is a piece of baggage that constraints their creativity.
Flexibility to work anywhere and anytime — including the office (when they want to)
Engineers enjoy deep work with little interruptions. This explains why most of them feel most productive at night when it is quiet. They don’t want to attend meetings and work in the office with lots of people around. However, they sometimes crave social interactions in the office.
Autonomy is a scale
The truth is there is no complete autonomy unless it is your own business or side projects. Furthermore, the level of autonomy each engineer needs also varies.
Generally, juniors don’t mind being told which tasks to take on. They thrive on receiving mentorship and working with more experienced engineers.
Choose the right level of autonomy, ranked from low to high below. It boils down to “what task to do” and “how to do it”.
- Told exactly what tasks to work on and how to do them→ Low autonomy
The how is defined by a “tech lead”. They just need to do exactly what they are told.
- Choose what tasks to work on from a list and how to do them → Medium autonomy
A common approach for scrum teams that allow engineers to choose from a backlog — so the business knows what deliverables are.
- Told what the tasks are and choose from a predefined list of technologies → Medium autonomy
Companies may want to stick with the stack they are using. This saves time from ramping up other engineers.
- Told what the vision is and has complete control on the how → High autonomy
Implement a brand new application and service, typically involve architectural design with a large scope.
What to watch out for when giving autonomy?
There is a lot of uncertainty when you introduce a new variable and technology. How do you ensure that it doesn’t put the launch timeline at risk?
When you are new to a company or team, don’t get discouraged if you don’t have complete free rein right away. Avoid these red flags, then you will earn your autonomy and trust over time.
- Doesn’t mean not involving the team. You need to inform teams that can be impacted by your decision. Do they need to change their features to support your new code — so it doesn’t introduce bugs?
- Ramp up other engineers on the new change. After playing with the new toy, You can’t just wipe your hands off and drop that on others’ plates. Create a FAQ document so you are not the only person who knows how to fix the problems. I’ve seen engineers getting impatient when others “don’t get their design”. In the future, I’m hesitant to give them a high level of autonomy.
- Seniority doesn’t mean more autonomy. Even if they have more experience coding or had “used this stack” with the greatest success, there is no guarantee that their decision will be right. There are a lot of unknowns when using a shiny, new technology with other older parts. You need to consider the system holistically. That’s why the previous point “involving the team” is important. Watch out when engineers are afraid to speak against the engineers with the loudest voice
- Don’t forget accountability. You own the mistakes and success when pushing to use your preferred technology. To avoid overinvesting in the new direction, set up ground rules to know when we need to revisit whether the long term benefits outweigh the cost. So that the rest of the team doesn’t need to work overtime to save the sinking ship. Very often, this leads to more accountability and they work harder to prove that they made the right choice.
What to do if you can’t offer the freedom to pick the technique, time, and tasks?
Even if your current company
- Can’t afford the uncertainty of re-writing or adopting a new technology
- Not ready to change your company policy to offer flex-hours and remote work
Use the two other motivators highlighted by Daniel Pink:
- Mastery — the urge to get better and better at something that matters
- Purpose — the yearning to do what we do in the service of something larger than ourselves
I personally think Mastery and Purpose are more important than autonomy.
Why autonomy alone cannot keep your engineers?
Lack of purpose: This tends to happen for companies that are still looking for product-market fit. You can work on the coolest technologies — but if nobody uses the product, it is hard to keep going.
What is even more demotivating is the features they built never ship. Halfway through building the product, the company decides to switch direction to pursue another market or problem.
Lack of mastery: You can be working anywhere and anytime — but if it is the same tasks you do everyday. Engineers are problem solvers. We need to keep them intellectually challenged and feel that they are learning.
That’s why it is important to have succession planning where a senior engineer can train an intermediate engineer to pass on knowledge and leave them to work on other tasks. The monotonous tasks previously completed by the senior are new and challenging to the intermediate engineer.
Sum it Up
Responsible and technically competent engineers are hard to find. Losing a critical team player not only incurs financial cost and also impacts team morale. Motivate them to stay with you and accomplish more than what they think they are capable of.
Want to work more effectively with engineers?
Check out these related articles:
Download my book How to work with Engineers
