I have been talking to a few people recently about industry buzzwords. There seems to be an increasing number of mock variations on Test Driven Development (TDD) as a means of describing the ever-changing – and somewhat erroneous – driving factors behind development.
We all know the digital industry is obsessed with acronyms; they are accepted and used interchangeably to express ideas or ideals. For example, XP doesn’t just refer to the practice of ‘Extreme Programming’ – it represents a revolution in the industry. So it is easy to grab people’s attention by using acronyms they haven’t heard before, and use it to trigger a conversation about a new idea or approach.
What is Executive Driven Development?
There are a few platitudes that have now become commonplace:
- MDD – ‘Mortgage Driven Development’ – def. a team / team members who are only interested in getting paid; and
- CVDD – ‘CV Driven Development’ – def. team/team member who are only interested in the next career growth opportunity purely so they can bolster their CV.
The one I coined recently (but am most certainly not the first to use) is to describe an unwelcome situation I have seen repeatedly across the market is:
- EDD – ‘Exec Driven Development’ – def. where execs have started telling their engineers what to do, but not the why.
EDD is a variation on the HIPPO (Highest Paid Person’s Opinion – yes, another acronym) principle – where the reason behind doing a piece of work comes down to: ‘because X said so’. It has become an anti-pattern. X is usually a CEO, MD, Director or such like; anyone who has the organisational authority or power to mobilise a team.
In some instances this has worked – Facebook is a great example. But it is also a unicorn. Mark Zuckerberg’s development team blindly trusted him when they were told to build the platform, without knowing whether it would take off. Luckily for him (and them) it did, but blind trust is not a reliable motivator.
Motivating through Fear
In all scenarios I’ve witnessed, the main motivating factor behind EDD is fear: fear of senior individuals, fear of getting a bad review or even fear of losing your job.
It is possible that the executives themselves may be acting out of fear. It is not uncommon to find that the authoriser is the conduit of a higher edict and may also be the victim of being told to ‘Do it, or else’. This often manifests in arbitrary deadlines, seemingly plucked out of thin air. There remains a firm belief that time targets are a motivating factor. As we all know, having a fixed date and fixed deliverable without flexing the capacity of a delivery team is fighting a losing battle. The deadline becomes the enemy and as it draws nearer the fear mounts further.
Another tactic I often see is fear generated by referring to ‘The Board’. Phrases like ‘The Board is expecting it in Q1’ or ‘The Board isn’t going to sign off next year’s budget if it doesn’t land soon’. The team has no idea who these people are, just that they are important and therefore cannot be told ‘no’. By allowing this preconception to prevail, the executive is failing to lead effectively. His / her actual job is to manage ‘The Board’s’ expectations, and check with the team that what is being asked of them is actually achievable before committing to anything.
While it shouldn’t need stating, the fact that motivation through fear continues in development situations, means that it requires more attention. I speak from experience when I say fear is a terrible motivator when building software because, perhaps unsurprisingly, it has the opposite effect. As a former developer (and knowing others who have been in similar positions), when fear is part of the equation, your output suffers. Delivery is almost always rushed because you’re willing to give up at least two of the three S’s (security, stability, and scalability) in favour of getting it done. The software seldom turns out to be of discernible quality.
Inspiration is Key
Is there an alternative to fear-based EDD? Absolutely. As a friend of mine who has recently joined a social media giant as a product manager told me “My job is now 50% evangelism”. Half of his energy is (rightly) spent convincing his development team to believe in what they are building. He takes the time to formulate and relay his vision until his team understands and hopefully, shares it. As such, it becomes a choice – the team has the freedom to decide whether or not they work on the product he is passionately advocating.
Applying this to EDD is not difficult, it just requires
a different approach. And a dose of courage. Instead of instructing a team to do something because someone senior said so, it’s wiser – and I believe necessary – to share the reasons why. As Simon Sinek explains in depth here, performance levels are better when people want the same outcome as senior management.
Crucially, any executive who truly believes doing/building/developing their vision is the right thing to should have no problem communicating why. If they can’t, they don’t believe in it, and shouldn’t be forcing others to either.
Changing your Approach
If you’re a developer being told to follow an EDD approach, ask to be convinced. The reason may be obvious to the person asking, it may be that they have also been told ‘Because X said so’, but you’re challenging them to inspire you and that’s a good thing. You’re giving them the opportunity to share or create a vision that will hopefully lead to you working on something you actually believe in. Or, if you are the E in EDD – be prepared (and willing) to inspire people to do what you are asking of them, it really does matter.
