The Business Sensei

The Measure Of All Things

“If you can’t measure it, you can’t manage it.”

It’s a familiar refrain, one I hear quite often. There’s even some truth to it, at least for those things that are easily measureable. After all, if you want to keep track of how many widgets you are stamping out, maximize efficiency, profit, and so forth, then it really does help to be able to measure it. If you’re mixing ingredients for a cake, it helps be able to precisely measure out a cup of sugar or three eggs. The problem is, not everything quite so easily lends itself to being measured. Take, for example, enthusiasm.

Enthusiasm is something everyone wants; let’s face it, unenthusiastic employees are particularly hard to motivate, whereas enthusiastic people are very much self-motivated. Enthusiasm, however, is difficult to measure. The most common attempt to measure something like enthusiasm is to look for things that might indicate enthusiasm: perhaps people arriving early and leaving late is a good marker of enthusiasm. On the other hand, perhaps neither of those behaviors are markers of enthusiasm. After all, why should they be? I admit that it seems likely that they are, but seeming likely is no guarantee of anything. In this case, we’re falling into the trap of grabbing onto something that easy to track and using it to measure the thing we care about. That’s sort of like using a tape measure to determine the correct quantity of flour for a cake simply because the tape measure is handy and the measuring cup is not. In fact, while some people manifest enthusiasm by showing up early and leaving late, others manifest enthusiasm through greater intensity of focus for shorter periods of time or by coming up with ideas at weird hours and so forth. The manifestation depends a lot on the person and the job to be done.

A related problem is confusing how we’re trying measure a thing for the thing itself. In this case, after deciding that coming in early and staying late must be valid ways to measure enthusiasm, someone comes up with the brilliant idea if you just require that everyone arrive early and leave late then they will become enthusiastic. In fact, quite the opposite is likely to occur. A Geiger counter measures radioactivity, but, outside of a Bugs Bunny cartoon, rewiring a Geiger counter so it clicks wildly doesn’t make the area radioactive.

So, we have a problem. We don’t want measure something by just picking the most convenient yardstick and hoping that it works. We also don’t want to mistake that convenient yardstick, or even an accurate yardstick, for the thing we’re trying to measure. What do we do?

At root, measuring is just a way of comparing two things. A ruler lets us measure length by comparing the length of an object to something – the ruler – with a known length. A Geiger counter lets us measure radioactivity by translating radiation into something we can hear. Thus, if we want to measure enthusiasm, we need to figure out what things we really are trying to compare with one another. Does enthusiasm mean less failure work? Does it mean fewer bugs in the product? More work done in a shorter time? How about greater creativity or a desire to come up with novel solutions to problems? Or maybe people coming up with unexpected and imaginative ways to approach their jobs? Any of the above, but not all of them at once?

Measuring by comparison does provide us with an approach to measuring, and potentially managing, things are inherently hard to measure. It does, however, lack a certain level of precision. On the other hand, that may not be all that important. Sometimes, all you really need is a reasonably good sense of which direction you are going.

“If you can’t compare it, you can’t manage it,” isn’t quite as snappy or as simple as “if you can’t measure it, you can’t manage it,” but it is more useful. You just have to find the right points of comparison and be willing to work with a certain degree of imprecision. Once you can do that, it’s amazing how many different, and effective, ways there are to manage the things you can’t measure.

When Goals Take Over

“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 most computers will run before crashing (or installing an update without warning). 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, speed 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.

So why were these teams so insistent upon solving the wrong problems? 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. At that point, once goals are set, they become the focus of everyone’s attention and a lot of work goes into accomplishing them. That is, after all, the best thing about goals; unfortunately, it can also be the worst thing about goals.

While clear, specific goals are certainly good things, goals also have to make sense. You need to have the right goals. 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 possible 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 the results you actually need.

Once goals are set, they have a way of taking over. What are you doing to make sure you don’t set goals before you know where you’re going?

