The Business Sensei

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.

Of Deck Chairs and Ocean Liners

As published in The CEO Refresher

“Just give me the numbers!”

Falling firmly into the “I just can’t make this stuff up” category, the preceding statement was made by the head of a certain engineering department. He wanted the performance figures on a series of database lookups so that he could determine if the database code was performing up to specifications. This would be a perfectly reasonable request except for one minor problem: the database code was not producing the correct results in the first place. Performance was sort of irrelevant given that getting the wrong answers quickly is not necessarily all that helpful, although it may be less irritating than having to wait for the wrong answers. It’s rather like driving at 75mph when lost: you may not know where you are or where you are going, but at least you’ll get there quickly. Or something.

In another example, the engineers developing a bioinformatics data analysis package spent all their time arguing about the correct way to set up the GUI elements on each page. The problem was that when they actually ran one of the calculations, the program appeared to hang. In fact, I was assured by everyone, it just “took a long time to run.” How long? The answer was, “maybe a few weeks.”

This may come as a shock to those few people who have never used a PC, but a few weeks is generally longer than either a PC or a Mac will run before crashing. Besides, the complete lack of response from the program regularly convinced users that the program had crashed. The engineers did not want to put in some visual indicator of progress because they felt it wouldn’t look good visually. They refused to remove that calculation from the product because “someone might want to try it.” Eventually, they grudgingly agreed to warn the user that it “might take a very long time to run.”

In both of these cases, the team was solving the wrong problem. Although there were definitely complaints about the speed of the database, that was very much a secondary issue so long as the database wasn’t producing correct results. And while the user interface decisions were certainly important, designing an elegant interface for a feature that will convince the user that the product is not working is not particularly useful. At least rearranging the deck chairs on the Titanic was only a waste of time. It didn’t contribute to the ship sinking.

The element that made each of these situations noteworthy is that in both cases there were people present pointing out that the wrong problems were getting all the attention. The people making the decisions didn’t want to hear that. They wanted to solve a certain set of problems and, by golly, they were going to solve them! This is a version of the Hammer syndrome: when all you have is a hammer, everything looks like a nail. Sometimes, though, that nail turns out to be a thumbnail.

So why were these teams so insistent upon solving the wrong problems? Fundamentally, because they could. Simply put, if you give someone a problem they can solve comfortably, and one that they have no idea how to approach, they will do the former. In addition, they had never established clear metrics for success, never established standards by which they would know if the database was fast enough or the user interface was good enough. As a result, they built their goals and evaluated their performance around those issues. They were not being evaluated on whether they got the right answer, despite the opinions that the customers might have in that regard.

While clear, specific goals are certainly good things, goals also have to make sense. When a company is constantly seeing flaws in its products, it can be a very valuable exercise to look at the goals assigned to each person and each team in the company. Do those goals make sense? What problems or challenges are they addressing? Are the goals complementary, or are there significant gaps? If the engineering team is being evaluated on how many bugs they can fix and the QA team on how many new bugs they can find, what happens to the step where fixed bugs get verified? If no one is responsible for that happening, it won’t get done (and didn’t, in several software companies!). If the team focuses on the wrong problems, they’ll spend their time fighting symptoms or revisiting solved problems, and never deal with the real issues.

Therefore, even before you can set goals, you have to know what the problem is that you are trying to solve. That means first separating the symptoms of the problem from the problem itself. The symptoms are only symptoms; frequently, they can point to many possible problems. It’s important to look at the symptoms and brainstorm which problems they could be indicating. When you start developing solutions, you then need to ask what the final product will look like if you go ahead with your solution and you need to know what success looks like. Make sure that your proposed solution will actually solve at least some of the potential problems you’ve identified, and develop some way of testing to make sure you are solving the correct problem. In other words, have some checkpoints along the way so you can make sure that you’re actually improving things. Only then can you start to set goals that will effectively guide you to producing a quality product.

What are you doing to make sure that you are not rearranging deck chairs on the Titanic?

Smell Test

As published in Corp! Magazine

The door opens onto a room filled with equipment: banks of computers, spectrometers, air and tissue samplers and things that you cannot even recognize. The hum of electronics fills the room and there is a definite odor of fish. As you look around, you can see dozens of fish waiting to be analyzed for oil contamination. The purpose of all this machinery is to determine if seafood is safe to eat after the Gulf oil spill.

