The Business Sensei

It’s Not a Sprint, It’s a Hike up a Mountain!

Last summer, I had the opportunity to hike Algonquin. For those who are not familiar with Algonquin, which included me up until about two days before I climbed it, Algonquin is the second highest mountain in New York state. This translates to roughly 5100 feet, which may not be much by Sierra Nevada standards, but when actually doing the hike such subtleties swiftly become irrelevant. The trail up Algonquin starts at 2000 feet and climbs 3000 feet in 4 miles. There are a number of words for a trail like that; one of the less emotionally expressive ones is “steep.” The estimated time for the hike was 8 hours.

I have long believed the old adage that building a software project is a marathon, not a sprint. I was wrong. It’s a hike up a mountain. Consider that a marathon may be long, but it is basically predictable. You know how far you are going and exactly what the conditions will be along the way. When you get to the end, you’re done. Maybe it’s a big circle or there are busses waiting to take you home; either way, the finish line is the finish line.

Climbing a peak like Algonquin, however, is a different experience. At the base camp, the weather was sunny and warm, a typical August day. My wife directed my attention to the sign that said that the temperature at the peak was 40 degrees Fahrenheit, just a tad cooler. I hadn’t noticed that as my attention was on the sign that explained that no matter how beautiful the weather, sudden snow storms were still possible. Yes, even in August there are occasionally snow storms at and around the peak.

The trail itself started off very smooth and easy. My brother-in-law set a good pace, since we wanted to be up and down before dark. Assume one mile per hour, was what he told us. I was thinking that the trail wasn’t that hard, so why such a low estimate? Then we reached the steep part. Well, at least the part that seemed steep until we got to the really steep part. Then it got steeper from there. Suddenly, a mile an hour seemed optimistic.

See the connection to a software project yet?

Even a difficult project seems pretty manageable at the start. Sure, everyone talks about the inevitable rough patches, but no one really expects them to seriously derail the schedule. But then it gets steep; or, in other words, something turns out to be much harder or more complex than expected. Lack of planning? Not really; planning is important, but it can only take you so far. Sometimes you have to plan to not know something until you get there. Your plan needs to include how you’ll deal with that discovery.

I didn’t realize how steep the hike up Algonquin would be. But, I had a hiking stick and my wife was using poles. My stick was very useful; on one particularly wet and slippery section of rock, it nobly sacrificed itself to save my ankle. The, now much shorter, hiking stick was still useful in various creative ways on some other impressively inclined sections of the trail.

Preparation can seem pointless until you need it. If you haven’t prepared properly, your will to win won’t matter. That said, sometimes you also have to improvise and be willing to back up and try something different if your first idea doesn’t work.

Algonquin peak was beautiful. Despite the weather reports, it wasn’t nearly as cold up there as expected. No sudden snowstorms came rolling in. Of course, it was also only the halfway mark; we still had to hike back down. That didn’t stop us from having a picnic and enjoying the view; it’s important to celebrate successes along the way, even if you still have more to do. If you never stop and recharge, you’ll never maintain the focus necessary to reach the end. Hiking a wet, steep, trail, that can mean a blown knee or busted ankle; with software, it can mean endless delays, poor design decisions, and a buggy release.

In the end, our 8 hour hike took us closer to 10 hours. Fortunately, we’d started early in the day so we didn’t run out of light; if night had fallen, that would have been a serious problem. Although I did have a flashlight, I had neither a headlamp nor any desire to spend the night on the mountain. Leaving a little more time than you think you need is always a good idea; projects inevitably take longer than expected. Getting stuck on a mountain means a very long, unpleasant, and potentially serious delay; being too aggressive with your schedule can likewise trigger unexpected problems. Putting in some slush time prevents the unexpected from becoming the catastrophic.

As we finished the hike and emerged from the woods into the sunset, we were both exhausted and exhilarated. Algonquin is a tough hike; we celebrated with dinner at a very good restaurant. At the end of your projects, what are you doing to celebrate? No matter how dedicated people are and how much they enjoy the activity, there are sections that are just exhausting. Taking the time to relax and have some fun after the slog helps us appreciate our accomplishments and prepares us to tackle the next big challenge.

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,” sold out at Amazon.com two days after it was released. 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.

Fatal Deadlines

“It ships on Monday!”

“We have a deadline to meet!”

“Why did you even set a deadline if you’re going to change it?”