Creating effective routines

This is an excerpt from my new book, Organizational Psychology for Managers.

Basically, a routine is a series of actions that we perform so often that they become automatic and which often produce a particular mindset. The more we practice the routine, the more rapidly we create the mindset. Eventually, merely contemplating the routine will initiate the mental state, although performing the routine is still essential most of the time if we want it to last. When an athlete executes a pre-performance routine, that routine is intended to get them physically and mentally prepared for competition. Many people create morning routines around breakfast, coffee, and reading the news as a way of mentally preparing to focus on the day’s work. My first jujitsu sensei used to tell us that the reason we bowed as we entered the dojo was to leave the day’s baggage at the door so that we could concentrate on the workout. If we practiced the routine with that image in mind, it worked. If we didn’t, it didn’t.

Quite often, though, routines are created less carefully. They just build up over time: for example, the student I described in the opening to this chapter was in the process of building up a routine around her throws. Throw, focus on the negative, produce a negative, pessimistic mindset, repeat. Of course, as she built that mindset, her throws would get worse, there would be more negatives to focus on, and so it went. When this process isn’t interrupted, students start dreading the practice of throwing because they’ve built such negative associations.

I’ve encountered this phenomenon in jujitsu, and also when conducting seminars on mental skills techniques for athletes in other sports. It comes up in the business world as well: as I alluded to at the beginning of this chapter, in one particularly dramatic example, a software engineering team at one major company would conduct a post-mortem review after each product ship. Unfortunately, as we know from chapter three, group polarization can produce extremes of behavior in a team. In this case, team members all wanted to demonstrate that they were serious and dedicated and open to giving and receiving criticism. It wasn’t long before each product ship was followed by a laser-like focus on the flaws, while the very real successes were minimized or ignored. Over time, the ability of the team declined simply because they convinced themselves that they just weren’t all that good and eventually product quality followed. Then they really did have something to complain about! Performance reviews are another area in which routines develop over time, a point well illustrated by the number of managers who complain to me about how unpleasant it is to even contemplate the review process!

Riveting!  Yes, I called a leadership book riveting.  I couldn’t wait to finish one chapter so I could begin reading the next.  The book’s combination of pop culture references, personal stories, and thought providing insights to illustrate world class leadership principles makes it a must read for business professionals at all management levels.

Eric Bloom

President

Manager Mechanics, LLC

Nationally Syndicated Columnist and Author

Make it easy

This is an excerpt from my new book, Organizational Psychology for Managers.

It’s worth a brief discussion at this point of the concept of making things easy. My first jujitsu sensei used to frequently remind me to not stand my partner’s foot when I was trying to throw him. It was frustrating for me and didn’t particularly amuse my partner.

All too often, we get in our own way when we want people to do something. There is a big difference between making it hard for someone to say “No” and making it easy for them to say “Yes.” When we make it hard to say “No,” we are also making it hard to say “Yes” because we are, in effect, denying the other person autonomy or control. When we make it easy for them to say “Yes,” we are constructing the situation to produce the results we want and letting the other person freely choose to give us those results. As one Googler in that NY Times article put it, even on days off she comes into the office: there’s always healthy food available and it’s a more interesting place to be.

Organizational Psychology for Managers is phenomenal.  Just as his talks at conferences are captivating to his audience, Steve’s book will captivate his readers.  In my opinion, this book should be required reading in MBA programs, military leadership courses, and needs to be on the bookshelf of every Fortune 1000 VP of Human Resources.  Steve Balzac is the 21^st century’s Tom Peters.

Stephen R Guendert, PhD

CMG Director of Publications

The Efficient Light Bulb: A Productivity Fable

This is an excerpt from my new book, Organizational Psychology for Managers.

Once upon a time, there was a light bulb. This light bulb was quite a remarkable light bulb: it was praised far and wide for its incredible efficiency. This light bulb gave off no waste heat. This light bulb did not contribute to global warming. It had no carbon footprint.  It did not rely on fossil fuels. Truly, it was an amazing light bulb and visitors came every day to see this remarkable light bulb.

