The Business Sensei

Future Retrospective

Once upon a time there was a staircase. Although it wound its way up from floor to floor in the manner traditionally associated with staircases, this was no ordinary staircase. Although it stood in a courthouse in Franklin, Ohio, in a fashion much like other staircases, yet it was not like the other staircases. With most staircases, those who look down see stairs beneath their feet. With this staircase, however, those who looked down saw the floor below and those people walking up the stairs. They saw those who stood at the bottom of the staircase, for this staircase, you see, was made of clear glass. While we have no information as to whether those climbing the staircase felt a sense of vertigo when they looked down, we do have definitive information about what they said when they looked down: “Hey, those people at the bottom of the stairs are staring up my dress.”

Although the news report was slightly vague on this point, we may safely assume that this comment was made only by those who were, in fact, wearing a dress.

But yes, it seems that people on the staircase made an observation that had eluded the architects who designed the staircase: that if you can look down through the glass, you can look up through it as well.

When questioned on this point, the architects responded by saying that they had naturally assumed that no one would be so inappropriate as to stand at the bottom of a glass staircase in a courthouse and look up women’s dresses.

When this insightful observation was relayed to the judge, he replied that, “If people always exercised good judgment and decorum, we wouldn’t need this building.”

The architects had carefully considered their building material. They had thought about how to make the glass durable and resilient. They had considered the problems involved in building a glass staircase in such a way that it would continue to look good even after having hundreds of people walking up and down it each day. They had, in fact, solved each one of these problems.

What they had not considered was how the customer, to wit, the people in the courthouse, would actually use the product. They were so fixated on the concept that a staircase is for walking on, not staring through, that they failed to consider the ramifications of their architectural decisions. To be fair, architects are hardly unique in making this type of mistake. It can be very easy to let your assumptions about how something should work or how it will be used to blind you to how it will actually work or be used. Consider the example of the business school competition to design a helicopter. The contest was judged on a number of factors, including the weight of the finished product. The winner was the helicopter without an engine. Apparently, no one had included “able to fly” in the criteria for success. The assumption that, of course, a helicopter should fly was so taken for granted that no one thought to see if it was included in the rules.

On the bright side, it had considerably less severe consequences than the situation involving the helicopter that flipped upside down while in flight. Or the data analysis software package that looked like it had crashed the computer, causing users to reboot shortly before the calculations were complete. Or the organizational improvements that led to a massive talent exodus.

In each situation, the people designing the end result honestly believed they were giving the customers, including the employees in the final case, what the customers had requested and that belief prevented them from considering any other possibilities.

“We asked!” the designers protested. “That’s what they said they wanted.”

Were the customers really asking for a helicopter that flipped upside down or an expensive glass staircase that had to be subsequently covered? Of course not. But somehow, that’s what the designers heard.

The problem was that they asked the wrong questions, further leading them into their one, narrow, view of the result. Thus, no one ever stopped to imagine how the end product, be it staircase, contest rules, helicopter, software, or organizational procedures would actually be used.

In each situation, rather than seeking information, the people asking the questions sought validation. They already had an idea in their heads, and any inquiries they made were aimed at confirming that idea, not testing it.

When you say, “This is what you wanted, right?” or “What do you think of this approach?” odds are you aren’t requesting information; you are requesting validation. Indeed, even if you are seriously trying to get information, such questions usually get you validation instead. This is because the client assumes that you, as the expert, know what you’re talking about.

So how do you ask for information? One answer is to change the time frame. Instead of asking them to imagine the future, pretend it’s the future and imagine the past: “If we went with this approach, and six months from now you weren’t happy, what would have gone wrong? If you were happy, what would have gone right?”

This small change causes people to actually imagine using the product or living with the new procedures. Now, instead of validation, you’ll get information. That information may shake up your carefully constructed vision of the future, but that’s fine. Better now than after the sightseers congregate at the bottom of that glass staircase. A future retrospective also forces you to more honest with yourself and address the issues in front of you.