Deadlines. They matter until they don’t. They are far away until suddenly they are right on top of us. Sometimes a deadline is sacrosanct, unchangeable no matter the situation or the quality of the product: one technology CEO I knew released his products on the day he promised them and nothing would change his mind. It was a point of pride for him to always release on schedule. His customers, however, were equally adamant that they wished it would be a point of pride for him to release products that worked. Yes, this particular CEO would release a non-functional product on the chosen date and then deal with fixing it in the field rather than slip the date and deal with the problems. Eventually, the customers won: they went to a competitor.

Other times, deadlines seem to be almost mystical talismans: setting a deadline will magically cause a product to be ready by that date. In one rather dramatic example from early in my career in high tech, the CEO turned to the head of engineering and asked him when the product would be ready.

“September 1^st, best case scenario,” was the curt reply.

The CEO nodded, picked up the phone, and said, “We’ll have it ready by July 15^th.”

The head of engineering did a very credible job of not exploding.

When July 15^th rolled around, the product was not ready. The CEO was shocked. His reaction was, “I set a deadline!”

Sometimes a deadline can spur people to dramatic action. Sometimes it can’t. It’s important to know which situation is which. When I was managing a team, I was once asked why I even bothered to set deadlines if I would then change them. The short answer was that it was because the only deadline that actually mattered was the one at the end, and that one we consistently managed to hit. How?

At the most basic level, deadlines are merely tools. They are powerful tools, but tools nonetheless. As will all power tools, it’s important to know how to use them properly, lest your deadline prove fatal to your success.

At the beginning of any non-routine, non-trivial project, deadlines are basically little more than wishful thinking. Early deadlines exist to give you feedback: how well is your team working? How difficult is this project turning out to be? Will we be able to marshal the resources we need at the times we need them? Are we being aggressive enough? Are we being too aggressive? That feedback provides your roadmap moving forward. Therefore, start with small deadlines: don’t rush forward in giant leaps which give you little information.

Whether you make those initial deadlines or miss them, the key is to be strategic: why did you make them? Why did you miss them? What are you learning about your team and your project? Early stage deadlines can be easily shifted and adjusted as needed, provided you don’t lose sight of the feedback they are generating. Done right, the more flexible your early deadlines, the easier it is to hit your later ones. When you do miss a deadline, recalibrate! Don’t just pile the extra work onto the next deadline; that only triggers a series of failed deadlines, which reduces productivity. Success is not how fast you can move, it’s how smoothly you can accelerate.

As the project continues, you’ll find that your ability to set useful, doable, aggressive deadlines will increase. You want your deadlines aggressive enough to excite and challenge your team, not so aggressive that people look and tell themselves that there’s no point in trying. The secret to maintaining that excitement is simple: strive for deadlines that can be beaten with serious, but not unsustainable, effort. Beating deadlines increases excitement and builds a sense of success. Failing to meet deadlines has just the opposite effect. Quite simply, when people are ahead of schedule, they work harder, are more creative and innovative, and are better at problem solving.

Many a race ends with a final sprint across the finish line. How well you’ve managed the deadlines to that point will determine how hard the sprint is, and how much fuel your team has in its tank when you get there. If the team is exhausted and burned out, your deadline will likely prove fatal to your plans. On the other hand, if the team is excited and energized, they’ll blast through that final deadline.

The Speed of Mistrust

Remember the scene in the original Star Wars where Luke, Hans, Chewbacca, and Leia are trapped in the garbage disposal with the walls closing in on them? As the walls inexorably press closer and closer, they engage in increasingly desperate attempts to stop them, a ritual made famous in dozens of adventure movies. No matter how hard they push back against the walls, their efforts are futile. Of course, they are the heroes of the movie, so they do find another way out; after all, if they had not, the movie would have come to an abrupt ending and the fans would have been crushed.

Of course, rather than counting on finding a miraculous escape, it would have been better to have not been in that tight a predicament in the first place.

At Soak Systems, the CEO, whom we’ll refer to as Luke, recently made the comment that, “I guess I should have pushed back harder.”

He was referring to a disastrous product release, one whose eager anticipation by their largest customer was exceeded only by that same customer’s anger and disgust when they finally received it. Their subsequent email was, to say the least, crushing.

In the inevitable post-mortem, it quickly came up that Luke had made at least a couple of attempts to play with the product before it was shipped, but that engineering had “refused to let me see it.”

In retrospect, Luke felt that if he had only insisted more strongly, then clearly engineering would have complied and he would have been able to identify the problems and save the release. Luke is also capable of holding back those moving walls with just the little finger of his left hand. Okay, well maybe not.