One day, though, a traveler coming to see the light bulb in action was delayed by an unfortunate flood that closed several roads. He did not arrive until well after night had fallen. Much to his surprise, he found the light bulb sitting in a pitch dark room.

“Why aren’t you giving light?” asked the traveler.

“Give light!” replied the light bulb in shocked tones. “You must be joking. If I did that, I would use fossil fuels. I would have a carbon footprint. I would give off waste heat. I would no longer be efficient.”

“But isn’t the purpose of a light bulb to give light?” asked the traveler.

“I’ve always been told to be efficient,” replied the light bulb with a shrug. If you have never seen a light bulb shrug, it is truly a wonder to behold. The traveler would have been amazed, except, of course, that the room was too dark for him to see the miraculous event.

Once upon a time, there was a software company named “Soak, Inc.” Soak’s product relied upon a very complex database server. One day, the VP of Engineering stormed into the office and declared, “The server is too slow. We need to speed it up.”

From that day forth, every effort was focused on improving the speed of the server. Other issues were deemed insignificant beside the one, critical, goal of performance. Engineers who dared to raise other issues were publically humiliated for wasting the company’s time. Bugs that did not relate to performance issues were deemed “optional.” People who spent time reviewing the optional bugs and trying to fix them were warned that their insubordination would cost them their jobs if it did not cease immediately.

Eventually, Soak developed an amazingly efficient server. It was fast. It was robust. It was ready to demonstrate to potential clients.

The demo started out remarkably well. The server did not crash, causing some to believe that this couldn’t actually be a demonstration of a software product. Indeed, the server performed flawlessly. All would have gone well indeed for Soak had not someone noticed that the data being delivered by the server didn’t make sense. Yes, what the server had gained in performance it had lost in accuracy. In other words, it was incredibly good at very rapidly delivering useless or incorrect information.

When the engineers were questioned about this unfortunate oversight, they shrugged and replied, “We were told to be efficient.”

While it is not nearly as amazing to see an engineer shrug as it is to see a light bulb shrug, the effects are much the same.

At Soak, a goal was set, a metric for success was defined, and that metric became the sole determinant of progress. Goals are extremely powerful tools: the best thing about them is that you accomplish them. Unfortunately, sometimes the worst thing about goals is that you accomplish them. At Soak, they accomplished their goals. A dead light bulb is extremely efficient, but not useful. Similar observations can be made about the server.

Before leaping into setting a goal, especially a goal to solve a problem, it helps to understand the actual problem and to understand what the actual symptoms are. Rather than create useful goals, they fixated on a symptom. That did not, however, actually change anything.

At Soak , the VP stated that they were trying to solve the problems his company was facing as rapidly and effectively as possible. They were setting goals. They were Taking Action! Taking action is certainly helpful, but it is even more helpful to be taking the correct action. Since it’s not always possible to determine just what the correct action is, it becomes even more critical to listen to the feedback and questions from the people who are charged with actually executing the action. The engineers knew that something was wrong, but no one was willing to listen to them. As we will discuss shortly, a key aspect of successful goal setting is understanding the feedback you’re getting.

I realize that many of you reading this are probably chuckling to yourselves and thinking that this scenario could never happen at your companies. The folks at Soak said the same before, during, and even after it happened to them. The light bulb had no comment.

Productivity seems like such a simple thing. Somehow, though, it never is. As we have already discussed, cognitive shortcuts such as the Halo Effect can influence how productive we perceive someone to be. Ultimately, the only real way to measure productivity is through understanding goals and knowing how to construct goals so that they will actually get you what you want. Otherwise, you may just end up with a dead light bulb.

After it was released, Organizational Psychology for Managers sold out in two days at Amazon.com. Order your copy now.

Organizational Learning

