Three leadership inspirations from an orchestra conductor

Reading time: 3 min.

Benjamin Zander at TED 2008

Renowned conductor Benjamin Zander, conductor of the Boston Philharmonic since 1979, had been conducting for 20 years before he realized something about his job. When he changed how he worked based on his realization, members of the orchestra came up to him, in astonishment and delight, to ask what had changed.

What did Zander realize that led him to be a better conductor? He realized that while the work of an orchestra is to make music, the conductor him- or herself doesn’t make a sound.

“My picture appears on the front of the CD, but the conductor doesn’t make a sound. He depends, for his power, on his ability to make other people powerful.” (Benjamin Zander: The transformative power of classical music, TED 2008)

It’s the same for a CIO or IT executive, even for a team leader. If you’re a CIO or IT executive, your photo may be on the website and in the annual report, as Zander’s photo is on the Boston Philharmonic’s CDs. Team leaders, even if they don’t get a photo, may get the credit. But there’s an invisible photo, too, and that’s what you do to make your talent and your organization powerful.

Leadership isn’t control

Why Brian Williams isn’t lying

Reading time: 3 min. 30 sec.

Brian Williams at Tulane University, 2007

Brian Williams, for many years an anchor for NBC, used to tell a story about being on a helicopter that was struck by an RPG over Iraq. But in February 2015, evidence surfaced that the story wasn’t true. A different helicopter had gotten shot down; the helicopter he was in, flying about an hour later, landed unharmed.

Theories flourished: Brian Williams was lying, he was unconsciously constructing himself as a hero, someone else made the mistake and it was too awkward for him to correct it, he misremembered after so many years.

Let’s talk about memory.

I remember vividly an exhibit I saw in the early 1990s at the Smithsonian. The subject of the exhibit was the painting “El Jaleo,” by John Singer Sargent, an enormous canvas 11 1/2 feet wide and nearly 8 feet tall, showing a gypsy dancer and musicians.

Business leadership isn’t about avoiding “mistakes”

Reading time: 2 min.

Vilem Sokol, photo from SYSO

One year when I was in high school, I went to a summer music camp (it was Marrowstone, in case you’re familiar with it). The conductor of the orchestra I was in – I played viola – was a strict, intense man who scared everyone in the orchestra. Another player who’d been at this summer camp before, said that this conductor used to be even scarier, often reducing young players to tears.

One time when we were in rehearsal, we all anticipated a beat, not waiting for his baton indicate it. The conductor stopped us and said, “There is no second beat in that measure until I give it.” Chastened, we paid more attention when he started us up again.

At its most basic, the purpose of a conductor is to get the orchestra to work together to play a piece of music. That sounds a lot like what a leader does, doesn’t it? (Of course, you knew that that’s where I was leading.) In fact, the conductor Benjamin Zander teaches leadership lessons based on his years of experience as a conductor.

Clearly, the orchestra has to follow the conductor, and observe the tempo that the conductor indicates with his or her baton. But being strict, and scaring the talent, doesn’t yield the best results. A good orchestra must have the freedom to bring its best to the music. Similarly, businesses need the engagement, curiosity, and drive that their talent bring to the table.

How *not* to communicate with us

Reading time: 2 min.

I recently watched a TED talk from 2012 that encapsulates all of the mistakes that non-technical people make when they try to tell us how to communicate.

The talk was “Talk Nerdy to Me,” by Melissa Marshall, a faculty member in the Department of Communication Arts & Sciences at Penn State University. Marshall’s stated goal was to help scientists and engineers communicate ideas to nonscientists and nonengineers — a laudable goal, except she showed astonishing lack of understanding of the very audience she was trying to reach.

Her biggest lack of understanding of technical people showed in the second point of her talk: “Beware jargon.”

We all know that we don’t use “jargon”! We use specific terms that have precise meaning. Someone who calls our language “jargon” trivializes us and shows no respect for what we do.

She should have said, “Translate your specific, precise terms into everyday language.” Or, alternatively, “Define all terms of art with everyday words and/or phrases.”

How to belong in the C suite — without selling out

Reading time: 3 min. 30 sec.

If you’re a CIO, CDO, or CTO and you aren’t getting the respect you deserve from the C suite or the board – or both –, consider additional strategies you can use to get that respect. Then use that respect to get what you need for your division and for your career.

