Cedric moved through his office packing up his personal belongings. His boss, Sheila, stood in the doorway, looking uncomfortable. As he started the last box, Cedric sat down in his chair. “How did it come to this, Sheila? I thought I was doing the right thing putting quality processes in place.”

Sheila sighed and leaned against the doorframe.

“We’ve been over this before. The processes you put in place are good practices, Cedric. Just not the right ones for us, at least not yet.”

Cedric had been hired nine months earlier to address quality problems that ShipFast, a small, fast-growing software company, was experiencing. Cedric had been eager to take on the challenge of finding defects and putting quality processes in place.

So Cedric set about establishing a test group from the ground up. He hired testers, built a development environment, purchased defect tracking tools and various other test tools, and established entry criteria, test standards, and procedures. He trained his new testers in classifying defects and writing good defect reports.

Then, Sheila made it clear that Cedric’s group would test the next release for all projects.

Not surprisingly, there were some grumblings and protestations that testing would delay delivering software to customers. But Sheila stood firm and laid out the case for testing, and eventually, the development managers agreed.

Cedric’s group tested three projects in the first four months after they were up and running. Sure, there were glitches, but for the most part, Cedric’s attention to structure and process produced results. The testers found various defects and wrongly implemented requirements, and they duly wrote bug reports, logged the bugs, and ranked their severity.

Cedric produced metrics and reports and showed them to Sheila. He thought things were going well.

And then the grumbling started again.

“I don’t see what value Cedric’s group is adding,” fumed Marisa, one of the development managers. “The system crashes as much as it always has.”

“Sure, he’s finding defects,” chimed in Jason. “But half of them are known defects with workarounds. The other half are minor. If Cedric would ever talk to the helpdesk or us, he’d know that those bugs never happen in production. Those aren’t the bugs that are crashing the system—the reason the system crashes is that all the different applications are stepping all over each other on the desktop and bringing the network down.?”

“In the long run, I’d love to fix all these minor defects,” Marisa said. “But right now, I just want to keep the software from crashing.”

When the development managers tried to talk to Cedric, he dismissed them. “You don’t understand quality and process,” he sniffed. “You just want to hack.”

By the end of six months, the software was still crashing—and so were Cedric’s working relationships.

Where Did Cedric Go Wrong?

Cedric’s approach to establishing a test group isn’t an unreasonable one, and he’d been successful with this approach in the past. But the practices and processes that Cedric implemented weren’t addressing ShipFast’s most important problems.

Cedric’s first mistake was implementing his test group without understanding the context of the current environment. He came in believing that he knew exactly what the test group should be doing, and how they should do it. Cedric didn’t talk to the development managers or business people to understand what problems they were experiencing, and how he could help solve those problems.

Understand What’s Working and What’s Not

In almost every organization, some things are working well or the company wouldn’t still be in business. Investigate what’s working, as well as what’s not working. Part of any change is deciding what to keep.

If Cedric had investigated, he might have realized that functional testing was not their number one concern. The development managers were aware of many of the defects, but to them, and to the customers, system stability was more critical than the bugs they knew how to avoid.

Build Alliances

People are usually not receptive to a newcomer waltzing in and telling them they’ve been doing their jobs wrong. Understand what’s giving people a pain in the tush, and then help them see how your goals will help solve their problems or create the situation they want. People who see you as helpful are likely to reciprocate in the future. People who feel badgered and looked down on, as Cedric’s colleagues did, are generally less cooperative.

Work within the Current Situation

Cedric came in believing that there was one right way to do testing and one path to get there. When the development managers at ShipFast didn’t see things the same way, he dismissed them. Cedric may have established a test group in record time, but in the end, he failed in the goal of improving the quality of the ShipFast product.

Practices that fit at one company may not fit well in another organization, may not fit right now, or may not fit at all. Even “best practices” need to be adjusted to suit the current situation. The right practice is one that helps the company meet its goals.

Whether you are establishing a new test group, implementing requirements modeling, or bringing discipline to project management, successful change starts where people currently are. Understand the context, adjust practices to fit that context, and build relationships and alliances. The road may be less direct, but some of those detours—helping others to solve problems before putting out your own agenda—will help you reach your destination faster in the end.

convert this post to pdf.

“That idea won’t work here, because we’re different.” is a refrain familiar to the ears of consultants everywhere. Some people respond to this defense by using evidence and argument to persuade their clients that they are not so different, really, and this new idea will work if you give it a chance. I don’t know how successful that strategy is in general, but it doesn’t work well for me. I use a different tactic: I say “you’re right, it might not work here, because you are different.” This works pretty much every time.

Oh, I don’t mean that I convince them to do what I recommend, every time. By “this works” I mean that my response helps defuse the emotional energy behind the response by honoring the fear that sustains it — the fear that they will accidentally lose their identity as an organization if they pursue certain ideas too far. It’s a legitimate fear. Sometimes companies do lose touch with what makes them unique and special. Their fear is legitimate and honorable even when it’s important that they give up an old identity and take on a new one. Identity change is like dying. That’s why Peter Pan was afraid to grow up. Few organisms want to die, even for some reward in the afterlife — or later life.

I suspect a lot of problems with the diffusion of ideas come down to problems of preserving the integrity and identity of an organization. That’s why I’ve found it useful to look at change artistry in terms of pathogens and immune systems. I’ve learned to think like a disease in order to help my clients achieve what they desire. I didn’t say it was a pleasant metaphor, but it works for me.

Avoid triggering the immune response Everyone I’m asked to help has a psychosocial immune system in addition to a biological one. If I’m going to help them, I need to avoid triggering an immune response that will engulf me and my contributions. Here are some principles I’ve learned for doing that.

Share their identity

Get to know their DNA. Immune systems specialize in telling the difference between us and them. If I pass the “us” test, I get to contribute. If I fail the “us” test, I get isolated. Sharing their identity means that I understand their culture: the rules, protocols, values, vocabulary, etc. and honor it. I clothe myself in the familiar, and offer the unfamiliar only when coated in the “protein” of the familiar. I persuade clients using with their own familiar experiences, as much as I can.

Co-opt the immune response

