Money and Greed
Software developers are greedy and money hungry.
To hire the best developers on the market you need to keep putting their rates up, buy them all the trendy tech, and do little ‘brown bag’ days where you promise them new technology so they can make sure their CV is always growing at the same pace as their salary expectations.
Or so we are told.
This is the myth I commonly hear and it really irks me because I was a software developer (before I gave myself the poncy title of Logic Room founder), I like money, I can be greedy and I always wanted to make sure my tech stack was relevant.
But we have a big problem with this assumption; the problem is that primarily software developers are human. And humans are not driven by money, they are driven by neurochemistry.
Neurochemistry is the single most important thing to consider if you do want to hire and retain the best talent on the market without needing to resort to money, shiny stuff and silly meetings that sound great to management.
When a person comes to work they are tired. Most of us have stuff going on and life to deal with. We have rent to pay, mortgages to serve and 18 month old offspring?…
When we enter work we ‘must’ switch off life because we are now entering our place of professionalism. And professionals must be able to divert their attention accordingly.
When a software developer gets into work the best way to get their attention is to find a way to stimulate their dopamine!
Dopamine is the chemical our brains release upon what I like to know as the ‘seek, find and implement’ behaviour.
As advanced apes us humans love to ‘seek, find and implement’.
Everything we do is an act of seeking information, finding an answer and implementing it.
This cycle needs to be delicately managed so it’s not too hard, it’s not to difficult and it progressively get’s more difficult.
This keeps our brains steadily releasing dopamine. The dopamine triggers us to feel good. And the feeling good makes us want another hit of dopamine.
It’s a virtuous cycle…
It is a delicate balancing act!
Many developers I have met say that money is really important to them. And research I have done suggests that for the majority that this ‘is’ the most important.
However I have also seen a problem with this. Many companies fail to create environments which are harmonious to productive development. The code bases are a mess, there is little adoption of good practices and generally the business creates pressure in the wrong places which results in teams that look good on paper but when you dig into it simply aren’t performing to their max capacity – how do I know? Just look at the comments I get on my posts on LinkedIn. Developers are not happy!
In my opinion software developers are ultimately shoehorned quite regularly into having to choose money as the most important facet when choosing a role. But I think if you give them the usual chaos that seems to be the norm in companies then of course they don’t have much choice.
Almost every client who comes into the Logic Room offices these days to spec up a new app is using this term ‘Gamification’.
What this means is that we set up new apps to slowly uncover more information or settings so that the user is naturally drawn into using it more often.
The premise is that a user that is gamified will come back more often. And users that come back more often make the app owners (our clients) more money.
I have no problem with gamification.
But if gamification is good enough to make customers more interested in the app, then why aren’t we using it to get the developers to be more interested in making the app too?
Why aren’t we setting up our software teams and projects to keep dopamine and gamification as the number one concern instead of money and cool stuff?
When we developed our Team Transformation Framework Amplitude one of the primary things we wanted to do was establish what would be missing from software teams that wanted to retain developers for longer.
One of the parts of Amplitude identifies a capability we have identified important to a software team known as ‘Execution and Technical Practices’.
This describes how a team operates together and what practices the individuals use on a daily basis in order to ‘work’. We look at what a typical day might be like for a team, how they work from hour to hour but specifically what structures are in place to make sure that work is done throughout the team in a consistent manner.
We rate a team anywhere from 1-5 dependant on how much we think the team is operating in a way that has clarity for standardised ways of working, including things like architecture, test automation, tools and the sorts of disciplines that are in place (like peer reviews and self code reviews).
In my opinion this is perhaps the most important part. Because it can bring to light the most important thing I think teams should be doing if they want to ‘gamify’ things for the developers; and that is to ‘standardise’.
Standardisation of Work
If we were to think back to our ‘seek and find’ idea from earlier. We know that developers want a way of working that slowly allows them to tackle harder and harder challenges.
If businesses were to focus on the technical practices of a team and make sure that a developers day is spent on high value work then they should create an environment where this is can happen.
The problem with the majority of software teams is that this simply ‘doesn’t’ happen.
We throw together teams of people with different skill levels, competing interests, wildly different attitudes to things like quality; and then expect them to deliver.
If we have differences in the standards that we have in place on a personal level (regardless of what the team says they do or put on their job adverts) then we will simply have developers who cannot reach a state of flow; together, as a team.
They can’t reach it because they are all operating at different gears. One developer may be writing test automation for all their code, only to have it trampled on by another developer who doesn’t understand how to do it. Another developer may be self checking all of their work before committing it to the source control server; only to have their work impacted by another that doesn’t.
All of these little differences start to piss developers off – even if they aren’t saying it. No matter how much you pay them. How big a screen you give them or what new tech you give them you are offending their ability to work unencumbered by the differentiation of basic principles and practices of their peers. This affects their deeper ability to be able to enter a state of flow and have their dopamine hit!
Not optimising a team for the dopamine hit will always leave companies and developer with no other solution but to fall back to the superficial things like money and toys.
This article is not an excuse to pay less or not to offer shiny toys. It’s about finding better technical practices which will make your software team happier.
It is an argument that before looking at money and tech look at what really makes technical people tick. Consider the ramifications of simplifying their workflow by standardising the work they need to do – and the way they execute.
The priority should be around creating a environments that are conducive to performance on a cognitive level first.
If companies focus first on the fundamentals and create teams of professionals who can regularly enter a state of flow and execute as a team then they will be tapping into a stronger output. If they optimise things like automation, software architecture, developer principles such as clean code and test driven development this will create stronger performance.
Ultimately starting at the bottom and not the top with teams will help them to retain better staff, have higher productivity and keep developers happy so they aren’t constantly forced to choose money over happiness in their search for their perfect team!
I am the founder of Logic Room.