A Code of Work Rules for Consultants

I frequently meet a consultant who is deeply troubled by the implications of the work of a consultant. What we do today may affect the lives of thousands or millions of people for many years to come.

Moreover, most of those people we affect won't have any way to relate a discomfort in their lives to what we are doing today.

They will, perhaps, sheepishly accept the explanation, "That's the way the computer must do it," or the even more insidious, "that's the way things are."

Some consultants I know, particularly those working in shops where nobody ever looks at anybody else's work, salve their conscience by sabotaging their client's information systems.

In many cases, it's difficult to tell whether this is intentional or unintentional. In other cases, there is no doubt.

Many programmers, analysts, and consultants have complained to me that their work holds no meaning for them. They don't know what is being done with the piece of design or specification they work on, or they know and don't approve.
Their response is to stay on the assignment, draw their fee, and badmouth their client at every safe opportunity.

I think it's time we stood up to be counted. We have an enormous responsibility to the people whose lives will be impacted by the organizations we work for.
If we don't believe in what our client is doing, or we don't understand it, then why are we working there? To draw a fat fee? Then what does that make us?

For some years now, I've been giving a set of principles to consultants who are seeking a new assignment, or are considering changing their present assignment because of such doubts.

In recent years, as the job market shrinks, the number of such doubters seems to be increasing so I thought that many professionals would like to see these principles written down:

1. I will not work for an organization whose goals are not consonant with my beliefs.

2. I will not work on projects whose goals I do not understand, or cannot agree with.

3. Before becoming part of a project, I must first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.

4. I will not work under measurement schemes that pit one person's performance against another's. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.

5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.

6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.

7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

Over the years, I've found that people who ask these questions and set those conditions don't wind up in jobs that make them miserable. Sometimes, when they ask them honestly they leave their present position for something else that makes them happier, even at a lower fee scale.

Sometimes, a client manager is outraged at one of these conditions, which is a sure indication of trouble later, if not sooner.

Many of us lost souls need some guidance, and it might have been easier to have a set of principles when the job market wasn't so tight. But over the years, I've learned that consultants following these principles are more successful at landing good contracts–ones that make them richer and, more important, happier.

The Fundamental Regulator Paradox

Read all four articles, but esp. these and the following paragraphs:

Amplify’d from www.developsense.com

Blog: Project Estimation and Black Swans (Part 4)

So: we can’t predict the unpredictable. There is a viable alternative, though: we can expect the unpredictable, anticipate it to some degree, manage it as best we can, and learn from the experience. Embracing the unpredictable reminds me of the The Fundamental Regulator Paradox, from Jerry and Dani Weinberg’s General Principles of System Design which I’ve referred to before:

The task of a regulator is to eliminate variation, but this variation is the ultimate source of information about the quality of its work. Therefore, the better job a regulator does, the less information it gets about how to improve.

This suggests to me that, at least to a certain degree, we shouldn’t make our estimates too precise, our commitments too rigid, our processes too strict, our roles too closed, and our vision of the future too clear. When we do that, we reduce the flow of information coming in from outside the system, and that means that the system doesn’t develop an important quality: adaptability. Read more at www.developsense.com

 

See this Amp at http://amplify.com/u/dzht

Mnemonics

How do you remember things?

I remember pi with a little poem I created some forty years ago:

C over D

Yes. I have a trick, sequences to recall,
Using one plain mnemonic faultless ordinal,
Breaching all of the barriers that retain pi–
Bereft, will all lax thinkers die,
By circles overborne?

(Pi to 30 digits, with the decimal point and a question mark at the end signifying there's more to come.)

So, how do you remember things?

Give us a comment, so we can improve our memories, too.


Or would you like a machine that replays movies of your memories?

The Aremac does that: Read:
The Aremac Project in Paperback
The Aremac Project as eBook



A Workshop to Remember

And remember, the Problem-Solving Leadership Workshop (PSL) is coming in May, and fills up fast. So tie a string around your finger, or visit my website

Rumors of My Quitting Are Grossly Exaggerated

InfoQ's website ran an essay that said:

"Now he doesn't do that much in software anymore, he writes science fiction [and] he runs his AYE Conference, which is a human potential kind of conference."

I tried to reply, but their reply function crashed on me, so I'm putting my response here, to clear things up:

Gee fellas and gals,
Well, I was slowed down for a year while beating "incurable" cancer. bit how many of the rest of you have published even one book on software in the past two years? (I've done several.)

If that isn't "much," then how about my Problem-Solving Leadership Workshop (PSL), or my keynotes at software conferences? And AYE is principally for software folks, just like your website. Isn't your website "doing much"? (I think it is.

And, then there's consulting. Don't my clients think they're doing software?

Maybe my novels are confusing you (and others). They're entertaining stories, to be sure (at least I think so, but see for yourself). But they are full of s/w lessons--just another one of the ways I'm trying to get these lessons across. You know as well as I how hard that is. So, after 50 years, I decided to try something new--in ADDITION to my other activities--books, essays, blogs, workshops, conferences, consulting--AND responding to other people's blogs, like right now.

Thanks for listening. - Jerry Weinberg

Visit my website if you'd like to know more about what I've been doing.