I’ve found it helpful to accompany my work with self-criticism and other ideas for how my client can put the brakes on at any time. This makes it easier for the client to dismiss my work, but also makes them less frightened of me and thus less likely to raise an alarm. Thus, my own efforts to carefully explain the limits and caveats of my work can serve as a sort of proxy for an organizational immune response.

Co-opt whole the immune system

Assure that the goals of the immune system are achieved, and maybe it won’t flare up. Appeal to the opinion leaders (not just managers) as people. Find out what they want and need. Give them that. Sometimes I’ve been allowed to do certain things I wanted to do because I’ve been able to guarantee that certain stakeholders get what they want.

Avoid suspicious behavior

The immune response is triggered by certain patterns (of behavior, vocabulary, etc.) and evolves sensitivity to certain pathogenic strategies. So, I avoid the common strategies. For instance, I avoid hyperbole of any kind. I avoid using anyone else’s data. I avoid quoting authorities. I avoid flashy brochures. I embrace details. If I’m speculating, I say so. If my actions don’t match my plan, I try to be the first to point that out.

Small doses at first

Small efforts, perhaps even shielded from the eyes of management, are less likely to trigger alarm. That way, a successful outcome can prepare the way for a larger one that will withstand the immune response, and an unsuccessful one may not be so noticed that it inoculates the organization against future attempts.

Educate the immune system

If the immune system considers me a helpful vitamin, they let me alone. The challenge with that is that they don’t know, starting out, whether I’m helpful or harmful. So, I use the other principles, above, to get just enough time to show results. Eventually success will cause my DNA to be absorbed into the system, and become the new status quo.

Don’t kill your host

Successful pathogens leave their hosts alive. That’s why the common cold is so common, and we don’t talk about the “common Ebola.” What this principle means to me is this: even if my idea is expelled from an organization, the experience may still provide the basis for a future success or relationship, assuming that organization is not too sick of me. Furthermore, a favorable impression left with people in that organization may sow the seeds for future work with someone else.

Sometimes I’m glad to trigger an immune response from a client, because that may be an excellent indicator that I’m not a fit for that situation. Immune systems are designed to skeptical, because skepticism happens to work well as a defense against constant organizational disintegration. If it sometimes causes a client to reject an idea that I think is good for them, well, that won’t kill me. It may cure me, though.

convert this post to pdf.

These days, with all the talk about “internet time,” professional workers are always trying to be the first with new ideas. But is that really the only path to success? Is it, indeed, a very effective path at all? What about being second?

Our culture certainly encourages people to be “first.” In school, the emphasis ranges from who raises a hand first in class to who graduates with the highest grade-point average. The valedictorian – first in the class – gets lots of honors, but the salutatorian – second in the class – has to make the speech (phooey!).

Sports competitions also honor the “winner,” and books on problem solving and business often borrow this metaphor – emphasizing finding the “winning” idea before anybody else. But most problem-solving areas of life are not, in fact, like sports. It?s not having the idea that matters, it?s what you do with the idea that counts.

And, in fact, ideas don?t count that much in sports, either. Anyone can have the idea, “Hit a home run now and win the game,” but there?s a lot more to hitting home runs than simply having the idea. To have a fair chance of hitting a home run, you have to practice, practice, and practice. As in most of life, the key issue is not who is there first with the idea; the key issue is how you develop the idea once you have it. It?s not your ideas alone that win, but ideas plus capability and the will to develop your ideas.

If you think having ideas first is the issue, consider this. Every year, tens of thousands of individuals start businesses based on being the first with a “new” idea. If that was all it took to be wildly successful, many of these firms would quickly displace all of the giant firms and become giants themselves, every year! Yes, we all know stories of small firms that had a better idea and indeed succeeded at becoming giants, but most of the time, the giants persist and the midgets fall humbly by the wayside.

Giant companies survive the onslaught of little start-ups with one of two strategies:
1. Exploring many parallel ideas and developing the few good ones.
2. Letting others do most of the searching for ideas, then developing the few good ones.

What can the individual professional learn from these strategies?

Exploring many parallel ideas depends on having huge amounts of capital, which the individual professional cannot manage. But even giants couldn?t afford to have so many explorations in the pipeline if they didn?t know how to kill the ones that show no promise, and kill them early. So, for the individual, the lesson of this strategy is to learn how to let go.

For me, letting go means not trying to maintain leading-edge competence in every field in which I was once competent. I used to be one of the world?s great IBM 704 assembly language programmers, and I suppose there are still some jobs maintaining such code, but I don?t think I?d want them anyway. I?ve let go of that one, along with dozens of others.

Letting go also means that I don?t try to pursue every new fad I happen to hear mentioned at a conference or on the web – which leads me into the second strategy – letting others do most of the searching for me.
In a field where capital costs are low (like software development), chances are better that some small firm will come up with the good idea first because there are tens of thousands of such small firms out there. In that case, the big successful companies don?t rely on coming up with every good idea first. Instead, they pursue an “always be second” policy, and support it. They maintain some minimal competency in a wide variety of areas, so that they?ll readily recognize one of these good ideas when it comes along – from another company, or often from one of their customers. Then, they?ll either copy the idea, buy the rights, or buy the company.

I?m not able to buy companies, or even their licenses, but I am able to learn from them. And, under some circumstances, I can ally with them. That way, even a single individual can pursue an always-be-second strategy.
To be a great second, I use a process that resembles the way a breeder produces improved plants and animals, with three essential elements: variation, selection, and retention. Variation provides the new ideas; selection weeds out the ones lacking promise; and retention propagates the ones that survive the selection.

Variation (new ideas) for an individual, comes from using a network to supply information from literally hundreds of sources. By communication with people in my network, I can be sure that few new ideas escape my attention. I have created a huge virtual organization, far larger than any real organization I could afford. The AYE Conference is a central element of that network, where I can meeting many of my “nodes” face-to- face once a year and exchange ideas and experiences.

The network provides some of the selection, too. First of all, any idea that nobody passes on to me is unlikely to be a worthwhile idea. Conversely, when I hear of the same idea from three separate sources, I raise its “score.” Of course, in order for this selection process to be meaningful, I have to consider the reliability of my sources. For example, if I hear an idea supported enthusiastically by certain people, I reduce it?s score.
I work hard to keep my network alive and healthy so I can depend on it to do a good job of variation and selection. Ultimately, though, I have to rely on myself to select which ideas are worth retaining and developing, but the whole process is designed to keep me from developing “neat things” that don?t fit the market.

