A software team is not a factory. It is a band.

Jan 11, 2026

People are often surprised when they learn I play in a classic rock cover band. Somehow, they feel it contradicts what I do for a living: being in IT. But to me, this makes total sense. Music and IT are much more alike than people think.

Let me explain. Although many very successful solo artists exist, when performing live, they rely heavily on the band accompanying them. Without that, they are nothing. Well, most of the time anyway.

People often compare software teams to factories. They interpret how people interact as flowchart diagrams, processes, and logical progression. Nothing could be further from the truth: building software requires creativity and room for personal input. Just like making music does. Like making music, making great software only works if everyone understands their role and listens to each other.

Let’s meet the band.

The architect: the composer/arranger

The composer doesn’t play every single note. They write the song. They decide on:

  • The structure
  • The key
  • The tempo
  • When things get quiet
  • When things are allowed to explode.

A good composer leaves space. A bad one writes 17 instrument chances in 12 bars and wonders why rehearsals are painful.

Great architects

  • Think in themes, not tricks
  • Create coherence over cleverness
  • Accept that the solution will evolve once the team starts building.

If the architecture or the composition is wrong, no amount of virtuosity can save the gig.

The backend developer and DBA: Drum and Bass

This is the engine room. The guys and girls with their sleeves rolled up, covered in grease stains (or coffee stains).

Not flashy.

Rarely applauded.

Absolutely unforgiving if they mess up.

Drum and bass:

  • Define rhythm
  • Define timing
  • Define whether people can even dance.

Backend developers and DBAs do the same, but then in software development

  • They take care of data consistency
  • They ensure performance
  • They ensure reliability
  • They take care of security
  • They look after scalability

As a band, you can survive a sloppy guitar solo (ask me how I know). You cannot survive a drummer who can’t keep time.

When the backend is solid, nobody notices. When it’s not, everything falls apart immediately.

The senior developer: rhythm guitar.

Often overlooked. Always essential.

The girl or guy who plays rhythm guitar,

  • Locks in with drum and bass
  • Provides additional structure
  • Fills space where needed without demanding attention.

Senior developers

  • Stabilize the codebase
  • Mentor others
  • Translate architecture into reality
  • Quietly prevents disasters no one ever hears about.

These people are not trying to steal the spotlight. Instead, they are trying to keep the song playable.

Every band that fires its rhythm guitarist because ‘the singer is more important’ learns this lesson the hard way.

Not surprisingly, I am most comfortable playing rhythm guitar and being a senior developer. But that’s just how I am wired.

Well, almost… I also sing a bit in the band.

The frontend developer: lead singer

I have to admit, I am not a frontend developer. But that makes sense: in my band, I share the lead singing role. So, everything still works out.

But let’s be honest. The lead singer gets the attention (and the girls, guys, or whatever they desire). They are

  • Visible
  • Opinionated
  • Style-sensitive (this applies much more to my co-singer than to me)
  • The part that the audience actually remembers.

And that’s fine. That’s literally the job.

But a singer and frontend dev

  • Rely on timing
  • Rely on structure
  • Rely on the band not falling apart behind them.

A great frontend dev knows:

“I shine because the rest of the band is tight.”

A bad one thinks the band is holding them back, whatever that may mean.

Spoiler: the audience knows this.

The QA / Tester: the keyboard player

Subtle. Layered. Often misunderstood. Unless you are Sir Elton John, of course.

A good keyboard player

  • Fills gaps
  • Adds depth
  • Notices clashes others miss
  • Makes the whole thing feel finished.

QA does the same:

  • Edge case
  • Weird transitions
  • Things that only break on the second chorus.

When a keyboard player is absent, the song feels… empty. And when QA is ignored, the product sounds great until the bridge part collapses live on stage.

DevOps / Platform Engineer: The Sound Engineer.

Not on stage. But they control everything.

If they are good:

  • The band sounds amazing
  • Nobody thinks about them

If they are bad:

  • Feedback noise
  • Outages
  • “Can you turn yourself up?"
  • Panic

They don’t change the song. They determine if anyone can hear it. You can make the comparison with the DevOps people and Platform engineers yourself. You are the unsung heroes.

The Team Lead / Engineering Manager: The Band Leader

This is not necessarily the best musician. More often than not, they are not. But

  • They set direction
  • Handles conflict
  • Protects rehearsal times
  • Make sure the singer doesn’t fire the drummer mid-tour.

A great band leader knows when to

  • Step in
  • Step back
  • Let the band argue, and then decide when to stop it.

They don’t make the band play louder. They make the band play better.

So why does this matter?

You don’t build great software by hiring

  • Only singers
  • Only soloists
  • Only people who want the spotlight.

You build great software by building a balanced team.

Where:

  • Everyone respects the rhythm
  • Nobody forgets the song
  • And ego never outranks timing

Let us not forget one important thing: both good artists and good software teams share a common belief. They know what they are doing is not for their benefit. It is for the audience. And that is something most of us seem to forget.

And yes, the audience might remember the singer. But they feel the band.

Dennis Vroegop