Thursday, December 22, 2016

What does it take to become a good management consultant?

When the question in the title came up, all the answers seemed to be answering a different question, something like 

What does it take to get a good job as a management consultant in a large consulting firm?

Lots of people who are not good consultants get jobs as management consultants in large consulting firms. And lots of good consultants can't get jobs with such firms. I know these things because I've been a consultant (a consultant's consultant) to a number of such firms.

If you really want to know what it takes to become a good management consultant, the answer begins with the observation that there are many different styles of good management consulting. The most important quality good management consulting requires is the ability to know yourself, both the good and the bad, along with the ability to retain the good things and improve the bad ones.

To take one example, consider health. I’ve watched many would-be management consultants fail because they couldn't control their drinking or eating habits when traveling on an expense account.

Or another example is would-be consultants who think their domain knowledge will be sufficient for doing a good job, but they lack "people skills." They believe, erroneously, that they can be arrogant, offensive, non-empathetic consultants but people will hire them because they're so smart and well-informed. They're wrong, and most of them never realize why they're failing. That's why I've written a number of books for consultants who wish to improve their consulting success:


Want to see a list of my books?

Saturday, December 17, 2016

What's the most touching thing to say to a teacher?

What's the most touching thing to say to a teacher?

The question was, "What's the most touching thing to say to a teacher?" There were many fine answers, and all of them said more or less the same thing: thank your teacher for changing your life.

I agree that telling your teacher “thank you” can be touching, but in my 60+ years of teaching, it’s only the second most touching thing. So, what’s the most touching?

What touches me most is when a student teaches me something I did not know. That shows me that the student has become a contemporary, a grown-up person who will go on to teach others, part of the great chain of “paying forward.” When that happens, I know that I have succeeded in some small way of helping that student and the world in which we all live. That’s what touches me the deepest.

Moreover, in my career such learning has happened thousands of times. If I am a better teacher today, a better human being, I owe it all to my students. Thank you, students. Thank you.


See, Experiential Learning for more on how and why I learn from my students, so you, too, can be touched by what they teach you.

Monday, November 28, 2016

How do I find cheap freelance hardware and software developers?

The question was, "How do I find cheap freelance hardware and software developers?"

I warned the questioner to be very careful about what he was asking for:

First of all, you don’t want “cheap” developers; you want inexpensive developers.

Second, the expense of developers is not their hourly or daily rate. It’s the total cost of building and delivering the software and hardware you want.

In my experience, the least expensive developers have much higher rates than the more costly ones. The deliver what you want, the first time, in less time, with less trouble.


However, a high hourly rate doesn’t guarantee an inexpensive product. Freelance developers can charge anything they want, so price doesn’t necessarily indicate value.

Instead, speak to references about any developer you’re considering. Find out first hand what you’re going to get for what you’re paying.

And, by the way, don't think you'll save money by hiring individual developers. Your best bet will generally be to choose a team, perhaps an Agile team, but in any case, a team that has a history of working well together.

Wednesday, November 09, 2016

How do I choose the right career?

The question was, "How do I choose the right career?"

My answer was, "You can’t."

Other responders told you things about how to choose your right JOB, but a job is not a career. Maybe before the 21st century, the world of work was sufficiently stable that one could choose a career, but not longer.

For instance, I’m an old guy so I’ve had sort of a career—in computing. But back in the 1940s, when I asked this question, computers didn’t even exist. At least, none of my career counselors knew of them.

And even for the 20th century, I’ve had a rather stable career. My wife, on the other hand, started out to be a concert pianist, then became a musicologist, then a piano teacher, then an anthropologist, then a management consultant, then a world-class dog trainer, and right now is an animal behavior specialist. She works primarily with canines, but until she was 33 years old, she was deathly afraid of dogs.


In other words, don’t try to choose the right career, but prepare yourself for choosing many careers throughout your working life. Learn the fundamental skills that will serve you well in all your future careers, whatever you choose, whenever you choose them—people skills, problem solving, and systems thinking are what come to my mind as things you'd need in all careers. 

That's why I've studied these things, teach them in workshops, and write books about them.

Monday, October 31, 2016

What's the most complex thing about software development?

What's the most complex thing about software development?

Interesting question.

So far, on Quora.com, there have been four excellent answers to this question: discussing 
- the confusing role of people, 
-the requirements problems,
-the interactions with the physical world.

Each of these factors certainly makes software development more complex, and processes such as Agile are designed to cope with this complexity. But, the ultimate complexity factor is software testing.

Why testing? In the software development literature, testing is not usually treated as a glamorous part of development, but when we're testing, we're up against the Second Law of Thermodynamics, which warns us that perfection is ultimately unobtainable.

So, even if we absolutely knew all the requirements (which we can't, of course), kept all the human factors under control (also impossible), and knew exactly all the physical properties of the real world (once more, impossible), we would still never be able to perform the infinite number of tests to cover all possible situations.

In other words, the software could still surprise us at any time. That's what I call complexity.

Of course, we can still work hard to solve these other problems. On requirements, for instance, see our Exploring Requirements books.





But no matter how hard you try, you'll still be faced with the testing problem. To understand this problem and what you can do to reduce (but not eliminate) it, take a look at Perfect Software and Other Illusions about Testing.

Tuesday, October 25, 2016

Leaders: Born or Made?

The question was asked: "What's the best way to explain the phrase 'leaders are born not made'?"

That's easy. The best explanation is that it’s pure bunk, not supported by any evidence whatsoever.

But if it’s bunk, why do people repeat it? Perhaps they are making an excuse for not being a leader themselves, and not doing anything about it.

If they did want to do something about it, they could find many resources to help them grow into a better leader. My own contributions include:




and



But I'm not the only leadership coach. You have many choices, so if  you catch yourself arguing that leaders are born not made, stop making excuses. 

If you want to stop making excuses and start making a leader out of yourself, find yourself a collection of coaches and get busy with the making. 

Sunday, October 09, 2016

improve my coding skills?

The questioner wrote, "Besides practicing, what else can I do to improve my coding skills?"

I took up the challenge with a warning:

Be careful of practice, because if that’s all you do, you’ll just be reinforcing your bad habits.

Instead, read and understand the coding of others. Reviewing code is the fastest way to improve your own code. If the reviewed code is well done, you learn good techniques. If it’s badly done, you learn what things to avoid.

If you’re on an Agile team, reviewing the code of others will be a natural part of your work, and you’ll also learn from others’ reviews of your work.

In any case, one of the very best ways to read and understand the code of others is by participating in software testing. By testing, you learn what really works and what really causes trouble.

And, of course, you should always take the opportunity not just to study code, but to watch others actually producing that code. What tools do they use? How do they use them? What’s their thinking process? What do they read to learn?


Finally, read some good books about thinking, reviewing, and learning. I’ve written some, and my own books refer to others. (http://www.geraldmweinberg.com)

Friday, September 30, 2016

How can someone prepare for consulting?

Someone asked, "How can someone prepare for consulting?"

Here's my short answer:

You can look upon consulting as having two parts (for the sake of this answer): subject matter expertise and expertise at offering advice on any subject. Obviously, you prepare tor consulting by becoming an expert in some subject matter—railroads, computers, marriage, divorce, submarines, glass, beer, management, software development, anything at all. Each subject will be different and require a different way to prepare.

The second part, though, has a great deal in common regardless of the subject matter. You need to know how to offer advice that people will listen to and act upon. Over my many decades as a consultant, I’ve frequently been asked about how to do this. So I wrote a book on the subject—and thus became a consultant to other consultants.

The book, The Secrets of Consulting, became so popular that I wrote a second book, More Secrets of Consulting, which also became a valued resource for consultants. So, unless you’d like to hire me as your consultant at $500/hour, and if you’re serious about become a consultant, or a better consultant, I’d suggest you spend the cost of a lunch and buy one or both of these books. Read them, follow their advice, and if it doesn’t help you, ask for and receive your money back. It’s guaranteed.


By the way, the person who asked this question didn't say whether s/he wanted to give or receive consulting. I assumed in my answer that they wanted to offer consulting, but the books work well either way—for consultants or those who hire consultants.

Tuesday, September 20, 2016

The Tenth Law of Pricing

The question was, "What can be said on the topic of generating revenue in a solo consulting practice?" You may not think of yourself as a consultant, but if you are an employee, you still have the problem of generating revenue, so this essay applies to you, too.

As a reply, I suggested reading my book, The Secrets of Consulting. The questioner then asked if I could supply a sample, so I provided a little sample from the book. In the chapter on pricing, I give my ten Laws of Pricing—laws that have made numerous consultants rich. I won’t explain them all here (or else I won’t get rich from sdelling my books), but I’ll give a summary along with the section about the tenth law:

FEE AS FEELING: THE TENTH LAW OF PRICING

The previous nine laws may sound overly analytical, but I don't perform this balancing act in any particularly analytical way. I just lay out several prices in a range and than imagine myself in a situation in which I'm turned down and am sitting at home, or the situation in which I've accepted and I'm doing the job. As I imagine myself in each of these situations, I notice my feelings. I find these fantasy feelings a particularly reliable guide to how I'm going to feel in the actual situation. Based on where I feel best on all sides, I set my price.

If the procedure sounds fuzzy, you may want to review the pricing laws:

1. Pricing has many functions, only one of which is the exchange of money.
2. The more they pay you, the more they love you. The less they pay you, the less they respect you.
3. The money is usually the smallest part of the price.
4. Pricing is not a zero-sum game.
5. If you need the money, don't take the job.
6. If they don't like your work, don't take their money.
7. Money is more than price.
8. Price is not a thing; it's a negotiated relationship.
9. Set the price so you won't regret it either way.

If you examine these laws, you'll realize that they don't talk about rationality, but emotionality. In other words, underlying all the other laws of pricing is The Tenth Law:

All prices are ultimately based on feelings, both yours and theirs.

It's important to note other feelings, such as how strongly the clients feel their need, and what they feel they can pay. It's especially important to understand what they feel you're worth. But most important is what *you* feel you're worth.

Oscar Wilde once said that people know the price of everything and the value of nothing. Since Wilde's time, however, things have gone downhill. Now people don't even know their own price. Not consultants, anyway. There may be some consultants in the world who never wonder whether they've set the right price on their heads, but I've never met any. I've concluded that, in the case of consultants, Wilde was wrong. Consultants have so much trouble talking about prices because they know their value only too well. Or, they secretly fear that they know.


So, if you're having problems setting a price on your head, take a good look at your deep feelings of self-worth. You're probably not worth as much as you hoped. On the other hand, you're probably worth a lot more than you feared.

Monday, September 12, 2016

What are the most important software quality assurance techniques?

When this question was possed on a public form, the answers were predictably things like estimation, project management, and testing. All those things are important, but not the most important.

a) By far the most important Q/A technique is telling the truth about relevant Q/A issues in a way that can be understood by your audience. 







b) Of course, you must first be able to know what is the truth, and that requires observation skills of a high degree.



(see also, An Introduction to General Systems Thinking )







c) And, too, you must be able to know which truths are relevant. For that you must understand the processes practiced to produc the products whose quality you are supposed to be assuring.(see the Quality Software Series)


