Tom DeMarco, Timothy Lister • 1987, 2014 • ISBN 978-0-321-93411-6 • 272 pages
Amazon • Goodreads • Wikipedia
Tim Lister (born 1949) is a software engineer with specialty in software risk management is a lecturer and author on several books on software management.
Tom DeMarco (born 1940) is a software engineer, lecturer and an early developer of structured analysis. Fellow of IEEE and received Warnier Prize for "lifetime contribution to the field of computing" in 1986 and Stevens Award for "contribution to the methods of software development" in 1999.
Both authors are principals of Atlantic Systems Guild, a consulting company specialized in methods and management of software development. They've been lecturing, consulting and writing on management, estimating, productivity and corporate culture since 1979.
This is one of the books found in most must read lists for software engineers. It's notable for dealing with team productivity and people management. As the authors themselves noted
"Maybe... the major problems of systems work are not so much technological as sociological."
Being able to organize programmers into a productive team is often compared to herding cats, and seems to be an endemic issue in the industry. I wanted to understand team dynamics better and make our team work smoother and be more productive. I was also curious to see what are we already doing right, and where could we improve our practices to empower our team.
The book is made out of 39 chapters broken down to five sections - Managing the Human Resource, The Office Environment, The Right People, Growing Productive Teams, Fertile Soil and It’s Supposed to Be Fun to Work Here
The main goal of the book seems to be to shine light on team dynamics and help software development teams to be successful, since most issues in software development are sociological, any technology is unlikely to solve them.
...it soon became clear to both of us that the social complexities on most of the projects we’d known simply dwarfed any real technological challenges that the projects had had to deal with.
Most technological managers fall into the trap of trying to manage people like modular pieces. It's a consequence of the experience in the industry where most technology can and is managed in modular pieces. It doesn't work when trying to manage people the same way.
With over 500 project surveys (authors call them project autopsies) some trends emerged:
- 15% of projects got canceled, postponed or resulted in products never used
- 25% projects that lasted 25 work-years or more failed to complete
There was never a technological reason for these failures - it always boiled down to sociological problems. Most people in the industry like to think they are in high-tech business. The truth is only the people who brought the breakthroughs are in the high-tech business. The rest of us are appliers of their work. We're in the people business.
Speaking to a group of software managers, we introduced a strategy for what we think of as iterative design. The idea is that some designs are intrinsically defect-prone; they ought to be rejected, not repaired. Such dead ends should be expected in the design activity. The lost effort of the dead end is a small price to pay for a clean, fresh start. To our surprise, many managers felt this would pose an impossible political problem for their own bosses: “How can we throw away a product that our company has paid to produce?” They seemed to believe that they’d be better off salvaging the defective version even though it might cost more in the long run.
It should be acceptable, even encouraged to make mistakes
Fostering an atmosphere that doesn’t allow for error simply makes people defensive. They don’t try things that may turn out badly. You encourage this defensiveness when you try to systematize the process, when you impose rigid methodologies so that staff members are not allowed to make any of the key strategic decisions lest they make them incorrectly.
In traditional management, it's difficult to recognize more intangible contributions. People's worth tends to be evaluated based on the quantity of work they do, like the amount of lines of code they produce.
The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work.
It might be difficult for a "regular" manager to recognize catalyst's contribution
I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me to request that I assess some of the people in the course (his project staff). He was particularly curious about one woman. It was obvious he had his doubts about her: “I don’t quite see what she adds to a project; she’s not a great developer or tester or much of anything.” With a little investigation, I turned up this intriguing fact: During her 12 years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn’t obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out. He just didn’t recognize the role of catalyst as essential to a project.
The more intensely deadlined the project is, the more important is to have frequent revisits of the project's goal and purpose and brainstorming sessions about the project's parts.
The project that has to be done by an impossible fixed date is the very one that can’t afford not to have frequent brainstorms and even a project dinner or some such affair to help the individual participants knit into an effective whole.
In almost a perverse way, managers seem to believe that making people work harder and longer is a sign of their success at team management
Some years ago, I was swapping war stories with the manager of a large project in Southern California. He began to relate the effect that his project and its crazy hours had had on his staff. There were two divorces that he could trace directly to the overtime his people were putting in, and one of his worker’s kids had gotten into some kind of trouble with drugs, probably because his father had been too busy for parenting during the past year. Finally, there had been the nervous breakdown of the test-team leader. As he continued through these horrors, I began to realize that in his own strange way, the man was bragging. You might suspect that with another divorce or two and a suicide, the project would have been a complete success, at least in his eyes.
Here we get introduced to Spanish and English Theories of Value.
- Spanish: a fixed amount of value exists, therefore the only way to get more wealth is to exploit it better from earth or people's backs
- English: wealth can be created from creativity and ingenuity
As a result, England had the Industrial Revolution, and Spain spun it's wheels trying to exploit the land end people in the New World. Among many managers, the Spanish theory is alive and well
Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay.
Overtime isn't a real benefit to anyone. Nobody can really work over forty hours, at least not continually and with the intensity required for creative intellectual work.
Overtime for salaried workers is a figment of the naïve manager’s imagination. Oh, there might be some benefit in a few extra hours worked on Saturday to meet a Monday deadline, but that’s almost always followed by an equal period of compensatory “undertime” while the workers catch up with their lives. Throughout the effort, there will be more or less an hour of undertime for every hour of overtime. The trade-off might work to your advantage for the short term, but for the long term it will cancel out.
Workaholics might put in extra hours for long time before they realize they sacrificed something more important (their spouses, their children, their lives) for something less important (work) which will leave them disappointed and probably quitting the job, being another case of burnout.
If you exploit them to the hilt in typical Spanish Theory fashion, you’ll eventually lose them. No matter how desperately you need them to put in all those hours, you can’t let them do so at the expense of their personal lives. The loss of a good person isn’t worth it.
Psychologists have identified a small number of basic instincts dominating every person (survival, self-esteem, reproduction, territory etc). Any time strong emotions are involved, it's most likely that one of these instincts was threatened. And in the workplace, most often it's the self-esteem.
Managers jeopardize product quality by setting unreachable deadlines. They don’t think about their action in such terms; they think rather that what they’re doing is throwing down an interesting challenge to their workers, something to help them strive for excellence.
We all tie our self-esteem to the quality of our work - nobody takes pride in producing ton of mediocre stuff. Anything that might jeopardize the quality of the project will cause the team working on it to flare up.
Workers kept under extreme time pressure will begin to sacrifice quality. They will push problems under the rug to be dealt with later or foisted off onto the product’s end user. They will deliver products that are unstable and not really complete. They will hate what they’re doing, but what other choice do they have?
Decision to pressure people into delivering a product that doesn't measure up to their own quality standards is almost always a mistake. In the words of Tajima and Matsubara (1984. "Inside the Japanese Software Industry")
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.
Writing in 1954, the British author C. Northcote Parkinson introduced the notion that work expands to fill the time allocated for it, now known as Parkinson’s Law.
Unlike Newton's laws which are physical laws you cannot break, Parkinson's law got accepted not because it was true, but because it was funny. It mostly applies to bureaucracy, as a workplace where there's little satisfaction.
In tech industry it's more likely people will rush to complete the job, to get the satisfaction of publishing something they can be proud of.
In a healthy work environment, the reasons that some people don’t perform are lack of competence, lack of confidence, and lack of affiliation with others on the project and the project goals. In none of these cases is schedule pressure liable to help very much. When a worker seems unable to perform and seems not to care at all about the quality of his work, for example, it is a sure sign that the poor fellow is overwhelmed by the difficulty of the work. He doesn’t need more pressure. What he needs is reassignment, possibly to another company.
Two respected researchers at the University of New South Wales, Michael Lawrence and Ross Jeffery ran annual surveys on different aspects of tech industry in 80ies and 90ies. The survey from 1985 looked into effectiveness of different estimating methods. Turns out
Programmers seem to be a bit more productive after they’ve done the estimate themselves, compared to cases in which the manager did it without even consulting them.
However, when they added a system analyst, the productivity was higher
The systems analyst tends to be a better estimator than either the programmer or the supervisor. He or she typically knows the work in as much detail, but is not hampered by the natural optimism of the person who’s actually going to do the job or the political and budgetary biases of the boss. Moreover, systems analysts typically have more estimating experience; they are able to project the effort more accurately because they’ve done more of it in the past and have thus learned their lessons.
However, most surprising was the fact that biggest productivity was when there were no estimates at all
Laetrile is a colorless liquid pressed from the soft bitter insides of apricot pits. In Sweden, you can buy the stuff in the grocery store for about the price of almond extract, and you use it in baking much as you would any other extract. In Mexico, you can buy it for fifty dollars a drop to “cure” your fatal cancer. Of course, it doesn’t cure anything... People who are desperate enough don’t look very hard at the evidence. Similarly, lots of managers are “desperate enough,” and their desperation makes them easy victims of a kind of technical laetrile that purports to improve productivity. There is seldom any evidence at all to support the claims of what they buy.
Too often people grab onto anything promising them more productivity, especially if it's a technological solution - simply because it's easier to use a technological solution than dealing with people
We’re all under a lot of pressure to improve productivity. The problem is no longer susceptible to easy solutions, because all the easy solutions were thought of and applied long ago. Yet some organizations are doing a lot better than others. We’re convinced that those who do better are not using any particularly advanced technology. Their better performance can be explained entirely by their more effective ways of handling people, modifying the workplace and corporate culture
The best managers understand it's not their job to make people work, but to make it possible for people to work
In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, later to become president of the Codd and Date Consulting Group. She was a walking example of much of what I now think of as enlightened management. One snowy day, I dragged myself out of a sickbed to pull together our shaky system for a user demo. Sharon came in and found me propped up at the console. She disappeared and came back a few minutes later with a container of soup. After she’d poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do. She gave me her patented grin and said, “Tom, this is management.”
There are a million ways to lose a workday, but not even a single way to get one back.
Even though our team doesn't work in a traditional office, we're still vulnerable to distractions and other productivity killers
The Furniture Police are people in charge of office spaces. They usually don't collect any data or do research on the spaces conducive to productive work (like closed vs open spaces etc).
While on break at a seminar, a fellow told me that his company doesn’t allow anything to be left on the desk at night except for a five-by-seven photo of the worker’s family. Anything else and in the morning you’ll find stuck to your desktop a nasty note (on corporate letterhead yet) from the Furniture Police. One guy was so offended by these notes that he could barely restrain his anger. Knowing how he felt, his fellow workers played a joke on him: They bought a picture frame from the local five-and-dime store, choosing one with a photograph of an all-American family as a sample. Then they replaced the photo of his own family with the other. Under the photo was what looked like a note from the Furniture Police, stating that since his family didn’t pass muster by the corporate standards, he was being issued an “official company family photo” to leave on his desk.
Open office spaces are probably the worst. Since there's not enough windows for everybody - nobody gets the window. Such places are un-private, noisy and sterile. More suitable for prison inmates than people doing intellectual work.
To be productive, people may come in early or stay late or even try to escape entirely, by staying home for a day to get a critical piece of work done. One of our seminar participants reported that her new boss wouldn’t allow her to work at home, so on the day before an important report was due, she took a sick day to get it done.
The authors performed a number of surveys with programmers from 92 companies to establish the factors that affected productivity. The things that didn't affect productivity were:
- Language - doesn't matter if they used Cobol or C
- Years of experience - people with ten years of experience didn't outperform those with two
- Number of bugs
- Salary
What surprised the authors was the fact that who you work with has the most influence on the productivity
Two people from the same organization tend to perform alike. That means the best performers are clustering in some organizations while the worst performers are clustering in others.
Software pioneer Harlan Mills predicted in 1981
While this [10 to 1] productivity differential among programmers is understandable, there is also a 10 to 1 difference in productivity among software organizations.
The best organization worked more than ten times faster than the worst organization.
The bald fact is that many companies provide developers with a workplace that is so crowded, noisy, and interruptive as to fill their days with frustration. That alone could explain reduced efficiency as well as a tendency for good people to migrate elsewhere.
It might be that the better environment in the workplace isn't the reason for boosted productivity - it might mean that better programmers migrate to workplaces with more productive environments. In any case, it proved that paying attention to the workplace environment is important.
American office workers have barely looked up while their work quarters have been degraded from sensible to silly. Not so long ago, they worked in two- and three-person offices with walls, doors, and windows. (You remember walls, doors, and windows, don’t you?) In such space, one could work in quiet or conduct meetings with colleagues without disrupting neighbors. Then, without warning, open-plan seating was upon us like a plague upon the land. The advocates of the new format produced not one shred of evidence that effectiveness would not be impaired. They really couldn’t. Meaningful measurement of productivity is a complex and elusive thing. It has to be performed differently in each different work sector. It takes expertise, careful study, and lots of data collection.
The real reasons for the open-plan offices are easier electrical distribution planning, computer support capabilities and more effective use of space. It's not considering people who will work there.
Most workers from open-plan offices complained mostly about the noise - and the research showed the noisier the environment was, more bugs were made in their code.
When the office environment is frustrating enough, people look for a place to hide out. They book the conference rooms or head for the library or wander off for coffee and just don’t come back. No, they are not meeting for secret romance or plotting political coups; they are hiding out to work. The good news here is that your people really do need to feel the accomplishment of work completed. They will go to great extremes to make that happen. When the crunch is on, people will try to find workable space no matter where. If you peek into a conference room, you may find three people working in silence. If you wander to the cafeteria midafternoon, you’re likely to find folks seated, one to a table, with their work spread out before them. Some of your workers can’t be found at all. People are hiding out to get some work done. If this rings true to your organization, it’s an indictment. Saving money on space may be costing you a fortune.
A short chapter inserted between others deals with how to measure productivity. For a number of reasons the intellect-work productivity measurement is considered elusive and immeasurable - for some people, like a study of UFOs.
In London for one year’s International Conference on Software Engineering, I spent an afternoon with Tom Gilb, the author of Software Metrics and dozens of published papers on measurement of the development process. I found that an easy way to get him heated up was to suggest that something you need to know is “unmeasurable.” The man was offended by the very idea. He favored me that day with a description of what he considered a fundamental truth about measurability. The idea seemed at once so wise and so encouraging that I copied it verbatim into my journal under the heading of Gilb’s Law:
Anything you need to quantify can be measured in some way that is superior to not measuring it at all.
Gilb’s Law doesn’t promise you that measurement will be free or even cheap, and it may not be perfect— just better than nothing.
We can't afford not to know, and frankly, without some sort of measurement, we haven't the foggiest idea where our productivity stands
Given that there are ten to one differences from one organization to another, you simply can’t afford to remain ignorant of where you stand. Your competition may be ten times more effective than you are in doing the same work. If you don’t know it, you can’t begin to do something about it.
Even though the work measurement can be used for improved motivation and work satisfaction, it's rarely used that way - more commonly it's burdensome and threatening. Data collected on the individual should only serve that individual, and not passed up, except the anonymized averages.
Collection of this very sensitive data on the individual can only be effected with the active and willing cooperation of the individual. If ever its confidentiality is compromised, if ever the data is used against even one individual, the entire data collection scheme will come to an abrupt halt.
The individuals are inclined to do exactly the same things with the data that the manager would do. They will try to improve the things they do less well or try to specialize in the areas where they already excel. In the extreme case, an individual may even “fire” himself in order to stop depending on skills that have been found to be deficient. The manager doesn’t really need the individual data in order to benefit from it.
In one of the studies it showed that on average day, developers worked 30% alone, 50% of the time with one more person, and 20% time with more than one person. Which means, 30% of the time we're noise sensitive and the rest of the time, we're noise generators
During single-minded work time, people are ideally in a state that psychologists call flow. Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: “I began to work. I looked up, and three hours had passed.” There is no consciousness of effort; the work just seems to, well, flow. You’ve been in this state often, so we don’t have to describe it to you.
It usually takes around 15 minutes of dedicated focus to get in the flow (or the zone), during that time, the person is sensitive to distractions. Any interruption in the flow and it requires another period of immersion to get to the same productive state.
The phenomena of flow and immersion give us a more realistic way to model how time is applied to a development task. What matters is not the amount of time you’re present, but the amount of time that you’re working at full potential. An hour in flow really accomplishes something, but 10 six-minute work periods sandwiched between 11 interruptions won’t accomplish anything.
Because of this reason, it's unfair and unrealistic to time-measure people for their effectiveness. People should be logging uninterrupted hours. That's the brain time vs body time - how many hours people are actually mindfully working vs the number of hours they have been physically present.
In a standard office environment, the telephone is like a monster. Interrupting people for various reasons, mostly because everybody got used to using it whenever they feel like asking somebody a question, results in people planning less ahead. Not to mention that the ringing won't stop until you answer it.
One systems department head even wrote this:
It has come to my attention that many of you, when you are busy, are letting your phones ring for three rings and thus get switched over to one of the secretaries. With all these interruptions, the secretaries can never get any productive work done. The official policy here is that when you’re at your desk you will answer your phone before the third ring...
The most obvious solution and the one proposed by the authors is to use the phone only for emergencies and divert all other communication to e-mail.
The chapter is about the degradation of workplace environment, where only the top management gets to enjoy the luxury of having the door to their office - a way to stop distractions and noise. Most workers are immersed in the never-ending noise.
It emphasizes the need for workers to voice their concerns. Most people won't say anything, but when another person complains, they'll join in.
Appearance is stressed far too much in workplace design. What is more relevant is whether the workplace lets you work or inhibits you. Work-conducive office space is not a status symbol, it’s a necessity. Either you pay for it by shelling out what it costs, or you pay for it in lost productivity.
Management, at its best, should make sure there is enough space, enough quiet, and enough ways to ensure privacy so that people can create their own sensible work space. Uniformity has no place in this view. You have to grin and bear it when people put up odd pictures or clutter their desks or move the furniture around or merge their offices. When they’ve got it just the way they want it, they’ll be able to put it out of their minds entirely and get on with the work.
There is one timeless way of building.
It is thousands of years old, and the same today as it has always been.
The great traditional buildings of the past, the villages and tents and temples in which man feels at home, have always been made by people who were very close to the center of this way. It is not possible to make great buildings, or great towns, beautiful places, places where you feel yourself, places where you feel alive, except by following this way. And, as you will see, this way will lead anyone who looks for it to buildings which are themselves as ancient in their form, as the trees and hills, and as our faces are.
—Christopher Alexander, The Timeless Way of Building
This chapter deals with envisioning an ideal place to work. Even for people working in a cramped, noisy places currently, they might be in a position to create a better workplace someday. It discusses the theories of Christopher Alexander, especially his notion of Organic Order where the building is created piecemeal, locally, paying attention to the needs of people who'll be inhabiting the space.
Modern management science is more concerned with the boss's role of a principal strategist and how the work is done. It's much more important who is doing the work. Authors give us a formula for success as such:
- Get the right people
- Make them happy so they don't want to leave
- Turn them loose
Horatio Hornblower was an English officer during the Napoleonic wars. There are many analogies between running a team and commanding a ship. There are many lessons to be learned from his decisions.
In today's egalitarian times it's hard to accept Hornblower's conviction that achievers are born, not made. Parents do shape children into adults, but managers are unlikely to change their people in any meaningful way.
The people who work for you through whatever period will be more or less the same at the end as they were at the beginning. If they’re not right for the job from the start, they never will be. All of this means that getting the right people in the first place is all-important.
Too many times, the hiring decisions reflect the ideas of hiring manager's superior, and their superior and so on - the need uniformity reflects insecurity.
When the culture is unhealthy, it’s difficult or impossible to hire the one person who matters most, the one who doesn’t think like all the rest.
Uniformity is so important to insecure authoritarian regimes (parochial schools and armies, for example) that they even impose dress codes. Different lengths of skirt or colors of jacket are threatening, and so they are forbidden. Nothing is allowed to mar the long rows of nearly identical troops. Accomplishment matters only to the extent it can be achieved by people who don’t look different.
In one company, the managers forbade the employees from making popcorn using the company kitchen's microwave, deeming it unprofessional
The term unprofessional is often used to characterize surprising and threatening behavior. Anything that upsets the weak manager is almost by definition unprofessional.
Of course, this perverted sense of professionalism is pathological. In a healthier organizational culture, people are thought professional to the extent they are knowledgeable and competent.
Leadership on the job is rare, but talk about it is ubiquitous. Companies talk about it all the time.
To lead, it's more important to be qualified and fearless, the positional authority means little without proper behavior and initiative. To lead without anyone ever appointing you a leader, you need to
- Step up to the task
- Be evidently fit for the task
- Prepare for the task by doing the required homework ahead of the time
- Maximize value for everyone
- Do it with humor and obvious goodwill
The propensity to lead without being given the authority to do so is what, in organizations, distinguishes people that can innovate and break free of the constraints that limit their competitors. Innovation is all about leadership, and leadership is all about innovation. The rarity of the one is a direct result of the rarity of the other.
Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.
Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.
Manager: Do you work with flaming objects?
Candidate: Sure.
Manager:...knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.
Manager: Do you have a line of funny patter that goes with your juggling?
Candidate: It’s hilarious.
Manager: Well, that sounds fine. I guess you’re hired.
Candidate: Umm... Don’t you want to see me juggle?
Manager: Gee, I never thought of that.
It would be ludicrous to think of hiring a juggler without first seeing him perform. That’s just common sense. Yet when you set out to hire an engineer or a designer or a programmer or a group manager, the rules of common sense are often suspended. You don’t ask to see a design or a program or anything. In fact, the interview is just talk.
It's surprising how much hiring of developers happens without ever seeing samples of the work. For programmers who assemble a portfolio showing off samples of their work, such as code examples, methods, routines, flow charts, and such are definitely going to stand out among the other candidates.
To test candidate's communication and people skills, the authors suggest holding an audition - asking the candidate to prepare 10 or 15 minute presentation on an aspect of past work, where the candidate chooses the theme. It should be held in front of the future co-workers and then have a discussion after the candidate leaves. There's no more accurate way of establishing will a person fit the team than having the team pitching in their opinion.
My first experience with auditions was in hiring people to be consultants and instructors. My motivation in torturing these prospective hires was simple enough: I wanted to get a sense of whether they were natural explainers of matters simple or complex, or people who could be taught to explain such matters, or those who could never explain anything to anyone. I also wanted some second opinions on the matter, so I had those of my people who were in the office at the time of the audition sit in on the presentation. Over five years, we conducted nearly two hundred auditions. It soon became clear that the audition process served to accelerate the socialization process between a new hire and the existing staff members. A successful audition was a kind of certification as a peer. The reverse seemed to hold true as well. Failed auditions were a morale booster for the staff. They were continuing proof that being hired for the group was more than just the dumb luck of when résumés happened to hit my desk.
With freelancers, contractors, globally available workforce, working remotely and such, today's project teams can be wildly diverse
The “class picture” you take of your next project team is likely to show something that looks more like a United Nations task force than the kind of single-culture group that our fathers and grandfathers managed. Melding the mix into a team can be a challenge, but there are benefits as well.
The same way we're used to different cuisines in our diet, we should be used to different backgrounds and cultures our work colleagues come from, and relish their contributions in diverse ways of thinking and learning.
That said, there's a limit of how much newness a team can handle. Renting people like renting cars should be avoided since they won't be able to work as a team
Team jell takes time, and, during much of that time, the composition of the team can’t be changing. If you need to use a reactive strategy of contract labor, your team will probably never jell. In fact, the workforce you manage almost certainly won’t be a team at all.
Young people arriving into the workplace today are different from the previous generations and it should be taken into the account.
Disney Fellow Alan Kay defines technology as whatever is around you today but was not there when you were growing up. He further observes that what was already around you when you were growing up has a name: It’s called environment. One generation’s technology is the next generation’s environment.
Most of the difference is in the attention. Older generations focus on one or two tasks at the time, while the younger generations divide their tasks. Used to distractions, they operate in what's been called "continuous partial attention". The problem with that is that it's the complete opposite of flow.
You need to make your youngest workers understand the difference between spending 2 percent of their workday on Facebook in a single block of time and spending 2 percent of their attention all day on Facebook. The one may be a reasonable accommodation for human workers’ personal needs (much like the occasional call or text message home during working hours), while the other may be a deterrent to their ever fitting in. Workers who can’t get into flow are not just less effective, they also are unlikely to fit into a jelled team of mixed-generation people.
Q1: What annual employee turnover has your organization experienced over the last few years?
Q2: How much does it cost on average to replace a person who leaves?
Score yourself as follows: If you had any answer at all to the two questions, you pass. Otherwise, you fail. Most people fail.
Typical turnover rates the authors encountered rate from 80% to 33% per year which implies average employee longevity of 15 - 36 months. It costs one-and-a-half to two month salary to hire a new person. And the new employee is completely useless on Day One, or even worse than useless, because someone else's time is required to bring the new person up to speed.
By the end of a few months, the new person is doing some useful work; within five months, he or she is at full working capacity. A reasonable assessment of start-up cost is therefore approximately three lost work-months per new hire. (Obviously, the start-up cost is worse or much worse to the extent that the work to be performed is highly esoteric.) The total cost of replacing each person is the equivalent of four-and-a-half to five months of employee cost or about 20 percent of the cost of keeping that employee for the full two years on the job.
High turnover is more damaging than obvious cost of constant need to hire people
In an organization with high turnover, nobody is willing to take the long view. If the organization is a bank, it will lend money to the Ugandan Development Corporation because the 22-percent interest looks terrific on this quarter’s books. Of course, the UDC may default in a couple of years, but who’s even going to be here then? If the organization is a development shop, it will optimize for the short term, exploit people, cheat on the workplace, and do nothing to conserve its very lifeblood, the peopleware that is its only real asset. If we ran our agricultural economy on the same basis, we’d eat our seed corn immediately and all starve next year.
High turnover turns into a wicked cycle - management is reluctant to invest in educating and empowering their employees, since they will leave soon, and in turn, the employees don't feel valued enough to stay.
Why the people leave?
- A just-passing-through mentality: Co-workers engender no feelings of long-term involvement in the job.
- A feeling of disposability: Management can only think of its workers as interchangeable parts (since turnover is so high, nobody is indispensable).
- A sense that loyalty would be ludicrous: Who could be loyal to an organization that views its people as parts?
New people are not hired for their extraordinary qualities, since replacing extraordinary qualities is too difficult. The feeling that the company sees nothing extraordinary in the worker makes the worker feel unappreciated as an individual.
It's difficult to find a formula among the best companies, because they are frequently more dissimilar than similar, but what they do have in common is preoccupation with being the best.
The best organizations are consciously striving to be best. This is a common goal that provides common direction, joint satisfaction, and a strong binding effect. There is a mentality of permanence about such places, the sense that you’d be dumb to look for a job elsewhere— people would look at you as though you were daft.
One can prove that retraining is not the cheapest way to fill a new slot. It’s always cheaper in the short run to fire the person who needs retraining and hire someone else who already has the required skills. Most organizations do just that. The best organizations do not. They realize that retraining helps to build the mentality of permanence that results in low turnover and a strong sense of community. They realize that it more than justifies its cost.
An expense is money that gets used up. At the end of the month, the money is gone and so is the heat (or whatever the expense was for). An investment, on the other hand, is use of an asset to purchase another asset. The value has not been used up, but only converted from one form to another. When you treat an expenditure as an investment instead of as an expense, you are capitalizing the expenditure.
What about people? While most managers consider salaries and other cost as an expense, whatever the company invests in the worker is actually an asset, since the acquired knowledge, skill and expertise stay with the person and will contribute to the company.
Companies that manage their investment sensibly will prosper in the long run. Companies of knowledge workers have to realize that it is their investment in human capital that matters most. The good ones already do.
Majority of our most pleasant work memories are from challenges we faced and overcame, however, if you think more about it, it's usually the team interaction during the challenge we cherish the most.
What’s in the foreground of most of our prized work memories is team interaction. When a group of people fuse into a meaningful whole, the entire character of the work changes. The challenge of the work is important, but not in and of itself; it is important because it gives us something to focus on together. The challenge is the instrument for our coming together. In the best work groups, the ones in which people have the most fun and perform at their upper limits, team interactions are everything. They are the reason that people stick it out, put their all into the work, overcome enormous obstacles.
Not every group of people working together can be called a team. What they lack is a common definition of success or any identifiable team spirit. What's missing is a phenomenon the authors call jell.
A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. The production of such a team is greater than that of the same people working in unjelled form. Just as important, the enjoyment that people derive from their work is greater than what you’d expect given the nature of the work itself. In some cases, jelled teams working on assignments that others would declare downright dull have a simply marvelous time.
Once a team begins to jell, the probability of success goes up dramatically. The team can become almost unstoppable, a juggernaut for success. Managing these juggernaut teams is a real pleasure. You spend most of your time just getting obstacles out of their way, clearing the path so that bystanders don’t get trampled underfoot: “Here they come, folks. Stand back and hold onto your hats.” They don’t need to be managed in the traditional sense, and they certainly don’t need to be motivated. They’ve got momentum.
The most important aspect of teams that jell is sharing a common goal. However arbitrary, the goal becomes of the utmost importance to the team and they will pursue it with enormous energy.
“Today the Sysboombah Project, tomorrow the world!” Throughout the upper ranks of the organization, there is marvelous ingenuity at work to be sure that each manager has a strong personal incentive to accept the corporate goals. Only at the bottom, where the real work is performed, does this ingenuity fail. There we count on “professionalism” and nothing else to assure that people are all pulling in the same direction. Lots of luck.
Most managers naively expect their employees to accept the company goal as their own, and even feel betrayed when their workers aren't as enthusiastic as they are.
I once ran a telecommunications project for a large consumer finance company. This organization was in the business of lending money to poor people at outlandishly high rates of interest, a business that back then was illegal in 23 states. Increasing the company’s already huge profit was not something the average worker could easily identify with, but management seemed to think it was. A delegation came to talk to me late one Friday afternoon. The company’s chances for the best second quarter in history were in our hands, they said. They asked me to share this fact with the rest of the team, “to focus their efforts.” I had never worked on a more focused team in my life, but I dutifully passed the word on the next morning. (They were so fired up that the whole team was in, even though it was a Saturday.) The energy went out of the team like wind out of a sail. The chief programmer summed it all up: “Who gives a rat’s ass for their second quarter?” Half an hour later, they’d all gone home.
However arbitrary the goal of building the system was, the team accepted it as their own and were enthusiastic about it. Refocusing their attention on the company interest just made the project seem trivial and meaningless.
Goals of the corporation will always seem arbitrary to people, but that's fine - most sport goals are totally arbitrary but people get completely involved in the sport's team goals. Important insight is that team don't achieve goals - individuals achieve goals. Most of the work on any project is done by individuals working alone. The purpose of the team isn't goal achievement, it's _goal alignment. When the team is fulfilling it's purpose, team members are more effective because they're more directed.
The signs of the jelled teams:
- Low turnover - people won't leave until the work is done. Things that mattered before jell (position, money, status) matter little after jell
- Strong sense of identity teammates might give a funny name to themselves (Okie Coders, Gang of Four), share many in-jokes and use the same catch phrases
- Sense of Eliteness - team members feel they're part of something unique, they have a cocky, SWAT Team attitude which may be faintly annoying to people who aren't a part of the group
- Feeling of joint ownership of the product
- Obvious enjoyment that people make in their work, the interactions are easy and confident and warm
Many an insecure manager might feel this description of a team is more suitable to a clique.
Managers are often not true members of their teams, so the loyalties that exclude them are stronger than the ones that bind them into the group. The loyalties within the group are stronger than those tying the group to the company. Then there is the awful thought that a tightly knit team may leave en masse and take all of its energy and enthusiasm over to the competition. For all these reasons, the insecure manager is threatened by cliques. He or she would feel better working with a staff of uniform plastic people, identical, interchangeable, and unbonded.
The jelled work group may be cocky and self-sufficient, irritating and exclusive, but it does more to serve the manager’s real goals than any assemblage of interchangeable parts could ever do.
The Black Team was a group of software testers that began to make it's mark in the 1960ies in the company that made large blue computers.
(Abbreviated version)
For a while, the company put its efforts into training the customers to make them more tolerant of bugs. But this approach didn’t work out, so they bit the bullet and decided to get rid of the bugs instead.
Finding the last bug was hard, but some testers were better than others. The company formed a group of these particularly talented testers and gave them the charter to do final testing on critical software before it was sent to the customers. Thus was born the legendary Black Team.
The Black Team was initially made up of people who had proved themselves to be slightly better at testing than their peers. They were slightly more motivated. They also were testing code that had been written by someone else, so they were free of the cognitive dissonance that hampers developers when testing their own programs.
At first it was simply a joke that the tests they ran were mean and nasty, and that the team members actually loved to make your code fail. Then it wasn’t a joke at all. They began to cultivate an image of destroyers. What they destroyed was not only your code but your whole day. They did monstrously unfair things to elicit failure, overloading the buffers, comparing empty files, and keying in outrageous input sequences. Grown men and women were reduced to tears by watching their programs misbehave under the demented handling of these fiends. The worse they made you feel, the more they enjoyed it.
To enhance the growing image of nastiness, team members began to dress in black (hence the name Black Team). They took to cackling horribly whenever a program failed. Some of the members grew long mustaches that they could twirl in Simon Legree fashion. They’d get together and work out ever-more-awful testing ploys. Programmers began to mutter about the diseased minds on the Black Team.
Needless to say, the company was delighted. Every defect the team found was one that the customers wouldn’t find. The team was a success. It succeeded as a test group, but more important for our purposes here, it succeeded as a social unit. People on the team got such a kick out of what they were doing that colleagues outside the team were positively jealous.
Over time, members of the team moved on one at a time to other things. Since the team function was important to the company, departing members were replaced immediately. This continued until finally there wasn’t a single member left of the original group. But there was still a Black Team. The team survived the loss of all of its original staff, and it emerged with its energy and its personality intact.
The original chapter the authors wanted to write was supposed to contain prescriptions on how to build teams that jell. However, while trying to write it, it became clear there's no cut-and-dry process.
What was wrong was the whole idea of making teams jell. You can’t make teams jell. You can hope they will jell; you can cross your fingers; you can act to improve the odds of jelling— but you can’t make it happen. The process is much too fragile to be controlled. Part of our scaling down of expectations involved a change in vocabulary. We stopped talking about building teams, and talked instead of growing them.
To get through this hurdle, authors tried the opposite approach (like in Edward De Bono's Lateral Thinking) to get unstuck. They came up with ways which make it impossible for the team to jell
Defensive management - it's impossible to protect yourself from your people's incompetence and any defensive measure is sure to backfire and will poison any chance of team to jell.
I found myself one day giving Consultant’s Speech Number 9B to a project group, chastising them because they’d failed to get client approval for their emerging concept of a new system. They all looked faintly embarrassed. Finally, one of them said, “We all agree that the client ought to be seeing this stuff. But our boss has laid down a firm rule that nothing will ever be shown to people outside the project unless it has his approval.” She went on to explain that the boss was so swamped that months of work had piled up in his In-box. What option did they have? They were just plugging away in the dark knowing full well that most of what they were producing wouldn’t pass muster with the client staff when it was finally shown to them.
The boss didn't trust his own people - only his judgement mattered.
At any point in the project where you don’t interpose your own judgment, your people are more likely to make a mistake. So what? Let them make some mistakes. That doesn’t mean you can’t override a decision (very occasionally) or give specific direction to the project. But if the staff comes to believe it’s not allowed to make any errors of its own, the message that you don’t trust them comes through loud and clear. There is no message you can send that will better inhibit team formation.
Bureaucracy - there's a growing trend to make development workers more and more into bureaucrats. Mindless paper pushing should be attacked because it keeps people from working
Just telling your people that the goal matters won’t be enough if you also have to tell them they should spend a third of their time pushing paper. Paper pushers just can’t get themselves into SWAT Team mode.
Physical separation - group members have to be able to have casual interaction, without which it's almost impossible to build a sense of common identity
Fragmentation of people’s time - too often people get assigned to multiple projects as the management feels their skills are too valuable. But it's not conducive to growing a jelled team as it's not possible to belong to multiple exclusive groups
Fragmentation is bad for team formation, but it’s also bad for efficiency. People can keep track of only so many human interactions. When they try to be part of four working groups, they have four times as many interactions to track. They spend all their time changing gears. No one can be part of multiple jelled teams. The tight interactions of the jelled team are exclusive.
Quality reduction of the product - the typical steps we usually take to deliver the product in less time result in decreased quality
An early casualty of quality reduction is whatever sense of team identification the group has been able to build. Co-workers who are developing a shoddy product don’t even want to look each other in the eye. There is no joint sense of accomplishment in store for them. They know that there will be a general sense of relief when they can stop doing what they’re doing.
Phony deadlines - some believe people work best under pressure and making up deadlines is often a manager's tool to achieve that pressure
The people on your staff will know if they’re being bamboozled. If you say the product absolutely has to be out the door by some arbitrary date, they will ask, “Why? Will the universe grind to a halt if we’re late? Will the company fold? Will the nation slide into the sea? Will Western Civilization break down?”
In the typical phony deadline spiel, the manager announces that the work must be done on such and such a date. The date mentioned is impossible to meet, and everyone knows it. The effort will certainly slip (so much for the idea that the deadline is absolute). The work has been defined in such a way that success is impossible....The boss believes they won’t do a stroke of work except under duress. Don’t expect a jelled team on that project.
Clique control - the higher up the organizational chart, the less of jelled teams there are, they only exist on the bottom, where the actual work is being done, but too often insecure managers try to break up the teams they perceive as cliques
Most organizations don’t set out consciously to kill teams. They just act that way.
In the new release of the book, the authors found two other ways to kill the possibility of jelled teams.
Those Damn Posters and Plaques - the motivational accessories are a triumph of form over function - and worse - they demean the work and the people doing it
Management here believes that these virtues [Quality, Leadership, Loyalty, Creativity] can be improved with posters rather than by hard work and managerial talent. Everyone quickly understands that the presence of the posters is a sure sign of the absence of hard work and talent. That important matters like these should be the subject of motivational posters is already an insult.
Motivational accessories are phony enough to make most people’s skin crawl. They do harm in healthy organizations. The only place where they do no harm is where they are ignored— as in companies where the harm was done long, long ago and people have ceased to register any further decline.
Overtime: An Unanticipated Side Effect - beside the risks of the individual burnout, the overtime hours can also poison any chance of the team to jell
In almost any team of four or five or six people, there are bound to be a few who can’t be expected to put in the kind of overtime that might fit pretty well into some of the others’ lives. All that can be shrugged off as unimportant if the overtime is only a matter of a few long evenings and maybe one extra weekend day. But if the overtime drags on over months and starts to exact a real toll on even the most willing team members, there is bound to be damage to team cohesion. The people who aren’t sharing the pain will become, little by little, estranged from the others. And the team magic will be gone.
Most managers have at least a suspicion that overtime doesn’t help, that projects that work a lot of overtime are not much of a credit to their managers’ skills and talents. But they end up allowing or encouraging overtime, anyway. Why is this? Consultant and author Jerry Weinberg has an answer of sorts: He suggests that we don’t work overtime so much to get the work done on time as to shield ourselves from blame when the work inevitably doesn’t get done on time.
The competition among team members is not likely to produce a group of people that enjoy working together. From the family analogy, it's known that highly competitive siblings grow up to be distanced from each other.
What is the long-term effect of heightened competition among people who need to work together? One of the first victims is the easy, effective peer-coaching that is ubiquitous in healthy teams.
When you observe a well-knit team in action, you’ll see a basic hygienic act of peer-coaching that is going on all the time. Team members sit down in pairs to transfer knowledge. When this happens, there is always one learner and one teacher.
The act of coaching simply cannot take place if people don’t feel safe. In a suitably competitive atmosphere, you would be crazy to let anyone see you sitting down to be coached; it would be a clear indication that you knew less than your coach about some subject matter. You would be similarly crazy to coach someone else, as that person may eventually use your assistance to pass you by.
The story of spaghetti dinner tells about dinner meeting at the manager's house where the team goes to the store, buys the necessary groceries and makes the dinner together, without a specific guidance by the manager. The point is to make the team succeed together.
The common thread is that good managers provide frequent easy opportunities for the team to succeed together. The opportunities may be tiny pilot subprojects, or demonstrations, or simulations, anything that gets the team quickly into the habit of succeeding together. The best success is the one in which there is no evident management, in which the team works as a genial aggregation of peers. The best boss is the one who can manage this over and over again without the team members knowing they’ve been “managed.” These bosses are viewed by their peers as just lucky. Everything seems to break right for them. They get a fired-up team of people, the project comes together quickly, and everyone stays enthusiastic through the end. These managers never break into a sweat. It looks so easy that no one can believe they are managing at all.
The Open Kimono attitude is the exact opposite of defensive management. You take no steps to defend yourself from the people you’ve put into positions of trust. And all the people under you are in positions of trust. A person you can’t trust with any autonomy is of no use to you.
It’s heady and a little frightening to know that the boss has put part of his or her reputation into the subordinates’ hands. It brings out the best in everyone. The team has something meaningful to form around. They’re not just getting a job done. They’re making sure that the trust that’s been placed in them is rewarded. It is this kind of Open Kimono management that gives teams their best chance to form.
Trusting people who work for you will reward you with people who try not to disappoint. Many managers try to kick their workers into submission by visually supervising them. Visual supervision is a joke to development workers. Visual supervision is for prisoners.
Some years ago, we were part of a pretty well-knit working group, a group whose members started to have many characteristics in common— in particular, a similar sense of humor. We even developed a shared theory about humor. This theory held that some things are intrinsically funny. Chickens, for instance, are funny, but horses aren’t. Lips are hilarious, elbows and knees are funny, but shoulders are just shoulders. One day we had an audition for a new group member. After he’d spoken and left, one of our colleagues critiqued, “I guess you can’t fault his knowledge. But do you think he’d ever come to understand that chickens with lips are funny?” The candidate didn’t get the job.
Make a cult of quality.
Your marketplace, your product consumers, your clients, and your upper management are never going to make the case for high quality. Extraordinary quality doesn’t make good short-term economic sense. When team members develop a cult of quality, they always turn out something that’s better than what their market is asking for. They can do this, but only when protected from short-term economics. In the long run, this always pays off. People get high on quality and outdo themselves to protect it.
Provide lots of satisfying closure. It is the satisfying "thunk" of all parts falling into place. It's the successful finish of a project. While the team is coming together, it's especially important for frequent closure - team members have to get used to succeeding together and liking it.
The chemistry-building manager takes pains to divide the work into pieces and makes sure that each piece has some substantive demonstration of its own completion. Such a manager may contrive to deliver a product in twenty versions, even though two are sufficient for upper management and the user. It may even be necessary to conceal some of these interim versions from the client, and build them only for internal confirmation and satisfaction. Each new version is an opportunity for closure. Team members get warmed up as the moment approaches; they sprint near the very end. They get a high from success. It suffuses them with renewed energy for the next step. It makes them feel closer together.
Build a sense of eliteness.
There is a widespread feeling that managers are just not doing their jobs if the team sticks out in any way. The group’s adherence to a corporate standard of uniformity is almost a symbol of the manager’s degree of control. Yet from the viewpoint of the people being managed, this symbol is deadly. The more comforting it is to the manager, the more it saps the lifeblood of the team.
People require a sense of uniqueness to be at peace with themselves, and they need to be at peace with themselves to let the jelling process begin. When management acts to stifle uniqueness, uniqueness happens anyway. People simply express their uniqueness in uncontrolled dimensions. For example, employees who take a perverse pride in being difficult to manage or hard to motivate or unable to work with others may be reacting to too much control. They would almost certainly rather express themselves in some less difficult way, something that would not work to the detriment of the group’s effectiveness.
Allow and encourage heterogeneity.
A little bit of heterogeneity can be an enormous aid to create a jelled team. Add one handicapped developer to a newly formed work group, and the odds go up that the team will knit. The same effect can result from adding a co-op student or an ex-admin on the first project after being retrained. Whatever the heterogeneous element is, it takes on symbolic importance to team members. It is a clear signal that it’s okay not to be a clone, okay not to fit into the corporate mold of Uniform Plastic Person.
Preserve and protect successful teams.
Provide strategic but not tactical direction.
The invisible risk of too much automation is the inability to self-heal. Turning a previously all-human effort into automated process makes the process unable to self-correct.
Automators spend much of their time thinking through situations that are so unlikely or occur so rarely that the human elements of the old system never even bothered to consider them unless and until they actually happened. If the business policy governing the new system has a sufficient degree of natural ad hoc-racy, it’s a mistake to automate it. Determinism will be no asset then; the system will be in constant need of maintenance. The reason that nondeterministic systems can often heal themselves painlessly and elegantly (sometimes at no cost at all) is that the humans who make up the system have an easy familiarity with the underlying goals. When a new situation crops up, they know immediately what action makes sense.
The point of discussing this issue are growing efforts to use standardized methodologies to make companies (non-deterministic systems) more deterministic. The motivation is the desire to go around human limitations, and by using some methodology get the same results whether we're staffed by exceptional or mediocre people.
The Methodology would make all the decisions, people would make none.
A Methodology is a general systems theory of how a whole class of thought-intensive work ought to be conducted. It comes in the form of a fat book that specifies in detail exactly what steps to take at any time, regardless of who’s doing the work, regardless of where or when. The people who write the Methodology are smart. The people who carry it out can be dumb.
If the people aren't smart enough, the work will fail and no Methodology can help. It also makes people using it give up their responsibility, because it's the Methodology's responsibility, "they were just following the process". Huge amount of documentation and paperwork prevents people from doing any meaningful work. The management's decision to use the Methodology tells the workers the management deems them incompetent which destroys the motivation to participate.
First of all, it’s worth saying that project risk is a good thing, a likely indicator of value. Projects that have real value but little or no risk were all done ages ago. The ones that matter today are laden with risk.
While the companies focus on managing project risk, and other existing risks, rarely they consider their possible non-performance a real risk.
The real reason for risk management: It’s not to make the risks go away, but to enable sensible mitigation should they occur. And mitigation may well have to be planned and provisioned well ahead of time.
The infamous Denver International Airport Baggage Handling System is a case in point. The powers that be had decided that on-time delivery of the system was so important that nonperformance (lateness) could not be considered a risk. It wasn’t a risk because it simply wasn’t going to be allowed to happen. The risk was whisked away by managerial fiat.
If they had managed the risk, they would have been obliged to plan a manual or semi-automatic backup plan to move the bags in case the new system wasn’t ready. They didn’t. So when the system was late, they had to defer opening the airport. The capital cost of carrying a second nonfunctional airport for more than a year eventually came to billions.
By the time the risk materialized and the system wasn’t available on opening day, it was too late to start mitigation planning. If, on the other hand, the mitigation had been ready, the airport would have opened with old-fashioned, temporary guys-plus-little-trucks moving the baggage, and the lateness of the software system would have been nothing more than a minor disappointment. You never would have heard of DIA’s Baggage Handling System; no one would have except the people on the project.
It’s perfectly reasonable not to manage a risk for which the probability of occurrence is extremely low. It’s not reasonable to leave unmanaged the risk for which the consequences are “just too awful to think about.”
Fortunately, I'm working in a place which has no unnecessary meetings, but many others aren't so lucky. It seems the longer the organization is around, meeting time increases until there's little time for anything else.
The good trend is of the stand-up meetings, but they too can be a waste if they lack purpose and focus.
A meeting that is specifically called to get something done might be called a working meeting. A working meeting is typically called to reach a decision. Who should be invited? That’s easy, the people who need to agree before the decision can be judged made. Nobody else. To make sure no one is blindsided, it’s essential that the working meeting have an agenda relevant to its purpose and that it stick to that agenda.
Working meetings have a charming characteristic. You know when they’re done. When the decision has been reached, there is no further need to meet. Before it’s been reached, the meeting is not yet complete.
Same idea backwards: If you can say definitively what group action terminates the meeting, then it’s a working meeting. If you can’t, it isn’t.
It's wasting people's time. For example, when a manager calls a meeting but is then late. Another way of wasting time is having people fragmented over several projects. It's usually not noticed how much wasted time there is in switching gears from one context to another several times in a day.
It used to be pretty expensive in both money and time to communicate via letters (dictating, transcribing, paying for postage, etc) - today we can send email for the fraction of the cost. The downside is that it often drove the quality of the communication down. We have become used to ton of coordinating email that we now take if for granted.
A family therapist will tell you that when one person in a relationship over-functions, the others are sure to under-function. When one sibling leaps up to clear the table and wash the dishes, you’re liable to see the others slipping off to do something more amusing. Could that be happening in your organization? When you over-coordinate the people who work for you, they’re all too likely to under-coordinate their own efforts.
A decent coach understands that his or her job is not to coordinate interaction, but to help people learn to self-coordinate.
Corporate spam is all the mail that has many people CC'd on it, who don't need to actually read or respond to the email. How to eliminate the corporate spam? One way to do it would be applying some security-minded thinking: while going through your inbox ask yourself - "Do I need to know this?". When security is key, the information is routed on strictly need-to-know basis. Ask the same question when sending email and only include the people who absolutely need to know the information being sent.
Do the need-to-know test on your incoming e-mail, but do it, too, on the messages you send out. Each time you’re inclined to send a coordinating e-mail to a colleague or to anyone who works for you, think about what steps you have to make to coach that person to self-coordinate. Don’t expect this to be easy. Telling someone what to do is easy, while instilling self-coordinating abilities in that same person is much more complicated. But it pays off in the long run. If you need to puzzle long and hard over how to make it happen, remember that’s why you make the big bucks.
People generally really hate change.
We need to talk about change because it is our business. More than being just system builders, we are change agents. Every time we deliver a new system, we are obliging people to change the way they do their work; we might be redefining their jobs entirely. We are demanding that they change, and while we’re at it, our own organizations are demanding that we change, too. The emerging technologies and the building cycle-time pressures are forcing us to change how we build our products.
Problem with introducing changes is that everyone who is comfortable with the current way of doing things is absolutely going to oppose the change, and unfortunately, the people who're gaining from the change will barely support it.
While you risk making enemies of those who have mastered the old ways— you are forcing them back to the uncomfortable position of novice— you receive only minor support from those who would gain. Why is that? Why are those who stand most to gain from the change still half-hearted in their support? That’s because people hate change. When we start out to change, it is never certain that we will succeed. And the uncertainty is more compelling than the potential for gain.
The fundamental response to change is not logical but emotional.
Jerry Johnson, one-time director of Menninger Foundation devised a resistance to change continuum - everybody falls someplace in this continuum in the way they will respond to change.
- Blindly loyal (ask no questions)
- Believers but Questioners
a. Skeptics (Show me)
b. Passive Observers (What's in it for me?)
c. Opposed (Fear of Change)
d. Opposed (Fear of Loss of Power) - Militantly Opposed (Will Undermine and Destroy)
Believers but Questioners are the only helpful allies for any change. The ask-no-questions are following fads and whatever is hot right now, while militantly opposed are obviously enemies. The success of the change will depend on how the Believers but Questioners handled.
As systems developers, we have selected ourselves into the world of cool, calming, rational thought. Either our code compiles, or it doesn’t. The compiler is never happy for us, nor mad at us. Perhaps this is why we tend to apply logic as our main device for resolving disputes. You may catch yourself patiently explaining to your kid: “I know you want a bike, but it is neither your birthday nor is it Christmas, the cultural dates upon which gifts may reasonably be expected. If you have accumulated sufficient allowance, you may proceed with the purchase yourself.” And you may be frustrated by a not-very-logical response like, “But I want a bike! I want it right now.” When we argue logically for change, one tactic is to contrast how the new world will be (good) compared to the current situation (bad). But think: Who helped implement the current situation? Who are the masters of the ways that we currently work? Could these people possibly take offense at any diminution of the current mode? Damn right they could.
A naive view of change expects it to be a transition from old to new way of doing things.
- Old Status Quo
A Better Idea - New Status Quo
But in reality what happens is something closer to
- Old Status Quo
A Foreign Element - Chaos
Transformative Idea - Practice and Integration
- New Status Quo
The chaos is the dip in productivity - using new tool or procedure is hard, people feel it's waste of time, things were better before... etc. You are worse off, temporarily. It's frustrating to feel like a novice when there is a tried way of doing things. The passage through Chaos is mandatory and can't be shortcut.
The transformative idea is when people start getting the hang of it and see the success is near, devising ways of incorporating change into their daily work.
With the naive approach, since we don't expect Chaos, we mistake it for the New Status Quo and think "Oops, we blew it, better change back". Temporarily loss of mastery is embarrassing for most people - it has to be safe to change, without demeaning anyone.
Change has only chance of succeeding if failure, at least a little bit of failure - is okay.
Watching and listening to adults and children on their first ski trips, we get the distinct impression that adults are not so much concerned with injuring themselves as they are with making fools of themselves. Kids almost never have that thought. They may actually choose to fall down in the snow, to roll in it, to throw it, to eat it. (Our natural adult response to snow is to shovel it so we won’t slip.) On the slopes, adults don’t want to fall where they can be seen by those in the chairlift. The anticipated humiliation is enough to keep them in the lodge. But give a healthy kid a lesson or two with a ski instructor, and it’s, “Look at me, I’m Picabo Street!”
It's important to understand that accumulated experience isn't the same as learning. Experience only becomes learning when an organization alters itself by implementing what experience has brought.
One of my clients had a long history of software development, going back more than forty years. Through much of this period, it kept a thousand or more software developers at work. So, its managers could brag, without exaggeration, that they had more than forty thousand person-years of software experience. I was greatly impressed: Imagine all that learning being brought to bear on each new project. So I asked a group of them, “When you send a new manager off to run a new software project, what words of wisdom do you whisper in his or her ear?” They thought for just a moment and then gave their answer, almost in unison: “Good luck.”
The organization can either Instill new skills and approaches in it's people or Redesign itself to operate in some different manner. In any case, the learning of the organization is limited by it's ability to keep its people.
The need for a community is build in deeply in humans, the best managers know that and focus their efforts on making communities. The companies that succeed in building a satisfying community tends to keep it's people - when the sense of community is strong enough, nobody wants to leave. Even when people need to leave for any reason, they will time their departure so they don't impact any on-going project.
We are not going to presume to set forth a formula for such a complicated matter. There is no formula. Like any work of art, your success at fostering community is going to require substantial talent, courage, and creativity. It will also need an enormous investment of time. The work will not be completed by you alone; at best, you will be the catalyst. The form of your creation will not be very much like anyone else’s.
So, in place of a formula, we offer instead an example, a single example. The example comes from one of our client companies, a company where one enterprising manager stepped in and changed the culture forever. This catalytic genius persuaded the organization to build itself around a school. The school is made up of a day-care and preschool center, plus classes for kindergarteners through fifth graders. The school is for the children of employees.
No doubt you can see the dollars-and-cents rationale for this, the unique advantage the company gained for hiring programmers and engineers in a tight market. But you’d have to walk through the company to see what the school does for community. You’d have to be there for that moment every afternoon when the teachers lead the entire student body through the whole facility. They make up a noisy, funny, triumphantly silly parade of little kids whooping it up and saying hello to everyone. You can hear them coming a mile away. All work pauses for the procession. There are lots of hugs. When it’s over, everyone feels great.
Imagine having been the person responsible for that. Imagine having that to look back at from the age of a hundred and one.
Somewhere deep in our ancestral memory is buried the notion that work is supposed to be onerous. If you enjoy doing something, it isn’t really work. If you enjoy it enough, it’s probably sinful. You ought not to do it too much or even at all. You certainly shouldn’t be paid for it. What you really ought to do is find something else to work at, something that feels like work. Then you can be bored, tired, and generally miserable like everybody else.
There is something about human nature that makes us the implacable enemies of chaos. Whenever we encounter chaos, we roll up our sleeves and go right to work to replace it with order.
We’re all eager to improve our methods and make the business of development a more orderly enterprise. That’s progress. True, some of the crazy fun is lost in the process, but one person’s fun may be another’s agony (that project you thought was such a lark probably gave your boss an ulcer). In any event, progress toward more orderly, controllable methods is an unstoppable trend. The thoughtful manager doesn’t want to stop the trend, but may nonetheless feel a need to replace some of the lost disorder that has breathed so much energy into the work. This leads to a policy of constructive reintroduction of small amounts of disorder.
The authors here give us a list of methods they've successfully used to reintroduce disorder:
- Pilot projects
- War games
- Brainstorming
- Provocative training experiences
- Training, trips, conferences, celebrations and retreats
The pilot project is the one on which you try some new and unproved technique. It will inevitably feel clumsy and unproductive at first, but at the other end there's a boost in productivity resulting from the use of the new technique, and the Hawthorne effect - the boost of energy and interest that people get when they're doing something new and different.
Should all projects be pilot projects? That's the approach of Fujitsu, parts of the Southern Company and some divisions of IBM.
One caveat about pilot projects: Don’t experiment with more than one aspect of development technology on any given project. For all the talk about the importance of standards, it’s surprising how often managers abandon all standards on the rare project that is designated a pilot. They often try out new hardware, new software, new quality control procedures, matrix management, and new prototyping techniques, all on the same project.
A sensible approach to pilot projects is that they each be allowed to tinker with one component of the process. In the healthiest environment, project personnel would understand that they are encouraged to experiment with some single new technique on each project, but nonetheless expected to respect standards in other areas.
It can be a very enjoyable experience to try your hand at a set of tailored problems, and compare your performance to statistical performance profile of your peers. It has to be safe to perform badly, and confidential enough to be enjoyable.
Some of the companies that implemented authors' War Games started performing annual war games for a way for their employees to gauge improvements in their skills over time. They did that in a way you'd do an annual physical exam.
- Select a small development project or well-defined task as a guinea pig. The best choice is an actual job from your organization, something that requires from one to two person-months of effort. Pick a problem that has some novelty and challenge, but that nonetheless makes broad use of your people’s typical working skills.
- Conduct the project in a normal fashion up through publication of a concrete statement of work.
- Announce a 24-hour Project Tournament to be conducted on an upcoming weekend. Make sure everybody understands that you’re not saving money at the expense of their weekend. Explain that the tournament is run over a weekend so the teams can have the place to themselves, not so you can save on manpower cost. Encourage people to form teams of four each and compete on a totally voluntary basis.
- Distribute the statement of work in advance, along with a statement of rules and objectives.
- On the day of the Tournament, only participants are present. Supply everything they need (food, machines, cots, copiers, conference rooms, whatever). Have all of the teams undertake the same work in head-to-head competition with each other.
- Have facilitators available to enforce the ground rules, ready to head off fatal problems and to make lots of noise over every milestone attained.
- Look for opportunities to make everyone a winner in some sense (elapsed-time winners, robust-product winners, clever-solution winners). Make a big fuss over any and all accomplishments.
- Install the winning product, or perhaps several winning products in parallel. Keep careful track over time of product stability, number of defects, level of user acceptance, cost to change, and whatever other parameters affect project success. Report meaningful data back to the teams.
Some things to keep in mind about activities like the Project Tournament:
- It costs money, don't expect to get free labour because it's organized on the weekend, your employees don't want to feel exploited
- Make sure the project specification is particularly solid, building a lot of checkpoints and milestones
- Invest time to ensure the project scope is suitable for the time allocated
- Look for opportunities to spend money generously on meals
Running the project through a whole night, for some reason, adds to the fun. People love an excuse to get tired together, to push back sleep and let their peers see them with their hair down, unshaved, rumpled, and grumpy, with no makeup or pretense. And it makes them feel more closely bound to each other
A structured interactive session focused on creative insight. There aren't many rules and the facilitator needs to impress on everyone to strive for the quantity of ideas, not quality and to keep it loose, even silly.
There is no evaluation of proposed ideas during the brainstorming, that comes later. Discourage negative comments like "that's a dumb ideas" - dumb ideas tend to lead others to think of clever ideas.
When the idea flow slows down, try some of these:
- Analogy thinking (How does Nature solve this or a similar process)
- Inversion (How do we achieve the opposite of our goal?)
- Immersion (How might you project yourself into the problem?)
One of the things people in workplaces relish is combining travel with their peers and one-of-a-kind experience.
The cost of such and experience can be several thousand dollars per person, and if your budged doesn't allow for that, you can get creative. Such as one manager who hired a hot-dog vendor, complete with cart, sauerkraut, all the condiments and a blue and orange umbrella to take the elevator thirty floors up and serve lunch to the team. Those who were there got high on good spirits and began to do bits and skits about their work, their managers and each other. It was talked about ever since. That manager wrote it off as a business lunch, but it wasn't a lunch, it was a celebration.
Today, most people in places that are different than traditional jobs, like remote work, freelancing, self-employed or contracting.
Organizations today battle this by offering more attractive in-house positions, and one of the ways is offering people to define their own jobs. They're called free electrons as they are free to chose their own orbits.
It pays of enormously to the companies as the people employed in such a way are strongly motivated to make the positions created for them pay off for the companies.
The mark of the best manager is the ability to single out the few key spirits who have the proper mix of perspective and maturity and then turn them loose. Such a manager knows that he or she can't really give direction to these natural free electrons. They have progressed to the point where their own direction is more unerringly in the best interest of the organization than any direction that might come down from above. It's time to get out of their way.
In the conclusive chapter of the book authors warn us to keep our efforts for change focused. It's better to pull off one substantial change (inspired by the book) properly than to try to do too much, causing chaos and dissatisfaction of everyone involved.
Just north of the Danish city of Copenhagen is the castle Kronborg. For a price of few kroner, you can visit the castle casements and see there the reclining form of Holgar Dansk, the legendary sleeping giant of Denmark. He sleeps quietly while the country rests in peace, but if ever Denmark should be in danger, Holgar will awake, and then his wrath will be terrible to see.
The giant in your organization is the body of your coworkers. If there's too little common sense, and too much harm is done to the environment of the workplace, the giant will wake up. It doesn't take a lot, it can be enough that a single person says "This is unacceptable".
- An entire department of a large government agency has stuffed the bells in it's old-fashioned telephones with tissues. There is no loud ringing now - only a gentle purr of clicks (or is it the quiet voice of Holgar Dansk?)
- A California computer company has had a rash of guerrilla attacks against the paging system in the programmer area. The wires keep getting cut. Because the are programmers seated in what used to be an assembly bay, the ceilings (and the paging system speakers) are 16 feet up in the air. Who can ever reach so high? Perhaps it was Holgar Dansk
- The manager of a large project in Minneapolis has refused to move his people to the new quarters. ("New" in this case meant smaller and noisier.) Administrators were simply stunned at his refusal; they had never considered the possibility. Working people are supposed to do as they're told. The manager had a different theory, that working people are supposed to do work. He had assembled enough evidence about the new environment to convince himself that they couldn't do that in the new workplace. So the proper function of the manager was to say no. If he had been all alone in taking this stand, it would have been easy to overrule him. But he wasn't alone, he had Holgar Dansk on his side.
Sociology matters more than technology or even money. It's supposed to be productive, satisfying fun to work. If it isn't, then there's nothing else worth concentrating on.
This work is a priceless collection of advice distilled from years of working in the software industry - and it's applicable for any working environment of knowledge workers. Too often we get blind sighted with the technology aspect of managing people and forget to manage them as humans.
The book should be mandatory reading for anyone who works in tech industry, regardless if they manage people or are managed by others. An enlightening, fun and educating read.