How Concerts Gave Me a Crash Course in Problem Solving

Always follow the cable

Lasse Olsen
Failing forward book
5 min readOct 31, 2023

--

In my previous life, it seems like now, I used to work as a sound technician. That’s the people who make everything go loud at concerts. While I have so many good memories and fun stories, it’s easily the most stressful job I ever had.

At one concert a rapper lost his voice, and people started threating me because the vocals where so low (again, the rapper lost his voice). Another time, at a Octoberfest, some drunk person unplugged the electricity so the whole show went down.

One intense memory are from the pictures under. The mixing desk hadn’t been working all day and 1000 auidences started entering the room while the band hadn’t even tested the sound. All of this happened while the organizer screamed beside me, literally crying for a solution. That day I mixed the band live and it would be one of my last shows.

21–22 year old me who just wanted to work with music

There’s so many things that can happen in a concert. With that, you become good at decrypting where problems are located. In other words, you become good at following the cable.

Take an easy example

On a normal drum set up you have 8 microphones. If something happens, the problem isn’t “it’s something wrong with the drums”.

It’s “somewhere a long these points, there’s an issue getting sound from this microphone”. To fix the issue, you follow the cable by starting at the core (microphone itself in this example) and check backwards to all the points to find where the error is.

How you would troubleshoot if you got no sound from the kick drum. P.S. for all you sound nerds out there, I know DI box on kick is not the best example.

This technique is the same for more complex cases like the sound is distorted, monitors aren’t working properly and yes, the mixing desk is dead. Follow the cable.

The reason I’m writing this is that I believe we often need to step away from focusing over “the problem” and rather following the cable on what is causing the problem(s) and fix/improve these.

A problem isn’t a problem

A problem usually isn’t the problem in itself. It’s a summary of several problems that boils up to create that overall problem. (scroll a bit down for an illustration if that didn’t make sense)

It’s far more effective to do incremental improvements on mulitple points leading up to an overall problem, rather than using a lot of time trying to solve the overall problem in itself.

Developers do this all the time. They spot an issue and have to follow the cable to find out where the issue is.

Example from a retro

Take a common statement on “We just keep the lights on in this team”. This is, for now, just a subjective opinion that you may have gotten from a retro (remember when we talked about retros?).

You’re not going to fix this by mirroring the statement and saying “Well gang, let’s build something new & cool 🤙🏼”.

If you start adding the points that leads up to this overall issue, it might look something like this.

This list could/should be more expansive. It’s also smart to get input from some of your teammates.

What you’ll see is that those points are overall problems for something else again. So the cable get’s longer and you get more points that can be fixed.

If you’re having troubles coming up with points, get an allie from your team and do it together. Five why’s is a great technique for provoking answers or more questions. My son that’s 4 uses this technique all the time.

Yesterday he asked me five times what a shadow is. Honestly makes you think.

Anyway.

Hopefully after doing a good ol’ braindump you’ll have enough to understand what can be the causes for the overall problem.

You’re not going to fix everything, because it’s a process, but you can see more clearly where changes can be made that will make the boat go faster for your team.

Pick out the things you can do someting about now. Doesn’t mean the other things aren’t important, but these are the most important things you can do right now.

As a nudge to the importance of doing incremental improvements on points, I want to add three paragraphs from Atomic Habits (by James Clear) that triggered this post. It’s about the English cycling team and how they turned everything around to become one of the greatest to do it.

Brailsford and his coaches began by making small adjustments you might expect from a professional cycling team. They redesigned the bike seats to make them more comfortable and rubbed alchohol on the tires for a better grip. They asked riders to wear electrically heated overshorts to maintain ideal muscle temperature while riding and used biofeedback sensors to monitor how each athelese responded to a particular workout. The team tested various fabrics in a wind tunnel and had their outdoor riders switch to indoor racing suits, which proved to be lighter and more aerodynamic.

But they didn’t stop there. Brailsford and his team continued to find 1 percent improvements in overlooked and unexpected areas. They tested different types of massage gels to see which one led to the fastest muscle recovery. They hired a surgeon to teach each rider the best way to wash their hands to reduce the changes of catching a cold. They determined the type of pillow and mattress that led to the best night’s sleep for each rider. They even painted the inside of the team truck white, which helped them spot little bits of dust that would normally slip by unnoticed but could degrade the performance of the finely tuned bikes.

As these and hundreds of other small improvements accumulated the results came faster than anyone could have imagened.

You will always have problems. That’s part of what makes this job exciting. You just have to choose where to put the energy so the boat goes faster for your team.

Nice, you made it to the end! 🎉

P.S. If you want to read about how to talk about problems with your team, check out: Great Teams Have Issues Too.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

--

--