This is an excerpt from my new book, Organizational Psychology for Managers

Fans of James Bond movies might recall a scene that goes something like this:

We are looking at an unidentified room. Two people we’ve never seen before are standing in front of a desk. We might be able to see the back of the head of the man who sits behind that desk. A voice rings out:

“You have failed SPECTRE. Number 3, why did you not kill 007 as ordered?”

Number 3 stammers out some response and the voice turns its attention on the other person.

“Number 5, you have also failed SPECTRE…”

Eventually, Number 3 is told everything is forgiven and he can leave. Of course, this is SPECTRE. As soon as he walks out of the room he’s dropped into a tank of piranhas, or the bottom of the elevator turns out to be a trap door and Number 3 learns that Maxwell Elevators really are good to the last drop, or he dies in some other Rube Goldbergesque manner.

SPECTRE, as all Bond fans know, is the villainous organization headed by Ernst Stavro Blofeld, the evil genius who spends most of his time trying unsuccessfully to kill 007. Given his track record, as evil geniuses go, he frequently seems more like Wile E. Coyote.

Blofeld’s problem, of course, is that every time one of his agents makes a mistake that agent dies. Those whom James Bond doesn’t kill are terminated by Blofeld himself. This makes it extremely difficult to conduct any form of on-the-job learning. When every mistake is fatal, the lessons tend to come a little too late to do much good. As learning organizations go, SPECTRE has issues.

Although the consequences are generally not so flashy, businesses do face some similar problems. Granted, most business mistakes don’t make for a good action movie, and dropping people in piranha tanks is generally frowned upon. However, there is still the very real problem of figuring out how to enable people to learn from their mistakes without those mistakes harming the business. James Bond, after all, at least gets a script.

Part of the challenge is that even when leaders are well-trained and highly skilled, there is a big difference between what one learns in most management training classes and the actual experience of leading a team, department, division, or company. That doesn’t mean that the training is useless, but it does mean that the training needs to be appropriate.

In sports, for example, athletes drill constantly: they practice the fundamental skills of their sport until they can execute those skills without thought. Doing that, however, is not enough to make an athlete a successful competitor. Such training is necessary, but it’s not sufficient.

As a soccer-playing friend once commented to me, there’s a big difference between the drill and the game. The drill is controlled and predictable; the game is not. The game is confusing and chaotic, and in the moment of truth all those carefully drilled skills simply vanish away. The problem is that chaos is overwhelming: it takes getting used to in order to navigate it. The Japanese term, “randori,” used to describe Judo competition, means “seizing chaos.”

Athletes practice getting used to chaos by moving past drills and practicing in various free play scenarios: mock games, spring training, practice randori, etc. These experiences enable the athlete to experience the chaos in small doses and hence become increasingly comfortable with it. They learn which skills to execute when. The day of the actual tournament, they are ready. When they do make mistakes, they have something to fall back on to help them recover quickly, as opposed to something to fall into and get eaten.

Businesses are in a fundamentally similar position: while there are some obvious differences in the details between learning the skills of a sport and learning sales or management or computer programming, the fundamental process is the same. Since organizational performance is ongoing instead of being organized into discrete chunks such as tournaments, organizational learning needs to be ongoing as well. Optimally, organizational learning should also be an enjoyable experience, not just because that makes people happy but because people learn best when they are enjoying themselves. The methods and approaches to organizational learning should also serve to simplify other issues, such as orientation, accreditation, and organizational change. The lessons of sports and games will serve us well in understanding how to make organizational learning effective.

To begin with, though, we need to understand what learning is and how it works.

Riveting! Yes, I called a leadership book riveting. I couldn’t wait to finish one chapter so I could begin reading the next. The book’s combination of pop culture references, personal stories, and thought providing insights to illustrate world class leadership principles makes it a must read for business professionals at all management levels.