All specific techniques are dependent on these underlying techniques. If you lack a, b, or c, you will not be able to perform other techniques well.
If you wish to learn more about any of these techniques, or others, I’ve written many books on these subjects, not just the ones shown here. For a list of these books, see my author page on Leanpub.com

Tuesday, September 06, 2016

Preventing a Software Quality Crisis



Abstract
Many software development organizations today are so overloaded with quality problems that they are no longer coping with their business of developing software. They display all the classic symptoms of overloaded organizations—lack of problem awareness, lack of self-awareness, plus characteristic behavior patterns and feelings. Management may not recognize the relationship between this overload and quality problems stemming from larger, more complex systems. If not, their actions tend to be counterproductive. In order to cure or prevent such a crisis, management needs to understand the system dynamics of quality.

Symptoms of Overload Due to Poor Quality
In our consulting work, we are often called upon to rescue software development operations that have somehow gotten out of control. The organization seems to have slipped into a constant state of crisis, but management cannot seem to pin the symptoms down to one central cause. Quite often, that central cause turns out to be overload due to lack of software quality, and lack of software quality due to overload.

Our first job as consultants is to study symptoms. We classify symptoms of overload into four general categories—lack of problem awareness, lack of self-awareness, plus characteristic patterns of behavior and feelings. Before we  describe the dynamics underlying these symptoms, lets look at some of them as they my be manifest in a typical, composite organization, which we shall call the XYZ corporation.

