Introduction

In software engineering a rockstar is any software engineer whose engineering work: scales really well; is completed more quickly than other engineers; involves logic that others depth or range of knowledge does not produce. Now…does this perfectly describe a rockstar? No. I gave three criterion and three criterion almost never accurately decsribes any concept. What I’m doing here is simply attempting to provide a simplistic outline of characteristics typically exhibited by rockstars in order to provide a basic argument structure for why rockstars are rare and deserve professional empowerment.

So You’ve Landed a Rockstar…

Imagine, or reflect on how lucky you are, that you’ve actually landed a rockstar. After all: isn’t the point of hiring to build out a team of rockstars? No, the point of hiring isn’t to build out a team of rockstars because rockstars are rare: that’s uh…what makes them rockstars. Are there things companies can do to attract rockstars? Yeah. Is your company doing them? I don’t know…probably not and that’s definitely a crucial topic that I plan to cover in the near future1. But say you do or have landed a rockstar? How do you proceed? What follows is a list of how to maximize your rockstar’s happiness and effectiveness.

A small caveat before proceeding:

The title of this article is not “A Rockstar is the Most Important Engineer On Your Team” and the impetus for writing it is merely to share lessons learned from my having worked with a couple rockstars whom I felt management could have empowered better.

Resist the Temptation to Make Rockstars into Leads if it Means Reducing Their Engineering Time

This is obvious. And to their credit, most organizations know that stifling a rockstar with anti-engineering tasks is seriously inefficient, if not outright masochistic. However, at small (and possibly some mid-sized) companies where leads may have managerial tasks it’s prudent to calculate how much time a rockstar would be spending completing “other stuff”. Spoiler: if it’s a lot time then reconsider. If a rockstar wants to go into management for the money or simply because they have excellent interpersonal communication skills then they should be empowered to do so, but management and executives should resist any tempations to put rockstars in positions where even some of their time isn’t spent engineering.

Rockstars Need to Train-Up Those in Need

There is no other way to say it: having a genius on the team, could, if utilized appropriately, make everyone else a better engineer! Hence empowering your rockstar to meet individually and in groups with the rockstar’s teammates and even other teams should be a top priority. Here is a very basic list of specific methods that can be used to empower your rockstar to train others:

• most importantly: clear some portion of their schedule to actually do so. This is primary. A rockstar cannot train others up if they are constantly being bombarded with escalations and “the crisis du jour”.
• have them meet with team members 1:1 to discuss the fundamentals of classically misunderstood SRE topics like: PKI, database security, modern encryption techniques, programmatic traps such as: golfiness; shitty documentation; tight coupling, etc. Then have them demo these topics to the team and provide a Q&A platform. All of this should be done with straight development teams, as well. It goes without saying that training devs up on ops has to happen for a modern organization to be lean and profitable.
• give them “office hours” where they are quite literally available to do nothing but answer any theory or work questions that other engineers may have

Obviously a rockstar needs to produce in other ways than training others up, as well, and the specific suggestions above are just given as possibilities, but do make sure to afford them with designated time to train others. It is absolutely critical to the organization.

Connect Rockstars with Key-Decision Makers

Most companies have regular architecture-related meetings which are typically a mix of architects and “people that somehow can get money for stuff.” A rockstar must be in these meetings because organizational direction is concentrated here, hence it is here where the rockstar’s genius can have an origin of implementation. It makes no sense to have a rockstar if they can’t…well…rock. Furthermore, if a rockstar lands on a team and is not able to give architectural insight then they will quit and find a better job.

Get Rockstars in the R&D Lab

Rockstars don’t just think differently about engineering: they think better about engineering. Because of this an organization should strive to, as much as possible, empower a rockstar to conduct research and development for tools, services and applications that the organization doesn’t even know it needs yet. There is a chance that this R&D could lead to a new open source project that could help other companies and that will really help your company. Having a FOSS breakthrough has put many-an-org in the limelight, at least for a time: American Express (Cloud Custodian), Ubuntu (Cloud Init), Github (Hubot), the list goes on forever.

There is also a chance that availing a rockstar of R&D time could lead to a significant improvement in overall product quality due to a rockstar’s analysis of current products or creation of a service, tool or application that makes other applications unecessary or more efficient.

Finally, it’s important that management not try and guide a rockstar’s R&D: the rockstar was hired for the incredible way in which they think, so ideally, management would encourage such a mind to operate and flourish as organically as possible.

Conclusion

In general, management should not make rockstars management: they’ve been hired to engineer, not engineer part-time and manage part-time. Unless they want to go that route, resist the tempation. Furthermore, three critical ways to empower a rockstar are to have them train-up everyone that needs training, connect with key-decision makers and spend time doing nothing but research and development. Although these recommendations are obvious they are rarely implemented well, if at all and their actualization is a key measurement of organizational effectiveness!

1 There is no direct way to attract rockstars except to have a kick-ass, worker-empowered culture and incredibly generous benefits. Having employees that aren’t running around sexually harassing or assaulting other employees is a great start, as well.