by Gerald Weinberg, 1986 (2011 Kindle Edition), 304 pages
I have looked up books about technical management and this one was among the mostly recommended ones (along with Peopleware and Mythical Man Month) to develop and refine skills in technical leadership. Since I have no formal training in technical management, I wanted to learn more and make myself a more valuable member of our tech team.
This book comes from the Author's course "Technical Leadership in Computer Programming". It's basically a self-paced workshop, written as a book, broken down to 24 chapters. Every chapter covers an aspect of what it means to be a problem-solving leader, usually with several anecdotes, and ends with a number of questions for reader to work through. A large number of exercises and questions are more suitably for a study of the book, not a casual read before bed.
The main idea is that "becoming a leader is not something that happens to you, but something that you do", so the focus of the book is working on oneself, using the book as a guide.
The first five chapters are about dispelling the myths surrounding the ideas of the leadership. For some, discussing leadership might be difficult, for many, recognizing it is a challenge. Shown are the ways how the traditional psychology can't understand or describe technical team dynamic, since one person might make 100 commits (big influence), while another can fix a single bug among their colleague's contributions, which makes a way greater impact.
Someone once said that the central dogma of academic psychology is that there is one and only one correct solution to every problem— and the psychologist knows it.
Linear models tend to look at roles (a boss is supposed to behave in such-and-such way), where organic models look in terms of relationships (boss thinks how are himself and the coworker related to the problem).
The organic model says that leadership is the process of creating an environment in which people become empowered. When people are empowered, they are free to see, to hear, to feel, and to comment. They are also free to move about, to act, to ask for what they want, to be creative, and to make choices.
Effective leadership looks into each involved's persons strengths and weaknesses instead of relying on a strict reward/threat model. Proposed alternative is a "MOI" model.
- Motivation - what is it that makes people get involved?
- Organization - structure enabling that ideas be put in practice
- Ideas - or Innovation, the seeds of what will become a reality
Everyone can be a better leader by working on their weaknesses - "Mr. Universe doesn’t have more muscles than I do, just better developed ones."
The best technical leaders make sure they really understand the problem, manage the flow of ideas and maintain quality. Creating a new metrics system (I-strategy) involves showing the people the usefulness of it (M-strategy) and documenting and describing the ways to use it (O-strategy).
One of the strongest ideas here is that there is always a better way.
According to the threat/ reward model, the number of ideas in the world is limited, so for each person who succeeds as a problem-solving leader, a hundred others must fail. For one to be on top, many others must be on the bottom. Perhaps that is why so many people are warning us of the dangers of high technology.
The part about understanding the problem clearly is heavily emphasized, and here's a part I found very informative:
Read the specifications very carefully. Success or failure often turns on minuscule differences in problem definitions.
Although it is necessary to have an overview of the problem, the big picture often turns on one critical detail. Problem-solving leaders recognize this and pay attention to such details. Hackers, by contrast, become bored and want to rush on to something else the instant they have a solution that seems to work. To the worst type of hacker, the ultimate user of the solution is merely a nuisance.
I recall a bid for a computer system that called for 99.9 percent availability, a difficult and expensive requirement to meet. One of the design engineers, however, noticed that the company’s definition of “availability” was not quite what the engineers had believed. It proved to be acceptable to bring the system down if the company was notified at least an hour in advance, which enabled the engineers to design an error-detection scheme, rather than an error-prevention scheme. The difference was worth about four million dollars, but two of the engineers still wanted to build the error-prevention system because it was a more interesting technical problem. They had no idea who would pay the extra four million dollars, and they didn’t really care.
And another one
Resolve arguments by referring back to the original problem. Unless and until all members of a team have a common understanding of the problem, attempts to solve the problem are just so much wasted energy.
Most prolonged arguments are not over the relative value of the solution, but over different understandings of the problem.
Problem-solving leaders are able to read the signs that tell whether an argument is based on a difference in problem definition or a difference in solution method. Seek clarifications and additional information about the specifications from the customer.
No worthwhile project is ever described fully and correctly, even in a written document, but some people would rather plunge right in with what they have than interact with other people.
How to manage the flow of ideas?
- Contribute a clever idea to the team.
- Encourage copying of useful ideas.
- A bit of research might save a lot of time. There's very few truly original ideas
- Elaborate on an idea that a teammate contributed.
- No idea is perfect when first suggested
- Drop one’s own idea in favor of an idea the team wants to develop, and Refuse to let an idea drop until everyone understands it.
- Resist time pressure, and take the time to listen when other people explain their ideas.
- Under pressure, most ideas get dropped before they are understood
- Test ideas contributed by other people.
- Withhold quick criticism of teammates’ ideas, in order to keep the ideas flowing.
- Criticism is one thing, quick criticism is another
- When you must criticize an idea, make clear that you are criticizing the idea, not the person who offered the idea.
- Test your own ideas before offering them.
- Make time to consider your idea, or you risking boring the teammates or preventing them from contributing by droning about your undeveloped idea
- When time and labor are running short, stop working on new ideas and just pitch in.
- Encourage the team to drop ideas that had succeeded earlier, but cannot be extended to the new situation.
- Even pizza gets boring if you have it five days in a row
- Revive a dropped idea later, when it has value for another part of the problem.
- No idea is bad, only inappropriate for time and place; sometimes old technologies might solve newest problems
How to maintain quality? Like a chef, who tests the meal several time while preparing it, keep coming back to the requirements and measure if the result satisfies the quality requirements. Never compromise on quality, if necessary, change the schedule. Sometimes, take a step back and get a fresh perspective of your problem/solution. Restore morale when an idea collapses by reminding everyone it's a release from a fruitless idea.
The development of leaders is a process of growth and stagnation. More often than not, when you learn something new, you get in a ravine, where your productivity is worse than you've started. But after a while, you soar to a new plateau (think learning a new programming language). The growth is a series of such cycles. Don't be afraid of the ditch, but look forward to the next plateau.
It's easy to fall into a trap of believing in an appointed leader.
In a well-designed engine, there is no weakest link. If spark plugs are truly the weakest link, then a superior engine design eliminates the spark plugs altogether, giving us the diesel engine. Or, if you can’t think how to eliminate spark plugs, at least you make them easily interchangeable.
In the same way, the best-designed working groups are those in which leadership comes from everybody, not merely the appointed leaders. Therefore, you need not wait you should not wait— for an appointment.
There is no leader type - everyone can be one, taking initiative in areas they feel strong, where they could teach others, and lead by example.
Three big obstacles preventing innovation:
1.) Self-blindness
We are mostly unable to see ourselves how others see us, especially in our least productive behaviors. The best way is asking another person to watch you and accepting their honest feedback, making it mutual by also observing them and giving them feedback too.
2.) NO-PROBLEM syndrome
A innovation-stifling issue very common in hi-tech is automatic response of "No problem" when someone describes a complex problem. It's very often a lack of listening to the problem and proper understanding of it.
Here's how to deal with it:
- You describe your very difficult problem.
- The respondent says, “No problem!”
- You say, “Oh, that’s terrific! Could you please describe my problem that you’re going to solve?”
- a. If the respondent then describes your problem, even erroneously, it’s not a case of NPS but only a case of Enthusiasm. b. If the respondent describes a proposed solution to your problem rather than the problem itself, then sadly it’s NPS. The kindest thing you can do for all concerned is smile and walk briskly to the nearest exit.
3.) Single Solution Belief
Coming from the academic psychology, the idea that every problem has exactly one solution is poison. No situation in life has just one single "best" possible solution. It prevents people and teams from considering a number of alternative proposals and it stops the search for the more suitable solution once a fit is found.
The simple tool to build self awareness is to lead a personal journal. The best scientists and engineers always kept a journal of their work. You can write about what happened during the day, how it made you feel and what you learned from it - or just write whatever you want, but make sure you do. Anything you write down will be relevant to you.
When working on solving a problem remember that any real problem has one more solution, which nobody has found - yet. Don't be afraid of errors, it was ruined photo film that pushed Becquerel to discover X-rays and a contaminated bacterial culture what made Pasteur to come up with penicillin.
Don't be ashamed of lifting ideas. Stealing idea from one person is called "plagiarizing" and stealing from many is called "research".
To get new ideas, don't be afraid of making mistakes, stealing from others and combining multiple ideas together.
To foster innovation from other and create an empowering environment, make sure everybody knows and understands the overarching vision. Nobody becomes a leader because they don't fail, but because of how they respond to failure. Think about your personal vision, what is it that makes you do what you do. You are #1 character in the story of your life - what do you believe in?
First great obstacle in motivation is inability to see yourself how the others see you. It takes great effort to be impartial and see yourself from another person's point of view.
Top problem solvers tend to believe that they each have succeeded without the help of other people. Other people are invisible, or, if seen at all, are seen as obstacles.
But when the individual star tries to become a leader, this lack of awareness of other people’s reactions becomes the number one obstacle.
Other people are welcome to work with the genius, so long as they stay out of the way and confine themselves to admiration and administration.
To better understand ourselves, we can use the following interaction model. All of these steps happen in each instance of communicating with another person:
- sensory input
- what enters through the ears (if listening) or eyes (if reading)
- interpretation
- what I think is being said
- feeling
- how I initially react
- feeling about feeling
- how I feel about my reaction
- defense
- what I want to respond with
- rules for commenting
- self-censorship - what's okay to say
- outcome
- what I eventually respond with
You can only start helping if both parties have a clear understanding of the problem at hand.
Helping other people might be a noble goal, but that doesn't make it any easier. If people don't want your help you'll never succeed in helping. Always check if they want their help, otherwise you might be taken as a nosy meddler. Attempts at help are often interpreted as attempts to interfere.
The rest of the part 3 goes into exploration of one's own motives and feelings about being motivated by others, to better understand how we think and feel. It includes a lot of questions to work through, but is extremely enlightening.
Part 4 is about organizing teams, with tools and suggestions and part 5 is about creating one's own personal plan to change into a problem-solving leader.
The book was mostly an enjoyable read, but I found the style to be somewhat dry and had to keep myself alert. The numerous real-life anecdotes help to get certain points across and break up the "teaching" tone of the chapters.
I did gloss over some more abstract parts but mostly, I've answered all the questions at the end of each chapter. Since every chapter is self-contained, it seems useful to refer to a specific chapter when dealing with related issues (for example chapters in Part 4 on organization, when I'm tasked with making sure a certain project needs to be done)
I will definitely re-read the book and do the exercises again after few months. It's a good resource on problem-solving leadership and a valuable reference. Since it's organized as a workshop, the real value I see in continuing to work on myself using it as a guide, and keep coming back to it to see how well or how badly I'm doing.