We Hold These Truths to Be Self-Evident

The baker's dozen list of management “duhs” every CIO should know

For the last year or so we’ve been writing a column looking at things that frequently go wrong in large IT shops, asking why, and commenting “duh.” We usually try to be more subtle than that (our editor reminds us that it’s best not to offend our audience), but we think it’s equally true that it’s better not to offend their intelligence. So, in the spirit of the holidays, which it is when we write this column if not when you read it, we’d like to offer you a baker’s dozen of “duhs” for the new millennium:

Hire Really Good People

It’s actually pretty easy to identify the most important job a manager has. And it’s not all that difficult to do it, either. As managers, our number one responsibility is to hire the best people we can for the job, and then to do everything we can to keep and motivate them.

How? Do it yourself and do it with your team. Ask hard relevant questions designed to discover three things: does the candidate have the skills; can he or she think, do they want to work? Separate interviewing from recruiting: Decide whether you want the candidate and then try to sell them. The team of people who will work with the candidate and depend on him should make the decision, and do the selling.

Don’t delegate. Under no circumstances whatsoever should you let human resources do more than source candidates, schedule interview dates, and rough-check backgrounds.

The goal in hiring is to improve the overall quality of the team. That means that everyone you hire should be better than at least half of the people you already have. Our personal goal is to try to always hire people who are better than we are. If we’ve done a good job, we should be 50 percent the better performer.

You won’t find as many good people as you need, and that’s OK. What’s not OK is to hire unqualified people. You’ll get a whole lot more done with 10 good people than 20 mediocre ones.

And remember, “good” people are the ones who get the work done, not the snappy dressers with the nice suits and good hair who get along with everyone.

Strive to Win

One of our favorite expressions is: “The problem with mediocrity as a goal is that it’s hard to know when you’re just bad enough.” Think about it.

The management tomes urge setting clear goals. For every project you have, ask yourself what victory would look like and whether every team member would have the same definition.

Winning means exceeding, or at least meeting, expectations. As a manager, part of your job is to set those expectations for the team and the customers. And then to refine and manage them. Always know what the minimum required feature set is, but also remember what the system can do to delight the customers. And always remember that the baseline isn’t your last release, but what the competitors offer. Remember the two campers who hear the grizzly bear outside their tent. One starts to put on his sneakers, while the other, starting to run, points out that the sneakers won’t help outrun the grizzly. “I don’t have to outrun the grizzly. I just have to outrun you,” he answers.

Keep It Small

The effectiveness of a team is inversely proportional to its size. Phillipe Kahn, the founder of Borland, had a software development law that defined the diminishing effectiveness of adding a new team member in terms of the communications cost as an inverse factorial problem. Effectively, it takes one conversation per pair of people for a team to stay up-to-date in terms of what they are all doing. For the second team member, that’s one daily conversation, for the tenth, that’s nine.

Email helps. Under “Phillipe’s Law” the optimal team size was about eight people. With efficient written updates, a dozen or so is quite reasonable. On the other hand, efficient communications is very much an art, and typically a lost art, in most major corporations.

If the job absolutely, positively requires five people to do it right and on schedule, do it with four. But not three.

Build One to Throw Away

Most major corporate software projects fail because no one ever defines the requirements. Most people have no idea how to write requirements for new development—it’s just too hard. But everyone knows how to criticize something they have and don’t like—which means that the vast majority of requirements are incremental and based on problems with the current environment. So if you want your users to have a different framework, build one for them.

And then throw it away. Requirements prototypes aren’t production. These prototypes are designed to flesh out requirements, not fulfill them. Most good requirements may be incremental, but most good systems aren’t. It might be painful to dispose of the prototype, but it will be a lot less painful than trying to support it later on.

Since it’s going into the trash, don’t engineer it, and certainly don’t overengineer it. Remember that the goal of a requirements prototype is agreement and understanding of the functional requirements of the system, and no more than that. Before adding a feature to the prototype, ask what additional level of clarification it will provide.

One good way to do this is to make the product managers and program managers do the requirements prototyping with minimal help from the development team and in a development environment as dissimilar as possible from the intended production environment. This approach tends to provide a high degree of focus and has the side benefit of building a deeper level of appreciation between the development and requirements people.

Fail, and Do It Quickly

Think about the usual self-contradictory blather of corporate advice-givers:

•“Set stretch goals.”

•“Under-promise, but over-deliver.”

•“Nothing ventured, nothing gained.”

•“Nothing ventured, nothing lost.”

•“No one ever got ahead by failing.”

•“We learn best from our own failures.”

