Mainframe Blog

We Can All Be Leaders; We All Need To Be, To Really Succeed

Jazz musicians performing in nightclub
3 minute read
Mark Schettenhelm

On the evening of January 16, 1938, Benny Goodman took the stage at New York’s famous Carnegie Hall with his big band. It was a big risk and there was some nervousness among the band members because it was the first time that a swing band played there, and many critics felt they didn’t belong in such a prestigious venue. The opening number was one of their regular numbers, “Don’t Be That Way,” which was normally very popular. But it fell flat. The band was stiff, and the audience reserved. This was not a good start.

Then, midway through the song, the drummer, Gene Krupa, started dropping strong drum accent “bombs” that stood out. He then played a two-bar break that lasted only three seconds, but brought the audience in. As Krupa said later, “I knew I had to do something. So, I had my drum breaks. So, I just hit everything I possibly could. Made a lot of noise. It woke everybody up. From then on it was smooth sailing.” He was right; that shook up the band, they loosened up, and the audience responded. If you listen to the recording now, you can hear, and feel, this change happening. The concert went on to become a success and proved that swing music belonged.

This illustrates the power of having a member of a team realize things aren’t as they should be and step up to move things in the right direction. I asked Allyson Briggs, singer and band leader of Fleur Seule, about the role played by each member of a band.

“A strong team is not one thing, it is many individuals keeping things flowing to appear as one,” she said. “When I come off a three-gig day, the guys know I need a little extra energy and support on that brunch gig the next day. If we get into a tune and someone is lost in the chart, we all sense it and rally to pick them up where they are to get back on track, while not letting the audience know. Being part of a team is holding your own yet knowing when to jump in to help.”

While Agile Scrum teams may have a “scrum master,” every member has a responsibility. They cannot rely on only one person to provide leadership. Effective teams follow these practices:

  • Be aware. Members of effective teams sense their surroundings, not just what is in front of them. The team is more than you and your task; both you and your code need to fit with others. Team members need to be aware of what others—and their code—are doing.
  • Communicate. Everyone must contribute; each member has a part to play. If developers see an area that could be improved, or something that they feel is wrong, they need to say something to the team and then decide together how to make things better. When small problems are found later, they may have become bigger problems—unspoken problems can’t be resolved.
  • Focus on commitments. Teams make commitments during each sprint at the planning stage. When stories are dependent on one another, any lateness creates a ripple effect that affects the team and possibly other teams, the organization, and end users. Find blockers and let the necessary people know if your commitment deadlines cannot be met, and remember to honor your commitment to your team members first.
  • Offer support. This can occur in two places. One is during the daily standup when developers might mention impediments they are facing. This is an opportunity to offer assistance if you have the ability to do so. The other is during the sprint review, when you can show appreciation for your team members’ contributions.
  • Know your teammates. While all team members may have common skills, each also has areas where they excel or can improve, such as a comfort level with certain languages and especially with areas of the code. Knowing your teammates can also help with task assignments and when deciding whether to leverage the skills of the person in the best position to succeed or give someone else a chance to gain experience. During code reviews, prior to looking at the code, keep notes on potential problem areas the team has been facing.

A great development team should be like great jazz musicians. They should play well off of each other, with each picking up where others left off and focusing on the whole group, as well as their role within it. Only by combining their individual talents and roles can they produce something that will really matter in the long run.

Access the 2023 Mainframe Report

The results of the 18th annual BMC Mainframe Survey are in, and the state of the mainframe remains strong. Overall perception of the mainframe is positive, as is the outlook for future growth on the platform, with workloads growing and investment in new technologies and processes increasing.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing

Business, Faster than Humanly Possible

BMC works with 86% of the Forbes Global 50 and customers and partners around the world to create their future. With our history of innovation, industry-leading automation, operations, and service management solutions, combined with unmatched flexibility, we help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead.
Learn more about BMC ›

About the author

Mark Schettenhelm

Mark is a DevOps Evangelist and Lead Product Manager at BMC who has experience working with developers around the world in Source Control Management, Testing, DevOps and Application Portfolio Analysis. He is a frequent conference speaker, webinar presenter, blogger, and columnist, often explaining the benefits of bringing Agile and DevOps to mainframe development and encouraging development teams to adopt new methodologies and continuously improve.

His writing has appeared in Enterprise Executive and Enterprise Tech Journal and he is a frequent contributor to and SHARE Tech Watch. Mark is currently the Lead Product Manager for BMC products in Source Control Management, Deploy, Code and Fault Analysis.