How to keep software engineers motivated
Having a difficult time keeping your engineers motivated at work? Find out what really fuels their passion.
In our previous article, Five signs your employee will resign soon, I talked about signs that an employee resignation is impending. While these attributes are common among most employees, their motivations to leave or stay can vary from one business function to another, and that includes Engineering.
It's important to note that at the point of writing, I do not have a specific persona archetype in mind - geeky male in black hoodies or not. The following is my broad observation having worked with hundreds of engineers to date. One thing is clear about these engineers. They are simply not motivated by 'growth', or at least not in the same way as how the business defines. Instead, they are often driven by 3 main factors, in no particular order.
Software engineers know they are highly sought-after by virtually every employer, hence, their loyalty is often placed on the highest bidder - and this can feed into their egos. Don't take this the wrong way. There is absolutely nothing wrong to be driven by monetary interests and indulge in occasional self-pride especially in the corporate world. In fact, if you are an employer, you can leverage this information to create a better working environment that attracts software engineers and one that makes them happy to continue working with you.
Typically, when software engineers start to look for a job, they are often motivated by lucrative salary packages. Engineers know very well through experience that they may not even end up doing the very thing they were hired for as per the job description. They can be a senior software engineer on one day and a mid-level engineer on another depending on whichever gets the job done. Given the nature of their role, software engineers are not as bothered by job titles as they are with their salaries.
Cautious about how this might turn into a sticky situation, it is only fair that both parties understand their respective responsibilities to each other to ensure fair compensation. Employers should aim to build an unbiased hiring and retention system such as one that can respond well to business needs and prioritise skills vis-à-vis the value they bring to the table in helping the company achieve its goals. The system should also be built on meritrocacy.
Upon being hired, engineers would start exploring the technology stack that is in store. From this point forward, they will strive to perform their best on the job.
Things get awry if the business continues to make unreasonable and often frivolous demands such as changing the colour of buttons or re-aligning design components, while making them sound like mission critical tasks moments before deployment. Firstly, time is spent on operations at the expense of innovation, and engineers often get frustrated from having to repeat menial tasks that could have been better planned for. It also shows a lack of understanding and appreciation for the job that engineers value the most, that is ensuring a robust system to support and scale the business. The best way to prevent this scenario from happening is to nail all requirements down correctly as a team before development work commences.
Software engineers know they may have to work with legacy Java frameworks which the business decided to implement a decade ago, and that will not change anytime soon. They also know that it's unlikely that they will be properly assigned over the next one to two years. In a hopeful attempt to make their lives exciting, they will have new ideas which often involve trying out new technologies and approaches to software development. It's unwise to kill these ideas even before they make it to the roundtable.
It's true that not all ideas are worth pursuing but the best employers provide the avenue for engineers to discuss their ideas. It is difficult for software engineers to accept rote tasks knowing there are new technologies in the market which other engineers are racing towards, and no one likes to be left out. Simply put, engineers enjoy the thrill of sharpening their sword with the latest smithing tools and techniques.
A good approach to encourage technologically innovative ideas is to run proof-of-concepts (POC) that will not hurt the production environment or business as usual (BAU). POC projects should be evaluated and managed like any other projects. Time-box ideas with clear success metrics and assign timelines to them. Software engineers love working with project managers who are flexible enough to allow them time to work on cool side projects, and even more so if project managers take a genuine interest in understanding their work and find ways to monetise their ideas. Knowing that their work can benefit others - within or outside the organisation - is a strong motivating factor for engineers to continue doing their best work.
Software engineers always like a good challenge. The same can be said about all other employees who are driven by self-improvement. If, for some reason, the organisation is unable to create a conducive environment for engineers to innovate, then it all boils down to the nature of the project that the engineers are working on.
Even on this note, the business and engineering team can sometimes disagree on what constitutes a good project. What the business deems as good, presumably based on favourable revenue forecasts, may not be as well-perceived by engineers who tend to favour technical sophistication and learning opportunities.
Imagine taking a chemist out of her research laboratory to teach elementary Chemistry at a primary school. No doubt it is a fullfiling job but it is also one that would hold her back from reaching the depths of her knowledge. The same can be said about an engineer who took a 3-year data science course, only to land a job that requires her to perform basic SQL queries due to the nature of the project. Then, there are also senior software engineers with over 12 years of working experience who find themselves working on HTML and CSS because of resource constraints.
All the scenarios above are likened to using a sledgehammer to crack a nut. The results? Employers end up paying top dollar for an entry-level job, and now we have a bunch of frustrated engineers who would rather spend their time solving a worthy puzzle elsewhere. Having more complex problems to solve means having more opportunities to grow.
Going back to the concept of 'growth', unlike most of their business counterparts, most engineers have little to no desire in climbing the corporate ladder. Instead, they define career growth as having the opportunity to work with challenging technologies and approaches as these skills are highly valued and transferable in the market. Hence, it is in their best interest to stay on top of their knowledge game.
Surely this can be relative as tech maturity level varies across different organisations, industries, and geograhies. For a traditional business with no digital presence, setting up an e-commerce platform can seem like a huge leap in innovation, but for a company like Facebook (or Meta) who are already working on building a virtual reality universe, placing a senior software engineer on an e-commerce project is not the best way to utilise his skills or talent.
Engineers can seem demanding or even entitled to those who fail to understand their pain points and the nature of their work. After all, we are only driven by our innate humanly desires.
On the other hand, employers who can relate to their motivations and struggles do their best to provide a conducive environment for their engineers to thrive. Unlike their colleagues from Finance or Legal where certainty is key to the job, engineers prefer to dive into challenges that come with uncertainty when they can afford to, because it's the only way they can grow. Hence, they respect employers who understand these nuances and encourage their innovation mindset.
Good employers also appreciate the science that led to the technological advancements we see today, and are not afraid to commit and invest on a strategic business use case. In my own experience, they actively engage their engineers on potential use cases that can be derived from their work, thus putting engineers in the front seat of their decision-making process alongside the business, as opposed to an afterthought.