Photo by Brands&People on Unsplash
What do developers want?
Big bonuses? The latest iPhone? A new watch? Whilst few people would say no to free swag, we think it takes a lot more than ‘stuff’ to create an engaging working environment for developers in 2022.
Why keep engineers engaged?
1: Retention
The current market for developer talent is fierce, and only expected to grow with the global talent shortage expected to hit 85.2 million by 2030. Further to this, according to Stack Overflow a massive 74% of developers are currently open to new job offers. If your developers are not engaged and enjoying their work, they could be leaving the nest for pastures new in no time, all at a cost to your organization.
2: Performance
According to Forbes, engaged teams are 21% more profitable and 17% more productive. Any tech team that wants to be high-performing should have an engagement plan in place to ensure developers are in an environment that allows them to do their best work.
It’s clear that retaining and getting the best out of your team’s developers has never been more important.
But what metrics matter when looking to incentivise developers in 2022?
Photo by Japheth Mast on Unsplash
What metrics drive developer engagement?
Using objective frameworks such as Google’s DORA framework can be a significant driver in incentivising developers to improve performance.
At Adadot we believe the ultimate set of developer metrics can be split into three key sections; work, wellbeing, and collaboration.
1: Work
Making it easy to know what ‘good’ looks like is massively motivating. Without this, we run the risk of leaving our development teams to work in silos in a conveyor belt style, shipping code but not knowing why, or how effectively they are doing so.
We recently wrote a blog about how Zoopla use the DORA framework to bake rigorous scientific theory about developer performance into their working environment.
Making these metrics transparent is also vital, and something that Gitlab does really well. They publish all their team performance stats on their website so anyone can see them. This takes the power of metrics away from hidden rooms full of management and puts it in the hands of those on the front line of development. Not only does this make performance and benchmarks universally clear, but it also allows people to understand the wider purpose of those metrics, showing what they ladder up to and why.
So metrics can be useful, sometimes. However, every action has a counterreaction, and the same applies here. We’ve all experienced a pushy salesperson, who has been incentivized through a bonus scheme where they get money for each sale made. This will typically see sales go up, but customer satisfaction goes down due to the focus on sales rather than service. Are our metrics sending the right signals to our developers? Or are we driving short-term productivity at the expense of their wellbeing and, ultimately, their long-term productivity?
2: Wellbeing
Stack Overflow did some research into developer engagement, and whilst competitive remuneration remains the number one concern for developers at 70% of respondents, work/life balance is not far behind at 48.3% of respondents. The need for greater focus on wellbeing is clear, and that shouldn’t stop at your HR department, it should extend to the way you measure performance too.
The DORA framework doesn’t stop at work alone, with burnout and work environment being key components.
Adding these dimensions to the metrics you use to encourage developer performance ensures you’re recognising the right working behaviors; shifting the means of enhancing performance from increased hours to increased efficiency.
3: Collaboration
Strong collaborative practices are also key to developer team success, and therefore developer engagement.
However, again using DORA as our Bible, we acknowledge that metrics aren’t everything here. Ensuring you cover the softer side of collaboration through effective retrospective sessions that capture continuous improvement ideas from developers is important, ensuring their voices are heard and the team ‘inspects and adapts’ accordingly. This further lends itself to ensuring your developers are empowered to be self-organizing and given the autonomy they need to excel, moving away from any hint of command and control management to more Agile servant leadership approaches.
The rest is down to you, we give you the data and levers to pull, you just need to choose which ones to pull.
This article was first published here.