Confessions of a (former) Rockstar Developer

This is a difficult article for me to write. I’m admitting something that makes me feel ashamed to the entire internet - and it’s tied to my real name. I also know there are former colleagues and current friends that follow my blog and that heartfelt confessions might feel like a cheap apology for previous transgressions. It is what is however - and I feel like I have valuable insight to give the wider world regarding the phenomenon of the “Rockstar Developer”.

There’s a lot of definitions of what exactly a Rockstar Developer is floating around. I’d like to add mine, hoping its simplicity captures the essence of the problem without drawing assumptions about the people who currently fit this mold.

Rockstar Developer: a single developer who is indispensable to a project

There are some key things to note about this definition. First, is that a Rockstar isn’t inherently a good or bad person. In fact, I’ve seen that most Rockstars are well liked by their colleagues and often talked about warmly and have generally a positive social impact. Second, is that a Rockstar isn’t necessarily a fantastic developer - but they are prolific and to the project’s stakeholders it appears that the “team” isn’t capable of delivering business value without them.

In a team setting they can often be seen taking work away from slower developers, or never assigning them work in the first place, becoming a vacuum for anything important to the project. The project’s deliverables swirl around them, eventually getting sucked in to be accomplished by the Rockstar alone.

How did I find out I was a Rockstar?

Once I became a Rockstar, I think I always knew that’s what I was. I tried very hard not to be arrogant or proud about it - but I knew deep down that trajectory I was on was one that meant I was becoming indispensable to the projects I worked on. I constantly told how great of a job I was doing, and how important I was to various aspects of work. It’s not the people giving me praise’s fault I was a Rockstar though - their actions were more of a symptom of the problem, not the cause of it. To them, things were getting done because of me and that needed to be rewarded - all the while I kept burrowing deeper and deeper into the roots of these projects like a tick.

What finally made me admit that I had been a Rockstar however, wasn’t some moment of deep introspection or another person calling me out on my behavior. No, what made me finally realize and fully accept that I had been a Rockstar Developer, was working professionally with another Rockstar Developer.

What does a good team look like?

Let’s take a minute and talk about what a good team should look like. I often like to take the structure of a professional kitchen and apply it to software teams. Typically, a professional kitchen has a very strict and well-defined hierarchy (at least on paper, I admit I’ve never worked in one). Often referred to as The Brigade de Cuisine - this structure ensures that a kitchen can keep up with high demand of a restaurant.

While I won’t go through the entire structure, I want to focus on a few points. Again, I’ve never worked a kitchen so I’m basing this primarily off research. If any professional chefs read this, please forgive me if I butcher things too badly.

Chef de Cuisine (Head Chef) & Sous Chef (Deputy Chef)

These two are the primary leaders of a kitchen. While the Chef De Cuisine typically focuses less on cooking and more on managerial duties, both they and the Sous Chef often “get their hands dirty” so to speak and help out where required. They are experienced in all realms of the kitchen and could step into any role if necessary.

This is the team role that a Rockstar Developer oftentimes finds themselves fulfilling first - being a head responsible for the working of the software “kitchen” and held accountable for the quality of the dishes. I feel like most Rockstar’s start off innocently - being put into roles where their large amount of experience and skills could be put to good as

Chef de Partie (Station Chef)

Station Chefs have a specific area, or deliverable type for which they are responsible. Often you’ll have Chefs in charge of sauces, grills, general meats, and vegetables. These chefs are have specialized knowledge and skills, as well as entire teams underneath them to fulfill the responsibilities of their roles (in bigger kitchens).

Often it’s the Station Chef’s that produce the actual “deliverables” in a kitchen. While the Head Chef and Deputy Chef might help organize and coordinate between stations, their work is just that - organizational and knowledge sharing. They are not the ones actually producing artifacts for consumption by human beings.

This is where the problem of a Rockstar Developer becomes most apparent. Instead of sharing experience, guidance, and organizing the work - a Rockstar instead seeks to fulfill the work of the lower level chefs himself - and this throws the entire software kitchen into chaos.

Working with a Rockstar

So what’s it like working with a Rockstar Developer? A Software Chef De Cuisine that doesn’t let his Station Chefs actually do work?

It’s frustrating.

I mean that in the literal definition of the word. I operate under the assumption that 90% of members on a team want that team to succeed - and that they also want to work and do their best work when doing so. They want to produce quality software, solve business problems, and generally fulfill the responsibilities of their roles. When a Rockstar is working however, all efforts by others at finding work, producing artifacts, and fulfilling business needs are often frustrated - literally prevented from succeeding or progressing.

Don’t get me wrong, the Rockstar isn’t usually purposefully doing this - it’s just the result of the current work paradigm and the feedback loops they’ve created with management and stakeholders. I’ve seen it happen over and over again - the Rockstar goes above and beyond to deliver software faster than thought possible (often at the sacrifice of sleep and work/life balance) and that delivery speed becomes the new de-facto standard for all future deliveries.

Rockstar Prevention & Recovery

I wish my insights about being a Rockstar Developer extended to fixing the damage they can cause. I wish I could say I found a way to remove myself from Rockstar status and that I helped my previous organization heal. I didn’t though. I left.

That’s what usually happens, the Rockstar leaves for one reason or another. When they do, the house of cards comes crashing down and the lack of the structure that should have been there from the beginning is being widely lamented. Often the Rockstar’s work artifacts are quietly retired - removed in favor of team-built and team-understood replacements. They’re remembered fondly, but the impact they hoped they’d have eventually disappears as an actual team is built from the ashes.

I would like to share some hope though - some advice for both those who are currently Rockstars and those working with them.

Advice for working with a Rockstar Developer

1. Encourage Documentation and Understanding: This often equates to encouraging the Rockstar to slow down. Oftentimes they’re moving so fast that no one knows what’s going on, being written, or being accomplished but them. Make an effort to push for documentation, knowledge sharing sessions, and gasp pair programming sessions if need be.
2. Share the Cognitive Load: If you can, you need to make the Rockstar share the burden they’re carrying alone. Everyone is trying to do what’s best for the business. Your mileage may vary here, and each person is different so I can’t give you more advice than a general push to encourage the Rockstar see you as someone who can help.
3. Unify the Team: You all need to work together to gather and unify the team. You’ll need to become a competent Sous Chef - willing and able to pull from the Rockstar’s plate, and ensuring that you delegate to your other team members.

Advice for being a Rockstar Developer

1. Your ultimate goal should be to stop being a Rockstar: Every action you should be taken from the time you realize you’re in this position until the end of your tenure should be in service of spreading the load and building your software kitchen to make this a thing of the past.
2. Delegate: and not just the boring stuff! You need to consistently delegate a large amount of the deliverables coming your way to your team - including the fun or difficult parts. Your team won’t grow unless you challenge them, and if you take all the hurdles on yourself you leave no room for anyone to grow.
3. Learn how to Trust: This is obviously easier said then done - but you must learn how to trust your team. I strongly believe that a large percentage of Rockstars are that way because they lack trust in anyone including themselves. Whole blog articles could be written on how to accomplish this, and maybe I will, but you might need to do your own research on how to best accomplish this for yourself.
4. Let the Organization Stumble: This is not going to be easy, but you might need to let your organization stumble a few times without you fixing things. You need to show them how dangerous that situation was before, and that they need to help you build the team that will fulfill these roles.

Remember that we’re all learning how to be humans on this earth. Rockstars are just human, and oftentimes are good people who have just stumbled into software quicksand and need a helping hand out of it.

We’re all in this together.