Retaining Software Engineers

After observing the early symptoms of unhappy software engineers it is time to work out what we can do about it.

Many people have spent time writing on this subject. There is no lack of ideas, but there is often an apathy over trying something different out. The ultimate aim of delivering a product and making money usually overwhelms an organisation and the needs of individuals and teams get sidelined as less important. Ultimately there is a need for being in a secure environment, a place where people feel valued, listened to, protected and safe. The reason for not moving on to another offer is usually based around this human need.

There are some interesting observations I have made around this need. The example that sticks out to me is when being in a scrum team and having retrospectives the team would often choose to talk about how they were feeling. In one team they complained about the state of the office toilets every retrospective. It became a running joke and was banned as a subject by the scrum master. However there was something missed about that situation. The needs of the team were not based on engineering principles, but a human need for good hygiene and feeling comfortable in the place they worked. Rather than being able to acknowledge that the scrum master saw it as irrelevant to the ways of working and tried to bring round the topics of delivering a project.

A holistic approach to the way we work gives a better balance of overall well being. The technologies that we use and the way an engineer feels about the technology are both important. We work with people and not robots. We build software for people, from people and with people. We cannot escape that being a software engineer is intrinsically about people, those are the users, other business people and peers.

Rewarding Engineers#

If money grew on trees it would help, but it would not always fix the need to feel rewarded. Different people feel more rewarded in different ways. Some people feel rewarded knowing that they did a good job on something from within themselves, others need to be told they have done something good to feel rewarded and others need an action for the feeling of reward to happen.

Pay#

There is a need to budget for pay increases with market rates. Done actively it reduces the carrot of other opportunities elsewhere. When pay is not rewarded then people will move jobs and get much larger pay increases, sometimes more than double what they were earning. When we hire new engineers we often get surprised at the market rates on offer.

Time#

A new feature has just been released, the team have been working on it for a few weeks in total and it is looking good. Back in the office we might have had a treat brought in or gone for a drink. We would have taken a break of some sort. Remote working is difficult to give the same sense of reward. An effective reward is the ability to tell the team to down tools early today. Giving people the opportunity to have an early finish (maybe an hour) is something that works remotely. When we finish off a feature it can be a natural point to give this reward. For it to work the team needs the reassurance that they can down tools and they don’t need to make up the time in the week.

Treats#

This was much easier in the office, a selection of cakes and sweets would often appear. Other options might be going for coffee, breakfast or lunch together. Remotely this is more difficult but it is possible to get grazing boxes sent out to people’s homes.

Celebrations#

Social gatherings are a good way to reward a team, however there needs to be consideration to all team members. Some people don’t drink alcohol and others dislike specific activities. It can become difficult to find things that fit a larger team but it is important to have the time doing other activities together.

Product Engagement#

Planning#

There is something interesting about the planning ritual in scrum. It is that the ownership shifted from product to the development team. This becomes a protected set of things that the dev team owns for the sprint. Planning here is the ritual of product explaining what they want from a story, the development team understanding the intent and committing to completing the agreed amount within a set time. It is for the development team to state how much they think they can get done and this is agreed upfront.

We don’t all need to do scrum, but when we don’t have this type of conversation the lines can be blurred. Sometimes it can feel like a push system rather than a pull and the communication around the work happening is not owned by the self-organising team but by individuals. This can have some side effects like individuals being painted into corners or only given a specific type of work.

The need to own things as a team and for the individuals to achieve healthy boundaries on what they can commit to comes out of having the planning conversation as a team.

Contributing ideas#

An interesting exercise is to map out the process of having an idea then all the steps before it goes live in production. I did this with a scrum team who were focusing on the dev part of the process. They were focused on the velocity of the engineering team and I sat down with the wider team and we mapped out on a wall the journey of an idea to production. It turned out there was at least an 8 week lead time to get an idea in front of the engineering team with some work taking 6 months to prepare. It showed the organisation that they needed to focus on the bit before it hit the engineering team to be more agile and get the cycle down. The team managed to hit a 4 week cycle for ideas to get to production. That had a huge impact on things like engineering teams being able to get their ideas implemented as it was not that they were ignored but at the bottom of the 6 month prep cycle rather than being able to be worked on sooner.

Knowing how an idea needs to be analysed and shaped, its value understood and its expected impact to be known is important. Having a clear understanding of this process helps the expectation of how a team member’s idea can be turned into value for the business.

Understanding the macro and the micro#

One thing we can do is to help is to have clear priorities set out on the macro level. Honesty is key here, saying “we don’t know” is better than making up something to keep a fuzzy idea. The big picture can often be ambiguous when there is an idea, this is when the smaller achievements are better understood. “What is the one thing that can be done today to improve the product?”

Bridging the macro and micro is important to have a clear sense of direction, this direction can change but gives a good foundation for the team. Being agile should encourage having the change in direction as it means we are able to move a product in a different direction quickly without the upset.

Engineering opportunities#

Opportunity to design and develop services/features

This is an obvious place to give the opportunity to develop a new idea or skill. However the trap of having the same goto person for the new things can easily happen. There is also a difficult decision in the amount of freedom given to a new feature or service technically. There are an unlimited number of ways we can solve a problem but we need healthy boundaries to give flexibility to think outside the box whilst staying on the correct path for the product. We should architect our systems in a way that allows for more innovation on the platform, giving the opportunity to test an architectural idea as well as understanding overheads for getting the work done.

One example was a team that decided to use Elixir for building a gateway service (rather than nodejs) and it was a well thought out decision as it could handle the high request rate needed. The team had not built anything with Elixir before but did a small slice to prove it. There is risk in doing these things but it gives a huge boost to the team. There was a greater sense of ownership and encouraged more innovation in the ideas and implementation.

At the core of this opportunity is to clearly define the boundaries and expectations for elapsed time. “We have a feature idea and we have 2 weeks to get it out” vs “We have a platform issue and we need to fix it in 6 weeks” are different problems that would have different boundaries.

Opportunity to focus on developing a depth of knowledge#

A full stack software engineer has huge expectations on the depth of knowledge and understanding required. They are expected to build UI components, Design data systems, Configure data center networks whilst considering all the non-functional requirements of a system. What we generally end up with are “T-shaped” engineers. These are people with some knowledge of everything but a greater depth of knowledge in one or more disciplines.

Engineers desiring to be “full-stack” want to increase the depth of understanding in areas they are less familiar in to become more “full-stack”. Some of these are the traditional roles of back-end, front-end, data, design etc. But there are also other areas that cut across like security and quality.

One way this has been done is using Champions and Guilds.

Champions are nominated within a team to have a focus on an area of the stack. This gives the opportunity to deepen the knowledge for the individual and give the opportunity to share that with others. Guilds are a place to discuss the subject, agree on approaches and give support. This can be done in regular gatherings or as a slack channel. E.g. #help-aws or #aws-guild