Sounds like something out of a science-fiction movie. That’s because it is something out of a movie: reality is not nearly so visually impressive. It turns out that the most sophisticated instrument for determining the safety of seafood is the trained human nose. With remarkably little training, the human nose can do something that all the expensive and elaborate electronic equipment cannot do: figure out whether a fish is contaminated or not.

About 20 years ago, a Japanese business decided to conduct a thorough chemical analysis of fine wine. They used sophisticated equipment and complex computer analysis to determine the chemical composition of the perfect bottle of wine. They then produced a wine that perfectly matched their profile.

In the ensuing blind test, tasters had no trouble recognizing the Japanese wine: it was universally described as “having the taste of dishwater and a bouquet of dirt.”

Once again the human nose proved superior to all the fancy equipment that was brought to bear on the question.

When speaking to a group of managers, I asked them to describe their company’s goals. The response was a rather confusing medley of Gantt Charts, Microsoft Project, comments on the latest decision support software and so forth. What was their approach to management? Once again, the same cacophonous medley ensued.

Fish, wine and management have a couple of things in common.

First and foremost, all those fancy tools and gadgets are tools, nothing more. There is nothing inherently special about them, any more than there is anything inherently special about a hammer. In the hands of a master craftsman, a hammer can be a very useful and versatile tool; in the hands of someone without that skill, a hammer is little more than a device for making sure that every problem looks like a nail.

By the same token, the value of management support software, or whatever other power tools are being used, is only as great as the skill of the manager using it. Tools leverage skill; if there is no skill, there is no leverage. There is also a strong possibility of cutting yourself off at the knees: power tools can be dangerous. In other words, all the management support tools in the world won’t help someone who doesn’t know how to manage. More to the point, just as a trained human nose is the best tool for detecting contaminated fish, the best leaders and managers are those who have actually learned how to lead and manage.

From a very practical perspective, the best leaders are those who can connect with their followers. It’s not about Gantt charts or other fancy tools. It’s about building trust and enabling people to feel that they can count on you.

Wait, isn’t that backwards? Doesn’t the leader need to be able to count on his followers? Sure. And the way you get there is by demonstrating that they can count on you, that they can trust you.

In a sadly familiar tale, at Soak Systems, no trust exists between different departments, between marketing and engineering, between engineering and the CEO. Why is there a lack of trust? The CEO constantly visits clients and makes promises that engineering can’t possibly fulfill. Even worse, he regularly changes direction and priorities: one day project X is vital to the future of the company, even when it fails to ship on time or when it ships and doesn’t work. The next day, it’s project Y. Each prediction of impending doom is followed by another prediction of impending doom if the project doesn’t work.

At this point, no one believes the CEO. No matter how important or unimportant his pronouncements, they are all greeted with the same level of skepticism. All his charts and graphs are failing to convince anyone. Is it possible for the CEO to reverse the trend and actually build credibility? Sure! The easiest way is for his prediction of doom to come true just once. Granted, that’s not particularly useful, but it is the easiest approach.

A more difficult approach is to put aside all the shiny tools and actually pay attention to the people. If he is willing to learn how to build trust and establish connection with his followers, then there’s a good chance he can turn things around. But he has to be willing to learn instead of being distracted by all the pretty toys.

I said earlier that there are two things that wine, fish and management have in common. We’ve discussed one. The other is pretty simple.

They all stink when they’re bad.

Mousetrap Company

As published in Corp! Magazine

Remember the classic kid’s game, Mousetrap? In this historic tribute to the legendary Rube Goldberg, players have to assemble an exceedingly convoluted and baroque mechanism that will supposedly catch a mouse. As I have young kids, I recently had a refresher course in the game. What was interesting was the debate about which part of the trap is the most important: the crank turn at the beginning? The shoe that kicks the bucket, the ball bouncing down the stairs, the diver that flies into the washtub or the trap itself falling down the pole? In the end, most of the kids decided that it must be the trap, since without that you can’t actually catch the mouse.