Eric Bloom
President
Manager Mechanics, LLC
Nationally Syndicated Columnist and Author

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. 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.” Steve’s latest book, “Organizational Psychology for Managers,” is due out from Springer in late 2013. For more information, or to sign up for Steve’s monthly newsletter, visit www.7stepsahead.com. You can also contact Steve at 978-298-5189 or steve@7stepsahead.com.

The Difference Between Leaders and Managers? Less Than You Think!

This article originally appeared in Corp! Magazine.

The world is full of classic face-offs:

Red Sox vs. Yankees

King Kong vs. Godzilla

Godzilla vs. Mechagodzilla

Dracula vs. Frankenstein

Kirk vs. Picard

They’re all pikers! Nothing, absolutely nothing, compared to the big one: Leaders vs. Managers. As important as any of these other matchups might be in some circles, none of them have ever generated the sheer volume, passion, and press as the eternal debate over the difference between leaders and managers. Classic arguments in the leader vs. manager debate include such pearls of wisdom as, “Managers take you safely along the map, leaders take you off the map;” Peter Drucker’s classic, “Managers do what’s right, leader’s do the right thing;” and so on.

If there is a fairly consistent theme in the leader vs. manager debate it’s that leaders are somehow innately superior to the poor manager. Managers are relegated to the role of also-ran or minor functionary. While I hate to disagree with Drucker, not only is this unfair to managers, it’s also inaccurate.

The fact is no one can single-handedly lead a large organization. A skilled, charismatic leader might be able to individually lead 10 or twenty people, although even that is probably pushing it. By the time your organization is up to 100, 1000, or 10,000 members, it’s too big for one person. There are too many moving parts, too many specialized groups. Each of those groups needs to know how they fit into the overall mission and strategy of the organization; how does the corporate mission apply to them and why are they important? Let’s face it, groups and individuals who are seen as not important to the success of the organization don’t stick around. Either they get fired because they aren’t producing or they leave because they don’t feel connected and involved.

That overall leader needs lieutenants, essentially “sub leaders,” whose job it is to communicate the leader’s vision to their individual groups. Those lieutenants, better known as managers, are the conduits through which the overall vision and strategy is brought home to individuals and small groups. It is up to them to provide the underlying support that enables the CEO to lead. The CEO of a company can speak in terms of broad and exciting visions, but the managers need to make it specific to each individual team member, and then enable each team member to contribute to the vision.

By individualizing the vision, managers enable individuals to contribute to the vision and help bring it to life. The best managers recognize that one of the most important things they can do is bring out the best in each person, hone their strengths so that they can become enthusiastic contributors to the organization; they don’t try to put in what isn’t there. The CEO is too far removed from the individual team members to see each person’s strengths and weaknesses and figure out how to make the best use of them. The individual managers, on the other hand, are perfectly positioned to do that. Just as the overall leader of an organization must identify and build the strengths of the business, so the leader of each team must help each individual develop his or her own individual strengths. Just as the CEO must weave together the differing strengths of each part of the organization into a cohesive whole, the manager must weave together the differing strengths of each individual team member to produce a high performance team. Mediocre managers focus on “fixing” weaknesses; great managers focus on building strengths. It’s not an easy task, however, which is why so many managers, and CEOs, fail to do it.

So what then is the real difference between leaders and managers? It comes down to scope: While the leader may set the overall vision and direction for the organization, the managers then bring it to life within their particular areas. People who cannot do that should not be managers… or leaders. In the end, managers and leaders really are not all that different!

Organizational Psychology for Managers is phenomenal. Just as his talks at conferences are captivating to his audience, Steve’s book will captivate his readers. In my opinion, this book should be required reading in MBA programs, military leadership courses, and needs to be on the bookshelf of every Fortune 1000 VP of Human Resources. Steve Balzac is the 21^st century’s Tom Peters.

Stephen R Guendert, PhD

