How Rock Stars Killed The Engineering Team

Ziggy played guitar

In late 2016, I wrote a slide deck. Or maybe it’s more accurate to say that I re-wrote -- no, I adapted -- a song. As a presentation slide deck. You know, as one does.

Over the next year and some change, however, I never delivered the presentation to an audience. I never... felt comfortable delivering the presentation to an audience. I wasn’t unaccustomed to public speaking. I’ve done plenty of presentations over the years I’ve been a professional software developer. I’ve presented to my teams, to my bosses, to my clients, to my customers, to the CEO, the president, to conferences (usually when I was on the schedule… once when I wasn’t). To adults. To children. Just never… to music. So I adapt (again).

David Bowie’s Ziggy Stardust tells the story of a rock-and-roll frontman whose self-absorbed braggadocio alienated (haha -- it’s a joke because… well, just read about the album), and ultimately destroyed, the band. Basically. David says it better, so listen to the song. I’ll wait.

3 minutes 13 seconds, 3 minutes 14… you’re back? Great. Where was I? Right. Ziggy. A Rock Star. Like those software job postings are always asking for. Wizards. Ninjas. Rock Stars. But is that what we want? Do we want to work on a team with someone who thinks they’re the nazz, parading their god-given ass around the office carrying a southpaw guitar? (Seriously, if you haven’t heard the song, then these references will make no sense at all. Go look up the lyrics, at least.)

Jamming good

We’ve all worked with someone who seems to know everything. Or acts like a know-it-all, anyway. Maybe they do their work really quickly. Or they come up with elaborate solutions, explaining how the problem is really complex, and how clever they had to be to solve it. They may be unconventional, do things differently. Management likes them, even though they’re… eccentric. They get accolades. They get attention. Still… something is off.

Made it too far

When one person has all the answers, other people lose their voice. The prominence and importance of one person is raised at the expense of others. These Rock Stars accomplish more than they should, and at too great a cost. They are toxic and should be considered ultimately harmful to the long-term health of a team.

The Rock Star will attract fans, groupies, other engineers who want to be like them. ‘Cause we all just wanna be big rock stars -- wait, wrong song. There will be people who admire the star’s work, who want their attention, who are eager to please them.

Others will chafe under the friction caused by the dissonance. They may be vocal with their objections, which will make them unpopular with management who appreciate the star and just wish everyone else could be more like him.

Should we crush his sweet hands?

A few people will work actively to undermine the star. This could take the form of withholding critical information, failing to call out risks, or of keeping quiet when a potential solution or improvement presents itself. The supporting members don’t feel like part of the team anymore.

The Rock Star will fight any challenge to his (we’ll save the discussion around gendered pronoun usage regarding egomaniacs for another blog post, mmkay?) dominance, trying to stay on top of the hill. He will denigrate, deny, deceive, and destroy in his struggle to remain relevant. In the Rock Star’s mind, his history of “success” enforces the idea that he is right, that challenges and objections are from small-minded people, jealous of his success, or simply less skilled and unable to see “The Truth” as he does. Even if the Rock Star has a good point, it may not be accepted by those he alienates.

But boy could he play guitar

Any personnel manager or HR professional should be triggered by the phrase “but he does such good work.” The Rock Star will cross a line sooner or later. Passive-aggressive bullying, or even overt abuse of others is a natural progression from the egotism combined with resistance and criticism. Don’t enable this behavior. Stamp it out quickly before it’s too late.

Before drastic measures are required.

Before it breaks up the band.

Oh, yeah

For all you engineers: don’t try to be a star. Be a catalyst. Start something wonderful -- be an instigator! Be someone who makes your team more than the sum of its parts. Everyone has a role to play, and that includes having a leader sometimes. Sometimes that might be you. Sometimes other people get the spotlight. Raise your voice in support of your teammates when it’s their turn to shine.

Ziggy played guitar

I wrote code. Increasingly, lately, I coach others through writing their code. When they ask a question, I lead them down a path to answering it themselves. I play rhythm, not the solos, trying to keep everyone on the beat, and in harmony. It takes getting used to. It takes practicing a new set of skills, and new approaches to situations. In the end, though, we all sound better when the band plays together. I don’t need to ham it up, to showboat, to impress anyone. I improvise. I adapt.

Still... just maybe, if I can ever get the slides to sync up with the music, maybe I’ll be the special man for three and a quarter minutes.

Special thanks to my good friend Mike Bland for his insight, thoughtful critique, and encouragement that led to this blog post, among other things.

Spectrum of Integration Automation

“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”
-- Martin Fowler,