Lack of Problem Awareness
All organizations have problems, but the overloaded organization doesn't have time to define those problems, and thus has little chance of solving them:

1. Nobody knows what's really happening to them.

2. Many people are not even aware that there is a system-wide problem.

3. Some people realize that there is a problem, but think it is confined to their operation.

4. Some people realize that there is a problem, but think it is confined to somebody else's operation.

5. Quality means meeting specifications. An organization that is experiencing serious quality problems may ignore those problems by a strategy of changing specifications to fit what they actually happen to produce. They can then believe that they are "meeting specifications." They may minimize parts of the specification, saying that it's not really important that they be done just that way. Carried to an extreme, this attitude leads to ignoring certain parts of the specification altogether. Where they can't be ignored, they are often simply
forgotten.

6. Another way of dealing with the overload is to ignore quality problems that arise, rather than handling them on the spot, or at least recording them so others will handle them. This attitude is symptomatic of an  organization that needs a top-to-bottom retraining in quality.

Lack of Self-Awareness
Even when an organization is submerged in problems, it can recover if the people in the organization are able to step back and get a look at themselves, In the chronically overloaded organization, people no longer have the means to do this. They are ignorant of their condition, and they have crippled their means of removing their ignorance:

7. Worse than not knowing what is going on is thinking you know, when you don't, and acting on it. Many managers at XYZ believe they have a grip on what's going on, but are too overloaded to actually check. When the reality is investigated, these managers often turn out to be wrongs For instance, when quizzed about testing methods used by their employees, most managers seriously overestimate the quality of testing, when compared with the programmers' and testers' reports.