I don?t know how to automate the retention and development of ideas, so it takes a lot of work, and I can?t afford to develop very many new ideas the way a large organization might. Sometime I can share work by co- developing ideas (seminars, books, articles) with colleagues from my network. But ultimately, I have to develop in my own way, to create the unique service I can sell to my clients. This is the place where it pays me to be first – I may be satisfied being second in the race to market, but I always try to be first in quality.

convert this post to pdf.

We hear a lot these days about “reusable programs,” but we seldom hear about programs that shouldn’t be reused. Most programmers know what it’s like to be forced to reuse code that was supposed to be used only once and then discarded, such as:

1. prototypes, as for simple, quick formatting of output
2. one-time reports
3. test drivers and harnesses
4. research programs to probe some peculiar feature of the programming language, operating system, databse, or other “black box”
5. engineering assist programs, to help diagnose a hardware malfunction

These examples generally fall into two categories:

Frequently retained when they should be discarded:
protoypes and one-time reports, and

Frequently disposed of when they should be kept:
test drivers, research programs, and hardware testers.

That is, though all are thought of as single-use programs, the should-be-discarded software tends to be held somewhere, “just in case.” Only the should-be-kept programs are actually discarded.

If the developer is responsible for the decision, the program is likely to be discarded; but if the customer is responsible, the program is likely to be kept.

Developers discard programs because they understand tha reuse is not free. A program not designed and test for reuse, but brought out of hibernation will cost even if no requirements changes are requested by the customer.

1. The hardware environment may have changed.
2. The system software environment may have changed.
3. The size or format of the data may have changed.
4. The human environment may have chnaged, which might, for example, activate a part of the program that has never been invoked before.
5. Some part of the program or its supporting material may have been lost or damaged.

The longer the period of hibernation, the greater the cost – if for no other reason than somebody must check for one of these five conditions. But you already knew this – we all know this. then why, oh why, do we keep tumbling into the same trap?

I believe the answer lies in our unwillingness or inability to feed back the true costs of program development and program maintenance to our customers. Many software development vendors have reduced the problem to manageable proportions by the following steps:

1. When a program is commissioned, the customer must specify the lifespan and the number of executuions.
2. If there is uncertainty about either of these figures, the vendor bids contingent prices, reflecting the differing costs.
3. The vendor offers a contract stating that the program will be destroyed after a certain time and/or number of executions, whichever comes first.
4. The program remains the property of the vendor, unless the customer takes ownership. In such a case, the vendor places a much higher cost on the job – to pay for preparing the program to be maintained by other than the original developers.
5. The vendor notifies the customer when the program is about to be destroyed, and gives the option (at a substantial and realistic price) of rebuilding the program for further use.
6. If the original contract was for a “one-time” program, no notification is required. Instead, the vendor destroys all copies of the program as soon as the customer has accepted the program’s output.

Inexperienced customers readily accept these terms. So do very experienced customers, who know quite well the realities of “one-time” programs that turn out to be “N-time” programs. Only the in-between customers have difficult accepting these conditions, for they believe – incorrectly – that they understand programming.

In-house IT organizaitons – especially where there is no true chargeback for development or maintenance – have more difficulty teaching these lessons. The users pay nothing for specifying a one-time program and then asking that it be run N times. Without cost, they have little motivation to learn. With chargeback, however, in-house IT organizations can do what good, professional vendors do.

If you work in an in-house IT organization without chargeback, however, you can sometimes achieve relief by manipulating your one available parameter – time. You ask the customer to specify a one-time or N-time program and then give different time estimates for each. The one-time estimate is shorter, but carefully spells out the procedure that will be followed in destroying the program after its first use. Initially, users simply will not believe you will enforce this procedure, so get it in writing. After a few lessons – if you don’t submit to screams and threats – they will begin to understand the true costs. Only then will they devote some energy to making their initial decision of one-time versus N-time.

convert this post to pdf.

As some of you know, a group of consultants are producing a conference for our colleagues and clients. It’s called AYE, for “Amplifying Your Effectiveness.” One of the main goals of this distributed project is to apply our own methods of amplifying effectiveness to the project itself, and thereby to learn what works and what doesn’t.

My first big learnings have been in the area of unplanned delays. The project members are distributed all over the United States, and often travelling from their home base — a situation that’s more than familiar to many Contract Professional readers. I was concerned about the difficulties of conducting distributed projects, but one advantage of this potential handicap is the availability of an email record of what’s happening. So, when I started being aware of delays, I surveyed my email and came up with a list of what had been holding us up and frustrating me.

I suspect the list itself will be a nice reminder to me for future planning, so I also thought it would be useful to many Contract Professional readers. After laying out all the delays and what we’re doing about them, I’ll present a few general principles that might also be helpful to others:

1. One project member’s email is somehow delayed in cyberspace for 2-3 days, without anybody knowing it. The result is messages arriving in the wrong order, and producing confusion that produces more confusing messages. We vow to notice dates on email.

2. Rick’s color monitor fails, and Rick is our webmaster (a single point failure). We talk back and forth for a week, and by then his monitor is fixed. We lose a week.

3. I forget to sign one of two signature lines on a bank form establishing the project bank account. This delays the payment of bills for 10 days, which might have caused rippling delays — but didn’t because people had their own budgets and could pay the bills and trust they would be reimbursed.

4. Kevin breaks his hand, which is especially tough because he can’t use his Braille reader. This delays lots of things Kevin is involved in, but the primary delay is in delivering his article for our pre-conference book. This turned out okay, because he wasn’t the only one whose article was delayed.

5. Dave, who is developing our wiki-web site, gets the flu. This delays the entire wiki testing for a couple of weeks, but it’s not yet on the critical path.

6. Some security certificates (whatever they are) expire on my browsers, and my attempt to update them crashes my system. This non-understood bug delays many tasks for several days (but the effect was somewhat ameliorated by having an alternative browser).

7. Several people take vacations they’ve been planning for a year or so (how inconsiderate of them!). This wouldn’t have been much of a problem if we’d thought to put these vacations in our plan.

