My Hovercraft is Full of Eels

As 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.

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.

Using the Force: What Every Exec Can Learn from Darth Vader

As published in the Worcester Business Journal

My 6-year-old son is seriously into Star Wars. As we were watching the movies recently, he turned to me and asked, “Why is Darth Vader such a mean leader?”

Coming from a kid who thinks the Sith are kind of cool, the question took me by surprise. On the other hand, it’s rather heartening to see that even a small child can recognize bad management. Of course, the real question is not what makes Darth Vader such a bad leader. After all, when you’re the Dark Lord of the Sith, you don’t really need a reason. More aptly, the question is: What does it take to be a good leader?

No Intimidation

First, we have to dispense with the primary weapon of the Sith: fear. Darth Vader rules through terror, but the fact is, you don’t need to have the power to choke people to death using the Force to create a climate of fear. Fear is very effective at getting people to move away from something. In the practice of Jujitsu, fear of injury is often quite sufficient to convince an attacker to dive headfirst into the ground or into the nearest wall. Some mistakes are a natural part of doing business. When people are shamed for making mistakes or threatened with loss of their jobs if they don’t measure up, they become less creative, less dedicated and errors are not corrected.

Team Spirit

To be a positive leader, the first step you need to take is to focus on affiliation. You might also think of it as team spirit. When people come together to form a team, the first thing they do is look for common ground. To really create affiliation, the leader needs to actively get to know his team members and encourage them to get to know one another.

Independence

Next is building autonomy. Perhaps counter-intuitively, autonomy is the result of having structure. Structure lets each team member know what the others are doing well enough to trust them when they aren’t visible. That trust is what permits autonomy.

Lack of structure is chaos. Too much structure is stifling. For example, when an employee comes up with a good idea and your response is to ignore them, that is too little structure. When you say, “Good idea! Here’s how we can make it better!” that’s too much structure. Appropriate structure is to say, “Great idea! How did you come up with it?”

Great Expectations

Competence is not just hiring competent people. It’s creating an atmosphere of competence. Nothing succeeds like the expectation of success.

Managers can motivate employees in one of two ways: you can focus on failures, and make dire predictions about what will happen if employees screw up; or you can focus on success, and remind the employee of the things they did well.

The keys to great leadership are: get away from fear, build affiliation, create structure to enable autonomy, and craft an atmosphere of competence.

The hard part is finding the right balance for your team and your company. Start slowly and let yourself accelerate as you learn to use these techniques effectively. You’ll soon be amazed at how fast you’re going.

Death of a Thousand Knives

As published in Corp! Magazine

Very few companies are ever driven out of business by their competitors.

I’ve found that this statement upsets a great many people, all of whom are quick to jump up and start providing examples of companies that were, in fact, driven out of business by their competitors. This is missing the point. Indeed, it’s rather like a detective in a murder mystery concluding that the cause of death was that the victim’s heart stopped. It matters whether the heart stopped due to lead poisoning, for example in the form of a bullet, or due to some other cause. Indeed, understanding exactly what led to that heart stopping moment is a key part of solving the mystery.

Similarly, while it’s not so unusual for a failing company to have the coup de grace administered by a competitor, how they got to that point makes all the difference. Focusing only on the end point provides a very simple, comfortable solution, but not necessarily a particularly useful one.

Robotic Chromosomes, for example, was a company that dominated a particular niche in the bioinformatics market. They were an early entrant into the field and their products were initially the best on the market.

Over the course of several years, though, they developed a view of their clients as idiots. The fact that their clients were all highly educated research scientists did not enter into the equation. If they had trouble using the software, they were idiots. As a result, the company became increasingly less open to feedback from either clients or the market. While their market share was increasing faster than the market itself, they could get away with that attitude. Eventually, though, their growth started lagging the growth in the market. Phrases like “law of large numbers” and “temporary aberration” were batted about. When their market share started shrinking, phrases like, “temporary aberration” became even more popular. The view of the clients as insanely stupid for buying competing products became more common.

Today, they no longer exist. Were they driven out of business by their competitors? Only in the sense that they put themselves in a position to allow their competitors to drive them out of their dominant position in the market. Sure, their competitors may have pushed them over the cliff, but they were the ones who chose to walk to the edge and lean over.