8. In XYZ) as in all overloaded organizations, communication within and across levels is unreliable and slow. Requests for one kind of information produce something else, or nothing at all. In attempting to speed up the work, people fail to take time to listen to one another, to write things down, or to follow through on requested actions.

9. Many individuals at XYZ are trying to reduce their overload by isolating themselves from their co-workers, either physically or emotionally. Some managers have encouraged their workers to take this approach, instructing them to solve problems by themselves, so as not to bother other people.

10. Perhaps the most dangerous overload reaction we observed was the tendency of people at XYZ to cut themselves off from any source of information that might make them aware of how bad the overload really is. The instant reaction to any new piece of information is to deny it, saying there are no facts to substantiate it. But no facts can be produced because the management has studiously avoided building or maintaining information systems that could contradict their claims that "we.just know what's going on." They don't know, they don't know they don't know, and they don't want to know they don't know. They're simply too busy.

Typical Behavior Patterns
In order to recognize overload, managers don't have to read people's minds. They can simply observe certain characteristic things they do:

11 . The first clear fact that demonstrates overload is the poor quality of the products being developed. Although it's possible to deny this poor quality when no measurements are made of the quality of work in progress, products already delivered have shown this  poor quality in an undeniable way.

12. All over the organization, people are trying to save time by short-circuiting those procedures that do exist. 'This tactic may occasionally work in a normal organization faced with a short-term crisis, but in XYZ, it has been going on for so long it has become part of standard operating procedure.

13. Most people are juggling many things at one time, and thus adding coordination time to their overload. In the absence of clear directives on what must be done first, people are free to make their own choices. Since they are generally unaware of the overall goals of the organization, they tend to suboptimize, choosing whatever looks good to them at the moment.

14. In order to get some feeling of accomplishment, when people have a choice of tasks to do, they tend to choose the easiest task first, so as to "do something." This decision process gives a short-term feeling of relief, but in the long term results in an accumulation of harder and harder problems.

15. Another way an individual can relieve overload is by passing problems to other people. As a result, problems don't get solved, they merely circulate. Some have been circulating for many months.