8. Naomi has a serious family situation, so she decides she must cut back on her participation until it’s resolved. This adds extra load to several other people, but we were not overloaded, so the schedule effect is minimal once Johanna, our project manager, reallocates the tasks. We are able to reduce Naomi’s participation to the one area where her contribution is least replaceable, and we can do that because we know exactly what Naomi is best at (helping other writers).

9. People who were not at our initial planning meeting have to be brought up to date — not just on our plans, but on the logic behind our plans. We haven’t planned for this, so it’s a real delay — but has an excellent side effect of making us rethink some of our logic before it’s too late to change.

10. James joins the team and has to be brought up to speed. Again, more delay, but with the benefit that James is a talented tester, and subjects many of our plans to tests that we haven’t thought of. James is also an excellent writer/editor, and can take up some of Naomi’s tasks. So, we paid with some delay, and were repaid with some later catching up. In other words, educating James about the project turns out to be a sound investment. Late in the project, however, it wouldn’t have had time to pay off.

11. Our phone and email lists are somewhat out of date at the start of the project, causing irritating delays until we stop and fix it. This contact information should have been done at the very beginning, as it is a core competency for a distributed project. Also, we needed plans for updating this information, because the project is about a year long, and over that period of time, some contact information will undoubtedly change.

12. Marie’s son gets sick, which takes her attention away from AYE business for several weeks. I begin to wonder why all these people are being so inconsiderate of our conference’s problems!

13. I find a strange new mole on my neck, and have to have what the doctor calls minor surgery. (Minor surgery is surgery done to someone else.) Then she finds another suspicious mole, and I have more minor surgery. Then I have a dental emergency (I’ll spare you the painful details). I begin to understand why all these people are being so inconsiderate of our conference’s problems.

14. We are putting together a book of essays by the conference hosts, to introduce people to our work. By definition, we have to have an essay from every one of us, but a few people are at the tail end of the curve with respect to personal pictures, bios, and essays. There are a variety of fine reasons for their delays, but the fundamental reason this is so troublesome is the structure of that part of the project. Since everybody has to have an essay in the book, finishing is like trying to get that last Pokemon card, or last number for a bingo. The mathematics of this kind of requirement ensures that such a project will cause anguish, and we eventually decide to relax the requirement that everybody contribute. If a few are missing, we can live with that. Relaxing this requirement relaxes those of us who are responsible for the book sub-project — and curiously enough, seems to cause all the pictures, bios, and essays to arrive on time.

15. Unfortunately, some of the articles submitted aren’t up to quality standards we had set, and they have to be recycled. We could save quite a bit of time by lowering our quality standards, but we decide against this, since quality is one of the key goals of our conference. What good would it do, we reason, to preach quality when we ourselves don’t practice it.

16. There are lots of typos in the material we prepare for our web site (ayeconference.com), but unlike many web developers, we believed that web sites do have to be tested. Therefore, these delays were anticipated and planned for by the web and project teams, and so fit within the schedule.

17. From time to time, some team member panics about some item or another — which takes time and effort to soothe. Our perfectionism is a major cause of these panic attacks; satisficing (learning to think about what was acceptable quality, rather than perfect quality) is a major cure.

18. Then there are holidays, delaying things in a variety of ways. Why couldn’t Jesus have been born in August, we ask? Poor planning, we concluded — was it by God or by us? Probably us.

19. And of course there is bad weather, which turns out not to hurt us as much as we expected because our travel is mostly virtual. We are lucky there, because the infrequent travel is more by personal preference than project planning. Most of us travel much of the time, and we’ve learned Freedman’s First Law of Consulting: Don’t fly on the East Coast in Winter.

20. We are hurt much more when my ISP (Internet Service Provider) starts delaying delivery of my email by 1 to 7 days. We are hurt even more when Steve’s ISP, which hosted our email lists, starts failing intermittently. Once we realize what is going on, though, we are able to bypass the convenience of group lists and simply maintain our own teams’ lists until Steve gets things straightened out with his ISP. Steve eventually realizes, though, that he had chosen his ISP because they were the low-cost provider — a lesson for next time.

21. Then, once we have all the essays and bios and pictures, we realize that some people haven’t kept the paperwork concerning their articles that they had previously published elsewhere. As one contributor says, “It just didn’t seem important to keep those legal things — at the time.” Lesson obvious, and lesson learned — I hope.

Conclusions

Well, there are lots more than twenty-one, but I think I’ll stop here. Some of us will publish the entire project’s delay list in the future; it will probably be a book. And we’re planning to conduct a retrospective at the conference itself. For now, though, I think you might like to look over the list once more and compare some of your conclusions with mine.

God may have other priorities higher than your project. Leave some slack for Acts of God.

Perfectionism kills schedules; reasonableness saves them.

Certain project structures make success as likely as winning the lottery. Search out and eliminate this lottery effect from your project plan. Not only does this eliminate “bad luck,” but it also lowers psychological pressure on participants, which leads to “good luck.”

Quality is negotiable, but not infinitely negotiable.

Plans are predictions; plan to test them early and often, and then adjust them.

Machines fail. Software fails. People are even less perfect, but they’re more adaptable, so they’re handy to have around to back up the machine systems.

If you have a single point of failure, it will fail at a single point in time. After that, if you have any brains at all, you’ll remove it.

Cross-training is one of the surest ways to protect against those single points of failure. So is a good asset control system for all your project’s assets. If you fail to follow this system because “it doesn’t seem important,” you’re sure to lose your assets.

You won’t be aware in advance of all possible single points of failure, but if you do some risk analysis, you’ll be aware of many of them, which will leave you more time to deal with the ones you weren’t aware of.

You won’t appreciate other peoples’ delays until they happen to you, but try to learn to grant them a generous interpretation. This may calm you down sufficiently so that you can actually become part of the solution, rather than adding your blaming to the problem.

And, finally, I often hear my clients telling me that their project will make its schedule “if everything works out right.” Well, I’ve been in the project business for over forty years now, and I’ve seen several thousand projects. I’ve never seen one where “everything works out right.” This has led me to formulate Jerry’s Iron Rule of Project Life:

It Always Takes Longer

