The Business Sensei

The Bi-Lingual Advantage in IT

Imagine a typical software solutions problem. The company needs to improve its bottom line revenue, the customers are complaining and want their problem solved yesterday. At best, the engineer sees a technical challenge involving algorithms and code. At worst, he sees an annoying interruption to solving interesting technical challenges. The engineer’s goal is to build a robust, elegant solution to a problem. The manager, on the other hand, sees something very different. His focus is not on the technology but the process of assembling and coordinating a team. Who has the right skills? What skills are needed? What will this cost? How quickly can it be done? The manager’s goal is to give the customer what they really want, even if that is not the most elegant solution.

Dilbert highlights, to great effect, the gap between management and engineering. Frequently, the two groups seem to live in different worlds. More significantly, they often appear to work for completely separate companies with totally contradictory agendas. Sadly, there is some truth to this. Ed Schein, professor emeritus of business psychology at MIT Sloan, points out, managers and engineers form two distinct, separate organizational subcultures. Each group has very specific goals, which may not always be in alignment. Unfortunately, since both groups are working for the same company, and apparently speaking the same language, they tend to assume that they have the same image in mind. As many managers and engineers have discovered, this can lead to more than a little friction.

Read the rest at Enterprise Management Quarterly

The Aardvark Principle

In any business, information can be thought of as the organizational equivalent of nerve impulses. Information about the state of the company, the state of the economy, the marketplace, how different parts of the company are functioning, and so forth, is critical to effective decision making. If any aspect of information flow is interrupted, it is like losing sensation in a part of your body: unable to feel, you may suffer serious injury without realizing it; if the nerves are unable to innervate muscles, those muscles will atrophy and not perform when called upon. By the same token, a business failing to receive crucial information about the state of the market can suffer financial disaster when products don’t sell or when innovation and productivity are crippled.

The problem with information flow is that people may not agree on the information, on the meaning of the information, or what should be done with or about the information. Disagreement leads, in turn, to argument or intra-organizational conflict.

Read the rest at AffluentMagazine.com

Right To Midnight

“Left or right?”

“Right to Midnight.”

I had this conversation recently with my 3.5 year old son. We were in the car, and he had just dropped his favorite stuffed animal, a black cat named Midnight. He couldn’t reach it, and I was feeling around trying to find it for him, while he kept telling me I was near Midnight. When I finally tried asking him if I should move my hand left or right, his response was that I should move my hand, “right to Midnight.”

Now the fact is, a 3.5 year old doesn’t really understand that I don’t know what he knows: after all, he can see my hand and the cat, therefore I should know which way to move. This sort of thing is not at all unusual with young children. For the most part, it’s generally pretty funny.

It’s much less funny when senior management is in the role of the 3.5 year old, and the employees or customers are trying to figure out what is going on. Young children haven’t yet learned to consider other perspectives; management, on the other hand, doesn’t have that excuse.

Many people are familiar with companies that put out products with incomprehensible interfaces or unreadable documentation, and then become highly irate when the customers complain that they can’t figure out how to use the product. I worked with one high tech company where the CEO and engineering team routinely described their customers, primarily research scientists, as a bunch of incompetent idiots. They simply could not understand why their customers could not understand how to use the product. After all, the CEO and the engineers understood it.

Fortunately, very few people are going to argue that a company needs to get input from its customers and involve them in the design process. After all, that’s the best way to make sure you’re giving them something that they’ll be happy to spend money on. The real problem arises when the company’s internal communications are lacking. It is, sadly, not at all unusual for management and engineering, or engineering and sales, or any other combination of departments to be talking past each other. The groups are nominally all working for the same company, but none are capable of recognizing that the others don’t know what they know or cannot imagine that different groups within the company have different, equally valid, priorities.

Engineers, for example, are most concerned with building elegant, effective solutions to problems. Salesmen want to sell product. Documentation wants to describe what the product does. Customer support wants to help the customer actually use the product. Managers are trying to meet deadlines and generate revenue for the company. It would seem that everyone is on the same page. The reality, though, is far different. The engineer’s elegant solution may be brilliant, but impractical: for example the engineer who suggested driving bolts into the side of my house to hold up a sunshade for an afternoon. While that would have solved the immediate problem, it was just a bit of overkill and could easily have caused other problems down the road. Salesmen may promise features that engineering can’t implement or management, in an effort to close a deal, might set overly aggressive deadlines. A case in point occurred in one company I dealt with, when the CEO turned to the VP of Engineering and asked when the product would be ready to ship.

“September 1^st,” said the VP.

The CEO turned back to the phone and said, “We’ll have it for you on July 15^th.”

The CEO simply could not understand why engineering couldn’t have the product done by July 15^th, and the VP of Engineering simply could not understand why the CEO couldn’t accept September 1^st. The net result was that the product ended up shipping on October 1^st, delayed by a constant series of unmeetable deadlines.

When I’m telling this story, someone always says to me that the two people simply needed to communicate better. True, but not very useful. If it were simple, they would have done it. Under the pressure to get a product out the door, each one forgot to stop and get the full picture. Their frames of reference narrowed to the point where they could not imagine any other answer than the one they had locked onto. Whether two people or ten people are involved, it’s important to stop and ask four critical questions:

1.      What do I know that they do not know?

2.      What do they know that I do not know?

3.      Do I actually have enough information to make a decision?

4.      Are we really all on the same page?

Taking the other person’s perspective can pay off in a big way. What’s stopping you?

Yankee Swap Rorschach

The holidays are the season for Yankee Swaps. Now, a Yankee Swap would seem to be a fairly simple and straightforward activity: each person either chooses a wrapped gift or steals an opened gift from someone else. This latter activity can, of course, trigger a chain reaction, but that’s part of the fun. At the end, everyone feels like they had at least some measure of control over the outcome. One would think it difficult, if not impossible, to mess up a Yankee Swap.

