In this article, part of my series explaining better ROI from software development, I’d like to look at the Hero Developer.
The Hero Developer is that developer that seemingly is holding the entire operation together.
They are Superman (or Superwoman) – they seem to do the work of an entire team. They are the go to person to get stuff done.
Everybody wants the Hero Developer on their project. And in many cases, every Developer wants to be the Hero.
They are the person that full understand the system. They are the person that can apply full control over it.
For the individual, there is huge sense of importance. It fulfils the Intrinsic Motivators as described in Drive by Daniel Pink and the need to be appreciated as highlighted by Dale Carnegie in How to make friends and influence people.
Working in this manner can really appeal to an individual – I've certainly enjoyed it in the past (and would probably attribute a good deal of my career success to it). The sense of having full control and being able to, generally, work unfettered with the end users can produce a great sense of worth and powerfully addictive buzz.
And business teams love the ability to have a go-to-guy/ gal for their system. They are busy people and want to get stuff done with the least fuss.
For this article, we are going to follow the adventures of three such super heroes;
Super helpful chap came to the aid of his organisation's compliance team. They needed a tool to record complaints and how they were handled – but no one could help them.
So our hero created a simple prototype system. It worked. It was great.
The Compliance team where super happy. They could get on with their job.
Go to guy was actually part of a team of 5, but he owned all of the complex important business specific – the stuff the company made a significant part of its revenue from. Our hero was working directly with the MD, doing what need to be done.
The MD was happy – probably the happiest he had ever been with IT because his Hero Developer would deliver what he wanted quickly. The Hero Developer was happy as the role gave him great job satisfaction.
The business wanted a website – a portal for their customers. Our hero, while not a employed as a developer had some experience, so offered to build it.
This was great for Can Do Man – it gave him a chance to expand his skills.
For the business, they were getting a chance to develop an individual AND get a website cheap.
Win win.
Nope. It really, really isn't.
They are working in isolation.
If I tell you this can sometimes be called cowboy development, it should give you an idea where I'm going.
While this can seem attractive to the business and, in some cases, the actual developer - it is storing up problems for later down the line.
The quality of the system can be poor as it is relying on one person’s view. This is basically the equivalent of marking your own homework. And if you are on tight deadlines, why wouldn't you push out the nice new shiny function and come back later to fix the bugs – after all, it’s your system?
It’s certainly not uncommon of the developer to become tired and inadvertently introduce bugs.
The system will generally be isolated in terms of its interconnectivity with the rest of the organisation. With only a single developer working on it, they are unlikely to see similarities in other systems or identify opportunities to integrate with other systems.
And if your developer gets hit with a bus?
This adage is still true today as it always has been. If one developer is the single source of knowledge then as a business you have simply not resilient to illness, time-off or even heavy workload. Some people believe this challenge can be circumvented through documentation. Personally I believe this to be a fallacy.
Even should the documentation be fully up to date (which invariable won’t be) it will still take considerable time to bring in a replacement and get them up to speed. Still not convinced – then treat as any other Disaster Recovery plan (because this exactly what it is) and test it and see how well it work. Until it’s tested, then it nothing more than a theory – and a dangerous one at that because you are gambling your business on it.
During my career I've seen plenty of examples of Hero Developers or even teams of Hero Developers being a team in name only.
Hero working occurs very naturally within start-ups and smaller companies – it’s a default position if there is only one developer. But it can also creep into larger organisations.
An individual owns a system or project either by virtue of them being the only person that can or by doing such a good job last time. In this latter case, I've seen hugely capable (and expensive) developers being tied to simple but critical system because they had simply stepped in to help out.
I've seen management wanting a “named individual”. There seems to be a myth that if they have an assigned individual then their requests will be better than if delivered by a team.
And while I'm sure some requests of this nature are for good values, the majority in my experience are purely driven by ego and not having to go into prioritisation assessment against other requests.
They are simply too busy, or too important, to have to justify what they want.
Back to our Heroes;
Super helpful chap’s secret identify was that of an Enterprise Architect - that’s a really expensive resource – thus from an ROI perspective this was a disaster.
You have an exceptionally expensive resource doing menial task.
You have a system which is completely isolated from the rest of the enterprise estate. Meaning you aren't getting innovation & insight from the data. You are also paying people to duplicate data.
Go to guy hadn't set out to exclude the team from this software, but that was the net effect when he was working directly to the MD to continually add additional functionality.
Then he left.
It hadn't dawned on the MD that the rest of the team had effectively been excluded from this core functionality.
This truth soon came crashing home.
I felt quite sorry for Can do man. At this point the developer was a junior – arguably a well-meaning novice without the support of other developers.
And he did his best. For the lack of support available to him, he actually did an amazing job.
He hadn't however thought about security. He hadn't had the experience working with other systems, other teams to know he needed to think about it.
When I was called into review, I was able to compromise his website within minutes gaining access to his entire customer base. And this site was live and being actively marketed.
Needless to say I disabled the website and worked through a series of steps with the developer to rectify the problem.
This isn't to say that individuals shouldn't be given opportunities – we definitely should – but they shouldn't be expected or allowed to operate as Heroes on systems of critical importance.
I was tempted to just say no. To keep this section simple. But in truth, like all things, there can be trade-offs.
In building quick prototypes or throw away system, there can be significant value in pairing a developer with a business team. It allows for quick turnaround and provides valuable feedback on the problem they are trying the resolve.
Used for very short experiments, this is fine. It can actually be a very good ROI.
I've done this myself on many occasions. For example, was embedded into a telesales team to provide them a system for tracking leads. This worked exceptionally well.
Why?
While I'd love to claim it worked because I was so much more gifted than our heroes - it simply wouldn't be true.
It was because within a month the system was able to prove that the initiative wouldn't work commercially. Thus closing out the team and the system quickly.
But it could so easily have become a critical system and I a hero developer. I have no special skills to make me any better that the three guys I've talked about above – it is a trap that can happen to anyone.
The problem is that it is human nature to take that prototype and use it a real system (as demonstrated above by the compliance team example).
The key here is extract the best ROI through collecting the value that rapid prototyping can achieve AND the costs of ownership benefits that comes from a team mentality.
This is easy to say, difficult to keep to.
So the easiest answer is simply don’t do it.
Do the prototype experiment, but use the team rather than the individual – it will be inherently better on the ROI in the long run.
Ok, a quick summary on ROI: