First of a few disclaimers : The title of this post probably does not make a lot of sense (if any). Any perceived person and/or organization in this blog post is not intended – it is based on my experience in several projects, for different companies, and different clients.

This is my first blog post ever!

Chronologically, considering the title of the post, I should write something about basket first. Actually, this post is not about basket at all, but just had to show this great picture of developers from Ukraine and Denmark after playing a bit of basket in the sun.

After this short detour lets get back on the track to what I actually want to write a bit about – what motivates a developer.

Ramble: It seems to be the perception from people looking at developers from the outside, be it managers, project managers, or people from the street that all developers care about is playing with new toys (languages, frameworks, new hardware, or gadgets).

While most developers love new toys (like women love new shoes), what motivates a developer is actually far more nuanced than just the urge to try new stuff. Albeit, some developers are motivated by money, most I have met (including myself) are motivated by an urge to craft software and learn. We want to craft stuff smarter, faster, with fewer bugs, and better features.

This is probably why developers in start-up companies seem to be more motivated – they have a clean slate and can craft and learn according to what is the smartest (perceived!) way of working at that point in time. After a few years what was smartest back in the beginning is probably not the smartest anymore, but more importantly the developers have learned a lot, and can now do even smarter (again perceived) stuff. But at this time the products and systems they work on have a lot of customers, thus the level of risk the business is willing to take decrease dramatically – meaning the developers get to craft and learn less. Thus, eventually the developers will become demotivated (seems to be close to a law of nature – at least from my personal experience).

There are a couple of challenges with demotivated developers.

• Retention becomes harder.
• Hiring becomes harder.

In the very best scenarios the developers are also very professional people (they do get paid) and will do their job adequately – but they will never do a GREAT job. For that they need to be motivated.

Avoiding this trap?

If it was easy less software products/ projects would fail. Nevertheless, I believe there is a path. Good developers have the urge to craft and learn just as strongly as all other developers, maybe even stronger. But, more importantly good developers also understand the business and the customers. Thus, a good developer would be able to determine quite well when to take which risks regarding which frameworks, languages, platforms, methodologies, etc. are used. A good developer also understands that not all risks should be taken at the same time: In general the good developer will be able to help guide the direction of the software.

Thus, to have motivated developers your need to empower the developer (does not mean no control – just more influence). This may sound risky, and indeed it is. If you empower a bad developer the results will not be nice – probably close to catastrophic. If you empower a good developer you are not guaranteed success, but you know that at the very least he will fight to succeed.

Soooo… empowerment is risky even with good developers (if you are choosing not to empower your developers because you believe they are bad I can only ask why the hell you are hiring bad developers (and keeping them)).

What’s the alternative? Demotivated developers…. I honestly do not believe you can successfully run a business based on software with demotivated developers working on it – it will fail, sooner or later – if you don’t change.

How much?

So how much should you empower your developers? This is not easy either – for some developers you can give almost free reins – while others need a quite firm hand controlling.

If I find the solution for this last bit, I will be sure to let you know :–)

/Ramble