How exactly do you simultaneously set stretch goals and under-promise? And how exactly do you define “stretch” if you are always expected to succeed? If we learn best from our own failures, ask yourself what most successful corporate managers have really learned.

Failure—that is, accepted and acceptable failure—is the true sign of a strong, win-oriented culture. The only way to succeed is to set stretch goals and strive for them. Teams rarely overachieve their goals. And if the sailing is always smooth, and the victory always assured, then the goals are too short, the risks insufficiently substantial, luck is too good, the spin machine too efficient, or all four of the preceding.

Good managers fail. They do not fail often, or too expensively, and they learn from the experience. And they fail early in the process, while there’s still time to correct course.

And don’t be led astray by the notion of separating internal and external goals. Having a 12-month public target and an eight-month internal target release date is the same thing as having a single 12-month target if you add one feature or skip a step because of the “extra” four months.

Reward Performance

This may seem obvious, but in our experience it’s anything but. Most major corporations reward and promote people who get along, look good, and don’t fail without really good excuses. This fact stands in marked contrast to our fifth point. We get sick when we hear managers telling performers, “You’ve done a really great job on this project, but if you want to get promoted, you really have to learn to make fewer waves.” An equally offensive line is, “You’re too project-oriented. You need to take a broader perspective.”

All success is project-oriented. Clearly we’re not arguing for the local suboptimization typical of many large companies with multiple, competing, inconsistent projects. What we’re talking about is the (hopefully) usual, reasonably well-defined initiatives with real defined business benefit that take a group of dedicated team members six to nine months or more to accomplish.

Taking this approach creates waves. Fixing anything in an organization always creates waves because organizations resist change. There’s always someone invested in the status quo, and anything new changes, and certainly threatens, the status quo. Telling people to accomplish without making waves is the moral equivalent of asking them to shower without getting wet. It’s impossible, discouraging, and sends the clear message that it’s time to get a new boss, perhaps at a different company. (Obviously, we’re not suggesting that it’s good to create unnecessary turbulence in the environment.)

Rewarding performance and not punishing measured failure is the tangible source of accomplished companies.

By now you’ve probably noticed that we’re threatening the “insight” portion of the column title. But if the first six items struck you as obvious, the second half dozen ought to really floor you. The question to ask yourself isn’t so much whether each of these items makes sense to you, it’s how well you and your company implement all of them consistently. Remember, this is the “duh” list, and the only passing grade is 100 percent.

Make Work as Enjoyable as Possible

This directive should be really obvious, but, in our experience, it’s the least frequently addressed issue on the list. Work is work, it’s why we get paid. If it were just fun, we’d do it for free. But just because work is work doesn’t mean we have to make it a challenge to get things done. Happy, motivated people are much more productive than unhappy clock watchers. And enjoyment, as well as misery, are infectious.

Ask yourself what you do for your employees, and what your company does for you, to make work enjoyable. Money doesn’t count.

If you’re the hard-nosed management type who doesn’t relate to the “fun” concept, ask the same question but substitute “productive” for “enjoyable.” It’s basically the same thing.

The best way to approach this problem is to think about the way people work at home. Most people with reasonable means set their homes up pretty much the way they like them. Even if your home is set up to please someone else, like your spouse, home offices are usually set up to help make us comfortable and productive. Contrast your work environment with your home work environment:

•Study after study shows that for knowledge workers, all else equal, productivity of office workers is about two and a half times that of workers in cubes. Don’t buy it? How many home cubes do you know of?

•The number of home office closets is not overwhelming. Windowed offices are better for productivity and enjoyment than windowless offices. And this doesn’t override the cube issue, although “space planners” will argue that an open office environment, providing more light to the cubes, is better than an office. It may be better aesthetically, but not for enjoyment or productivity.

•Dress code. Have one at home?

And the list goes on.

Separate Fact From Fiction

Senior managers are the only known breed that thrives on disinformation. While IT is hardly unique in this respect, IT organizations in large companies have all but perfected the art. The situation is self-feeding; if success is only slowly rewarded but punishment for failure is immediate, the impetus for sharing news of problems is vastly reduced.

Jim McCarthy has a wonderful story of a project that runs dead on schedule until one day, it’s six months late. Really bad night. And the first question the senior manager asks is how certain the six-month delay is. This question seems entirely inane as well as remarkably common. If the line manager thought the project was on schedule yesterday and is six months behind today, why would any reasonable person believe him unless they want to be misled?

Every status report on every project should focus on, not include, the ongoing risks to the project and what is being done to address them. There is nothing wrong with failure, or even schedule slippage, if it is well-understood and communicated, and all appropriate action has been taken. What is unacceptable is the sudden, unexpected, six-month slip.