What challenges are you facing? If, six months from now, you had successfully addressed your most persistent problems, what would you have done to make that happen?

Not In Front of Me!

Legendary bank robber John Dillinger was reputedly asked why he robbed banks. His answer, at least according to the aforementioned legend, was, “Because that’s where the money is.”

When you think about it, Dillinger did have a point: it would be silly to go to all that effort and risk if there was no money there! However, Dillinger did not rob just every bank: he was actually somewhat picky. In particular, Dillinger did not rob banks that the police were actually watching. That’s not to say that he was never rudely interrupted as he went about his business, but, as a general rule, John Dillinger did try to avoid committing his crimes in front of the police.

Somehow, though, the police had no trouble figuring out that he was involved.

Recently, several employees at a particular technology company came to the CEO with concerns about the inappropriate behavior of a certain manager. After listening carefully to their concerns, the CEO then told them that they were obviously mistaken: he had never seen the behavior, so clearly it could never have happened.

We can but imagine just how much John Dillinger would have appreciated having this man in charge of the police!

“Sir, John Dillinger just robbed the bank.”

“Nonsense! I didn’t see it, so it couldn’t have happened.”

While this would have been great for Dillinger, perhaps it would not have been so great for everyone else. As a form of leadership, well, it might be considered a bit thin.

One of the less attractive parts of leadership is dealing with unpleasant situations and badly behaved employees. This often means dealing with a situation that is not well defined: some people are unhappy, and someone else is claiming that nothing at all is going on. As a leader, it’s often easier to just shrug and decide that it’s not your problem; as long as it doesn’t happen in front of you, then you can just ignore it. That, however, is not leadership.

As the leader, you are the model for how people in your department or your company will behave. What you do sets the tone: show people that it’s okay to ignore problems that you don’t want to deal with, and they’ll quickly learn to do the same: unhappy customer? Didn’t happen in front of me. Product defect? Didn’t happen in front of me.

The “didn’t happen in front of me’s” can be quite contagious. They’re easy to use and they make the difficulty go away, or at least become someone else’s problem.

So what can you do about it? After all, it can be difficult to figure out just what is really going on.

Start by asking questions. Not just any questions but particularly difficult questions, at least for a leader: genuine ones. It can be challenging to acknowledge how much we don’t know about a particular situation and ask the sorts of questions that show our ignorance. However, when we put our preconceptions aside and start asking about what people are actually experiencing, it’s amazing how much we can learn. MIT social psychologist Edgar Schein describes this process as humble inquiry. It involves taking the time to speak with people and enable them to become comfortable with you, and it involves being honestly curious about what they are doing even when it doesn’t matter. Building those connections is what enables information to flow upstream to you.

One of the most important lessons of leadership is that most things don’t happen in front of you. And, most leaders are very unhappy when they suddenly realize that things are happening in the company that they didn’t know about. Unpleasant situations are much easier to deal with when you’ve established the groundwork and shown genuine curiosity and interest. The question is not whether or not it’s happening in front of you, but what you are doing to make sure you’ll find out about it when it does happen. If you’re nervous, just remember, odds are extremely good that it won’t involve John Dillinger.

My Hovercraft is Full of Eels

Originally published in Corp! Magazine.

“Is the product done?” a certain manager asked during a product review meeting.

“It is done,” replied the engineer building the product.

“Are there any problems?”

“There are problems.”

“What is the problem?”

“It does not work.”

“Why doesn’t it work?”

“It is not done.”

I will spare you the transcription of the subsequent half hour of this not particularly funny comedy routine. The manager and the engineer managed to perform this little dance of talking past one another without ever seeming to realize just how ludicrous it sounded to everyone else in the room. It was rather like Monty Python’s classic Hungarian-English phrasebook sketch, in which translations in either direction are random. In other words, the Hungarian phrase, “I would like to buy a ticket,” might be translated to the English phrase, “My hovercraft is full of eels.”