Now, it may reasonably appear from the preceding description that Robotic Chromosomes was taken down by a clearly defined event, that is, viewing clients as idiots. That is not, however, quite correct. While it may appear that way in retrospect, the reality is that Robotic Chromosomes suffered from a series of cascading errors. Each mistake was small, easily overlooked or ignored. Each mistake led to more mistakes until eventually the company was suffering from so many small cuts that it eventually had no strength left to resist when its competitors moved in. So how does a company avoid this death of a thousand knives?

The obvious answer is that they needed better communications. While true, it again misses the point. Communications is where problems show up, but the communications are rarely the problem. Rather, the dysfunctional communications are the symptom of the problem. It’s critical to look beyond the symptoms to identify the real problem. Otherwise, you spend all your time looking at the wrong things, as Robotic Chromosomes so eloquently demonstrated.

Avoiding that fate requires a willingness to accept negative feedback; it means being willing to hear what people are saying about your product, your service or your management style. If you aren’t willing to listen, or if you structure the way in which you listen to negate the feedback, you’re setting yourself up for failure, one step at a time. For example, creating a culture that mocks and demeans your clients is not a recipe for success, and closes you off from valuable feedback from those clients.

Being willing to accept feedback is only a first step though. You have to create a context in which employees are not afraid to give you that feedback, and in which they believe that providing feedback is worthwhile. If people believe they’ll be punished for being critical or regarded as “not a team player,” it’ll be hard to get them to provide feedback.

Next, you need to clearly define your goals and also define how you’ll know whether you’re succeeding or failing. Robotic Chromosomes had very fluid definitions of success, definitions that shifted regularly to avoid facing unpleasant results. It’s important to separate the evaluation of the feedback you’re getting from the testing to see if the criteria for that evaluation are valid. In fact, verifying the validity of your criteria should be done before you then evaluate your feedback: otherwise, it’s too easy to redefine success and give yourself a few more cuts. None of them seem all that bad at the time.

Step by step, over the course of several years, Robotic Chromosomes successfully created an environment where any negative feedback could be ignored because that feedback was always coming from idiots. Their competitors didn’t drive them out of business. They drove themselves out of business; their competitors simply put them out of their misery. How will you avoid the death of a thousand knives?

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead (www.7stepsahead.com), an organizational development firm focused on helping leaders grow their businesses. Steve is the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill, and a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” Contact him at steve@7stepsahead.com.

The Accidental Leader

As published in Corp! Magazine

Does this sound painfully familiar?

The team leader left the company or was transferred elsewhere. No one knows anything about the new person coming in. Everything is up in the air. It’s almost impossible to get any work done because everyone is too busy wondering what’s going to happen next. Is the team going to be kept together? Will the project be cancelled?

Or how about this situation:

You were just assigned to take over a strong team. The former leader, well-respected by the team, is leaving. When you get there, there is a marked lack of enthusiasm. Everyone smiles and nods, but the suspicion is palpable. No sooner do the first words leave your mouth when you have a sinking feeling that whatever it was you said, it was exactly the wrong thing.

Although it may seem that the difference is which side of story you happen to be on, in reality, the situations aren’t really any different at all. In both cases a once functional team is tossed into a state of chaotic uncertainty. From feeling comfortable and secure, suddenly everyone is wondering if there’s another shoe about to drop.

Oddly enough, when the new leader comes in, the situation often gets worse. Rather than allaying people’s fears, too often those fears are increased. It’s not that the new leader is trying to scare people; it’s just that whatever she says, it just doesn’t seem to come out quite right.

At one company, the new executive director was welcomed with great fanfare. Thus, she was totally unprepared when her modest proposals to improve how the company delivered products ignited a firestorm of protest and resistance. This was a very painful situation, although I was able to help them work things out in the end. Still, though, perhaps we might want to look at a more upbeat scenario.

At another company, the new president decided to try something different. When he took over, he didn’t tell people how things would be; rather, he asked them how things should be. Rather than set deadlines, he asked employees what deadline the previous, successful president would have set for their projects. Rather than set new rules, or even focus on existing rules, he asked people what sort of structure would most help them. Rather than try to Impose His Mark on the organization, he took the time to understand what mark was already there. Rather than fight the natural resistance people have to change, he invited the rest of the company into the change process. The transition ended up going remarkably well. What was even more interesting was that along the way he took a fair bit of heat from his board that he was not “acting like a leader.”