Listening to the debate, I had the rather disturbing experience of being reminded of a certain software company. A similar debate occurred there as well: the engineers who were supposedly designing and implementing the software were being raked over the coals because they hadn’t successfully produced a workable product by the deadline. At first glance, it was clearly their responsibility to build the product, and their failure was costly indeed to the company.

The first glance is not, however, always the most accurate one.

In the game of Mousetrap, a number of things have to happen correctly in order for that all important trap to fall. If the shoe doesn’t kick the bucket, the ball won’t go bouncing down the stairs. If the crank doesn’t turn, the gears won’t rotate and the shoe won’t move. Indeed, while a failure at any point in this wonderfully elegant mechanism will derail the whole thing, failure at the start means that it won’t even get going.

At this software company, the process for getting a release out the door was, unfortunately, even more elaborate than the mousetrap. The biggest problem, though, was the crank at the top. The company had several products, and competition for resources was fierce. What the CEO seemed to be paying attention to was what received the time and energy of the engineers. Although the CEO kept saying that this particular release was critical to the future of the company, he made no effort to organize the company around that release, nor did he delegate that task to anyone else. Thus, the assumption from the top down was that this release couldn’t really be as important as all that.

By the time engineering got involved, the engineers were focused on multiple tasks. Without any direction from above, they took their best guess on which direction to go. Being engineers, that meant that they pursued the interesting technical problems, not the serious business priorities: when not given direction, most people will do the thing they are best at doing, whether or not that is the thing that really needs to be done at that moment.

When it came time to ship the product, the best that could be said about it was that it didn’t crash too often. The customer was not pleased.

What happened here was that there was no logical flow of control or means of prioritizing tasks. Superficially, an unhappy customer was the fault of the engineers; certainly, they took the blame. However, was that really accurate? The engineering team did their job as best they could with the information they had available. The real failure was in the leadership: when no one is leading, people follow the path of least resistance. That may not get you where you want to go. Although the failure did not manifest until the very end, the seeds of that failure were sown long before the engineers ever started working on that particular product.

Fundamentally, it is the job of the leader to set the direction for the company and keep people moving in the right direction.

It is the job of the leader to build the team so that the employees will follow him in that direction. It is the job of the leader to build up his management team so that he does not become the bottleneck.  It is the job of the leader to make sure that the technical problems and the business problems are in alignment and that the biggest contracts are the ones that get priority. This seems obvious, but for something obvious, it certainly fails to happen in far too many situations.

In this particular situation, the company’s mousetrap didn’t work very well. The trap didn’t fall. The rod didn’t move. The diver didn’t dive. The crank might have turned, but it didn’t turn particularly well. Indeed, the company really only got one part of the mousetrap process to work well.

They did manage to kick the bucket.

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

Being Fred Flintstone

Remember the classic kid’s TV show, the Flintstones? Fred and Wilma Flintstone are a stone age couple who live in something that looks oddly like the 1950s with rocks. Lots and lots of rocks. Despite this, the show had nothing to do with either rock music or getting stoned. It did, however, have an episode which predicted that the Beatles were a passing fad. So much for prognostication! Fortunately, that episode is not the point of this article.

In one episode, Fred complains to Wilma that he can’t understand what she does all day. How hard can it be to take care of a house? Of course, as Fred swiftly learns, after he and Wilma make a bet, the answer is very hard. Fred, of course, makes a total mess of the whole thing. Now, obviously, the cartoon was playing off of social issues of the time and was intended to make people laugh. The obvious lesson, that a “non-working mother” is a contradiction in terms, is hopefully one that most people have figured out by now. The less obvious lesson is the much more interesting one: it is often impossible to gauge from the results, or from watching someone work, just how difficult a job actually is or even how hard they are working! Conversely, how people feel about the results has little bearing on how hard you worked to get them.

Read the rest at the CEO Refresher

Growing Wheat in Siberia

If It Ain’t Broke…

There are a great many ways to complete the phrase, “If it ain’t broke…” The classic, of course, is “don’t fix it,” but I’ve found that “then it doesn’t have enough features,” is also pretty popular. While some other popular endings include “then you haven’t hit it hard enough,” “clearly it’s unbreakable,” and “don’t upgrade it,” for the most part, they’re variations of the first two.

Read the rest at Enterprise Management Quarterly.

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