Rockstar Driven Development (RDD)

Imagine this: You come into work on Tuesday morning after a four-day holiday weekend to find a cryptic email from one of your best developers describing some changes they just checked into your main branch. In the approximately 112 hours since you thought everyone went home on Thursday afternoon, they’ve been on a kind of technological bender, ripping out the workflow engine your team has painstakingly built and debugged over the last five years and replacing it with an open-source library that loads its configuration out of MongoDB.

The replacement is around 85% complete, with a bunch of necessary unhandled edge cases needing attention. While individual tests run correctly, you can’t run your entire integration test suite because there’s a cross dependency and they can’t run in parallel. There is some documentation, but it’s largely conceptual and leaves out significant details. Half your development team has work in flight that will need to be redone. Most of your customers deploy using Azure Storage and Azure SQL Server, and they’re not going to be happy with the new dependency on an unfamiliar database technology.

Worst of all, your developer isn’t answering their mobile phone and you suspect they’ve turned it off. Their email said they were going to sleep until the weekend, which is great for them but leaves you in a large hole.

Rockstar Driven Development is when you have a developer who does whatever-they-want, whenever-they-want, because they’re considered the golden child who can do no wrong, and because management effectively has no control over them.

A Rockstar developer tends to be particularly good at what they do – and has often delivered substantial value in the past because of their expertise across multiple problem domains. They’ve often built-up considerable trust because of their past efforts, with the result that they’re now largely left to their own recognizance when it comes to what they do.

They are almost always long timers in the team, people who have been around since the earliest days of the company. Sometimes they are founders. Invariably they have deep knowledge of the business, and they’ve contributed a heap of business value with their efforts in the past – but this has contributed to an aura that they can do no wrong.

And this is where it becomes dangerous, as the Rockstar can become disengaged from what the product team needs, focussing instead on what they think is cool, interesting, or desirable.