CMG Director of Publications

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. 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.” Steve’s latest book, “Organizational Psychology for Managers,” is due out from Springer in late 2013. For more information, or to sign up for Steve’s monthly newsletter, visit www.7stepsahead.com. You can also contact Steve at 978-298-5189 or steve@7stepsahead.com.

For the Deadline Was a Boojum, You See

“There was one who was famed for the number of things
He forgot when he entered the ship:
His umbrella, his watch, all his jewels and rings,
And the clothes he had bought for the trip.”

— Lewis Carroll, Hunting of the Snark

Lewis Carroll billed the Hunting of the Snark as an “agony in eight fits.” While it’s not entirely clear what Carroll meant by this, the sentiment well describes the process of scheduling and hitting deadlines in many organizations. Certainly it’s clear that the Bellman didn’t have a schedule, or he wouldn’t have left his crew’s belongings on the beach.

Some years ago, I worked for a software company where the CEO decided that missing a deadline was a personal failing on his part. No matter what, the software would ship on the day he had announced. Even if the product had bugs, even if it did not work, it shipped on the day the CEO had promised. “Not a single day of delay,” said he.

He preferred to ship a product that did not work and then release a bug-fix rather than delay the software even a day. He never understood why customers grew increasingly irate and would call the company to complain. He was keeping his promise to ship by a certain date, and certainly adherence to the schedule was important.

There are several problems with this belief. The most obvious, of course, is the stubborn belief that the software must go out on a specific date no matter what. Shipping any product that doesn’t work is going to upset your clients. Doing it repeatedly just makes the company look incompetent or indifferent to its customers. It is not meeting their needs to give them something that they cannot use.

Stepping back, though, from that minor problem, we have to ask what the point of the schedule was. There seemed to be little rhyme or reason to why the CEO picked the dates that he did. When pushed, his reaction was that scheduling was important, otherwise things didn’t get done. True, but not necessarily relevant. Fundamentally, a schedule is a tool; like all tools, it must be used properly or there is risk of serious injury. In this case, financial injury.

A schedule is not an arbitrary set of dates put down on paper to make sure that everyone works hard and doesn’t goof off. The goal of a schedule is also not to precisely calculate how long each task will take and account for every minute. It is not a holy writ to be held to beyond the bounds of common sense or product quality, nor is it put in place in order to have something to ignore. Sadly, I can’t count the number of times I’ve seen schedules designed with exactly those somewhat dubious objectives in mind. However, a well-designed schedule needs to satisfy some fairly significant constraints:

1. A schedule helps make sure you don’t forget anything. It is both a to-do list and calendar. It helps people know what to work on when so that they don’t have to waste time constantly figuring that out.
2. A schedule is a tool for marshalling resources. Building a product requires different resources, be those resources time, people, or equipment. The schedule helps make sure that the right resources are available at the right times so that the project can move steadily forward.
3. A schedule is a tool for managing dependencies. In any large project, different pieces will depend on other pieces or on obtaining external resources. Some dependencies are obvious from the beginning, others do not emerge until the project is under way. The schedule helps organize tasks and manage dependencies so that they don’t derail the project.
4. The schedule helps you determine what you can do in the time available with the resources you have; alternately, it helps you understand how long it will take to accomplish your goals with the resources you have available.
5. The schedule enables you to define reasonable checkpoints, or milestones, that will let you know if you are moving successfully toward your planned target date or if problems are emerging. Missing a milestone is feedback that something is not working as expected!
6. A schedule needs to have enough slush in it to handle unexpected problems. You can’t always determine all possible dependencies at the start; some parts of the project may turn out to be significantly more difficult than expected; you may discover that a piece that appeared to make perfect sense just won’t work and needs to be redone. When I speak about this to technology companies, someone always claims that they’ve done a few simple calculations and developed the perfect project schedule. Based on the reactions from the rest of that person’s department, I have my doubts.
7. The schedule also needs enough slush to handle external delays. If your schedule is so tight that a severe winter storm closing the roads or having someone come down with the flu or having a vendor be late on a delivery will cause real problems, then you need to rethink the schedule. As that great sage Murphy so wisely said, “If something can go wrong, it will go wrong.” Plan for it.