However, all things are possible. In this case, one company held a Yankee Swap with incredibly detailed and complicated rules which had as its most salient feature that no gifts were opened until the very end. In other words, the experience was transformed into the equivalent of a very slow grab bag: a long, frustrating, totally random process at the end of which people felt that they had no control over the outcome. Ironically, the most common complaint from employees at this company is that many of the rules are complex, time consuming, and leave them feeling like they have very little control over how they get their work done.

Now, a Yankee Swap is a pretty insignificant event, little more than an amusing party game. However, how a business goes about designing a small process says a lot about how it goes about designing larger, more significant processes: process design is strongly influenced by institutional habits and beliefs. With a small process, it’s easy to see the results of that belief in action because the entire event can be seen at one time; with larger processes, cause and effect may be separated by weeks or months, and the process is often so big that no one ever views it as a whole. The company ends up wondering why their results are poor, but can’t figure out the reasons. Those small processes can provide valuable insights into the company’s methodology and assumptions; recognizing consistent causes of small problems can enable you to avoid large ones. Ultimately, more important than improving one process is improving how the company designs all its processes.

In designing a process, it helps to clearly understand what you are trying to accomplish. Why did this particular company choose to redesign the Yankee Swap? Was there an actual problem that someone was trying to solve? Clearly, someone felt a need to come up with something, although their motives are impossible to fathom. As a result, they got a process that rather missed the point, but did end up reflective of the organization as a whole. However, it’s generally more successful to focus on results:

·        Clearly define the objective. If the objective is to solve a problem, take the time to look at the symptoms and consider what they mean. When do they come up? Under what circumstances? Remember, the symptoms are not the problem, they’re just the symptoms. Generate a list of hypotheses and then test them to see if they lead to the observed symptoms. Solving the wrong problem will generally make things worse, not better.

·        Describe what a successful outcome will look like. What will have changed? What behaviors will be different? Make this concrete. If success is, “people will have more fun,” how will you know? If the picture isn’t clear, identify the questions you need to answer to bring clarity. This may be an iterative process.

·        Identify what you can change and what you can’t. You probably can’t change the economy, but you can change how you deal with it. Tom Watson Sr., founder of IBM, used the Great Depression as an opportunity to build up a highly trained, extremely loyal workforce and a stockpile of equipment. When WWII started, IBM was in an excellent position to capitalize on the reawakening economy. If everything falls into the “can’t change” category, you need to revisit your goal or problem formulation.

·        Brainstorm possible solutions or approaches. Record ideas and do not evaluate any of them until you have a significant number of possibilities. Don’t worry if some ideas are silly or off-the-wall: innovative solutions come from the most unlikely sources.

·        Will your solutions really get you where you want to go? Do research. Don’t rely on opinion and conjecture.

·        Define your action steps.

·        Execute and evaluate. Did it work? If not, check your problem formulation and try again.

If you’re not getting the results you want, what steps are you missing?

Why Teams Fail

In today’s high-tech workplace, it is virtually impossible to not be part of a team. Projects are too big, too complex, too involved for a single person to do it all. Yet far too often people find teamwork to be frustrating and exhausting. Even when the team successfully ships a product, team members often feel burned out, frustrated, or surprisingly unhappy with their accomplishment.

Many managers have heard of the four stages of team development: Forming, Storming, Norming, and Performing. What is not as well known is the importance of that early, forming stage. During this phase, team members determine whether or not they feel emotionally and intellectually safe working with one another; they develop a sense of group identity, or remain a collection of individuals.

There’s an old saying that a couple isn’t really married until they’ve had their first fight. The same is true of teams. Part of working together involves arguing with coworkers: put any group of people together, and they are bound to have their own approaches and solutions to problems. If team members feel unable or unwilling to argue with one another, they avoid any conflict. If they are forced to argue but haven’t developed effective means for conflict management, the argument can quickly turn personal. In either case, the exchange of thoughts and ideas is blocked, anger builds, tension mounts, and the ability of team members to work together is severely compromised. Instead of developing group identity, team members may become convinced that their best strategy is maximizing personal gain instead of team performance.

The problems are exacerbated when the leader’s expertise is not management but engineering. There is a persistent, and ultimately painful, myth that engineers will only respect another engineer. Unfortunately, the very personality traits and skills that make someone a good engineer are often exactly the wrong skills to be a good manager. A team leader needs to have the social skills and empathy to manage the evolving dynamics of his team, and the interpersonal knowledge to apply those skills.

Of those people who do possess both sets of skills, even fewer can do both simultaneously. A good manager spends his time building the team. If he’s busy writing code, designing circuits, or what have you, then he’s not building the team. If he’s like most people thrust into a new situation and tasked with doing something he’s really good at, and something he’s not good at, he’ll gravitate toward the former.

Another problem faced by team leaders is that the storming phase can get, well, pretty stormy. The focus of that storm is often the leader. If the leader feels attacked, she’s likely to respond accordingly. This is a perfectly natural reaction. It’s also counterproductive. Managing conflict effectively means not getting enmeshed in the conflict in the first place: team progress can be set back weeks, months, or longer. Once conflict is joined, replacing the leader may improve things in the short-term, but can often make things worse long-term. The fundamental team dynamic needs to be repaired.

Unfortunately, more than half the teams in businesses become stuck in conflict or avoidance. When a team becomes stuck, it is stressful and exhausting to the team members. The company pays for this in lower productivity, reduced product quality, increased illness and absenteeism, and higher staff turnover, all of which can be fatal to a business.