In this article, part of my series explaining better ROI from software development, I expand what makes a great developer.
Being great at software development is, at its core, no different than any other profession; they need:
We’ll start with skills and then move on to motivation.
To do their daily job, a Software Development exercises various skills and knowledge;
As previously commented in my articles, problem solving is at the core of a software developer’s toolkit.
Even the most seemly trivial task may have no obvious solution - or multiple viable solutions. The software developer has to use their problem solving skills to find the best solution (or in some case, the least worse).
In many instances there is no definitive correct answer. Rather options that are closer to best practice than others.
An ability to problem solve will be effected by the software developers knowledge of system, tools, technologies and domain. It will also be affected by the ability to research solutions and communicate with others – either to highlights pros & cons or collaborate.
Like any skill, any given individual will have some capability ranging from basic to expert. The lower the problem solving skill, the more likely a negative impact on ROI:
Side note: In future articles I will look at the principal of “fail quickly”. This tells us that it is fine to fail – it allows us to learn and thus be better – just do it quickly to limit exposure.
Again as highlighted in previous article, software development is complex – it is huge and it is constantly changing. Without the ability (and willingness) to learn, a software developer will struggle to keep up.
Within the industry, there is the concept of the “developer half-life”. An acknowledgement that of the technology skills we use today, within a number of years half of it will no longer be relevant.
I’ve read various estimates on the numbers of years – ranging from 2 to 7 years generally. Personally I think that half-life is dependent on the technology in use – but 4 years is probably a good middle ground.
Again to give you some idea of how quickly things change; Microsoft’s primary website framework (ASP.Net MVC) has gone through 5 major revision since 2009 – with a 6th being due anytime now. Each of these revisions changes how the framework behaves.
Yes there are some core principles that survive through each revision – useful knowledge to take forwards - but each has benefits which, if not learnt, will generally mean missed opportunities for improving revenue/ reducing costs.
It is not uncommon to find an improvement that may “cost” half a day to learn, but save days of effort later on.
Personally I believe that it is a software developer’s responsibility to remain current. We are a long way removed from the days when you, as the business manager, are responsible for an employee’s career. It is career suicide for a software developer (or any professional) to expect their future income to be looked after by someone else.
That being said, I do however believe that an employer should help as much as possible. As the software developer learns new skills, it is your organisation that benefits.
There are a lot of easy ways to help them. It is key however to provide support or coach them into it. Forcing Personal Development Plans or other HR improvement programmes generally elicit the entirely wrong response. Too many developers have been through situations where “improvement programmes” have been sold as “for them” – but only to find that its used in salary reviews as a means to justify low rewards.
We’ll talk about motivation below; but basically you need to create the right environment and allow them to choose the right path.
I’ve heard it equated to looking after tropical fish – make sure the water is good & the fish will thrive. You can’t force the fish to thrive.
Small note of warning; as your software developer progresses and gets better and better at their job – don’t forget to reward them. This isn’t necessarily salary increases (although sometimes it will be). If you aren’t recognising the individual’s improvement, I’ll guarantee you that someone out there will do.
Simple enough – we need to be able to clearly express ideas, problems, options and solutions between everyone involved – be they business or technical.
Getting the “wrong end of the stick” is such an easy way to introduce huge wasted expenditure.
Obviously it helps for a developer to have good communication skills – but it also helps that the entire team (including business) are using effective communication.
In years past, we believed that producing huge documentation with multiple sign off was the best approach to clear communication.
Largely speak we were wrong. You only need to look at how the legal profession is built on interpretation of written rules.
Much more effective is direct focused communication. It allows us to communicate at the point of need and with great feedback mechanism – I’ll discuss this further in an article on Agile Software Development.
Another great help to communication is the concept of a Ubiquitous Language. This was a concept introduced by a software design process call Domain-Driven-Design (or DDD). While the process isn’t important for this article (may explore it more in a future article), the idea of the Ubiquitous Language is one I’d like to spend a couple paragraphs on.
Ubiquitous Language is intended to solve the problem due to clashes of terminology in communication between the business and software developers. Software developers have a tendency to talk in technical terms – the business in business terms. And with any two groups, different languages can lead to misunderstanding and confusion.
The idea of the Ubiquitous Language is that the team (business and technology) arrive at a shared lexicon. That way everyone in the team understands what those terms mean without ambiguity.
This is often the focus of recruitment – probably too much.
A developer needs to have knowledge of the technology and tools that they are using. This allows them to use the tools to solve the problems.
I personally however value problem solving skills and learning ability higher than any knowledge of a particular set of technology or tools.
With good problem solving skills and learning ability; a software developer will generally be able to close any lack of technology/ tools knowledge quickly.
Don’t get me wrong – a good understanding of the technology and tools makes the developer more efficient – and thus likely to provide a better ROI.
For a long term recruitment however that technology/ tools knowledge suffers from the developer half-life described above.
Again this is knowledge that can be learnt. It is however exceptionally valuable to an organisation once a developer has acquired it – often something overlooked.
First a step back; what is the domain;
The domain is short hand for what the organisation is trying to achieve and how it achieves it – simply put, knowledge of the business.
This can include:
And there is value in that knowledge. The more the software developer knows, the more effective they are.
This is most notably felt when you’re replacing a good developer with many years of domain knowledge. You will never find another developer with the same level of domain knowledge as someone that has lived it for years.
It can of course all be learnt (have I mentioned learning before) – but this can take time.
Taking a developer into a completely fresh industry for example will require the developer to learn and understand the industry specific terminology and activities to be effective in solving problems within them.
That isn’t to say that there isn’t value in bringing in fresh-blood. This in itself can be a truly revealing exercise for any organisation when perceived wisdom is questioned.
There are ways to shorten the domain learning – one technique mentioned earlier, Domain Driven Design, helps greatly. The technique effectively produces a glossary of terminologies – which is hugely useful for someone trying to learn the ropes.
With contractors, you will find they have their own tricks to close this gap quickly. For me it’s simple, ask questions. I’ve no problem asking the team to explain a new concept or term. It helps me to learn quickly AND confirms the team all have the same understanding.
It is surprising how terms that a team would have previously believed set in concrete become a lot less tangible when asked to describe it.
I do see this domain knowledge as being overlooked by most organisations – I’ve often been asked to compare current employees against “market rate”. Market rate will generally only measure their current skills with technology and tools. For an organisation trying to value their developers, they need to look at their worth to the business and the overall development team. Unfortunately this isn’t, as with most things, where the easy answer is the best one.
Ok, so once you have a developer with all the skills – how do you motivate them to use them?
In my last article, I talked a bit about how software developers are knowledge workers. And to get the best from knowledge workers you need to consider how you manage them. We need to look at something other than the standard “command and control” that most of us are used to.
In the book Drive by Daniel H. Pink, Daniel describes three drives:
Drive 1 – Biological motivators
Drive 2 – External motivators
Drive 3 – Intrinsic motivators
Command and control uses that second drive, the External motivators. Most of will recognise this as carrot and stick management.
Daniel’s book goes on to say:
“For routing tasks, which aren't very interesting and don’t demand much creative thinking, rewards can provide a small motivational booster shot without the harmful side effects”
The harmful side effects mentioned are the dysfunctional results observed when external motivators are used to encourage knowledge workers. As many academic studies and leading businesses case studies show they invariable have the opposite effect to the ones expected – they actually reduced productivity.
Let’s stop and examine that a bit;
We are being told that overpaying is bad.
By only using a reward method, an individual become motivated by the increased reward. They are expecting a continual increase and when it doesn’t appear they are de-motivated quickly.
Don’t get me wrong; we all like a pay rise – but this isn’t the only drive that should be used.
With regards to pay; focus on making sure that its fair – enough to take money off the table.
Within his book, Daniel’s evidence shows that the third drive is much more effective for creative, right-brain, heuristic tasks.
If we think about our own lives; we know that we would all prefer to be in roles where we believe we have a sense of purpose and enjoy it.
To engage the intrinsic motivators we need to look at autonomy, time and purpose.
We’ll look at these a bit more in terms of Agile values in the next article.
Domain Driven Design
Motivation