He ended up being one of the best leaders the company ever had. Despite initial beliefs to the contrary, it was no accident. By now, you might even recognize the company.

Most leaders respond to a chaotic situation by trying to impose order. This isn’t necessarily a bad idea, at least in theory. Chaotic situations are unpleasant and without some sort of structure, nothing is going to get done. Despite this, when order is imposed too rapidly, suddenly everyone is fighting for chaos.

The secret to taking over a new team, indeed, to dealing with any team or company in a chaotic situation, is to move slowly. Speed comes from being in the right place at the right time, not from rushing to get things done. When you take the time to find the most serious pain points, the places where people are most scared or most upset, and you resolve those situations, you build the trust you need to succeed.

How do you find those points? Ask the team. Involve them in the process. Don’t impose order; rather, create order.

Are people concerned about deadlines and how changes in product schedules might impact them? Invite them to help set the deadlines. Is product quality an issue? At one training company, the fear was that the changes would compromise the quality of the training being offered, which would, in turn, drive away clients. The solution was to stop fighting about it and instead identify the metrics currently being used to determine quality: both the official ones and the ones that staff members used privately. Once those metrics were brought to everyone’s attention, then the new CEO could help the staff members see how the new training would actually surpass the old training. Sounds simple, but the experience was anything but!

You impose order when you walk into the situation and tell everyone what to do. You create order when you find points of maximum leverage and invite people to suggest the order they want you to provide. The second may be slower, but, paradoxically, it gets you to where you want to go a lot sooner. How will you create order in your organization?

I Don’t Believe It!

Recently, I was running a leadership and negotiation exercise, which involved participants attempting to determine who they could and could not trust. The exercise required that participants work with one another and included various techniques for verifying the truth or falsehood of someone’s claims.

The dynamic between two of the participants, we’ll call them Fred and Barney, became extremely interesting: Fred needed Barney’s help, but Fred was convinced that Barney was lying to him and looking for a way to double-cross him on a business deal. Barney, meanwhile, was going to great lengths to prove that he was telling the truth and dealing in good faith. The more evidence Fred found that demonstrated Barney was telling the truth, the more Fred was sure he was lying. Not only was Fred not convinced, he even came up to me and complained that he thought that Barney was violating the rules of the exercise because he was clearly lying. When the exercise was over and I debriefed the participants, Fred was stunned when he found out that Barney was telling the truth all along.

Part of the value of this particular exercise is that behavior in the exercise tends to correlate well with behavior in the office. Unlike the exercise, however, in real life we don’t have any magical means of verifying the truth. Of course, as we can see, even that doesn’t necessarily matter. Once an opinion is formed, sometimes nothing will change it. That may be fine in some obscure situations, but in business it can get you in trouble.

Read the rest at Corp! Magazine

I Told You: 360-Degree Feedback Done Right

“We were thinking of doing a 360-degree feedback to help him understand what other people think.”

This very frustrated comment was made to me recently regarding efforts to explain to a very senior manager that his style of leadership wasn’t working for his team. At that point, all efforts to convince him to change were foundering on the manager’s simple perception that things were working just fine.

Such being the case, it’s hard to imagine how a 360 can help. Sure, he might find that his subordinates don’t like him very much, but he might also feel that his job isn’t to be liked, but to get people to perform.

Read the rest at LabManager Magazine.

Growing Wheat in Siberia

This one was just published in the CEO Refresher. The link is only good for month, so the text is below:

Once upon a time, the late and unlamented Soviet Union decided to grow wheat in Siberia. Their logic was simple: by growing wheat in the inhospitable conditions of Siberia, the wheat would become stronger. The wheat, however, was indifferent to Soviet philosophy. Despite speeches, threats, and promises from the government, the wheat stubbornly refused to grow.

In 1990s, a group of Nobel Prize winning economists developed some very interesting theories about how the financial markets should work. Their theories were brilliant and attracted billions in investment dollars into the hedge fund they created. Long-term Capital Management almost took down the entire US economy when it collapsed in the summer of 1998.

In both cases, a belief about how the world should work was trumped by the way the world does work.