Defy this Iron Law at your peril. Plan for delays, and plan to be adaptable and forgiving when delays occur that aren’t part of your plan. You’ll be more successful, and you might even be happier. As of now, we’re on schedule for November, and we’re rather happy about it.

convert this post to pdf.

People are always asking me to make predictions, especially predictions about their financial future. Which stocks will grow? Which dot.coms will fold? What jobs will be best? What should they study to prepare for their future jobs? Predictions are difficult. Well, actually predictions are easy – unless you want some accuracy. Since I’d feel responsible if I hurt somebody with a poor prediction, I seldom accept their invitation to predict.

Let me give some examples, starting with some predictions that, had I listened to them, would have seriously hurt my career as a writer. I have published about 40 successful books, yet I still don’t understand how publishers make predictions. The most successful of my books has been The Psychology of Computer Programming, which was delayed more than a year by a series of publishers who couldn’t decide what to do with it.

I first sent it to the company that had published all my previous books without hesitation. Here’s what they said: “It just is not worthwhile pushing this project any further. It may be that the concept is good … but the style and breadth of presentation is just not suitable. It could be that a major overhaul and rewrite will result in a marketable project. On the other hand, it may be wiser to forget the book concept entirely…”

The book was not overhauled, nor rewritten, but it was turned down by another publisher before it finally found a home. It’s now been in print for more than 30 years, and has sold over 100,000 copies in English, and many more in other languages. For the company that eventually published it, Psychology sold more copies and made more money than the next five books in their line. In retrospect, the two publishers who declined the project proved not to have much predictive power.

My second most successful book so far has been An Introduction to General Systems Thinking. Naturally, I sent this manuscript first to the perceptive publishers of Psychology. Here’s what they said: “Our referee believes that the market for such a volume is limited. With this in mind, I do not believe it is for us.” This one has been in print now for over 25 years, and has sold more than 50,000 copies.

The same pattern now holds for my third most successful book, The Secrets of Consulting, and the fourth, Are Your Lights On? – how to know what the problem really is, and the fifth, What Did You Say? – the art of giving and receiving feedback. And none of my less successful books, so far, have ever been turned down by publishers!

Experiences such as these have brought me to the reluctant conclusion that publishers know a lot about predicting the future success of a book – but what they know is exactly backwards. Or at least for new and different subjects. Shakespeare goes in and out of fashion, but even at low ebb sells pretty consistently. Algebra books compete with one another in a comfortable, steady market, as do introductory books in such subjects as economics, physics, philosophy. Books in such areas are more predictable, but, then, they’re less likely to make a big splash.

In computing, it’s not so steady, and predictions are even harder than with books. For publishers of computing books, the subject of tomorrow’s best-seller is unknown to today’s editor. Editors don’t follow the field; they follow the publications in the field. Unless and until somebody else publishes a book on the subject, the editor doesn’t consider it a subject at all. Those blinders are evident in the subjects of those books of mine that became the best sellers. Before the Psychology of Computer Programming appeared, the psychology of computer programming was not a subject.

Magazine and newspaper publishers have an easier time in a fast-moving field, because their publications generally get trashed before they become obsolete. Who reads last year’s Contract Professional to learn about the future of the job market?

But some of my friends do keep old copies of magazines, and I keep them if they contain an article of mine, so some evidence of successful or unsuccessful predictions remains for us to study. One of my friends sent me this prediction from Popular Science, May 1967, page 93:

“Timesharing, most experts agree, is the key to the computer’s future, at least for general use. A few years ago, when people thought about household computing at all, they thought of some small, inexpensive, individual unit that would keep track of the family checking account and automatically type out the Christmas card labels. Now we know it won’t be like that at all.

“The reason is economic. The bigger and faster the computer, the cheaper it makes each computation. Consequently, it will be far cheaper to build one monster computer with thousands of customers hooked to it than to have small, individual machines in individual homes.”

Here’s another prediction taken from the September, 1962 Datamation, which I happen to have because I had an article in it. (The article incidentally, was about how to make fake demonstrations, and that seems to be something we’re still doing 40 years later. Sound familiar?) Anyway, IBM’s 1962 recruiting ad said,

“IBM programmers … are devising programs that in turn use machine capability for formulating new programs. They are creating programs that enable computers to diagnose their own faults through self-checking. And they are helping to design the systems that will let scientists and engineers ‘talk’ to machines in the everyday language of science and engineering.”

I don’t know about you, but I hope they finish these projects before I retire. I so much want to talk to my computer in the everyday language of science and engineering. (Sound familiar?)

Patrick Henry once said, “I have but one lamp to guide my life. I only know the future from the past.” So, if the past can be used to make predictions, what predictions can we make using past predictions as a guide? Here are some that I’ve made, for myself:

1. Editors will predict what will be popular in the future. So will recruiters. They will be wrong.
2. People will predict that computers will get so cheap that programmers will be eliminated. They will be wrong.
3. People will predict that thinking and problem solving and other human activities will not be as important in the future as in the past. They will be wrong.
4. People will predict that there won’t be anything really new to do with computers (just Christmas-card labels and everyday language of science and engineering). They will be wrong.

So, here’s my advice for the future. Read some books, but not too many on one subject – and don’t take editors too seriously. Learn the most general of skills – how to think better and how to work with other people more effectively. Then look for jobs where you can apply those talents to build new things – but probably not things that are going to replace people. And, if you follow my predictions, you’ll probably have good jobs and good pay your whole life.

But I’m probably wrong.

convert this post to pdf.

What does it say about the participants of a weekly meeting when the meeting consistently starts 5-10 minutes behind schedule?

Answer, the participants are cooperating with each other to start late.

Starting late is the status quo.

Let’s explore:

1. Are you cooperating with the participants of your meetings
   to start late?
2. How do you feel about that?
3. How do you feel about feeling that way?

Let me share how I would have answered the questions in 1990:

1. Yes, I have cooperated with others to start late
2. I feel powerless to change the status quo
3. I feel angry about feeling powerless

I have never liked feeling angry. But I felt powerless to change the status quo so what could I do about the situation?

I had more power than I first thought. I took a deep breath. I decided to arrive before the scheduled start time. I encouraged other participants to arrive early. I worked to become a meeting leader; and, when I became a leader, I demanded that people arrive on time.