You’ll also notice that if you design a schedule this way, you’ll tend to be running ahead of schedule, not behind. Falling behind schedule is demoralizing, particularly when the schedule feels arbitrary. Running ahead of schedule energizes the team to work harder. A team that falls behind tends to stay behind, while a team that runs ahead tends to get further ahead. In other words, nothing succeeds like success.

When you view a schedule in this way, it has the potential to be a powerful, flexible tool for getting things done as opposed to causing quality, effort, and enthusiasm to softly and silently vanish away. Isn’t that the whole point?

Understanding Hierarchy

This is an excerpt from my upcoming book, Organizational Psychology for Managers.

While I was writing this, I was asked the question, “How important is hierarchy on a team? I’ve been told it’s a problem. I’m responsible for 160 people, and I don’t know what I’d do without a hierarchy.”

Hierarchy is a tool. Whether it works for you or against you depends on how well you understand your tool and the situation in which you are using it. For my friend who has to manage 160 people, some sort of hierarchy is essential: without it, he’d swiftly be overwhelmed.

Hierarchy is a way of organizing and structuring a system. In a typical martial arts school, the hierarchy of belts provides each student a quick visual assessment of who knows what. This can make it easier for students to ask questions or know whom to imitate: learning is enhanced when we can imitate someone we see as similar to us. That person who is one belt ahead is easier to see as “like me” than the person who is many years and belts advanced. The hierarchy also provides visual feedback of the student’s progress, a key component of maintaining motivation.

One of the key roles of the military ranking system is providing a method of coordinating precision operations. It does this by, amongst other things, providing clear rules for whom to listen to and under what circumstances and managing transitions of power should a leader be abruptly removed or cut off from the team. Like the belt system in martial arts, it also provides visual feedback of progress.

In a large organization, hierarchy provides a structured way to know where you are in your career, an easy way to identify nominal skill levels, and a means of coordinating different business activities.

However, when hierarchies become inflexible or bureaucratic, they can easily turn into obstacles. Small companies that attempt to impose rigid, large company hierarchies are asking for trouble: they don’t need the overhead and lack of flexibility that hierarchies can create. A small business’s biggest strength is that it can shift course quickly. A large company, on the other hand, is slower to change but has more resources. It is silly and counterproductive for a small business to impose large company hierarchy and thereby give up its flexibility when it doesn’t have the resources to take advantage of that hierarchy.

Even in larger organizations, the structure needs to be flexible enough to permit good information flow up and down the hierarchy. Too rigid an adherence to hierarchy will reduce productivity and motivation and stifle innovation.

Hierarchy needs to be built out carefully, in accordance with the narrative, goals, and needs of the organization. Make sure you clearly identify what each level of the hierarchy means and how people move up. Periodically review your hierarchical structure and make sure it is still serving you, and not the other way around.

We Can’t Afford That!

“Where are the computers?”

“We can’t afford computers.”

“How can we write software without computers?”

“You’ll figure out a way.”

It’s hard to imagine a conversation like this happening in any company. The truth is, it’s hard to imagine because it basically doesn’t happen. No manager is crazy enough to tell his team to write software without computers. So let’s posit a slightly different scenario:

“Hey, the computers aren’t working.”

“I can’t get the lights to turn on.”

“It’s getting hot in here. What’s going on?”

“Oh, we decided to save money by not paying the electric bill.”

Sorry, that’s still pretty ludicrous. Let’s try another scenario.

I was recently at MIT giving a talk on organizational development. In response to a question about maximizing team performance, I explained that the secret is to have a manager whose job is to be a coach: just like on a top sports team, the manager’s job is to encourage the players, brainstorm with them, push them to achieve more than they thought possible, and make sure they don’t forget to stop and take breaks. It is, after all, the manager’s enthusiasm and sincerity that sets the example for the team, and transforms a team of experts into an expert team.