To bring this a little closer to home, I worked with one high technology company that decided to create a set of coding standards for its software development team. While not an unusual occurrence in software companies, in this case, the manager in charge wrote up a fifty (that’s right, 50) page standards document. Naturally, everyone was overjoyed and memorized everything; at least, that’s what the manager thought. In fact, no one read more than a page or two and most of the engineers ignored even that.

Another company was trying to manage information: design decisions, notes from discussions, and so forth. They had the very good idea that they could manage all their accumulated wisdom as a Wiki. Unfortunately, the Wiki swiftly ballooned into an unmanageable morass of data in which no one could actually find anything useful. The problem wasn’t so much getting people to remember to update the Wiki; it was organizing the information in a manner useful to everyone who needed to use it, and in convincing people to take the time to keep it organized. Indeed, even agreeing on how it should be organized generated controversy and bad feeling.

In both of these cases, beliefs about how people should do their work were trumped by the way people actually do work. Like Soviet wheat, it can be remarkably difficult to motivate or threaten people into doing something that they really do not want to do. Unlike wheat, people can be forced. It’s merely a question of how much time and energy you want to spend: pushing people takes a great deal of effort and tends to result in significant amounts of anger and frustration for all parties involved. Not, in other words, a conducive atmosphere for creating a strong, collaborative team.

Of course, sometimes it is necessary to have people do things they don’t want to do. Code does need to be commented, information needs to be documented, and so forth. Fortunately, unlike wheat, people can be convinced. Instead of pushing them, the key is to get them to pull: the best teams are the ones that know where they should go and will trample anyone who gets in their way. How do you create such a team? Here are some tips:

  • Involve those who will be affected by the outcome in the process of solving the problem. Nothing gets buy-in like giving people the opportunity to develop the solution.
  • Identify the actual problem. Spend some time brainstorming; make sure you know what you’re trying to accomplish. The company with the 50 page style guide needed code that could be maintained over time and easily read by someone other than the writer, and they needed the process to not interfere with actually getting work done. That can be accomplished with a one page style guide. Instead, they were trying to win the World’s Most Beautiful Code Contest. That may be prestigious in certain obscure circles, but it doesn’t sell product. The customers only care that the software works.
  • Ask yourself how you’ll know when you have a workable solution. This may seem counter-intuitive since you don’t have a solution yet, but it helps to figure out what success looks like. That way, you’ll know it when you get there and you’ll be better able to recognize if you’re going off course.
  • Brainstorm possible solutions. Don’t be afraid to come up with wacky ideas.
  • Do not evaluate any solution until the end of the brainstorming process. Off-the-wall ideas frequently trigger creative solutions.
  • For each solution, ask yourself if it will actually get you to the outcome you want. Focus on the idea, not the person who came up with it. Even Nobel Prize winning economists can make mistakes.
    • Take the time to honestly assess what might go wrong.
    • Recognize that “oh, we’ll figure that out later,” is often a warning of trouble ahead. Make sure there is either a way past potential roadblocks or that you have identified the work you’ll need to do to determine how you’ll know if there’s a way.
  • Test your solution before you commit to it, or at least look for examples of similar solutions being successfully implemented. Why learn from your own mistakes when you have the opportunity to learn from someone else’s mistakes? The latter is a lot cheaper.
  • If more than one solution has survived to this point, pick one and implement it. Be willing to abandon it and pick another if it becomes obvious that it won’t work. You can’t foresee everything that can go wrong. Solutions that looked good from a distance sometimes turn out to be unworkable or too expensive when you get closer.
  • Be willing to reformulate the problem if the solution doesn’t work.
  • Give people as much autonomy as possible in implementing the solution. When possible, allow them to develop their own implementations. The company with the Wiki could have used email and encouraged each person to maintain their own records in whatever form was most individually useful. Instead of trying to figure out how to maintain a central repository, perhaps what they should have done was to present different ways of organizing the information and allow each person to pick the one most useful to them.

This may seem like a lot of steps, and there certainly is effort involved. The Soviet Union decided it was easier to yell at the wheat. Given the amount of wheat they imported, it’s clear which method is cheaper in the long run.

Good luck!

Leadership and team formation