Arriving early and encouraging other participants was successful at bringing more people into the room before the scheduled start time. Becoming a meeting leader and demanding that meetings start on time was a failure.

Despite my embarrassment, let me share just five of the many interventions I tried as a meeting leader to cause meetings to start on time:

• Rescheduling the meeting to a start time all participants agreed
  would work
• Contracting with the participants to arrive on schedule
• Locking the door to the room at the scheduled start time
• Cancelling meetings when an agreed upon quorum wasn’t present
• Publishing the names of the late arrivers in the meeting minutes

After gaining feedback from these interventions, I realized that successfully starting the meeting with all of the participants required the cooperation of, surprise, all the participants. The decision about whether we started on time was theirs to make.

Rather than fighting the status quo, I thought, “Why not make the status quo visible so every participant can decide for themselves whether it is acceptable?”

So Agenda Item #1 for all my meetings became Wait for people who arrive late. All the agenda items in my agenda have durations. I assign the duration for item #1 as the difference between the actual start time and scheduled start time of the previous meeting.

The agenda item looks like following:

#1. Wait for people who arrive late. 10 minutes

Regardless of why the status quo existed, its existence is out there for everyone to see.

What happened?

Reactions varied: Some participants didn’t react to the agenda item. They seemed to think it signaled nothing. Some participants commented that they thought the agenda item started the meeting out on a sour note and wanted it eliminated. And some participants thought starting late was unacceptable and they wanted to do something about it.

It’s easy to sense which reaction creates an opportunity to change the status quo.

Agenda Item #1 offers the opportunity for people to choose whether they want to continue the status quo or start changing it. I wish I could tell you agenda item #1 always triggered a change that caused a meeting I led to start on time. It didn’t. It does, however, always offer an opportunity for the participants to choose again. And sometime that’s all that’s need to trigger the change process that creates a new, more effective status quo.

You may be wondering, Does starting meetings on time truly matter? I believe it does. If people are the organs of an organization, then meetings are the organization’s lifeblood. These gatherings are where people come to define, solve and status problems. The more healthy a meeting, the more healthy the organization. And, conversely, the sicker the meetings, the sicker the organization.

If the people who participate in a meeting can’t cooperate to start their meeting on time, what chance is there they will cooperate to start a project on time? I you were a member of a relay team running a race against another team, would you agree that everyone on the team can arrive for the race whenever it fits for them?

The same people who participate in meeting are the same people who are responsible for the tasks in a project. A meeting is nothing but the simplest of projects. My experience is that attitudes of participants at meetings mirror their attitudes to their task work and the project as a whole. How could they not?

How healthy are your meetings? If they are sick, gaining cooperation about starting on time and actually starting on time will make them healthier. It’s not easy to change the status quo, but it can be changed.

convert this post to pdf.

I’m forty-five, with a mainframe background. I often hear complaints from colleagues — associates who are my contemporaries — that younger workers with experience in hot, new technologies are getting paid as much or more then them. They are certain that twenty years of experience in the industry entitles them to higher pay. Surveying my contemporaries, I am certain that some of them do have wisdom that is worth more pay. But I am just as certain that some of my contemporaries aren’t worth any more pay than a younger or less experienced worker.

I reached my conclusion after amusing myself with a comparison between me today and me in my early twenties. To simplify this written comparison I’m going to refer to me twenty years ago as “Young-Steve.”

Young-Steve was a monomaniac on a mission. He was fanatically dedicated to his work; twelve or more work hours per day was normal. He intuitively understood that his most marketable asset was his thirst for knowledge and relentless drive. So Young-Steve worked and worked and worked. He thought older colleagues who seemed less dedicated than he were less valuable. For instance, Ed — one of Young-Steve’s older colleagues — told him that, at night and weekends, he would put his telephone in the refrigerator to avoid after-hour questions about his System from the Operations staff. Although the quality of Ed’s System was excellent, he seemed lazy and unprofessional to Young-Steve. It would take some years for Young-Steve to understand that Old-Ed had other relationships that were more important to him than work. Young-Steve couldn’t understand how anything could be more important than work. But he would learn.

Young-Steve saw a world where everyone in computing played the “waiting game” for pay increases. Young-Steve was a computing whiz kid, so Management was happy to give him three jobs — and happy to pay him less than someone with ten years of experience who was only doing one job. Young-Steve thought those kind of pay decisions were weird, but learning about computing gave him so much joy that he didn’t care. Now it’s clear to me that Young-Steve deserved higher pay than someone with just “experience.” Today’s job market is more competitive, and if a younger person can do more they can get paid more. I applaud this outcome — it’s long overdue.

How would I stand up in a competition between me versus Young-Steve? Because of Young-Steve’s thirst and dedication, he would positively outdo me when it came to learning and exploiting new technology. The quality of his products would be, given his understanding of the requirements, excellent. Of course, Young-Steve would work to his own requirements, rather than the customer’s, and his decisions would sacrifice economy and delivery speed for quality every time. Young-Steve lived for his work, so delivery delays and extra hours seemed more than a fair tradeoff for a quality product. Hell, for Young-Steve the extra hours were fun.

I would positively outdo Young-Steve at understanding the customer, exploring their requirements, making explicit tradeoffs, and delivering a product tailored to the customer. I would also outdo him if the product required a group effort. I know how to tap into the power of a group. Young-Steve had the potential to work with groups, but he preferred being a hero.

It’s tempting for me to say now that Young-Steve didn’t have a life, but I believe that statement is false. Young-Steve was very happy twenty years ago. He just measured his value almost exclusively from work. And with so much emphasis on work, Young-Steve neglected relationships away from work. That choice cost him dearly.

Who is more valuable, me or Young-Steve, depends on the type of work, and the customer. Young-Steve gets the check mark if the work is more than 80% technical. I get the check mark if the work is more than 20% about influencing other people. When the customer acts erratically, Young-Steve gets the check mark because he would do almost anything in his power to satisfy the customer. I get the check mark if the customers need help understanding what they already know and adding to that knowledge. Young-Steve gets the check mark for sacrificing his life away from the job for work to meet customer demands. I get the check mark if the work requires setting boundaries and pushing back.