In software development there is a spectrum of the degree to which a project team can automate integration of components, bug fixes, enhancements, and new features into a complete software product. In a 2000 article (revised in 2006), Martin Fowler describes the then-current state of this automation using the term Continuous Integration.  Fowler describes the tools and processes used to achieve this automation and the benefits of achieving Continuous Integration. Since then, many more tools and processes have entered the industry and it is becoming harder to fit all automated software development projects into a single definition of Continuous Integration. To help facilitate analysis and conversation around software development automation, I want to offer a set of terms describing various features of automation, how those features can be combined to achieve different levels of automation, and the benefits derived from each.

Features of Automation

Reproducible Builds

  • Builds are conducted from a version-controlled source of truth using a scripted process.
  • Provides traceability and accountability for every build of the system.
  • Previous builds can be reproduced with precision by another developer at a later point in time.
  • Enables troubleshooting of production issues outside of the production environment.
  • Eliminates the risk associated with variability of a manual build.

Automated Builds

  • Builds happen without manual intervention, reducing cost and freeing resources.
  • Build-time failures are identified quickly, reducing the cost of remediation.

Automated Unit Testing

  • Fails the build if individual components do not pass tests of basic functions.
  • Logical and functional failures in components are identified quickly, reducing the cost of remediation.

Automated Qualitative Analysis

  • Every successful build is analyzed for standards compliance, common coding mistakes, and security vulnerabilities.
  • Quality and technical debt can be tracked and managed to reduce the ongoing cost of maintenance.

Automated System Testing

  • Comprehensive testing that fails the build if components are not integrating properly when running in a simulated production environment.
  • Identifies runtime functional errors quickly, reducing the cost of remediation.

Automated Delivery

  • Successful builds are automatically deployed to selected environments for manual exploratory and user acceptance testing.
Automation features at various levels

Levels of Automations


  • No automation.
  • Builds are created by IDE export features, manually from the command line, or through other processes that are subject to human error and environmental variability.
  • “It builds on my machine” is a common refrain.
  • It is impossible to precisely reproduce a previous build with any reliability.
  • Automated tests (e.g. JUnit, Selenium) may exist, but they are not run consistently and automatically.
  • Individual developers may apply quality analysis tools, although inconsistently and with no formal enforcement mechanism.


  • Builds are automated using a scriptable/configurable build tool: Ant, Buck, Gradle, Make, Maven, etc.
  • Build script may include running automated tests and qualitative analysis, but still lacks systematic formal enforcement.

Automated Integration

  • Builds are triggered automatically (typically nightly).
  • Automated tests (if present) are run.
  • Qualitative analysis may be performed.
  • Enforcement of testing and quality standards is now possible.

Continuous Integration

  • Developers integrate their changes into a central repository daily.
  • Builds are triggered continuously as changes come in.
  • Automated testing and analysis provide immediate feedback if breaking changes are introduced.
  • May include some level of automated system testing.
  • If deployment has been automated, CI should include automatically delivery of each build to a shared testing environment.

Continuous Delivery

  • A combination of rigorous standards compliance, up-front peer review, and automated testing at the unit and system level is sufficient that the team is comfortable promoting changes as soon as the lights turn green.
  • Builds and deployments are fully automated.
  • Any build that passes a final round of user acceptance testing can be promoted to production with a single click.

How Habits Steal Your Time (If You Let Them)

Filling The Void in Your Schedule

I made a casual reference this morning to how my habits and routines tend to expand to fill whatever "free time" I might otherwise have, causing me to defer other non-routine activities because "I don't have time." I don't even recall what my original point was at the time, but the idea that habits expand to fill a void in your schedule resonated with my audience. Time, essentially, is a scarce commodity, and "free time" is even rarer, so I find I have a natural tendency to allocate that time to familiar, comfortable, habitual leisure activities. Apparently, other people do this, too - or something like it. But often the non-routine activities that I put off nag at me. Maybe it is a chore I don't feel like doing, or a new and exciting leisure activity that might interest me but I'm putting off trying it out of habit. I do what is easy and familiar in the moment -  follow the path of least resistance.

David McRaney explains it very nicely, in the context of procrastination:
"This is why your Netflix queue is full of great films you keep passing over for “Family Guy.” With Netflix, the choice of what to watch right now and what to watch later is like candy bars versus carrot sticks. When you are planning ahead, your better angels point to the nourishing choices, but in the moment you go for what tastes good." 
Habit and routine taste good. Really, really good - to me, anyway. Habits are really powerful, and developing good habits (say, brushing your teeth) is a useful life skill. Indulging yourself, in moderation, is a good thing to do, too, so it is natural to find a free moment and think "I should go engage in my favorite leisure activity, indulge myself while I have a chance." But when those indulgences - those leisure activities - take on the form of habits, and you're just engaging in them because it is your normal routine, then there might be a problem: your routine might be expanding to fill a void in your schedule.

Nature abhors a vacuum. Gary Larson wrote that. So go out, break from routine, find something new, do something nice - and different - for yourself (or someone else). Take a walk on The Far Side.