The immediate response from one member of the audience was, “We can’t afford to have someone just sitting around and watching.”

Now, if they’d left it at that, I would have let it go. Unfortunately, or perhaps fortunately, since it led to this article, they didn’t. They went on to say that the manager needs to do the work of the employees: sales managers should be selling, engineering managers should be doing engineering, and so forth. Resisting the urge to point out that they clearly hadn’t heard a word I’d said to that point, I observed that a manager sits around and watches in the same way that a coach sits and watches. This needs further explanation.

As any Olympic coach can tell you, building a team and keeping it operating at peak performance is a full-time occupation. No one ever says, “These are professional athletes! They shouldn’t need a coach!” If the team wants to compete at a serious level, it needs a coach. If all you care about is playing in the D leagues, well, then perhaps you can get away without the coach. Of course, if that’s what you think of your business, why are you bothering?

When the manager is doing the work of a team member, you have a conflict. Salesmen try to outsell one another; sales success is their currency of respect. Engineers will argue over the best approach to solving a problem; being right is their currency of respect. When the manager is also doing the sales or the engineering or what have you, that shuts down the team. How can the members of the team compete with the manager? While it is a comforting thought to argue that professionals will compete with one another in a respectful manner, and a manager will respect the employee who out-competes him, it just doesn’t work. Comfort thoughts, like comfort foods, may feel good but can easily lead to fattening of the brain.

Athletes trust their coaches in large part because the coach’s job is to make the team successful: the coach is measured by how well he builds the individual athletes and the team. If the coach were being measured on how well he did as an individual competitor, few indeed are the athletes who would trust his advice.

Thus, when a company hires a “manager” who is nothing more than a glorified individual contributor who also signs time sheets, the results are often disappointing. At Soak Systems, it led to constant conflict and eventually to the loss of half the engineering team. If nothing else, the team will never achieve the level of performance that it could reach with a skilled manager.

Further guaranteeing that this problem will occur, most companies hire managers based on their technical, sales, marketing, and so on, skills. They do not hire, or promote, based on their coaching skills. They don’t provide them the training or coaching they need to succeed. Putting someone with no management training into a management role will, at best, produce someone who sits around and watches. More likely, it’ll produce someone who is actively harmful to the team. No wonder companies want “managers” who are also individual contributors: at least they are getting some work out of them and keeping them from causing trouble! Such “managers” really do look like an unnecessary expense. Since most people have never experienced really competent management, they also don’t realize just how much opportunity they are missing.

It’s quite true that you can’t afford to have an untrained manager sitting around and watching. There is also no point in buying computers if you won’t use them or paying for electricity if you don’t have anyone in the office. But if you want to write software you can’t afford to not buy computers. If you have people coming into the office, you can’t afford to not pay for the electricity. If you want to achieve top performance, you can’t afford to not train someone to sit around and watch.

“Author Stephen Balzac has written a terrific book that gets into the realpolitik of organizational psychology – the underlying patterns of behavior that create the all important company culture. He doesn’t stop at the surface level, explaining things we already know like ‘culture beats strategy’ – he gets into the deeper drivers and ties everything back to specific, actionable stories. For example he describes different approaches to apparent “insubordination” by a manager; rather then judging them, he shows how each management response is interpreted, and how it then drives response. Balzac preaches real engagement with one’s own company and a mindful state of operation, especially by executives – who must remember that culture “just happens” unless and until they learn to recognize that their behaviors play a huge part in creating and cementing it. It covers the full spectrum of corporate life, from challenging bad decisions to hiring, training, motivating teams – and the secrets of keeping people engaged and learning – and/or avoiding actions which do the opposite. I highly recommend this book for anyone who wants to participate in creating and steering company culture.”

Attivio – Active Intelligence