I’ve tried to compare us, but it’s hard because there really wouldn’t be a competition. I’ve changed. The work that interests me wouldn’t interest Young-Steve. He would want a narrow focus on technology, and I now want to focus on helping organizations improve their productivity. Although Young-Steve would outdo me technically, I could compete in that arena: Young-Steve couldn’t compete with me in my new mission. He doesn’t have the skills yet.

Let’s look at me now. I no longer inflict my opinions on people. When asked by Management for my opinion, I try to be practical and realistic, rather than optimistic. I haven’t forgotten the hard lessons I’ve learned over twenty years. I work to get the job done, rather than working for the pure fun of learning. Token management awards for working long hours that would have excited Young-Steve now turn me off. A project schedule with months of long days no longer fits me and I won’t put up with that kind of workload for very long. I want a project that is under control and doesn’t squander my time.

Everyone doesn’t share that priority. In my experience, managers in many organizations believe their very survival depends on increasing delivery speed. Those managers sacrifice — many times unknowingly — quality and economy to satisfy their desire for speed. And if delivery speed is the principal force behind management decisions, then young people with raw, adaptable technical skills are more likely to accept that force more easily than older workers. Younger and less experienced workers, like Young-Steve, are optimistic and want to please. They are more willing to march to the beat of a project that other workers — people who know how to detect unhealthy projects — would avoid because they would diagnose it as a deathmarch.

The world isn’t fair and it never will be. Someone with five to twenty years of experience isn’t necessarily any better than someone with no experience. What we do isn’t union work, so seniority is a meaningless idea. I know people with twenty years of experience that haven’t learned a new thing in nineteen years. If you have gained wisdom — and it can’t be scheduled or guaranteed — then you’re worth a whole lot more than either the young technical whiz or the person with twenty years of not learning. One sign of wisdom is knowing how to sell the value of your wisdom to a customer or employer. If, on the other hand, you can’t figure out how to articulate your wisdom and how to do sell it, then you don’t deserve better pay than the young whiz kid working next to you.

convert this post to pdf.

Do some members of your team make agreements during meetings but fail to support them afterwards?If this behavior is happening, I suspect your team is using an obscure process to make decisions.

Identifying Obscure Process

An obscure decision making process is easy to identify. Ask each member to create a map of the process used to make team decisions. If the individual maps aren’t similar, obscure is an accurate description of the process.

Probe the maps of an obscure process further and you will find false assumptions. Members assume things about the behavior of other members that isn’t true; for instance, some members assume that their teammates will support the decision made by a team and how it was made with outsiders and yet some other members assume that their support is only necessary when they personally agree with the decision.

I believe an obscure decision making process disables teamwork. People aren’t connected by shared principles. They don’t cooperate. They work like a group of individuals. It doesn’t have to be this way.

I have worked with a simple, clear process for making team decisions for over a decade. I have found it highly effective. It’s designed for teams who make their decisions by consensus. If you are the leader of a team, you may object to the idea of a consensus decision. The idea may trigger the word “groupthink” to pop into your head. But as I will discuss later in this post, a leader has more control over a consensus decision than they might initially think.

Making Team Decisions

The aforementioned simple process is called Roman Evaluation. Figure 1 is a map of the process. Using the process creates visible feedback about the state of each member’s agreement on a proposed team decision. That feedback drives needed discussion and eliminates unneeded discussion.

Figure 1. A Map of the Roman Evaluation Process

Follow the following four steps to help a team reach a decision:

1. Propose

A proposal that defines a course of action desired by a member of the team drives the process. Without a concrete proposal, there isn’t any decision to be made.

The first four words of any proposal are “I propose that we…” This wording explicitly announces the proposer’s desire; for example, “I propose that we reduce the duration of this meeting to 60 minutes.”

Note, the word “we” is used to clearly identify that it is a team decision.

Post a written copy of the proposal in the room so that every member is able to read it own their own during the entire decision making process. The proposal may be amended so leave room for changes.

I would write the proposal mentioned earlier as, “Steve proposes that we reduce the duration of this meeting to 60 minutes.” Communicate it to the group using whatever medium you prefer, such as a flip chart, overhead projector or computer projector.

2. Discuss

Let the proposer speak first so he or she can provide context. Start facilitating a group discussion with an explicit duration. The purpose of the discussion is to understand the proposal and its impact. Using the example, I might ask the proposer: “What’s the problem you are trying to solve by reducing the duration of the meeting?” I might ask the team, “What do you think?”

My experience is that groups often exceed the time allocated for discussions so constantly monitor the time and periodically share how much time remains. Whenever either the discussion naturally ends or the time limit expires, close the discussion and vote.

3. Vote

A group recognizes their agreement faster with clear signals. Ask each person to signal their decision with one of their thumbs:

• Up means “I agree.”
• Sideways means “I will accept the majority’s decision and support it.”
• Down means either “I disagree.” or “I have something to say.”

I suggest that you emphasize that a thumb up or sideways means the member will support the proposal. Spell out that support means they will say “We decided to…” when asked about a decision by an outsider (see my post entitled Word Choices — We — Part 2). And they will defend the logic behind why the decision was made. This understanding makes voting a serious responsibility rather than a ho-hum exercise.

The vote gives the team clear feedback about the state of their agreement on the proposal. It enables different choices to be made than are possible without feedback.

Record the vote and verify that you have the same number of votes as members. A consensus is any mixture of thumbs pointing up or sideways. Any thumb pointing down signifies dissension.

4. Process

As you tally the vote, write down the names of people with their thumb down. Ask each dissenter, name by name, what he or she would like to say about their vote. Don’t let anyone interrupt them. When each dissenter finishes, ask them whether their thumb is still down. They may surprise you. My experience is that many people want to say something and once they do, they move their thumb up or sideways.

If there is still dissent, ask the team whether someone wants to amend the proposal. If someone offers an amendment, discuss, vote, and process. Otherwise, reject the proposal.

Considering Consensus

As you may have guessed, I believe in consensus decision making. Some leaders have told me they don’t like it though. They believe it leads to “groupthink.” I understand the thought, but that doesn’t happen. If the leader makes it clear that in the absence of a consensus they will decide on the course of action, groupthink is impossible.