While it was gallant of Luke to accept some of the blame for the disaster, he was actually missing the point. In fact, the question is not whether Luke could push back hard enough to convince engineering to cooperate. The question is why he was in that position in the first place. Why, as CEO, does he need to push back that hard just to get basic cooperation? It’s hard to imagine how a release that disastrous could occur without plenty of warning. If nothing else, the stink should have been obvious.

At this point, the traditional thing to do is to nod sagely and observe that if they simply had better communications, the problem could have been avoided. While that observation may be true, it is definitely useless. Of course they weren’t communicating! Why not?

In Star Wars, our heroes at least had the excuse that they landed in the garbage disposal because they were trying to avoid pursuing Storm Troopers. In the resultant rush, they didn’t really have a chance to sit down and calmly discuss their options. At Soak, Luke didn’t have that excuse. There was no rush and no panic, other than the ones that he manufactured.

Effective communications comes from building trust, and trust comes from taking the time to build connections with employees and from, yes, communicating. The problem is that, as CEO, people don’t typically drop by to chat. If you want to get people talking to you, you need to seek them out. Luke didn’t do that. By comparison, IBM’s founder, Tom Watson, was legendary for showing up unannounced at different IBM locations and just dropping in to chat with different people. He was trusted as few CEOs have ever been: employees believed that he cared about them personally.

Luke, on the other hand, talked only to the people he’d worked with in other companies. When he came down to engineering at all, it was mainly to exhort them to do more or complain that they weren’t doing enough. When it became clear that the release had problems, the engineers had mixed feelings about talking to Luke. They couldn’t decide whether he would yell at them and go ahead anyway, threaten them and go ahead anyway, or simply ignore their input completely and go ahead anyway. The VP of Engineering wasn’t able to help them figure out which one it was either, so they decided to simply say nothing.

This is, perhaps, not the best way to establish strong and effective communications with your team.

Now, the fact is, Luke was certainly communicating with the rest of the company. His particularly choice of what to say and how he said it served to build a foundation of mistrust, not a foundation of trust. Sadly, in this environment, the speed of trust has nothing on the speed of mistrust.

Worst of all, Luke’s response, that he “should have pushed back harder,” only confirmed that mistrust. From the perspective of engineering, the release failed due to a number of serious problems that Luke and the rest of senior management were unwilling to address. Acting as if just yelling and demanding more would have changed anything was telling everyone in the company that Luke still didn’t acknowledge the severity of the problems.

The net result: nothing has changed since the release. The metaphorical walls are continuing to close in, Luke is ineffectually pushing back, and one after another the top people at the company are resigning. While Luke may end up with a company full of people he can push around, it’s not at all clear that any of them will be able to push a product out the door.

The situation is not totally irreparable, although it’s getting close. Luke needs to take the time to sit down with his people and actually talk to them and listen to their answers. He needs to take the time to actually get to know more employees than just those with whom he worked in the past. He has a lot of mistrust to overcome and doing that will not be easy. Whether he succeeds or not really depends on whether he is willing to recognize how little trust people have in him, and whether or not he’s willing to work to change that. Until he makes those changes, trust gets the dirt road and mistrust gets the superhighway.

Which is running faster in your company, trust or mistrust?

The Taboo of the Bananas: Organizational Culture and Recruiting

Once upon a time there was a company known as Robotic Chromosomes. Don’t bother Googling it; it’s no longer in business, and besides, that’s not the real name. Robotic Chromosomes had a way of hiring programmers that isn’t all that unfamiliar to folks in the software industry: logic puzzles. Like Microsoft, and various other companies, Robotic Chromosomes put every potential engineer
through a series of logic puzzles in order to determine if those engineers were qualified.

There is, in fact, no actual correlation between programming ability and the ability to solve logic puzzles.This did not stop the folks at Robotic Chromosomes, who were convinced of the validity of their methods and were not interested in allowing facts to get in the way.

Even within the logic puzzle method, though, there were some definite oddities and idiosyncrasies that distinguished Robotic
Chromosomes from other companies.

For several years, no one skilled in visual presentation or user interface development was ever good enough to solve
the logic puzzles, or at least they could never satisfy the solutions that the existing engineers believed were correct.

Read the rest at the Journal of Corporate Recruiting Leadership

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

Right To Midnight

“Left or right?”

“Right to Midnight.”

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

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

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

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

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

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

“September 1^st,” said the VP.

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

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

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

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

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

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

4.      Are we really all on the same page?

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