16. Perhaps the easiest way to recognize an overloaded organization is by noticing how frequently you hear People say, in effect, that they recognize that the way they're working is wrong, but they "have no time to do it right." This seems almost to be the motto of the XYZ organization.

Typical Feelings
If you wait for measurable results of overload, it may be too late. But its possible to recognize an overloaded organization through various expressions of peoples' feelings:

17. An easy way to recognize an overloaded organization is by the general atmosphere in the workplace. In many areas at XYZ there was no enthusiasm, no commitment, and no intensity. People were going through the motions of working, with no hope of really accomplishing their tasks.

18. Another internal symptom of overload is the number of times people expressed the wish that somehow the problem would just go away. Maybe the big customer will cancel the contract. Maybe the management will Just slip the schedules by a year. Maybe the sales force will stop taking more orders. Maybe the company will fail and be purchased by a larger company.

19. One common way of wishing the problem would go away is to choose a scapegoat, who is the personified source of all the difficulties, and then wish that this person would get transferred, get fired, get sick, or quit. At XYZ, there are at least ten different scapegoats—some of whom have long gone, although the problems still remain.

20. Perhaps the ultimate emotional reaction to overload is the intense desire to run away. When there are easy alternatives for employees, overload is followed by people leaving the organization, which only increases the overload. The most perceptive ones usually leave first. When there are few attractive opportunities outside, as at XYZ, then people "run away" on the job. They fantasize about other jobs, other places, other activities, though they don't act on their fantasies. Their bodies remain, but their hearts do not.

The Software Dynamics of Overload
There are a number of reasons for the overload situation at organizations like XYZ, but underlying everything is the quality problem, which in turn arises from the changing size and complexity of the work. This means that simple-minded solutions like adding large numbers of people will merely make the problems worse. In order for management to create a manageable organization, they will have to understand the dynamics of quality. In particular, they will have to understand how quality deteriorates, and how it has deteriorated in their organization over the years. The XYZ company makes an excellent case study.

The quality deterioration at XYZ has been a gradual effect that has crept up unnoticed as the size and complexity of systems has increased. The major management mistake has been lack of awareness of software dynamics, and the need for measurement if such creeping deterioration is to be prevented.

The quality deterioration experienced at XYZ is quite a common phenomenon in the software industry today, because management seems to make the same mistakes everywhere—they assume that the processes that would produce quality small systems will also produce quality large systems. But the difficulty of producing quality systems is exponentially related to system size and complexity, so old solutions quickly become inadequate. These dynamics have been studied by a number of software researchers, but it is not necessary to go fully into them here. A few examples will suffice to illustrate specifically what has been happening at XYZ and the kind of actions that are needed to reverse the situation.

NOTE: The remaining two-thirds of this article describes these dynamics and corrective actions, and can be found as a new chapter in the book, 


The book also details a number of the most common and distressing management problems, along with dozens of positive responses available to competent managers.

Sunday, September 04, 2016

Busy Manager's Guide to Performance Appraisal

I was busily converting my old paper files to digital format when I ran across this wonderful chart to use when making performance appraisals. It's the best I've ever seen, but I don't know where it came from. If you read this and know whose work it is, let me know and I'll update this entry to give credit.

If you want to be a better manager, you may use this chart, or perhaps you may want to read my book:






Monday, August 29, 2016

A small problem-solving tip for your TO DO list

Here's a little principle for all TO DO and NOT TO DO lists. I suspect most of us do this instinctively, but it's worth making it an explicit part of your planning process:

Break the tasks into small tasks for scheduling purposes.

If you have large tasks to do, they may keep falling to the bottom of your stack because they look too imposing or because you rarely have large blocks of empty time.

Also, smaller tasks have fewer conditions needed to start. A large task may have so many pre-conditions that even when you have the time, one of the conditions may be missing, so you don't start. 

One way to break up a large task is to create smaller tasks, each one of which removes a pre-condition for the larger task. For example, if you need to call a source, but you do most of your work at a time when the source may not be available, make the call into one small task so it can be removed from the constraints on the large task.

Small tasks are also motivating because you receive frequent feelings of accomplishment.