The leader is a member of the team. They vote on a proposal. And, like all the other members, they are free to vote so the team makes the appropriate decision. If they put their thumb down and an acceptable amendment can’t be found, then they are free to make the decision they think is best.

I suggest that leaders don’t make a habit of using this power. But, in my experience, some situations demand decisions in a faster time frame than a team may be able to process them.

Conclusion

Roman Evaluation has a powerful effect on decision making. It connects the members of the team. It creates shared principles. It increases cooperation. It helps build a solid foundation for teamwork.

When reinforced, the act of voting makes it clear that unless a member vetos a proposal, as a member of the team, they are expected to support the proposal. And that’s the kind of thinking that binds a team together.

If your team’s decision making process needs improvement, I can help. Contact me.

convert this post to pdf.

Three of my favorite quotes about change and translations:

“The only person who likes change is a wet baby.” This change corrects a problem so I’m OK with it.

“Everyone likes change, when someone else is doing it.” I’m OK with the status quo. You do the changing.

“The only universal constant is change.” Get used to changing. The universe constantly changes so you need to change too.

If change is so inevitable, why do people, teams and organizations experience so much difficulty changing? We should be good at it!

In fact, we are good at change, but in our own particular way. Any given change carries two factors. The requested change, and how we feel about that change. Recently while cooking, I grabbed the handle of a pan that had been in a 350 degree oven. It didn’t take long before I let go of the handle. I had no trouble accepting the need for this change.

Not all changes, though, are as universally accepted as dropping the hand of a hot pan. Suppose everyone were required to shave their head. This change wouldn’t bother me and I’d readily shave my head. Johanna Rothman assures me she’d have a big problem with this change and be very slow to change. This typifies “You go ahead and change. I’m happy with the status quo.”

Change Quotients

If we ignore neurologically requested changes (like letting go of the hot pan handle), we can view the ratio of the change/willingness to change as a quotient. As we average all the quotients over many situations for one individual, we arrive at a statistical value I’ll call that person’s Change Quotient. The Change Quotient relates to how open a person is to change.

Change Quotients vary from 0 to 1. Values close to 0 indicate a preference for slow changes and value approaching 1 indicate people who readily change. We each have a unique change quotient. 0 doesn’t mead “bad”, and 1 doesn’t mean “good”. The values simply indicate a preference.

People with lower change quotients often view those with high change quotients as chaotic and “flighty”. I was once asked to “make up my mind” when in fact I’d already made my mind up and shared the results twice while the other person was still thinking.

Conversely, “glacial” describes low change quotients to those having change quotients approaching 1. These people seem to reject instantly any suggestion to change, even something as simple as removing their boot from your bare toes.

Several things contribute to our Change Quotient. Any proposed change runs a gauntlet of survival rules, self-esteem, and personality/family checklists. The gauntlet forms our “willingness to change.”

Survival rules perform as “mental reflex actions”, the things we do, the thoughts we think, and feelings we have, that we don’t consciously think about. We build most of our survival rules by repeated assertion, usually by our parents or respected adults, of things to keep us alive. “Never make a decision until you have all the facts.” “Don’t be wishy-washy–make up your mind.” “Be your own man–don’t let others push you around.”

Self-esteem reflects how we currently feel about ourselves. This fluctuates based on our physical state (rested/tired, healthy/sick), our mental state (happy/sad, exited/bored) and how we feel others view us.

Our family creates our initial world view. Some families view consistency and slowness to change as admirable qualities. Others feel adaptability and responsiveness are desirable attributes. Each one of us starts with our family’s view of change start with this view.

Personality builds on this foundation. We add our experiences, successes and failures, to build new rules about change. Which kinds of change we can accommodate (or welcome) quickly, which changes we need to consider, which changes we want to avoid.

Responding to Change

Some years ago I found out that I was not really in charge of everything, and actually in control of very little. This led me to

Don’s Dismal Dilemma: How will I achieve my goals, when I’m not in charge or control?

Physical systems follow patterns established eons ago. Friends do what suits them. My clients determine when and where I’ll work with them.

As time progressed, I found the one thing in the universe I have complete control over: me. And so I found

Don’s Delightful Discovery: I can’t control what happens to me, but I can control me, and how I respond to what happens to me.

As Virginia Satir said, “We can direct our efforts to change what we can and to work out creative ways to live with what we can’t change.” [New Peoplemaking, pg 7]

When we quit changing with our environment, we face extinction. We need to update our mental models so they conform to current reality. As we grow and mature, our realities change. Our mental models need to reflect the changes. Mental models formed in childhood and not updated make for interesting adult behavior. Dad warned me about getting “Hardening of the Attitudes”. (Notice the survival rule that affects my change quotient?)

Changing allows me to achieve my goals. If the goal doesn’t change, and external events (by definition beyond my control) change the situation, I need to change my actions (I control these) to bring the results in line with achieving my goal. Or perhaps my actions aren’t producing the results needed to achieve the goal. Again change becomes necessary to realign with my goal. If I don’t change what I’m doing, my actions will take me away from my goal.

“Insanity: doing the same thing over and over again and expecting different results.” Albert Einstein

Occasionally I need to change my goals. As I learn more, what used to be important may not be important now. Changing goals allows me to work on what’s important to me.

So what to do? The answer depends if you are the changer or the changee.

For the changer …

Asking other people to change can appear as “Inflicting Help.” Insisting other people change borders on foolhardy. Think about the following:

1. You’ve already thought through the change, they haven’t. Allow some soak time.
2. Are you really solving a problem? Check out “Solving Other People’s Problems.^“1
3. Expect people to react differently at different times to different change requests.

For the changee …

Rhonda’s Second Revelation: “When change is inevitable, we struggle most to keep what we value most.” – Jerry Weinberg

1. Remember everyone has a different Change Quotient. What you see as change, they may view as stable.
2. The Helpful Rule reminds us “Regardless of how it looks, people are trying to be helpful.”
3. Share with the changer what is most valuable to you.

I’d like to share my favorite quote about change:

“Change happens one person at a time.” Virginia Satir

And you can always change your mind about how you change.

¹ Amplifying Your Effectiveness: Collected Essays, Dorset House, ISBN 0-932633-47-1, pages 17 – 21

convert this post to pdf.