Take some tips from Larry Bonfante, CIO and executive coach to IT executives, from his post “Can You Spot the CIO in the Boardroom?“

1. Look as though you belong, look reputable, so you’ll be taken seriously (although I add: still look like a technology geek, otherwise you’ll lose credibility among your reports).
2. Develop relationships and chat with people (yes, really).
3. Speak their language; educate the board about technology in terms that laypeople can understand.

So how do you accomplish these things? Read on.

Personal Barriers to Problem Solving #2: Trying to Control the Other Person

Reading time: 4 min.

Whenever you’re trying to resolve a problem you have with someone, you deserve to get the best possible resolution. You deserve a resolution that furthers the business goals, meets your needs, safeguards your position in the organization, helps you maximize engagement with a colleague or business associate – whatever you need in your situation.

Resolving interpersonal problems can be hard; we all know that, we’ve all experienced it. In my 12 years as a mediator, I’ve helped people resolve problems of all kinds. Over the years, I’ve noticed some things that people do that makes it harder for them to get the resolution that they deserve. I call these things personal barriers to resolution.

In my previous article on personal barriers to resolution (Personal barriers to problem solving #1: Being stuck in your perspective), I talked about how you can get better resolutions to problems if you learn how to let go of your perspective on the problem.

In this article, I’m going to talk about how you can get better resolutions to problems if you let go of trying to control the other person, or trying to change the other person’s behavior.

A coffee company *and* a retailer

Reading time: 30 sec.

If you needed any more evidence of what you already know, that companies that traditionally weren’t tech companies have become tech companies? Take a look at this:

Geekwire asked Starbucks Chief Digital Officer Adam Brotman, “Is Starbucks a tech company or a retailer?”

Brotman replied, “We consider ourselves a coffee company that happens to love using technology and innovation to make those experiences better.”

Q&A: Starbucks Digital Chief Adam Brotman on mobile ordering, delivery and international availability

How is your organization becoming a tech company?

Grow your Strengths, Don’t Worry about your “Personality”

Reading time: 2 min.

Did you see this article in the Wall Street Journal?

“The Personality Trait That Can Hold CIOs Back”

The title is a kind of anxiety-inducing click bait, inviting CIOs to worry about how they might be deficient. But if you read it hoping to find the secret for success among the C suite, you might be disappointed.

The essential point is that CIOs who’ve come up through the ranks of IT have differences in personality from most of the rest of the C suite, and that these differences can detract from their influence and power in the organization.

This conclusion is based on studies using the Myers-Briggs Type Indicator. You know that, it’s the assessment tool that says that you’re an ENFP or an ISTJ or some personality type similar to that.

Penberthy’s Law of Common Information, in response to Thomas Davenport

Reading time: 3 min.

In a delightfully tongue-in-cheek article in the Wall Street Journal on Wednesday, December 10 (“The Promise and Perils of Common Information”) – which I read while eating my morning oatmeal with bleu cheese and pepper (yes really) – Thomas Davenport puts forth his hypothesis as to why organizations have so many problems creating key information elements of their Common Information Model.

He states it in his “Law of Common Information”:

“The more an organization knows or cares about a particular business entity, the less likely it is to agree on a common term and meaning for it.”

As an example, he gives American Airlines’ difficulty in defining the meaning of the term “airport.”

Don’t worry, this was over a decade ago, and in any case it doesn’t mean you should avoid flying. It only means that, for example, cargo people, maintenance people, people who work with the International Air Transport Authority, and so on, define “airport” differently. In fact, at the time, American Airlines had 11 different definitions of the term.

In his article, Davenport makes a droll reference to eating Cocoa Puffs for breakfast. So, fueled by my aforementioned breakfast (oatmeal with bleu cheese and pepper), I submit Penberthy’s Law of Common Information:

“CIOs must write code,” yes or no?

Reading time: 30 sec.

Do you think CIOs should still write code, even though that’s not their primary function?

A LinkedIn conversation on this topic has gotten 466 comments worth of controversy since it was started in November 2013. Some people say yes, it’s important that CIOs keep up with trends in programming languages, development environments, etc. Some people say no, that CIOs need to be thinking strategically, and not taking time out to code.

What most people don’t talk about is that coding is just plain fun. Okay, not always “fun,” but challenging, intriguing, and rewarding.

Here’s the link to the convo: CIO [sic] Must Write Code