6 reasons why development teams are like bands

6 reasons why development teams are like bands

You might think of web development as a pretty mechanical and dry process. Write a command into a terminal exactly like the language dictates to make the machine do a specific thing. But there are actually many similarities between coding and playing music. After all, if you don’t follow the rules of music, you’ll end up sounding pretty bad. The art in both is about using the rules in creative and interesting ways to make your instrument worth listening to. In the same way, putting together a team for a client is like forming a band. You want the band to be great, and give the client/listener a good experience. And you also want the band to enjoy the experience, which makes them do better work. The performance should also be rewarding – for the band and for the listeners. Here are some aspects to consider for smashing performances.

1. The right people for the gig

What people do you need for the gig? Sometimes you only need a duo. Other times you need drums, bass, keys, two guitars and a roadie. The scope of the project and complexity of the technology will determine the team’s makeup (The composition of skills, not what they put on their faces). And when you are in the band, you are in the band. All are equally important. 

Too few people will make the band feel like Bilbo Baggins: thin, sort of stretched, like butter scraped over too much bread. Too many people will cause confusion as to who’s doing what, and the project will be too fragmented to create a delicious result. Too many chefs, and all that. But now we’re mixing analogies. The point is that we take care to have the right skills for the gig at hand, and that requires knowing the size of the venue, the available equipment, who is working on the night, and all the other details which might affect your work.

I mentioned who’s doing what, and there should be some thought dedicated to that when putting the team together. The transition phases are especially important, like: Is it more practical to have the designer or the content person do the core model workshops? Should the designer include some code and prototypes, or is it better to give the developer a “clean” Figma file?

  • Picking the right team members is a key to success. Do it with care.
  • Have clear responsibilities. Is there a dedicated QA person, or is it handled by some other person?
  • Commitment to the team <3

2. Experience matters

Web development is an art, and the best developers have a sort of indeterminate “X-factor” which makes them better than the sum of their training. There is a lot of value in knowing all the rules of music, but expertise only comes with experience. 

In the western world we usually value data over intuition, while in Asian countries it’s the opposite. We might have something to learn about trusting the X-factor when it comes to developers.

Session musicians who do hundreds of gigs per year don’t need much time to rehearse. They don’t even need sheet music for all the songs. They can jump into any band and sound great. Less experienced players need more sheets, more time and better communication.

It’s more fun to play when most of the musicians are on the same level. However, it’s also rewarding and important to nourish new talent. It’s easier for both parties if there is only one person with less experience. Easier for the senior developers because they don’t have to cover for the junior one when they need to go beyond a certain skill level, and easier for the junior because they get more personal learning time from the senior.

Takeaways:

Prep for people with less experience! Juniors on the team means:

  • More time is needed from PM for communication
  • More guides, best practices and review is needed from tech lead

3. Long-term ensembles 

People who have played together for years develop their own ways of communicating on stage. A quick look at the drummer can mean: Take us into the bridge. Not only is communication easier, but the band sounds better too. 

If the band needs a new bass player, they will make it work. But if they simultaneously replace their drummer, they will start to sound different. Musicians who play together on a regular basis do better!

After some concerts, the band will make mistakes and learn. They will also learn from their successes. That’s the beauty of long-running teams.

Takeaways:

  • Long running teams perform better
  • The same team can work on multiple projects (one after another)
  • Replacing one team member is better than putting together a brand new team
  • When all team members have participated in a failure, they learn collectively

Free eBook: The Future of Content Management Systems

4 A band needs a leader to be self organized

Most bands or orchestras have a leader. The top person in charge might be a producer or a conductor – but even so, there is usually a leader among the musicians as well. Like the leader of the first violin section, the concertmaster.

Takeaways:

  • It’s useful to have a leader among the “performing artists” in the group
  • It can be a PM or a scrum master/tech lead
  • The leader should be able to talk to all parties, internal and external

5 Chemistry between members

Musicians might do what they love, but it’s more rewarding to do it with people you care about. If you're in a band where the chemistry is bad, the motivation is not likely to last. However, there are cases where some friction is a good thing (if it stems from differences in opinion or personality, not abrasiveness). Properly directed it might lead to interesting and creative solutions.

Takeaways:

  • Build teams where the chemistry feels good
  • If a team member has a bad feeling regarding the team composition, s/he should talk to the leader
  • Once in a while, friction is good.

Read more about group cohesion here

6 It’s easier to book a band than many individuals

If you want to make money renting out musicians for celebrity weddings or TV on a regular basis, you get tired of putting together a new orchestra for each session. You want all the players to commit to a group, and simply allocate the band as a whole. That gives stability for the team members and an easy to manage “package” to sell to clients.

The band can always add a solo artist here and there when needed. Not all instrumentalists can be a full time team member (looking at you, cowbell man!). 

If the band needs to do two gigs at the same time, say no. If it happens often, you can always start another band.

Takeaways:

  • Team members who work together consistently is a win for all parties
  • It’s easier to allocate teams than people. And the clients love it.
  • Team members might get some idle time by committing to one team only, but it encourages bigger retainers and better customer satisfaction

TL;DR

Teams thrive when we approach them as bands. Happy gigging!

Get more insights like this to your inbox