Members of your engineering team at work share many common features. Hopefully, they all have a strong desire to solve problems, sort out options, and learn new skills. But they may also solve problems through different means and are driven by different, sometimes underlying, motives.
In this article, we’ll discuss what keeps engineers motivated in their work, how to maintain that level of engagement, and how to keep their interests alive.
The pandemic: Everything changes
Engineers (FE/BE, Desktop, Mobile, QA, etc.) along with everyone else have short- and long-term goals that sustain their level of interest in their current project. As an engineer, you’d be lucky to have everything go perfectly: the project’s cool, the stack is relevant, and the tasks are at a sweet spot of competence/difficulty/interesting ratio at the same time. Projects rarely come together in this way.
2020 became the year of the pandemic. That’s when we realized everything would have to be different. In the early spring, we started working remotely and engaging employees became a much bigger, much more immediate challenge. Once an employee shares their disinterest in a project or starts disengaging from their work, it’s crucial for managers at all levels to begin addressing the problem immediately. But what will truly convince higher-level managers that disengagement is a pressing issue?
There is a simple tool that will help turn your observations into data, so you can use this specific data to influence your higher management.
We will need four quadrants, formed by the X-axis measuring interest and the Y-axis measuring competence. At meetings with your engineers, try to arrange tasks within these quadrants accordingly. It’s a useful visual tool that can suggest directions for how an engineer can grow. If they are very interested in something, but lack competence, this is a sure sign you’d better discuss a career plan.
We faced a situation in which a team of engineers placed all the tasks in the “highly competent and not interested” quadrant. Even the most interesting projects will have their share of tedious tasks, so it’s of little to no importance here and now. However, if that’s the picture we’re going to observe for, say, six months straight, you need to do something about this.
Engagement: Why care about the interest of engineers?
An engineer’s lifetime in a company is 2.5 years on average. It is usually enough to understand what can and cannot be done in a company at the technical, product, and other levels. And if the current state of affairs doesn’t suit the engineer, they’ll go looking for another job in a new place where everything will start all over again.
It takes an incredible amount of effort, time, and money to hire a new engineer. At this stage, various HR structures are included in the work: sourcers, recruiters, travel coordinators, etc. I can’t say how much their work costs, but it is definitely not free. Someone from the team will participate in the interviews, which means that their time on the project is reduced. And then the new employee has to go through the process of onboarding and adaptation. In general, not having a replacement in advance means the team’s productivity is bound to start declining at least until a new engineer comes along.
How many months will pass until full replacement? Two months? Six? Therefore, if you or your manager think “No big deal, we’ll find another one!”, remember these numbers.
There is a study that looked at the average cost of hiring a new developer in U.S. companies. It estimated an average expenditure of about $30,000 before the new specialist is even signed. And this is without taking into account the decrease in the team’s productivity during this period.
Is creating interesting tasks really worth your effort?
Before throwing yourself into the heat of the battle, shouting “Interesting tasks for all engineers!”, make sure your company needs it, your team needs it, and you need it.
Does the company need it?
If the quality of work won’t dip after Engineer One leaves, Engineer Two’s skills will last you another six months, and staff turnover is an ordinary thing for the company, then it is unlikely that you will fix the state of affairs. It’s not in the best interest of the business. If the product is complex and requires a lot of expertise, which is expensive to lose, then it makes perfect sense to raise the question and discuss this problem.
Does the team need it?
Is the team suffering from this problem? Do team members have a request for new challenges in unknown areas? If not, we have to solve other issues that are also beyond the scope of this article. Otherwise, go to the last question.
Do you need it?
Once you fit into the changing state of affairs, it will not be easy to roll back.
For something to work out, the answer must be “Yes” in all three cases.
Talking to the team
Now, let’s go in the opposite direction. If you figure out your own interest, you now need to contact the team. A good manager should know their team, otherwise you can treat what isn’t damaged, or overlook an unobvious problem.
First, find out exactly how engineers want to grow and whether they want to at all. Maybe someone feels comfortable with current tasks and deals with them just perfectly. If this is the case, don’t fix it — it’s fine.
There may be other engineers on the team who probably miss hardcore algorithmic tasks, or are trying to polish and optimize existing features. There’s always someone who hates routine tasks and is ready to implement automation where possible. Someone who wants to share knowledge, participate in hackathons, and write articles. But it’s impossible to address the interests of your team if you’re not familiar with its members.
Initially, you do not have to offer them anything — just you knowing what can be offered is enough.
Talking to the business
Even if managers understand the value of an engineer’s expertise and realistically estimate the cost of replacement, they might not support their interests and aspirations. Managers are unlikely to agree to spend half of their working (and therefore paid) time on something like porting Doom to a pager from the early 2000s.
This is the stage where negotiations begin and the team manager acts as a truce envoy. The company probably has stakeholders: VP, CTO, heads of engineering departments, etc. You will have to discuss the vision of the life of an engineer in a company with at least one of them. In my experience, such negotiations can take many weeks, because gathering the right people at the same time and in the same place (even on Zoom) can be very difficult.
At the meetings, most likely, many discussions will be sparked on the other end, such as:
- Why even try to keep people in the company?
- How do they work on features?
- What do you mean they will, but not as much?
Arguments you can use to defend your position:
- The departure of an engineer will affect the performance of the team in the current tasks. If such a risk really exists, this should be your go-to, most significant argument.
- The departure of an engineer will affect the entire team. There are risks that other engineers will also lose productivity and/or start looking for another job.
- Finding a new person is cost-intensive.
- Signing a newcomer is not the end of the temporary turmoil. You will need to onboard an engineer and let them build new connections, which brings extra expenses.
With these four positions, you can have a more meaningful conversation.
If all the arguments are not heard or refuted, then the further decision is yours. Say the answer to “Does the company need this?” is a “No.” In this case, I can’t offer something worthwhile due to too many possible nuances. At the end of the day, the employee may be willing to work in the company regardless, or you might give it a go and try to change something bypassing the top management.
What I want to share though is what we eventually came up with. It’s five consecutive steps that can be applied in order. If the first point did not work, go to the second, and so on.
Five steps to keep an engineer’s interest alive
1. Select and create ambitious tasks from the team scope
If you need to make a single-page wizard for creating reports and the development does not require an FE engineer to be a genius, discuss the future of this functionality with the product manager. What if there is a chance that the wizard will grow and develop in the future? Then you can, for example, have an FE try to lay down a good architecture with the ability to quickly expand and update. This will take longer but will allow the engineer to work out a different development approach.
2. Nurture T-shape engineers: FE-BE, BE-QAA, BE-FE
It’s possible that some of the FE engineers would like to write BE or try themselves in autotests. Not an issue. Simple tasks and reviews from experienced colleagues can dilute the routine. In addition, this approach can help if the workload of engineers from other specializations does not allow them to take on some of the tasks at hand. Then our T-shape engineer will be able to take over the entire development cycle. Of course, you need to keep the balance between the complexity and priority of the task.
For example, we had a case where it was necessary to provide a prototype of new functionality. The prototype required front-end and back-end development, but there were no resources for back-end engineers. As a result, the front-end developer did both parts of the task, and more experienced engineers just reviewed the back-end bit.
3. Allocate time for tasks personally significant for the engineer
This category includes a sizable variety of tasks that somehow lay out the current product development stream. This may be a refactoring of some feature that keeps the engineer restless. Why not give them time to deal with it? It could be the development of some kind of app for holding meetups in a company or just an article for publication.
For example, we once encountered strange behavior in a testing library that was supposed to simulate asynchronous requests. As a result, the idea was born to write a couple of articles about asynchrony in Dart Angular.
4. Organize short-term staff rotation
If none of the previous options are suitable, you can arrange a local “business trip” to another team, during which the engineer will work on another scope, communicate with other people, and work with other processes.
5. Allow engineers to work on other teams’ public scope issues
How is this step different from the previous one? In this case, the engineer is still on their own team but is able to complete the tasks of other teams. This is one of the most difficult options because you need to find a public backlog, make an agreement with another team, find out what the Definition of Done for the task is, and who is responsible for testing.
Decisions on items two to five are taken individually with each member of the team. If there are, for example, six engineers in a team, then it is quite realistic to meet for an hour total and discuss which way the person wants to go and how you can try to combine their personal goals, the goals of the team, and of the company.
If an employee has chosen something from points two to five, then it is worth coordinating the time and goals with stakeholders and product managers. This is necessary so that all participants in the process understand what the engineer is doing now and why that individual is “not fixing that one minor bug.”
For example, you can negotiate five working days per quarter to work on such tasks. In our world, this is half a sprint. It is important that such tasks fall into the sprint along with product tasks and technical ones, and the engineer reports progress on a daily basis.
The task must be achievable. If the goal is to rewrite part of the product to a new technology stack, then it’s probably worth choosing another task within this personal limit.
And, of course, after a while, you will be asked: “Well, how is your retention and engagement effort? Any effect?” It’s worth agreeing from the get-go on how you will monitor the impact of this change. It is important for stakeholders to know everything is not in vain.
The easiest way is to ask the team how much they are interested in working for the company/team/project. You can note the things that were created as part of these changes: articles, performance improvements, refactoring, third-party products that are important to the company, etc. And, of course, reputation. It’s not as tangible as numbers and features, but if your team is talked about in a company, engineers will want to stay and other teams want to be like yours.
A word about SPACE
Interestingly, during the pandemic, companies began to actively seek opportunities to understand and evaluate the performance of engineers. In 2021, a lot of links led to the new-maple framework by such estimates. It’s called SPACE: satisfaction, performance, activity, communication, efficiency.
Its applicability and effectiveness is a whole other topic, but I would like to note that the first point is satisfaction. SPACE describes it very broadly: it includes what the engineer does, tools, the workplace, and everything else related to it.
The part that I’m looking for — the interest of a person in their work — just falls into the letter S. And considering that this topic was written about in many resources and even talked about in large companies such as Microsoft, I want to believe every engineer will get to experience this.
All this was related to product companies, where projects can last years. But what about non-product development? I don’t have much experience in such companies, but most often, there is a natural rotation of engineers among domain areas and technologies. And if a company has the luxury of keeping engineers benched waiting for new goals, there is a great chance for them to take some kind of educational course and get acquainted with new technologies or processes.
Final thoughts
The commitment of engineers may or may not be a resource your company can exploit. It depends on many factors. In any case, if you see it as a resource, be ready to replenish it. Negotiate with the business, argue, show numbers and metrics, and develop a plan that suits your team.
To demonstrate to stakeholders it’s all worth it, run a survey about how interested and engaged your engineers are before and after the implementation of the plan (every month) and show off the cool things the team has done during this time.
Some of what I formulated here was inspired by “An Elegant Puzzle,” the book by the experienced manager Will Larson. It’s an interesting book for those who have become a manager in development and plan to grow further in this role.
This article was written by a Wriker, in Wrike. See what it’s like to work with us and what career development opportunities we offer here.
Also, hear from our founder, Andrew Filev, about Wrike’s culture and values, the ways we work and appreciate Wrikers, and more here.