And it’s more of a condemnation of senior management than of junior. Project managers only behave this way if this kind of behavior is encouraged. If this is the typical behavior at your company, punish the senior IT managers for it if you want it to stop. Encourage them to face the truth and know what’s really going on.

Hire Qualified Managers

Effective hiring will be really hard to achieve if managers aren’t intimately familiar with the process of which they are in charge. In fact, lack of qualified technical management used to be (it’s getting better) the leading predictor of project failure. There are two related reasons for this.

First, no matter how good a leader, manager and domain expert a nontechnical IT manager is, he or she won’t earn or keep the technical team’s respect. The classic Dilbert cartoons all apply here. Our favorite is the “translation” panel which says “When technical people say it’s technologically unfeasible, what they mean is that they don’t feel like working on it.” This truth may offend some, but that doesn’t make it any less truthful.

The second issue is guidance. Good leaders and managers provide guidance. They have to be able to make the tough calls on everything from staffing to scheduling to prioritization. And they have to be able to communicate efficiently and effectively. Requiring that hard issues be thoroughly documented and translated is generally too onerous for smooth operating processes. A qualified manager should see the problem developing from the ongoing email streams, not from hiring a consultant to do a project analysis.

Let the People Who Know Make the Decisions

Every modern management text talks about the importance of “empowering” employees to make decisions. We don’t think this has much to do with empowerment, but rather a simple issue of defining responsibilities and then letting people do their jobs. The usual rationale for management decision-making is that it lets more experienced people with a better overall picture make the decisions. There are three basic problems with trying to push decision making “up” a level: It takes longer, it means decisions are being made with less detailed information, and it’s demotivating.

The balancing act is not that difficult, it is simply to require managers to actually do their own jobs rather than that of their employees. The manager’s job is to clarify goals, foster a better work environment, be available for consultation, and assign responsibilities. If managers actually do these things then their teams will generally do a better, cheaper, and faster job of the decision-making. And the teams will learn, increasing their own and the company’s overall experience level as well.

Stop the Insanity

A good manager focuses on removing all unnecessary obstacles to success. In other words, if something doesn’t contribute to the corporate, product, or project, it isn’t done. Any proposed action or policy is viewed against this criteria, from dress codes to methodologies to employee benefits to “administrivia.”

Does your company have policies on cube (or office size) by level? Is there a set of security regulations that include how employees are supposed to wear their ID badges? Do you have a process for ordering personalized letterhead? Are there HR policies of more than a page or two in length? Do you have a prohibition against using the Internet for personal business? Your computer? The telephone? Paper clips? How many non-project meetings do team members attend each week? How many HR seminars? How many meetings of any kind do you hold without agendas and specific decisions to be made?

Does the air conditioning go off at 6 p.m.? Does the cafeteria stop serving after a certain time? We worked at one company where the food service contract prohibited free coffee and machines on the floors. At another where pass cards didn’t give access for employees after 7 p.m. And another where the lights went out if no one moved for two minutes after 8. Honest.

Some of this stuff might make sense if your employees were all junior clerks, or more likely on prison work release programs. Are they?

Shipping is a Feature

Software gets shipped by cutting features from the final release.

Every release starts off with a goal that is only a step or two removed from solving world hunger, or at least a good portion of it, or at least creating a new “killer app.” Every team member, from marketing to product management to development and QA, has favorite features, parts of the release they are proud of, have told people about, or just think are really cool. These features must be in the release or it’s not worth shipping.

Somewhere, probably in some early documentation on the business plan for the release there’s a simple sentence or two describing the overall goal of the release. Features that must be included to meet anybody’s definition of that goal are the only required features for a release. The other 90 percent are more or less optional.

Doing every feature on the list is as unreasonable as fixing every conceivable bug. It’s not going to happen, and if it were it would take so long and cost so much that no one would care. Somewhere around the halfway point of any good project the goal has to move to getting it into the hands of the customers. Ship it!

The Less Things Change, the More They Remain the Same

It’s fun to read articles like this one, discuss them at the water cooler, even have offsites and HR seminars to discuss plans to change things. This is probably already happening today. In fact, if you pass this article along to your HR group, there’s probably someone there who’ll be thrilled to have it and thrilled to use it as the agenda for the next management offsite. But that’s not different.

Different is figuring out what you can do to fix things and doing them. Different is looking at the next proposed process change and asking what specific diagnosed problem the new process addresses and why anyone thinks it will fix the problem and what additional ones it might cause.

There’s a New Year’s resolution opportunity here.

• Privacy
• Your California Privacy Rights
• Copyright © 2008 United Business Media LLC