Ever wondered why some teams are a pleasure to work for and others are a royal pain? You can find out on my live radio interview on Leadership and Team Formation.

You can also read a discussion of the show here.

Slip Slidin’ Away

Here’s one just published in the CEO Refresher:

“You know the nearer your destination
The more you’re slip slidin’ away”

— Paul Simon

Some twenty years ago, I had a rather odd experience while working for a Silicon Valley software company. As we came closer and closer to shipping the product, more and more problems would crop up. Not problems with the software, as one might expect, but interpersonal problems. There was an increase in argument, bad feeling, and ineffective conflict at exactly the point where it would seem the most likely and logical that people would be feeling the greatest sense of unity and triumph. I experienced the same phenomenon at other companies, both in and out of high tech. In more than one instance, the team would successfully snatch defeat from the very jaws of victory.

In each of these situations the problem was simple; unfortunately, the solution was not. The team in each circumstance had never truly learned to work together, to handle disagreement, or to tolerate variations in working style. The only thing the team had ever agreed upon was the necessity of getting the product out by a certain time. The strength of that agreement was enough to forge sufficient common ground for the team to work together. Unfortunately, as the project drew nearer and nearer to completion, the glue holding the team together became weaker and weaker. Would the team hold together? Would everyone start fighting again? Would people leave the company? After all, working with people you don’t always agree with is often easier than working with complete strangers: as the old saying goes, better the devil you know than the devil you don’t. Ironically, then, people would engage in the very behaviors they were most afraid of in order to delay the completion of the project and keep the team intact.

Sounds ridiculous, does it not? Why would trained professionals make such a mistake? Managers and CEOs tell me over and over that this would never happen in their teams. In a couple of cases, they’ve said this even as it was happening around them. Wishful thinking is not a good strategy.

The great benefit of teams is that they provide a variety of skills and perspectives. The great weakness of teams is that they provide a variety of skills and perspectives. In order to reap the benefits of having a team, the members of the team need to learn to work together. This involves more than just agreeing on a set of goals, especially since agreement on goals is difficult to get when team members cannot even agree on how to work together.

The solution is to recognize the importance of the early days of the team’s existence. How many professional sports teams go into competition with a team that’s just been assembled? Very few. Of those few, how many win? Even fewer. Basketball fans might well remember the Olympic Dream Team of a few years ago: some of the best basketball players in the United States all playing on the same team. While they were certainly competent, they did not demonstrate the level of brilliant basketball everyone expected: despite their individual excellence, they never really came together as a team.

In business, the only difference from the sports world is the belief that a team can be assembled and instantly jump to performing at a high level. It simply does not work, no matter how much we may want it to. A team in this situation is particularly vulnerable to cracking under stress at exactly the moment when it most needs to be working together.

So what can the manager or the leader do to build a strong team?

Start by fostering common ground and appreciation of one another amongst the team members. What’s the vision of the company? What are you trying to accomplish? Get everyone excited by the outcome you’re after and help each person understand how they and their colleagues fit into bringing that outcome to fruition. If you can’t figure out how each person fits in, then perhaps your project is insufficiently well defined or your team is too big.

Create as much freedom for people to work according to their own styles. Think in terms of mechanisms that permit maximum autonomy while still enabling the team to communicate and be aware of one another’s progress and needs. Allow for autonomy to increase as the team gets better at working together. Encourage the use of email as much as possible, minimize meetings, and have clear checkpoints where you can easily monitor progress.

Approach problems with the attitude of “evaluate and adjust” not “judge and punish.” There will be false starts and mistakes made, especially in an early version of the product. If people are afraid to be wrong or make mistakes, they will also be less willing to advance different ideas or experiment with novel solutions. Set aside time for brainstorming.

What roles do the members of the team take on? Are those roles truly taking advantage of each person’s skills? As the project advances, are you prepared for roles to change or for team members to take on different roles in the project? Frequently, the roles people start with are not the best ones for them; being able to change as the project develops helps build team cohesion and increases productivity.

How do you recognize status? Everyone on the team is good at something; otherwise, why did you hire them? It pays to find ways of building up the status of your team members and developing the strengths each person brings to the table. The more each person can demonstrate their competence and apply their expertise, the more motivated they will be and the stronger your team will become.

What’s happening when you get nearer your destination?

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