It was extremely funny when Monty Python performed it. As for the manager and the engineer, well, perhaps they just didn’t have the comedic timing of Python’s John Cleese and Graham Chapman.

[SYSTEM-AD-LEFT]As it happens, “my hovercraft is full of eels” moments come about far too often. What was unusual in this situation is that it involved only two people. Usually, considerably more people take part. Thus, instead of a not particularly amusing exchange between two people, there is an extremely frustrating exchange involving several people. The most common failure to communicate is the game of telephone: as the message passes along the line, it becomes increasingly distorted.

What I hear from teams over and over is, “We are communicating! We send email to everyone.” This is where the hovercraft starts to fill with eels. Broadcasting is not really communicating: effective business communications require a certain amount of back and forth, questioning and explaining, before everyone is on the same page.

Who talks to whom? When you send out an email, do questions come back to you? Or do people on the team quietly ask one another to explain what you meant? While it’s comforting to believe that every missive we send out is so carefully crafted as to be completely unambiguous, very few of us write that well. Of that select few, even fewer can do it all the time. Particularly in the early stages of a project, if there are no questions, then there are certainly problems.

When someone else asks a question, either via email or in a meeting, does everyone wait for you to respond? Even worse, does Bob only jump into a thread if Fred jumps in first? Who is Bob responding to at that point, you or Fred? Are you still addressing the main topic or is the hovercraft starting to become eel infested?

It can be extremely frustrating to ask, “Are there any questions?” and receive either dead silence or questions about something trivial. It can easily become tempting to assume that there are no questions and just race full speed ahead. However, until employees figure out how much each person understands about the project and how you will respond to apparently dumb questions, they will be cautious about what they ask. Their curiosity is as much about one another and about you as it is about the project. How that curiosity gets satisfied determines whether you have productive conversations or a hovercraft that is full of eels. In the former case, you get strong employee engagement; in the latter case, you don’t.

If you’ve been working with a team for some months, or longer, and people are still not asking questions then there are really only two possibilities: either your team is composed of professional mind-readers or you are about to find a room full of those pesky eels. No project is ever perfectly defined from the beginning. Questions and debate should be ongoing throughout the development or production cycle. A lack of questions tells you that there is a lack of trust between the team members and between the team members and you. When trust is lacking, so is engagement.

Now some good news: remedying that lack of trust isn’t all that complicated. It does, however, require a certain amount of persistence and patience.

Start by highlighting each person’s role and contribution to the project. Why are they there? What makes them uniquely qualified to fill the role they are in? Be specific and detailed. If you can’t clearly define their roles, you can rest assured that they can’t either.  Questions come when people are clear about their roles. Disengagement comes when people are not clear about their roles.

Prime the pump with questions. Demonstrate that you don’t have all the answers and that you need the help of the team to find them. Give each person a chance to play the expert while you ask the dumb questions. When you set the tone, the others will follow. Communications start with the person in charge.

Separate producing answers from evaluating answers. Collect up the possibilities and take a break before you start examining them and making decisions about them. Brainstorming without evaluating allows ideas to build upon one another and apparently unworkable ideas to spark other ideas. Pausing to examine each potential answer as it comes up kills that process.

Encourage different forms of brainstorming: some people are very analytical, some are intuitive, some generate ideas by cracking jokes, others pace, and so on. Choose a venue where people are comfortable and only step in if the creative juices start to run dry or tempers start to get short. In either case, that means you need to take a break.  Intense discussions are fine, heated discussions not so much.

Initially, you will have to make all the decisions. That’s fine, but don’t get too comfortable with it. As trust and engagement build, the team will want to become more involved in the decision making process. Invite them in: that demonstration of trust will further build engagement and foster effective communications. Effective communications, in turn, builds trust and engagement.

Having a hovercraft full of eels isn’t the real problem. The real problem is what a hovercraft full of eels tells you about the trust, engagement, and communications in your company.