Summary of the book — Do You Want To Be A (Better) Manager?
With the encouragement shown towards my first summary of the Gerald (Jerry) Weinberg’s book — Perfect Software, here you go with the next one, which is one of my favorites. As Jerry asks in the excerpt of the book , “Do you want to be a (better) manager?” Whether your answer is “yes,” or “no,” or “I don’t know,” this book is for you. If you don’t know, the book should help you decide — or help you do the right things while you postpone your decision. If your answer is “yes,” many of the book’s essays are designed to guide you successfully in that direction. And if your answer is “no,” many of the essays will show you how to avoid waking up one day to discover that somehow you have become a (worse) manager.
The notes of this summary have been sitting in my notebook, for over some years now, and through Medium, you can read a detailed summary of Jerry’s book on management. enjoy. And, if you like it, I will suggest you get the book on Leanpub.
DO YOU WANT TO BE A (BETTER) MANAGER: Summary
I. Alternatives to Management
The move to management can be full of obstacles, so before you decide your next move, you may want to consider a few alternatives.
1. Motivated by Money?
I was so busy making money that I didn’t have time to keep track of where it was going. Now I was looking for a quick fix. One straw at which to clutch was an evening tax seminar. When I approached the coffee table, there stood my old friend, Oran who had got a promotion as a manager, so, I proceeded to congratulate him. He was there because he had managed to accumulate a little excess cash, which he’d like to invest with a minimum of taxes.
When I dared to admire his situation, he showed me that I was only looking at the gross raise he got, not the net. His managerial role had increased his total expenses now that he had to maintain a certain kind of lifestyle. He was so desperate for money that he had taken the risk to borrow his daughter’s morning-paper route for extra bucks.
Eventually, he took his old job back as a senior programmer but kept the manager’s salary and lost one year’s annual raise, which put him a little ahead of where he would have been if he’d never taken the job in the first place. So I had to ask, “And that’s where the extra funds come from?” “Oh, no! Those are the savings from my paper route!”
MORAL: If you want to be a manager for the money, consider getting a paper route instead.
2. Are You Willing to Sunlight?
However much we plan and study, people will invent new work arrangements that nobody foresaw. One such arrangement is “sunlighting,” a term I coined for one way of exploiting the remote work situation. The sunlighter holds down two jobs at the same time.
Here is an example of sunlighting: Sarah is 19 and cannot read or write, yet she is on the payroll of the XYZ company, earning $12,600 a year as a data entry clerk. Sara does not do any data entry. Her mother, Maude has a work-at-home arrangement with XYZ, and does the work for both of them while Sarah does the housekeeping. When XYZ decided to do a pilot work-at-home project, Maude’s boss, Denise, asked her to participate. Denise told me, “Maude’s husband left a few years ago and never paid a cent of the support money the court decreed for Sarah, who has some form of congenital brain damage. I know she was hard up and did not like to leave Sara during the day.”
Best operator
“Maude was our best operator, and I thought I might lose her to someone who did not have the kind of pay ceiling we have. So I suggested this arrangement and she jumped at the chance.” Denise’s boss does not know about this, but is pleased Denise was able to get an “extra” operator for data entry. Maude works about 10 hours a day. Half the work is under her own work code and half under Sarah’s. In ten hours, Maude doubles the maximum output for a 7-hour day at XYZ.
Of course, sunlighting is not the kind of practice you are likely to learn about through official channels. Sunlighting was made possible by a technical revolution — the ability to do information-intensive work away from over-the-shoulder supervision. But technology is not enough. Sunlighting is feasible only where some workers can easily exceed management’s productivity expectations.
Rare attitude
Denise’s approving attitude is rare. More managers might accept sunlighting if they knew it was going on, but Spencer, another sunlighter, does not think so. “If either of my managers knew I held two programming jobs, I would be fired instantly,” he says. Spencer works four days a week at home, using two PCs, one from each of his employers. Spencer forgot to mention he also gets paid twice as much — over $90,000 — but I do not think he cares that much about the money. He is happy working at his PCs.
Getting caught
What happens when managers catch a sunlighter? The only case I could verify involved Barbara, a claims processing manager in an insurance company. “Yes,” Barbara told me, “I did catch one of my employees trying to pull that con. She was doing data entry work for us at home, and running an answering service at the same time. When I confronted her she confessed the whole racket. Naturally, I fired her on the spot.” Although I could not interview Barbara’s former employee, I was told that she had always filled her data entry quota.
Any successful work-at-home plan demonstrates that people can work with less than the conventional dose of supervision.
Sunlighting managers
Are you one of those people who wants to be a manager as a way of earning more money? You might like to know it’s possible to be a sunlighting manager. You could add a newspaper route, like Oran, but there are many other interesting possibilities. For instance, Gemma directs development for a grocery chain. Her shop pretty much runs itself, giving her time to supplement her income as an eBay trader. She likes that sunlighting keeps her too busy to drift into micromanaging the developers and testers.
3. How To Get Fired as IT Manager
The thing I like second best about being a consultant is how much you learn from your clients. Like LeRoy, who taught me about what a recruiter expected of an IT manager. LeRoy was the President of a firm that had engaged my services to help reorganize the IT function. So I asked him about the position I was hired for:
“How many have you fired?”
“I really can’t remember them all. Let’s see, the first one kept telling me that what I wanted couldn’t be done — and implied that I was too stupid to understand why. I may be stupid, but
I’m not stupid enough to keep someone around who’s smarter than I am. Especially if he doesn’t give me what I want.”
‘Was he right?”
“Not really. His replacement built the “impossible” system in four months. She was a good one. I thought she’d be around for a long while.”
“But you fired her too?”
“Unfortunately. She could do almost anything, but she was so eager to please me she couldn’t ever admit to the smallest problem. Everything was always ‘No Problem.’ Eventually, she led us into an enormous disaster — pouring a million and change into developing a system that never worked.”
“And after her?”
“That was this last Bozo.”
“Which type was he — ’It can’t be done’ or ‘No Problem’?”
“Oh, he was a third type — possibly the worst of all. He never gave me a straight answer, but was always telling me, ‘You don’t really want to do that.”’
“But don’t you want to know if it’s something you really don’t want?”
“Of course I would,” LeRoy said, getting a bit angry, “but how does this guy know what I want and don’t want. I’m the President. I don’t work for him. He works for me. If a hotel manager knows how important orange juice is to my company, he should be running it, not me. I didn’t fire him for speaking up. I fired him for the way he spoke up — the way he assumed that he knew more about running the company than I did. Once a technologist starts believing that, he’s dangerous to have around.”
“What would you have wanted him to say?”
“More or less just what you just said. Yes. I don’t want a bunch of sheep working for me, but I do want people who understand that they, too, might be wrong. When I gave this IT manager a plan he thought was wrong, he could have said, ‘LeRoy, I’ve seen too many systems built and then discarded because they weren’t really wanted. Before I try to build this one for you, I’d like to understand more about why you want it. Perhaps I’ve missed the point, or perhaps I don’t have some information that you have, but I think I can do a much better.”
II. Management Techniques
What are some of the good things you’ll need to learn in order to handle some common management situations, like personnel interviews, technical reviews, addicted employees, and anger from you or toward you?
1. Acts of Leadership
You can be a successful leader without being a manager, but the opposite is not possible. To be a successful manager, you first need to be a leader. The following acts of leadership will help you become a great manager:
1. Open the discussion
2. Change the model they see
3. Compromise appropriately
4. Observe what is needed
5. Restructure the task
6. Restructure the group
7. Inventory the resources
8. Ask questions
9. Listen
10. Watch for misunderstanding
11. Empathize
12. Be ready to pitch in
13. Remain open to feedback
14. Encourage appropriate behavior
15. Withhold negative comments
16. Offer ideas without inflicting
17. Admit mistakes
18. Risk taking the lead
19. Risk following a lead
20. Let others succeed or fail
21. Set an example
There’s nothing on this list that ordinary people cannot do, or learn to do. More important, some actions are not on this list, such as,
• Give orders
• Punish people
• Threaten
• Ridicule wrong ideas
• Force acceptance of ideas
• Pass out favors
• Invoke authority
• Scream and shout
2. Smart Manager Tricks
Most successful managers have a toolbox of clever techniques. I’ve often thought managers could do a better job if they could share their tricks, though they seldom do. How about we do that here — share some clever things managers do, as related to me by some outstanding managers on my SHAPE forum.
Here’s what I asked them:
1. What’s your favorite clever manager trick?
2. Why is it clever?
3. What can be done to encourage it?
4. What must be done to keep it from turning into a Stupid Manager Trick?
Take each encounter at face value.
Assume the person I’m talking to knows what they’re talking about.
It’s a smart trick partly because it’s so rarely done. When someone does something differently than the way you normally consider it, it may be from a bunch of reasons:
• They know more than you do. After all, this is their job, not yours.
• You haven’t considered the risks to your way of thinking about the problem.
• It’s reasonable to bet on people’s hunches. They know more than you do. They often know more than they think they do.
Be realistic in your expectations.
Brian Pioreck once had a manager who would schedule four days of work on projects per week. The fifth day was for whatever the workers thought was important, on or off the project. They just had to keep him informed and follow through on a few ideas at a time.
This trick derives from Johanna’s trick of not pretending that you know everything. Brian’s manager figured there was at least 20% of stuff that he couldn’t possibly know as well as the people working under his supervision.
Match people and work.
Dwayne Phillips likes to put people into jobs they know how to do and like doing. It’s a clever trick because:
• The person is happier.
• The manager sees what the person knows and sees what the person likes.
• The person works much better because they enjoy their work and they are effective.
• The organization is better.
• People know what to do and do it.
• Most important, the person realizes they are not working for a “Dilbert manager.” They are working for a competent, caring person.
98.6% of the time, managers put people into positions where they are not knowledgeable and do not like the job. Keep that from happening by knowing each person’s background, obtaining a fresh resume every year, scheduling regular one-on-one meetings monthly to update your knowledge.
Get to know your people as people.
This is what Marie Benesh practiced to know her employees:
One thing I liked to do was to schedule one-on-one meetings with my direct reports every two weeks. That was a whole hour just for us to get together and talk about what was going on.
They could ask me questions about something or tell me whatever was on their mind. I rarely met in my office, but met in a coffee shop nearby, or in good weather we’d take a walk. Once a month the whole group of reports would get together and discuss issues and projects, but this time was about that one individual. It would be a stupid trick if the manager wasn’t sincere about hearing the other person. It is important to ask if the information can be shared outside this meeting if something interesting comes up that might require some action.
Avoid the negative.
Pat McGee’s favorite trick was never, ever, say anything bad or negative to, or about, a direct report. Or anyone else for that matter. This trick has many positive effects:
• People are much more willing to communicate openly.
• They feel very safe around you. People are much more likely to take responsibility for their problems instead of spending effort blaming it on someone else.
• People are happier at work, so they will probably stay longer.
• They’re much more willing to do out-of-the-ordinary work.
Try low-tech and highly interactive.
A trick from Dave Smith’s bag is to do planning with low-tech tools. He has his teams build plans using 4x6 cards or large sticky notes, and keep the plans live (and visible!) on whiteboards. Team members are encouraged to negotiate their own changes to the board, and get to check off cards with a red marker as tasks are completed. Team involvement in planning leads to better buy-in than the traditional “tell me how long this task will take so that I can enter it into a box in the master plan” approach.
Cards-on-the-wall planning can also help when negotiating tradeoffs. When your management says “cut four weeks off of the schedule,” take them to the board and ask them to help you remove four weeks-worth of cards. Surprising clarity about priorities can emerge.
This technique doesn’t scale well when the total number of cards exceeds about three large whiteboard’s worth of space. That’s been enough for a 20-person, 3-month endgame. Nobody can plan much beyond that size, anyway, so maybe you need to scale your projects to a more reasonable size.
Leverage diversity.
James Bullock believes that diversity matters: radical, bone deep diversity. He’s seen managers collect “three-sigma personalities” — people three standard deviations away from the mean. Unique individuals do unique things.
Where a manager has a “Unity in Diversity” management style, that can clearly be seen by the people he invites to join and by the different approaches and communication style. When that happens, it affects “buy in” for product vision and team focus. Moreover, different people have different problem solving styles. What seems to be a “deep” problem for me, can be an easy one for someone else.
Fostering diversity can turn into a stupid manager trick when managers behave like the Borg, saying that the diversity is needed to acquire more technological knowledge, but then you immediately get assimilated. For instance, when there is no room, nor time, nor budget, nor openness for finding out and addressing different needs and wants of people for productiveness in their preferred work.
Employ the coaching model.
Sharon Marsh Roberts believes that coaching supports all of the other clever tricks we’ve mentioned. Her coaching model says:
a. Allow those you manage to think through problems and reach their own conclusions.
b. Allow them to test their conclusions. Don’t second-guess those decisions.
c. Guide, advise, and help. Be available for times when they get “stuck.”
Sharon says her goals are:
• to transfer knowledge and skills to anyone whom she manages
• to make herself (and subsequent managers, when possible) redundant
• to help people create and succeed at their goals.
If people learn and succeed, Sharon achieves her goals.
Don’t take your own authority too seriously.
The degree of discomfort with your own authority of any form is a smart manager trick that keeps you honest. One way to notice this happening to yourself is when you start saying things like, “I am the manager.”
• You are not the manager, but just that at this moment, you’re filling the role of manager.
• You are not hereditary aristocracy; you’re just a person filling a job, just like all the people who work under your supervision.
Become a barrier buster.
As important as it is not to abuse your power, Johanna Rothman suggests that smart managers sometimes use their title or position to clear obstacles for their employees. It’s clever to use this trick on people who believe titles mean something because you may be able to get what you need
(hardware, software, time in the schedule, an appointment). She encourages it where
• people are stuck and can’t make priority decisions
• people are intimidated by titles or positions.
Strive for consensus by creating a sense of safety.
Jim Batterson’s favorite management trick is consensus: allowing everyone involved in a decision to get together and discuss it, as equals, until they come up with a solution that
everyone can at least support and endorse.
If a consensus is not reached easily, keep going until one is reached. Be patient, because:
a) Consensus has the best chance of producing high quality decisions.
b) Rarely is the manager, or any one participant, the person most knowledgeable in all areas.
c) Once a true consensus has been reached the decision can proceed with the full support of the entire team.
To encourage consensus, the manager, facilitator, and everyone else must take responsibility for:
• creating an environment in which all participants feel safe and comfortable.
• preventing any one participant from bullying others
• preventing the many from pressuring the one
• encouraging the shy and inarticulate not to give in just to avoid confrontation.
Tell the new people where the bathrooms are.
Nynke Fokma warns all managers to make sure every new person has the information they need to work well. Organizations acquire rituals and ingrained ways of doing things. Especially when a new person comes in, it’s really hard to explain all those things to the new person.
What does work is assigning a buddy to each newbie for their first month. That buddy is responsible for seeing that they know such things as:
• where to find the toilets (not to show them how to use one)
• where people can get food (not to choose their food)
• how to operate the copier (not to make their copies)
• who to talk to about what kinds of issues (not to plead their case or run errands)
3. What You Need To Know About Programming
Do you have to know how to program in order to manage an IT organization? It’s a perpetual question.
Programming is foresight.
One of the great pieces of foresight in modern history was naming IBM’s magazine THINK. Computers are not taking thought away from people. Quite the opposite. Since the computer can do nothing but follow instructions literally, all the thinking falls on the programmer, who must do this thinking in advance. We are not accustomed to think in advance.
Programming is writing the recipe, not baking the cake.
When you bake a cake, whether it wins a prize or burns to a cinder, you can eat it only once. When you write a recipe, however, you are writing about events in the future, and many different cakes can be baked from the same recipe.
The paradigm of programming, as of science, is “if-so-then-so.”
A programmer writes his commands to the computer in a contingency manner: “if that happens, then make this happen.” If a programmer were writing a recipe for an automatic cake-baking computer, s/he might specify:
IF THERE ARE LARGE EGGS, THEN USE 6 LARGE EGGS;
ELSE IF THERE ARE MEDIUM EGGS, THEN USE 7 MEDIUM EGGS;
ELSE IF THERE ARE SMALL EGGS, THEN USE 8 SMALL EGGS;
The programmer’s recipe must be unambiguous.
Look again at the statement:
IF THERE ARE LARGE EGGS, THEN USE 6 LARGE EGGS;
To us, it looked clear, but a programmer must recognize that it was supposed to say:
IF THERE ARE AT LEAST 6 LARGE, EGGS, THEN USE 6 LARGE EGGS;
Otherwise, the computer doesn’t know what to do if there are large eggs, but not as many as six.
The programmer’s recipe must be verifiable.
The program’s owners want assurance that it will perform well: that it will bake a cake, not a muffin or a brick; that it will leave the kitchen clean, not coated with six inches of sticky batter.
The programmer’s recipe must be created in a controlled way.
Since exhaustive testing cannot be used to verify programs, the programmer must exercise extreme control over the building process.
The team is the most powerful programming tool.
Programming is way too difficult for a single person to do consistently well. Simply put, programming well requires a team, a team that must be adaptive and work well together. You cannot provide the kind of reliable performance a manager could count on in project after project alone. For that, you have to build and maintain a team.
III. Common Difficult Situations
In this section, we will be using examples we can all extract a picture of a certain management style practiced by some of the best managers.
The situations include:
• non-technical managers having to make judgements of technical material
• interviewing candidates for technical positions
• responding to people who always have reasons for their poor performance
• dealing with people with various forms of addiction
1. Resisting the Sales Pitch
As a new manager, you will find yourself faced with a number of new responsibilities for which you have little preparation. As a low-level employee, you may have complained about your ignorant managers spending scarce resources on useless software, stupid consulting, or worthless training. Now, however, you’re in danger of becoming the stupid manager — unless you can sharpen your shopping skills.
While shopping for tools, products, services etc., follow the following rules:
1. Look for any device intended to fool you.
For instance, see seminar announcements featuring the picture of some famous person. The announcement gives the impression that this person will present the seminar, but when you read the small print you discover that some unnamed person will do the presentation, as the famous person is “not always available to do the presentation in person.”
2. Be particularly wary of “demonstrations.”
It’s the easiest thing in the world for a seller to set up a fake demo to “prove” anything. Whenever a seller won’t allow your professional testers to run their own acceptance tests, you have an automatic rejection.
3. Develop a set of key phrases producing clues to quality or lack of quality. Phrases like “once-in-a- lifetime opportunity” are sufficient to terminate the lifetime of the document, but there are positive clues as well. Use such clues as real references you can check.
4. If a letter “smells” fishy, file it where you file spoiled fish.
One problem with key phrases is that it’s easy for sellers to reprogram their word processor to spot and eliminate them before the text is printed. As a human being, however, you have a big advantage in this constant war between offense and defense. You can use your instincts.
5. Sometimes your instincts will be wrong, causing you to trash something really good.
Don’t worry. If it’s really good, you’ll get another chance. A good piece of software won’t go away overnight. When inundated with information, a good rule to follow is “When in doubt, throw it out.”
6. Let others do the screening for you.
A good book or a good piece of software will eventually garner good reviews. Cultivate sources of reliable criticism, such as friends, magazines, and websites.
7. Fight fire with fire.
Use software filters to apply rules for recognizing electronic junk mail. Buy an off-the-shelf filtering app — if you know how to filter out all the bad ones.
8. Perhaps know-how isn’t the ultimate skill.
Maybe what you most need is humility — to counter the flattery that’s the seller’s last resort. There are no managers more stupid than those who believe a seller telling them how smart they are.
2. An Agile Project Start
“What is the best way to organize, recruit, and train for a new software development project?”
I was asked to write on this topic, but I decided the best way to organize this paper is by discarding that topic for three others:
a. What are better ways of getting started than we now often do?
b. What are some of the errors that ensure a bad start?
c. Given limited resources (and presentation time), what are the most important areas for concentration of management attention?
Rule 1: Start with the people you have.
More projects fail for lack of realism at the outset than for any other reason. There are two principal forms of this mis-estimation:
a. You misestimate your people.
b. You misestimate the task.
First consider the people. Back when chief programmer teams were the latest
fad in software development, numerous teams failed because of misplacement of individuals, such as
a. You place an inadequate person as chief.
b. You appoint the more qualified person as backup.
Because programming work was traditionally hidden from the view of all but a single person, there was no reliable way to estimate the capabilities of each technical person. So, for a chief programmer team to work, the most qualified person had to be the chief.
In true team work, the open inspection of one another’s work reduces the misestimation of people. Therefore, projects should start with adaptive teams. The manager selects the members of the initial team primarily based on social skills, but avoids investing too much management prestige in the particular choice of technical skills. Technical skills can be learned rather quickly, but learning social skills may take a lifetime.
Team makeup is not set in concrete, but is conspicuously subject to revision as time is allowed for the team to develop. The team members, with occasional gentle assists from the manager, gradually adapt the team membership and responsibilities to the task at hand, in the light of increasingly accurate appraisals. Because of the need for time to adapt, modify Rule 1. Don’t break up a successful team just because you’ve finished one project and are starting another.
Rule 2: Never allow the problem to become undefined.
Much has been said about the importance of obtaining accurate project requirements, so I need not labor that point. Suppose, for the moment, that you did somehow obtain accurate and complete requirements at the outset. Once the project gets into full swing, however, everyone knows
a. The requirements will change.
b. People will be too busy, personally too interested, or technically too ignorant to appraise the conformity of the partial project to the requirements.
Functioning Agile teams know how to ensure a coherent project in the face of these problems — regularly scheduled reviews of conceptually manageable portions of the project. However, whenever a documented requirement is passed between teams, a formal review should mark its passage. Similarly, when a change is proposed to an external requirement, the proposal should invariably be filtered through a formal review.
When a team claims to have completed a certain portion of assigned work, that work must be reviewed by outsiders before it can be considered part of the completed system.
Rule 3: Invest early and keep investing in team building.
How does team-building take place? Though details vary, the underlying principle is always the same. Teams build by sharing experiences. You cannot build a champion software-building team when each member “owns” a private piece of the work. Only through mutual help and criticism can a team develop common understanding of objectives, accurate appraisals of individual abilities, patterns of work that involve the strengths and overcome the weaknesses of each team member.
One way of establishing a team for a new project is to beg, borrow, or steal an already existing team. Building a new team takes time, and often means a fallow period in which the members may seem less productive than they would have been as individuals. Another way of establishing teams is by keeping them intact, even though they have completed an initial project. If a new team had to be built for each new small project, only large organizations could afford the team building effort.
And if you have the sort of money you can invest in building a team of new programmers, do not shy away to invest in it.
Rule 4: Let your technical leaders do technical leading.
Managers who have formerly held technical skills are easily tempted into meddling in the technical team’s domain. But if that’s the best collection of technical players you can muster, perhaps your project is doomed to failure in advance.
In the early stages of a project, a manager may be relatively well informed technically — at least when compared with the analysts, designers, and programmers. Also, the manager may have considerable spare time to devote to making technical decisions for the team and the would-be team leaders. As the project progresses, however, the manager’s relative technical skill will diminish, and spare time will be a vanishing commodity. When it’s no longer possible to make technical interventions, the meddling manager will find that the micro-managed team still lacks the experience, confidence, and desire to select the right plays. Good performance in a game comes from good management prior to game time — not from sending in the winning play when the crowd is roaring loudest.
Rule 5: Allow adequate time and space for learning.
If the project is not similar to something you’ve done in the past, you cannot accurately estimate required people, hardware capacity, and other resources. In some cases, you can postpone the project itself in favor of a “research” project designed to pin down the looser ends — to educate everyone about the task facing them. If you cannot politically afford a distinct research effort, you must lard the project with slack in which the learning can take place.
When teams are in use, the proportion and quality of on-the-job learning is huge. The best investment in education is that devoted to getting teams started. That means that “social skills” are your best investment in training. Installations, groups, or individuals tend to develop a unique style of working — whether in the use of a particular language, style of development, tools, or work habits. Wherever there are communication boundaries, useful information is prevented from moving from one work style to another. Allowing adequate time and space for learning, then, is largely a matter of allowing adequate time and space for teams and reviews.
3. Instant Reviews, Instant Tests, Reasons
Managers should participate in all sorts of reviews, but not technical reviews. That doesn’t mean managers can’t review technical work, just not while in a review group. Besides, the kind of reviewing a manager should do takes little time and almost no preparation. This chapter explains how to review the results of the reviews performed by their technical staff. Each of these instant reviews can be done by a non-tech manager.
When to review quickly
In general, the quickest reviews are done by working on a “worst error first” basis. So, which are the worst errors? Reviewing is testing, and testing experience tells us that the worst errors for testing will be the worst errors for reviewing. Certainly, the worst error for testing is any error that blocks testing all or part of the object under test. For example, “I cannot understand this code well enough to be sure it works.” This is a blocking issue, and thus testers must give it highest priority. If you look over the list of instant review statements, you’ll notice each of them attempts to block a review. Thus, they are the worst errors — even though they are errors in the thought process of the producers, not in the product itself.
How to handle blocking attempts
If you’re puzzled by what to do with blocking attempts, translate them into testing terms.
“We don’t review the product because the customer doesn’t want to pay for the review” becomes “We won’t test the product because we think the customer doesn’t want to pay for testing.”
These instant reviews provide an enormous amount of important information for a tiny investment of time. But be warned: they may convince you, but you still may have to work to convince others.
Sometimes they’ll have to undergo the pain of a regular review so they can see how the review result was inevitable. Sometimes you’ll have to start testing and let the early test results show many issues that should have been detected in reviewing. Sometimes you’ll just have to explain your quick review result to potential reviewers and find out if they want to waste the time of convening the review. After a while, your people will learn to do these instant reviews themselves, and then you’ll find new sweetness in your entire development process.
Convert reasons to logic
You’re going to be the manager trying to introduce something new — a tool, a process, a document, a technique, anything new at all. And when you try, you’re going to find yourself faced with an infinitely high wall piled with reasons, mortared in place with that word, “because.” And what will you do then? Rather than go back and forth with a potentially infinite chain of “why-because,” save yourself some time and energy by recognizing that you will always lose this game, so switch to another. One of these new games is to try to convert to real logic.
When you get the first “because,” simply say, “You’re right. There are lots and lots of reasons why you might not want to do it this way, and you’re exactly right to start raising them. Let’s carry this through.” Then you take out a sheet of paper and draw a line down the middle. On the left, you label the column “Reasons Why Not.” On the right, “Reasons Why.” Then you write their reason in the left column and ask for one in the right column. If they can’t come up with one, prime the pump by showing how their own reason could just as well go on the right.
4. Congruent Interviewing by Audition
People have degrees, publications, and resumés showing all sorts of job experience. But, in the end, credentials aren’t what counts, for software development is not an academic subject — it’s a performing art. And that’s why interviewing ultimately has to be based on performance.
Hiring by audition
A manager wrote telling how he assesses the technical competence of people who have apparently qualified resumés:
Applicants are told prior to the first interview that they’ll be interviewed by an HR person, and that they then will be asked to write a short program. If somebody bills himself as a C/C++
or Ruby programmer, I might ask him to handwrite ten lines of simple bubble sort code, where I give the declarations and also provide a cogent description of a bubble sort from a standard textbook.
If the applicant fails to notice that the procedures were declared incorrectly, I can legitimately assume that he probably hasn’t written a lot of bug-free code lately. This is a handwritten exercise. Qualified applicants blast through this exercise in minutes, and don’t seem to mind this very rudimentary check.
All applicants completing the exercise are immediately interviewed by an engineer. Most applicants excuse themselves, saying that they don’t have the skills to write this code, and it’s a depressing experience on both sides — but one that doesn’t impact the engineers.
One part of me wonders whether this approach is unnecessarily stressful. The other part of me says that my cat could pass this test, and there’s no reason to be sensitive to the feelings of people who are faking their qualifications.
This kind of audition interviewing works. Checking credentials is certainly important, but that’s not sufficient. Would you hire an oboist for your symphony orchestra without an audition? No, right? Then why hire a developer who is simply good at faking credentials?
Be sure, though, that it’s an appropriate audition for the job you’re trying to fill.
Audition mistakes
Like any management process, auditioning needs to be explained and sold to the participants. It needs to be kept as simple as possible, but no simpler. One of my clients tried using this technique without the discussion — just having her engineers examine the code sample submitted by the applicant. This worked reasonably well, except for two applicants who slipped through by submitting code written by someone else. That is why discussion is important at the same time.
Like any interviewing technique, auditioning cannot be the sole reason for selecting the candidate. For one thing, if you are known to audition with a particular problem, people will find out and prepare for that specific problem. Audition interviewing works because it is congruent with the task you’re interviewing for. The psychologists call this quality of a test face validity. We call it congruence. Either way, the test itself must clearly match the work it’s testing for. It’s relevant; it’s open; it’s honest; it’s fair; and it creates an environment in which the candidates can show what they can do without playing guessing games with the interviewers.
IV. Management Traps to Avoid
The following chapters describe common traps that managers set for themselves, along with ideas about what to do to avoid or escape them.
1. Beware of Quick Fixes
Once you eliminate your number one problem, number two gets a promotion.
As Jean Sammet recalls in her History of Programming Languages, the users for whom COBOL was designed were two sub-classes of those people concerned with business data processing problems. One is the relatively inexperienced programmer, while the other type of user would be essentially anyone who had not written the program initially.
Like addicts deprived of their dope, the customers are eager for a “quick fix”, and ready to deal with any pusher. Some years back, the latest quick fix in software development was called “rapid prototyping.” Almost all of the “rapid prototyping” hasn’t been all that rapid, but that doesn’t matter, because it hasn’t been prototyping either. But let’s assume that everyone’s rapid prototyping system is both rapid and prototyping. Let’s grant that they work (after all, COBOL worked) and contemplate some of the consequences. Although many consider COBOL a failure, objective analysis says it was an instant success. If it hadn’t been a success, we wouldn’t have ten billion lines of COBOL code to maintain.
With time, as requirements changed, the COBOL programs have changed. In a mature COBOL program, there have been three lines written for every one that remains in the code. It’s not just the volume of COBOL code that causes the huge maintenance effort. Volume must be multiplied by a quality factor, because low quality code takes more effort to maintain.
2. The Sauerkraut Syndrome
There are quite a few managers in the over-40 category. It’s tempting for old managers to tell stories the young ‘uns can’t match — about such things as paper tape, relays, and sauerkraut. Sauerkraut? Exactly! They don’t get the reference.
So, what are the old managers supposed to do when one of our younger colleagues comes up with ideas they think are new, but we’ve tried before and regurgitated? How do you break the Sauerkraut Syndrome? Here are some suggestions:
• We can keep our mouths sealed against the temptation to say, “That’s not new. I tried that back in the Great Depression.”
• We can keep out of the way, letting them learn from their own mistakes, or their own triumphs.
• We can be emotionally supportive. In case you’ve forgotten, youth is a highly volatile time.
• We can refrain from saying “I told you so” if the idea fails this time. This doesn’t help anybody, and it doesn’t make friends.
• We can admit our fears and suggest slight modifications to the idea that will help reduce those fears or increase our own payoff.
• We can refrain from giving advice, especially if it’s not asked for. Advice can undermine the confidence of the receiver — if it works, it can make the receiver feel inadequate for not knowing without advice; if it fails, it can make the receiver feel stupid for listening to you.
• We can move in and grasp the young colleague’s new idea if it starts to work. Ideas need time to work out their glitches, and there’s nothing quite like an older, supposedly wiser, person saying, “Oh, now I see what you’re doing. Cool!”
3. Better Estimating Can Lead to Worse Performance
If someone keeps bragging about how they’ve come of age, you know they haven’t. We could apply that criterion to software development, which has been bragging about its impending maturity now for decades.
Estimates can become standards
One part of coming of age is learning to appraise your own abilities accurately — in other words, to estimate. When we learn to estimate software projects accurately, we’ll certainly be a step closer to maturity — but not, by any means, the whole way. The mature person can not only estimate performance, but also perform at some reasonably high level. Estimating is a means mature people use to help gain high performance, but sometimes we make the mistake of substituting means for ends.
The problem is when managers have learned to estimate their software projects reasonably well, there is a tendency to set these estimating parameters as standards. They say in effect: “As long as we do this well, we have no cause to worry about doing any better.” This might be acceptable if there was a single estimating model for all organizations, but there wasn’t. DeMarco found that no two of his clients came up with the same estimating model, and mine were just as diverse.
Using estimates well
So, if you want to be a better manager, how do you use estimates effectively? Any estimate is based on a model of what you’re estimating. The model will have a number of parameters that characterize the situation. In the case of estimating a software project, parameters of the estimate might include
• number of programming languages to be used
• experience level of development staff
• use of formal code reviews
• characteristic error rate per function point
• many other factors
Suppose, for example, the project has six teams, each of which prefers to use a different programming language. Up to now, you’ve tolerated this mixture of languages because you don’t
want to offend any of the teams. Your estimating model, however, tells you that reducing the number of languages will reduce risk and speed up the project. On the other hand, if you try to eliminate one of the languages, your model tells you that a team with less experience in a new language will increase risk. By exploring different values of these parameters, you can learn whether it’s worthwhile to convert some of the teams to a common language.
4. Preventing a Software Quality Crisis
In consulting work, the main job is 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.
So, the first job of a consultant is to study symptoms. The symptoms of overload can be classified into three general categories — lack of problem awareness, lack of self-awareness, plus characteristic patterns of behavior and feelings.
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:
• Nobody knows what’s really happening to them.
• Many people are not even aware that there is a system-wide problem.
• Some people realize that there is a problem, but think it is confined to their operation.
• Some people realize that there is a problem, but think it is confined to somebody else’s operation.
• 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.
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:
• 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.
• 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.
• Many individuals at XYZ are trying to reduce their overload by isolating themselves from their co-workers, either physically or emotionally.
• 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.
Typical Behavior and Feelings Patterns
• In order to recognize overload, managers don’t have to read people’s minds. They can simply observe certain characteristic things they do:
• The first clear fact that demonstrates overload is the poor quality of the products being developed.
• All over the organization, people are trying to save time by short-circuiting those procedures that do exist.
• Most people are juggling many things at one time, and thus adding coordination time to their overload.
• 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.
Time to Locate Problems
If the quality of individual parts is held constant, then as the number of parts increases, the time spent locating problems grows at least as fast as the square of the size, because there are more errors and more places to look.
Management Countermeasures:
There are a number of countermeasures that management can take to reduce this time spent locating errors, such as
• Steps should be taken to ensure higher quality of the “parts” before they are put together for testing.
• A trouble report control system that actually works should be implemented.
• Teams must be trained to work on error location, to prevent the circulation problem. Getting the right team in a room and locating the error in one sitting is essential, and eliminates administrative burdens.
Time to Fix Errors
If the quality of individual parts is held constant, then as the number of parts increases, the time spent fixing problems grows at least as fast as the square of the size, because there are more errors and each error takes longer, because there are more side effects to consider.
Management Countermeasures:
• Again, steps should be taken to ensure higher quality of the “parts” before they are put together for testing.
• A configuration control system should ensure that everyone knows what version they are working on, and to keep repairs in one place from affecting work in another.
• Teams must be trained to work on error correction, to prevent side effects. One part of the team approach is deciding what correction to make, another is conducting technical reviews of each proposed fix to prevent surprising side effects.
Effects of Shortcuts on Quality
The pressure of the exponential increase in the number of quality problems has tempted people at all levels of the organization to take shortcuts, hoping that quality will “somehow come out all right.” It won’t.
Management Countermeasures:
• A strong boundary must be created between maintenance and development work.
• Obviously, management must measure quality and track it precisely, but even more important, they must absolutely stand behind enforcement of quality standards.
• The procedures involved in quality assurance must be strengthened and put on an independent basis, reporting directly to the highest management.
5. Overstructured Management
What makes a manager a bad manager? In software engineering, the mushroom growth of “structured programming” is generally traced back to Dijkstra’s 1968 letter in the May 1968 Communications of the ACM. In the unsuccessful systems, Dijkstra found that the managers couldn’t keep under mental control. The failure of systems had to do with the way people in a project behaved, and the managers were trying to control by using overstructured models of human behavior.
Curiously, these overstructured models of human behavior turned out to be exactly those models of program control that had proved so successful in structuring computer programs. Could these managers have made the error of believing that people were like programs?
The DEAL Model
When interviewing managers about their role in software projects, I find the DEAL model of Fritz Heider (1958) particularly useful. DEAL is an acronym for four kinds of reasons
people give for success or failure:
D — Difficulty of the task
E — Effort put into doing the task
A — Ability relevant to the task
L — Luck
Successful managers always talk about the effort they put in and the ability they possess. Unsuccessful managers always talk about how hard the task was and what bad luck they had. They also talk about their poorly trained and unmotivated staff. Unsuccessful managers make as much effort as successful managers. I believe their projects are no more difficult — unless they themselves have made them so. Sometimes there is such a thing as bad luck, but successful managers were able to deal with bad luck and overcome it.
These unsuccessful managers lack ability. They may have a record of great skill in manipulating computers, but they lack the ability to use more realistic models of human behavior.
Sequence
The most fundamental control structure in programming is sequence. A sequence of actions is conceptually simple, and managers are quite correct to try to structure software projects so that important events take place in fixed, pre-determined sequences. Consider, for instance, the “classical” sequence — specification, design, code, test. Most system development models have several alternatives to this sequence, such as,
1. specification, kill
2. specification, design, kill
3. specification, design, code, kill
Yet the truly unsuccessful development projects I have observed never went through any of these alternatives. They were never killed by their own managers.
To make development managers more balanced, we must measure the number of systems that are killed in the various stages of development. If the number killed in early stages is too small, that means either that they are not attempting enough risky projects or that they are being too rigidly sequential. If they were called to account for these ratios, they might alter their overly structured models.
Choice
The second fundamental control structure in well-structured programs is choice — the selection of one of two alternatives. Managers with overly structured choice models have difficulty making sensible tradeoff decisions.
Modularization
Another concept from structured programming is the idea of the functional module-one module, one function. This idea is particularly appealing to the overstructured manager because it allows the substitution of labeling for thinking. Modular thinkers place more faith in labels — if the chart says Jack is in training today, then Jack must be learning something today.
What is the cure for modular thinking? Here there seems no substitute for experience with real human beings in all their lumpy glory. Sometimes this experience can be gained in workshops. I’ve noticed that volunteer community work, like working with handicapped children, seems to encourage remarkably fast erasure of modular thinking.
Iteration
Iteration, the third of the “big three” control structures, is also heavily favored by overstructured managers. One form of iteration is related to labeling. A manager simply repeats the same cliché over and over, as if it is a magical incantation that will solve problems. One observation done out of context leads to a baseless conclusion which in turn leads the manager to make a wrong and often annoying decision. And the more the manager repeats such a cliché, the more he annoys the employees. And because no one respects an annoying boss, nothing gets done.
What is to be done?
Try harder? People under pressure tend to revert to problem-solving strategies that worked for them in the past. If we tell managers to “try harder”, it will only make the problem worse. If we are to achieve better software engineering management, we must alleviate the pressure, not increase it. An overloaded manager is usually a bad manager.
V. Managing Yourself
Ultimately, if you can’t manage yourself, you have no business attempting to manage others. That may sound like a moral issue, but it’s actually a matter of effectiveness. When you become a manager, your added status magnifies your best efforts. At the same time, however, that power magnifies your ever tiny screw-up. There’s an old army saying, “The higher you climb the flagpole, the more people see your rear end.”
In this section, we will study several critical things about yous your people will always be watching:
• your strong emotional reactions, especially anger
• your style: blaming or congruent
• your ability to stay competent over time
1. Anger Management
What is anger, anyway? Your initial reaction to anger is to be aware of danger, though you may react to this danger in a variety of ways. You may move away from the angry person, or get angry back at them. But your awareness of danger is the clue that tells you what anger is all about.
Anger is a defensive reaction by someone who believes I’m hurting them, or threatening to hurt them. (Think of “anger” as defensive-anger, or d-anger.) But it has its consequences. A little anger can go a long way towards ruining a relationship.
Why Anger Is a Poor Tactic for a Manager
Anger persists because it has survival value. In a sufficiently primitive social system (like a schoolyard or a dog pen), anger — with its threat of escalation — can actually stop physical combat, with all its accompanying dangers.
But are your management tasks really that primitive? In the office environment, what can you threaten them with? People with management jobs might be able to use anger effectively. Employees who have given their career into the hands of one organization have lots to fear — getting fired and losing their accumulated benefits; making enemies who can hurt them at some later and unpredictable time.
And because employees have such reasons to be fearful of their managers, some managers can motivate people by using angry outbursts. But do these managers realize the long-term consequences of leading by fear? Do you want to manage in this way?
Identify and Interrupt Your Anger Sequence
Anger has only a few patterns. The most common pattern is
1. You notice something going on.
2. You’re distracted as this something continues.
3. You become concerned that it will affect the quality of your work.
4. If it continues, you become worried.
5. Then you grow anxious.
6. Then annoyed.
7. Then irritated.
8. Then you explode, and lose your ability to see more of your pattern.
If I want to succeed as a manager, I can’t afford to escalate like this. Instead, I can break into the sequence before it reaches the level of anger.
The earlier you catch your feelings, the more competent you still are to communicate about them. And the more competently you communicate, the more likely you are to be able to change the situation and remove the source of anger. Conversely, as your anger escalates, your mental powers deteriorate, and you become less and less likely to muster the full resources of your brain to deal with the situation.
Interrupt The Other Person’s Anger Sequence
Some of the most useless angry blowups occur when neither party is terribly threatened by the other, but they engage in a mutual feedback loop. The overall pattern of the system of person A and B is based on the dynamic
1. When A feels threatened by B, A shows some anger.
2. When B sees A’s anger, B feels threatened by A, so B shows A some anger.
3. Loop back to (1).
Clearly, this loop will lead to an explosion of anger unless A or B deliberately breaks the pattern.
Now if B thinks that A is s person just like him, with his own anger pattern, B will realize in the first stage that something is threatening A, and there’s no sense in B raising the threat level. So, instead of feeling threatened by A’s anger, B breaks the pattern and confronts politely what might be triggering A. And there, both A and B are not angry now.
2. Beyond Blaming: Congruence
What is congruence? It is a concept that describes the human experience of alignment between the internal and external–what is thought and felt (the internal), and what is said and how it is said (the external). In order to operate congruently in the world, you need to take into account three general factors: self (the internal world), other (the immediate external world of people), and context (the larger external world of things, structures, processes, laws, and cultures).
Congruence is integrity at the most basic level and thus has immense value to a project and each individual in it. Without integrity, we cannot build trust; without trust, we don’t feel safe; without safety we have a hard time being congruent. Thus, congruence reinforces congruence in a powerful loop which improves the chances of producing a quality product, on time, and within budget.
What is Blaming?
In a congruent organization, your manager asks, “Where does your project stand?” and you answer, “I’m rather scared that I’m not going to make my schedule.” This starts a problem-solving discussion, out of which the two of you make new plans to get the project back on track. In a blaming organization, however, your manager may well tell you that only inferior people lack confidence. In that case, problem-solving will be replaced by blame-avoidance.
How Blaming Hurts a Project
Normal project management can deal with limited situations in which people behave incongruently. But when the whole environment encourages blame, each new situation further elaborates the incongruence. Blaming culture hurts a project in at least six major ways:
1. People commit to plans they know they cannot achieve, at least to delay blame.
2. People hide facts that managers need to control the project.
3. When problems are finally revealed, people avoid coming forth with creative solution ideas, for fear they will be blamed if the ideas don’t work, or simply appear dumb at first glance.
4. In day-to-day operations, a major portion of everyone’s effort is devoted to positioning themselves so they will not be accused when the time of reckoning arrives.
5. Those people who somehow feel safe enough to focus on the job at hand find themselves spending large amounts of time checking up on the reliability of others’ communications.
6. People feel bad most of the time, and spend a lot of time fiddling with unproductive tasks or simply staring at the walls.
Congruent Culture
Congruence is the bright secret underlying the success of many projects. A congruent culture helps a project in at least six major ways:
1. People commit to plans they know only after open negotiation, so plans are more likely to be realistic in the first place.
2. People come forth readily with facts that managers need to control the project, as soon as they are known, so managers can act early and act small to correct the problems.
3. When problems are revealed, people readily come forth with creative solution ideas, increasing the chances for quick and effective solutions.
4. A major portion of everyone’s effort is devoted to getting their jobs done, and helping other get their jobs done.
5. Because human fallibility is considered normal, an appropriate–but small–amount of time is spent assuring the reliability of communications.
6. People feel good most of the time, and thus are productive most of the time.
Achieving Congruence
When Deming said, “Drive fear out of the workplace,” we think he was talking about changing the blaming organization to the congruent organization.
Let’s look at how each of these steps takes place in the context of an individual trying to change a blaming organization.
Awareness
Awareness says, “This is happening. This is real.” Awareness comes from experience. But awareness of the overall situation is not sufficient–you also need self-awareness. Self-awareness says, “This is me. This is mine.” You may be fully aware of the blaming, but as long as you merely say, “This is a blaming organization,” you’re not doing anything to change it. When you say, “I am a part of this blaming organization,’ you move forward. You own the blaming as a part of yourself and your behavior–not just something that “they” do (to you).
Acceptance
Acceptance moves the change process beyond self-blaming and says, “I’m not a bad person because I do this. My intentions are good, though my actions may not be effective.” Acceptance means that you understand that taking responsibility is not the same as blaming yourself.
Authorship
Authorship is the first decision point, when you say, “I have choices. I can do something about this.” With some encouragement, you accept that you are responsible for choice in your life. You understand that you don’t have to react, but that you can chose your response–that you create, in large part, your own interpersonal context.
Articulation
Articulation is the public commitment to change, and says, “I’m going public with this (for accountability and support).” Articulation is ineffective if attempted before the prerequisites are in place. If you can’t accept yourself or how you have reflected yourself out to the world, or if you don’t know that you have choices or feel you can gain support for those choices, then speaking out is merely ineffective bravado.
Application
Application says, ‘These are my choices (my new ways of coping).” You learn to be congruent yourself, first in your most immediate, safe, and encouraging context. Then you expand the contexts in which you can respond congruently.
Activism
Activism says, “Now that I can make a difference in myself and my most familiar world, I’m going to help spread this throughout the organization.” Activism is applied leadership, starting at the point at which you have enough competence at being congruent to reach out and be proactive–anticipating, initiating, instigating–but not inflicting.
3. In Danger of Success
If you’re not careful, your success as a manager can breed your failure.
Foolish pride
Success not only produces bigness, but also pride. Pride is a satisfying emotion, but may interfere with the acceptance of change.
The home-grown algorithm may have been the best in the world five years ago, yet now is inefficient and inappropriate because of new discoveries of new cost relationships among hardware, software, and personnel. When the oId method wasn’t ever very good, there’s not much resistance to dropping it for something better, but it’s truly an emotional blow when someone suggests putting the old champion out to pasture. For you, as manager, the dynamic is similar. You have many “algorithms” for managing, but they may no longer be appropriate.
Frozen knowledge
Success also produces capital, not just as money in the bank. Capital, whether in buildings, hardware, or software, is frozen knowledge. It represents an ever-growing investment in any successful organization, and provides the basis for future productivity. On the other hand, with a large capital stock, it’s terribly tempting to live on the returns to capital, rather than discard old knowledge for new. Such a change may require careful studies to justify scrapping the old hardware or software before it has generated maximum financial return. In your successful organization, however, those people capable of making such studies are too busy making money using the old investment.
Failing to adapt
Individuals, too, bear the burden of success. Few people become good programmers, but of the good ones, fewer still improve their technical competence through the change to a new language, machine, or operating system. Indeed, the majority don’t even retain the level of technical competence they had on the old system. Instead, they feel unable to move with the times, and accept the first promising non-technical position they are offered.
Successful managers can fail the same reasons successful programmers fail: inability to adapt to changed circumstances. And when successful managers fail to adapt, their organization has one more major burden to prevent its forward movement.
4. Staying Young
Should old acquaintance be forgot, and never brought to mind? Should old acquaintance be forgot, and auld lang syne?
Peter Principle simulated
All new members in a hierarchical organization climb the hierarchy until they reach their level of maximum incompetence.
The Peter effect arises from the practice of promoting the best performer at Level N to a position at level N+1. The Italians also simulated two other promotion policies:
1. Alternately promote first the most competent and then the least competent individuals.
2. Promote individuals at random.
According to their simulations, each of these methods improves the efficiency of an organization over the Peter method.
My thought: They could try promoting on the basis of who is most suited for the next level job. Duh! Or maybe they could try not mixing the concept of “promotion” with that of “reward.”
The Paul Principle
People become progressively less competent for jobs they once were well equipped to handle.
Paul proposed his law in 1970, and claimed his principle was more relevant in hightech fields, when the complexity of jobs grows faster than the people doing them. The Paul Principle has been virtually forgotten, but I think it is still worth some careful thinking by IT managers, consultants, and coaches.
The Other Paul Principle
Continue to provide people with what they need to succeed.
I suspect this management principle would also prove more effective at growing an organization than the Peter Principle. As a manager, you may not need to remain technologically current, but if you want to remain an effective manager, you’ll have to keep renewing yourself. As the years slip by, you’re going to be subject to the same “old fogey” dynamic of the Peter and Paul principles. So how do you beat this tendency to become an old fogey before your time?
5. Your time dimension
As a manager, you may not need to remain technologically current, but if you want to remain an effective manager, you’ll have to keep renewing yourself. As the years slip by, you’re going to be subject to the same “old fogey” dynamic of the Peter and Paul principles. So how do you beat this tendency to become an old fogey before your time?
I believe you must plan to invest at least 10% of your time and money investigating new things, and 20% would be better. You have to be ready and willing to risk a total loss on your investigations. If you’ve never read a stupid article, never gone to a useless conference, and never tried out a crippled software tool, you’re playing it too safe. You have to be willing to risk making a fool of yourself, otherwise you’re sure to make a fool of yourself.
