![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
"
nerds want the problem to be technological, but it never is.
people tend to lump this stuff under the word "politics", but usually it's not actually political, it's sociological. calling it "politics" gives the impression that you can't do anything about it.
if you were running a staff making cheeseburgers at a fast-food restaurant, you'd want to:
in a development project, you want to do almost the opposite of these things:
iterative development -- encourage people to try things out and then throw them away if they aren't working
you can't go the The People Store and say, "send me new George Gardenhyer, but make him a little less uppity"
spend time brainstorming, investigating new methods, planning, estimating, budgeting, scheduling, allocating personnell, figuring out how to avoid doing some of the subtasks, reading books, training, goofing off. spend less time doing and more time asking, "should we be doing this at all?"
"people under time pressure don't work better; they just work faster"
also, even if you get slightly more productivy out of people for one project, you'll increase turnover in the long term, which is a net loss
(except in bureacracies) where's the evidence for it? on the contrary, a 1985 Jeffery-Lawrence study showed that projects with no estimated times were the most productive (this doesn't disprove parkinson's law, but it makes you wonder).
you may have seen some workers who seems to avoid work, or who seems to have no standard of quality, or who just can't get the job done. this doesn't confirm Parkinson's Law; the person probably lacks competence, confidence, affiliation with others on the project, or identification with the project's goals. in any of these cases, schedule pressure isn't the answer.
proposed variant that they think is true: "organizational busy work tends to expand to fill the working day"
the market isn't willing to pay enough of a premium for high quality to make quality the most profitable choice (directly). but you should make high-quality stuff anyways, because people are more motivated when they are making something of high quality (b/c they can be proud of it -- they can tie their self-esteem, a primitive drive, to their work). the resulting productivity gains outweigh the costs of the higher quality standard.
let the project team veto the release of any product until they think it is of high quality.
see the Notes
don't let anyone but the person measuring the productivity data see an individual's productivity data -- especially, the data on an individual's productivity must never get back to their boss (but the boss can see the team stats)
as a manager, you have to deal with interruptions, so you may have a tendancy to be unsympathetic to others who get interrupted. but programmers work best in a state of flow, so the productivity cost of dealing with interruptions for them is high. so, allow them to turn off their phones and provide a way to indicate "do not disturb" to prevent coworkers from walking in and talking to them all the time (and to prevent you from doing so). don't have a noisy environment. don't have a paging system (bayle: seriously, some places do that?!?).
record the ratio of uninterrupted hours to total hours (for programmers). your target for this metric is about 40%; if it's much lower, you need to fix the environment.
if you use timesheets for anything besides payroll (i.e. the track hours spent on projects, and in that way the progress towards project completion), then augment timesheets with a timesheet that logs only uninterrupted hours, and consider using this as the basis for other metrics.
rely on non-replicable (non-modular) patterns of organization. replicable patterns based on repitition of identical modular components lead to huge awesome uniform edifices. but working in one of the uniform spots in such an edifice makes you feel like a tiny cog in a big machine, which is unmotivating
Christopher Alexander's prescription: "
if you are in a big organization with a uniform space, take the most important projects (or your project), and move it to a different space
plusses of a space:
minuses:
no dress codes in non-externally facing divisions
watch out for using the word "professional" as a codeword for enforcing uniformity
be on the lookout for a conformity bias as you hire ppl. you say, oh, i don't care about that stuff. but you'll feel subconscious pressure to hire someone you're boss will like, and someone your boss's boss will like, etc.
ask candidates to bring a portfolio with them
don't bother with aptitude tests. these are only good for measuring the task they're designed for, and that's usually a low-level, left-brained task, but the new hire will only be doing that for 2 years or so before being promoted, and then they'll be doing different tasks, which will be more right-brained.
to test communications skills, have an "audition", meaning, have the candidate give a 15 minute presentation on any topic of their choice that is immediately germane to the work your organization does, to an audience of you and the candidate's potential future coworkers. After the candidate leaves, let the coworkers discuss and only hire someone that they've approved.
turnover may be about 20% of the cost of employment (direct cost, including hiring, training, getting-up-to-speed time). turnover has a high variance between companies. measure turnover (also, mb measure the direct cost of replacement). the highest cost of turnover is the indirect cost of no sense of longevity in the company culture.
foster a sense of longevity:
heavyweight methodologies are dumb (i didnt take further notes on that part b/c it all seemed obvious at this point in time, tho i doubt it was when it was written)
jelled teams lead to increased productivity
what motivates ppl? their coworkers. don't assume that ppl will accept corporate goals as their own just b/c you (a manager) did. you are given strong incentives (promotion, etc) if the corporate goals are met, but you are expecting them to accept these goals just out of "professionalism"? in order for people to be motivated, you need jelled teams (i.e. real teams, not just a set of people arbitrarily designated a "team" by management)
teams sometimes get really psyched about their goals
"the purpose of team is not goal attainment but goal alignment"; they don't seem to be strictly necessary to get work done, if you consider the nature of the work, but in fact they have a large effect because of their effect on motivation
attributes of jelled teams:
a team is the same thing as a "clique", which has a bad connotation. jelled teams may be "cocky and self-sufficient, irritating and exclusive". managers are often not true members of their teams. the members of a tightly knit team are more loyal to each other than to the company or to the manager. this can be threatening to an insecure manager, who may prefer that es subordinates were a fungible resource, and the company may worry that the team will defect en masse to the competition. however, the productivity benefits of a tightly knit team are worth it.
a story about a team
the black team was a team of testers to do final testing on critical software, formed by a company (that made "large blue computers" and software in New York State; seems to be IBM). initially composed of testers who "had proven themselves to be slightly better at testing than their peers...slightly more motivated". "the most surprising thing about the Black Team was not how good it was at the beginning, but how much it improved during the next year....the team was forming a personality of its own. Theis personality was being shaped by an adversary philosophy of testing that evolved among group members, a philosophy that they had to want and expect to find defects. They weren't rooting for the developers at all, quite the opposite. They were delighting in submitting the program (and the programmers) to a sequence that was not just a test, but an ordeal. Bringing your program in for Black Team testing was like appearing before Ming the Merciless.
At first it was simply a joke that the tests they ran were mean and nasty, and that the team memmbers 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 cakling horribly whenever a program failed. Some of the members grew long mustaches that they could twirl in Simon Legree fashion....Programmers began to mutter about the diseased minds on the Black Team. ... Over time, members of the team moved on one at a time...((and)) were replaced...until ... 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 its original staff, and it emerged with its energy and personality intact. "
we had planned to write a chapter here about things you can do to make a team jell. But we realized that "you can't make teams jell....you can act to improve the odds...but...the process is much too fragile to be controlled". Don't think of __building__ teams, think of __growing__ them. You can enrich the soil and plant them and water them, and a team might grow, or it might not. Either way, next year you'll have to do it all again.
So we tried to think of a list of ways that you can 'enrich the soil'. We couldn't. So instead, we came up with a list of things that stop teams from jelling.
opens with a fictional story about someone assigned to a new project. before the project begins, they are invited for dinner thursday with the project manager. when they get there, they chat. eventually they realize that no one has made dinner. the boss admits they haven't had time to make dinner, and suggests that they go to the supermarket together and then make a spaghetti dinner together. they do. the boss doesn't give any directions or lead. apparently this is a good team-building exercise because "you've just had your first success as a group.". goes on to say that "presented this way, the spaghetti dinner may seem like a contrivance on the manager's part. But it probably wasn't and wouldn't have seemed like it had you been there. If you had asked the manager in question what she had in mind for the evening, she would probably have replied in total sincerity, 'Dinner'. A natural manager has got a subconscious feel for what's good for the team. "
"The entire experience is organized for small, easy joint successes. You have to look twice to see the manager's hand in any of this, it just seems to be happening."
"Good managers provide frequent easy opportunities for the team to succeed together."
"The opportunities may be tiny pilot sub-projects, or demonstrations, or simultations...the best success is one in which there is no evident management...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."
give team members work that enhances their self-regard. "assignment to such work is an acknowledgment of certain areas of compentence, and it provides autonomy and responsibility in these areas. Managers...((should be)) careful to respect that autonomy, once granted. They know that a worker's failure wil reflect badly on the boss, but that's just the breaks of the game. They're prepared to suffer the occasional setback, a direct result of failure by one of their people. When it happens, they suspect it will be a failure that they themselves would never have caused, had they been doing the work rather than managing it. But so what? You give your best shot to putting the right person in the position, but once he or she is there, you don't second-guess. "
"One of my first bosses was Jerry Wiener, who had run a development team for General Electric on the Dartmouth time-sharing project. He later formes a small high-technology company. At the time I came along, the company was about to enter into a contract that was larger than anything it had ever done before. The entire staff was assembled as our corporate lawyer handed Jerry the contract and told him to read it and sign on the last page. "I don't read contracts," Jerry said, and started to sign. "Oh, wait a minute," said the lawyer, "let me go over it one more time."
"management by walking around" is bad when you are walking around looking for people goofing off or for incompetence waiting to happen.
every now and then, when there is an "easily separable task" for which "no real management" is required, such as designing a software project after the spec is done, send the team away so as to get yourself out of their hair. E.g. find a remote office, a conference room, a summer house, or put them up at a hotel, send them to a ski area or a beach, or a conference and then stay a few extra days after.
"The engineering profession is famous for a kind of development mode that doesn't exist elsewhere: the __skunkworks project__. __Skunkworks__ implies that the project is hidden away someplace where it can be done without upper management's knowing what's going on." e.g. DEC's PDP-11. "The amusing thing is that __skunkworks__ is really just another word for __insubordination__. Management says no, and the project goes on anyway.
"One of our clients tried to cancel a product that was judged to have no market. Cooler heads prevailed and the product was built. It became a huge success. The manager who had unsuccessfully tried to kill the project (he now had become president of the whole company) ordered a medal for the team, with the citation, "First Annual Prize for Insubordination". He presented it with a speech, stating that others seeking the award had better be just as successful."
"People at all levels know whether some sensible insubordination is acceptable or not. People look out for their Open Kimono managers. They're determined to make them look good, even though the managers may botch an occasional decision. Defensive managers are on their own."
Larry Constantine couseled some client companes to "allow people at the lowest level some voice in team selection. As implemented, the idea was that the companies would post new projects on a central kiosk. People would form themselves into candidate teams and then "bid" on jobs. If you had a hankering to work with some of your mates, you would put your resumes together and make a joint pitch for the job.The points in your favor were how well-suited you were to the job, how well you complemented each other's capacities, and how little it would disrupt other work in the company to assign you as a group to this project. The company picked the best-suited team for each job.
This scheme gave people two unusual degrees of freedom. They got to choose the projects they worked on and the people they worked with. Management initially feared that only the glamorous projects would be bid for, but it didn't happen that way. Even the most mundane projects were bid for. What seemed to matter was the chance for people to work with those they wanted to...
The idea of an employment audition...has a similar effect. The project members who listen to the audition are not just an audience; they have a say in whether the person gets the offer. In addition to technical judgment, they're supplying a team perspective on how well the candidate will fate.
Good managers give direction and make judgements of their own, but only in those areas where they are thought by their subordinates to be more skilled (perhaps setting general direction, negotiating, and hiring).
"in organizations with the best chemistry, managers devote their energy to building and maintaining healthy chemistry...there is a holistic integrity to their method, and so it's hard to break down and analyze the component parts...But it's still worth a try"
"a network model of team behavior": "managers are usually not part of the teams that they manage. Teams are made up of peers, equals that function as equals. The manager is msot often outside the team, giving occasional direction from above and clearing away administrative and procedural obstacles....the manager is not a peer and so can't be part of the peer group...((but)) isn't the manager supposed to supply leadership, to function as quarterback, spiriting the team on to victory through judicious play selection and split-second timing? That may sound good, but the team that needs that much leadership isn't functioning very well as a team. On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strenghts. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down.
The structure of a team is a network, not a hierarchy. For all the deference paid to the concept of __leadership__ (a cult word in our industry), it just doesn't have much place here."
"somewhere deep in our ancestral memory is buried the notion that work is supposed to be onerous...in this part we'll address the opposite premise, that work should be fun"
"there is something about human nature that makes us the implacable enemies of chaos...but it does not follow ... that we'd be happier if there were no more chaos. On the contrary, we'd be bored to tears. What chaoes is left in modern society is a precious commodity. We have to be careful to conserve it and keep the greedy few from hogging more than their share. We managers tend to be the greedy few. We often see chaos as our particular domain. We assume that it's our job to clean it up, all of it. The Open Kimono manager ((a name for the style of management that the book advocates)) has a different approach. He or she...((leaves)) small packets of chaos to others...the people down below get to have the real fun of putting things shipshape.
"progress is our most important problem: the amount of chaos is ever declining. this is particularly evident in new technological fields. Those people who were attracted to such areas years ago by the newness, the lack of order, feel a nostalgic fondness for the days when everything wasn't so awfully mechanical. Every great advance of the past twenty years has had the effect of reducing the craziness of our work. Of course those advances were wonderful -- we'd never want to go back to the old days -- but still... ... 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).... The thoughtful manager doesn't want to stop the trend, but may...replace some of the lost disorder...a policy of constructive reintroduction of small amounts of disorder...
"A pilot project is one in which you set the fat book of standards aside and try some new and unproven technique...Our experience is that pilot projects, projects that try out any modified approach, tend towrard higher-than-average net productivity...Should all projects therefore be pilot projects? Your organization would be in good company if it adopted that policy...In any event, it makes far more sense to run all projects as pilots than to run no projects as pilots...caveat...: Don't experiment with more than one aspect of development technology on any given project
"sometimes raucous, competitive, no-lose experience...the experience is only enjoyable as long as ((there are)) security and confidentiality guarantees ((for participants))"
When you pull this off successfully, people will tell you they've had the most exciting and enjoyable experience of their entire careers; nothing less than this is your goal"
notes:
"quantity of ideas, not quality....keep the proceedings loose, even silly....no evaluation of proposed ideas....discourage negative comments, like 'that's a dumb idea', since dumb ideas often lead others to think of smart ideas...as facilitator, try these...when the flow slows down:
romantic locales are better (e.g. London).
particularly when a team is forming
Outward Bound is good
Fellows/intrapreneurs/gurus/internal consultants: jobs in companies with broad area/loosely stated responsibilities, who to some extent get to decide what they work on. it's a good idea.
make sure you use the ideas that people come up with, otherwise the ppl will leave, like at Xerox PARC
"most people need a firm direction, handed down from above, and welcome a clear statement from the boss of just what specific targets are to be met in order to be considered a success." but some don't -- and if they have the "proper mix of perspective and maturity", they should be turned loose
"...take on the Furniture Police, fight corporate entropy ((by which they mean "sameness")), defeat teamicidal tendencies, put more quality into the product (even if time __doesn't__ permit)), repeal Parkinson's law, loosen up formal Methodologies, raise your E-factor, open your kimono..."
only try to do one of these because otherwise "your colleagues and those above you in the corporate hierarchy are likely to write you off as a whiner"
don't try to reform the corporation with force:
interview with a famous toreador: "a reporter asked El Cordobes what regular exercises he did to stay fit enough for the ardors of bullfighting.
'Exercises?'
'Yes. You know, jogging or weight lifting to maintain your physical condition.'
'There is something you don't understand, my friend. I don't wrestle the bull.'
however, "When something is terribly out of kilter like too much noise in the workplace , it takes very little to raise people s consciousness of it. Then it s no longer just you. It s everyone."
two more paths to teamicide:
they are insulting; the team already understands that "quality is job one", etc. they convey that management thinks that "these virtues 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". also, the implementation is often even more insulting; consider a poster that says, "teamwork: The Fuel That Allows Common People To Attain Uncommon Results" or "Leadership: the speed of the leader determines the rate of the pack."
in addition to "error, burnout, accelerated turnover, and compensatory 'undertime'", another benefit to overtime is teamicide.
Some of the team members will be able to put in lots of overtime, some won't, due to life circumstances outside of the workplace such as family members they need to take care of. The team will understand, and cover for those people, and that'll be okay... in the beginning. But after lots of overtime that some of the team does and others don't do, the part of the team that does will resent these guys for not fulling their weight. This will kill team morale.
"Most managers have at least a suspicion that overtime doesn't help, that projects that work alot of overtime are not much of a credit to their managerso skills and talents. But they end up allowing or encouraging overtime, anyway. Why is this? 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 our selves from blame when the work inevitably doesn't get done on time"
at the extreme, competition is certainly bad for team jell. e.g. " If team members are told, for example, that only the best one of them will be around next year, you can be sure that they will not succeed in working together very well.". We suspect it is bad in lesser degrees too.
"Competition is fostered when the children are emotionally undernourished by the parents, when there just isn t enough time, respect, attention, and affection to go around. Conversely, when adult and young adult siblings are super supportive of each other, when they obviously care a lot about each other and take evident pleasure in their friendship, you know that their parents have done something right. Is it possible that internal competition in work teams is fos tered by a manager s lack of time, respect, attention, and affection for his or her people? Though that may be too simplistic, we believe there is an important kernel of truth to the idea"
in an overly competitive atmosphere, team members won't teach each other their skills. but this peer coaching is crucial to team jell.
the following things promote teamicide by inducing competition:
W. Edwards Deming, "Fourteen Points.", 1982, point 12B: "Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means [among other things] abolishment of the annual or merit rating and of management by objectives"
"Any action that rewards team members differentially is likely to foster competi tion. Managers need to take steps to decrease or counteract this effect"
another problem with the word 'team' is that on sports teams there is internal competition. players on the bleachers hope the players in play go out so they can go in. individual team members can have a great game even when the team as a whole loses, and vice versa.
a better metaphor for work groups would be a choir or a glee club; a musical ensemble. " You'll never have people congratulate you on singing your part perfectly while the choir as a whole sings off key"
interface standards are great. we don't believe in process standards or formal process improvement programs.
"The individual may strive for, practice, and or promote good skills, but the orga nization can only them. It is in this institutionalization that the danger lies."
"When process improvement as in '((CMM)) Level 3 by the end of the year!' becomes the goal, the scary projects get put onto the back burner. It's those scary projects, unfortunately, that are probably the ones worth doing. All the projects that carry real benefit carry real risks along with them"
you have to watch out for this: "Luke, look into your heart. You know the great financial gain that can be yours if you can reach Level 4. Remember, only the Emperor is allowed to be at Level 5. Let nothing stand in your way, Luke. Turn to the Dark Side. . . . Here is our plan: We will under take only projects that are clones of past efforts. We will work on only what we know we are good at. We will define a process that works beautifully for these vanilla situations. We will document everything that moves. When the Pan Galactic Process Police arrive, they will be completely seduced by our seamless implementation of a perfectly managed software process. You will attain that promised massive bonus for software process improvement, but then you must act quickly. Cash that bonus check before your organization goes right down the tubes."
"
in summary:
" You need as much proficiency as you can possibly build into your organization. You need that in order to take on ever more risky projects. The Key Process Areas, as identified by the SEI, will be useful to you in building proficiency; they define sets of skills that ought to be on any good software manager s wish list. Focus on the KPA skills, but do whatever you can to turn off the institutional score keeping. "
" If you are already a CMM Level 2 or higher organization, remember this:
The projects most worth doing are the ones that will move you DOWN one full level on your process scale
Maybe those are the only ones you can afford to do. "
" People hate change . . . and that's because people hate change. . . . I want to be sure that you get my point. People __really__ hate change. They __really, really__ do. -- Steve McMenamin?, The Atlantic Systems Guild, London 1996
" Steve's quote is taken from a presentation to an audience of IT managers who were more than a little troubled by his view. At first, they were pretty comfortable with rejecting it: "Hey, we build systems that change how people work and play. We try hard to make sure that the changes will be for the better. We explain how the new way will be better; sometimes, we even use precise geometric logic. Why would any rational person resist any change for the better?" To the protesters, Steve retorted, "You don't get it. I m sorry, but people really, truly hate change. That's the problem: They're not rejecting a particular change on its merits; they're rejecting change. And that s because people hate change." The examples he offered were devastating. Little by little the message got through, and the crisis counselors had to be called in. "
"And it should be considered that nothing is more difficult to handle, more doubtful of success, nor more dangerous to manage, than to put oneself at the head of introducing new orders. For the introducer has all those who benefit from the old orders as enemies, and he has lukewarm defenders in all those who might benefit from the new orders" -- Niccolo Machiavelli, The Prince, 1513
"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"
" In 1991, 1992, and 1993, I was the Chair of the National Software Methods Conference, held each spring in Florida. The first year, I made some opening remarks and handed out a questionnaire for all the par ticipants to complete. I asked all sorts of questions about what methods and tools they used to build soft ware. One question I asked was, "What method or tool has been seriously introduced in your organization but has failed to become common practice?" I collected the responses, to report the results back to the atten dees by the close of the conference. I started making a list of failed methods and tools, but stopped when I noticed something much simpler and clearer: Everything had failed, at least somewhere. The real irony is that when I did report back, I took the list of failures and asked if anybody was using those methods or tools regularly. I got a positive response on every single one. Everything works, and everything fails. What is going on here? -- TRL"
factions w/r/t a particular change: " 1. Blindly Loyal (Ask no questions) 2. 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) 3. Militantly Opposed (Will Undermine and Destroy Figure) " -- from Jerry Johnson
if you are introducing a change, "you might conclude that the Blindly Loyal are the good guys and the others are whiners, that the Blindly Loyal are allies and the other groups are enemies. Jerry pointed out that this view is all wrong". the Blindly Loyal are probably fairly powerless, and they will jump onto whatever appears hot, so when something else comes along, they will withdraw their support and switch to that.
Both extremes, Blindly Loyal and Militantly Opposed, are enemies; "the success of your change will depend on how you man age the Believers but Questioners. Don t count on logic, by the way, as your trump card: These on the fence, maybe-baby allies are never going to be swayed solely by a rational discussion of why the proposed new way will be so much better than the current situation. Here is something to repeat to yourself whenever you set out to ask people to change:
MANTRA: The fundamental response to change is not logical, but emotional
As systems developers, we have selected ourselves into the world of cool, calming, rational thought. Either our code com piles, 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 situa tion bad . But think: Who helped implement the current situa tion? 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. William Bridges, in suggests that we never demean our old ways. Instead, we need to the old as a way to help change happen. For example,
"Folks, the CGS Close in Guidance System has been running for 14 years. We estimate that it has perfectly handled over 1,000,000 take offs and landings. The hardware platform has become technically obsolete, and there is some new remote sensing technology that we can take advantage of. Now we have the chance to redesign and rebuild the entire system. We need you and your expertise gained over these years of successful CGS experience to help us succeed in this effort."
In general, it may help to remind people that any improvement involves change:
You never improve if you can t change at all "
naive model of change: "old status quo" [label="a better way"] --> "new status quo"
" "We were perking along in the old mode when Harvey had a sudden inspiration, and we switched over to a new and altogether superior way of doing business." Honestly, it can t be that simple. It isn't. "
virginia satir's model:
"old status quo" [label="foreign element"] --> "chaos" [label="transforming idea"] --> "practice and integration" --> "new status quo"
" According to Satir s model, change happens upon the intro duction of a foreign element: a catalyst for change. Without a catalyst, there is no recognition of the desirability of change. The foreign element can be an outside force or it can be the recogni tion that your world has somehow changed. Outside force: Watts Humphrey walks into your office and announces that you are a Level 0 shop. Hmmmm. or The world changes: The quarterly sales of your flag ship product drop for the very first time in its history. Owww. When you try to institute change, the first thing you hit is Chaos. You ve been there before. It s when you are convinced that you are worse off than before with this new tool, new proce dure, or new technique. People are saying things like, "If we just jettison this new stuff, maybe we ll get back on schedule. . . ." You are suffering from the dip in the learning curve, and the assessment that the change is the problem may well be right, at least for the moment. You worse off, for now. This is part of the reason why response to change is so emotional. It is frustrat ing and embarrassing to abandon approaches and methods you have long since mastered, only to become a novice again. Nobody enjoys that sense of floundering; you just know you would be better off with the old way. Unfortunately, this passage through Chaos is absolutely necessary, and it can t be shortcut. The transforming idea is something that people in Chaos can grab onto as offering hope that the end of the suffering is near. A structured huddle is sometimes the best medicine: "I think that we re getting the hang of C++ coding, but how about a daily meeting at four o clock for all of us to go over our class def initions together?" The Practice Integration phase occurs on the upswing of the learning curve. You are not yet completely comfortable, as you are not yet proficient at the new, but you perceive that the new is now beginning to pay off or at least to show promise. You have reached the New Status Quo when what you changed to becomes what you do. An interesting characteristic of human emotion is that the more painful the Chaos, the greater the perceived value of the New Status Quoif you can get there. The reason the Satir model is so important is that it alerts us that Chaos is an integral part of change. With the more naive two stage model, we don t expect chaos. When it occurs, we mistake it for the new status quo. And since the new status quo seems so chaotic, we think, "Whoops, looks like we blew it; let s change back." The change back message is bound to be heard loud and clear in the middle of any ambitious change. When you re looking for it, your chances of dealing sensibly with it are much improved. "
" How many times have you heard that some new technique is going to be used because it is the only chance to make the hard and fast deadline, and that if the deadline is missed, there will be hell to pay? The setup of the change has already made its out come more than a little dubious. The kid like willingness to throw ourselves into a potentially embarrassing endeavor is defeated by the potential for ridicule. "
when you send an employee off to a training session, his salary during that time is treated as an expense, by accounting convention. but it should really be thought of as a capitalization.
when there is turnover, there is a lot of time spent on getting the new person up to speed (say, about 3 person-months of effort for a six-month linear ramp-up; but often it's much more, say 2 years (1 person-year of effort)).
" Some organizations can learn and some can t. Some can learn a lesson in the abstract but can t change themselves to take advantage of what they have learned. Some can learn, but the pace of their learning is offset by the pace of their unlearning. We all understand that the difference between being among the learning washed, as opposed to among the learning unwashed, is a matter of vital importance, because non learners cannot expect to prosper for very long "
"The first thing to realize about organizational learning is that it is not the same as simple accumulation of experience...organizations may accumulate experience at an astonishing rate, but there is no guarantee that their learning will keep track...Experience gets turned into learning when an organization alters itself to take account of what experience has shown. This alteration takes two forms, which are different enough to talk about separately:
In the first case, the change is the direct result of added human capital... If the retrained people leave, the investment is lost and the learning is gone. In the second case, the change is temporarily in the heads of individuals who implement the redesign. Eventually, it becomes part of the bone knowledge of the organization, but in the interim it resides only in the participants minds. In this case, loss of key people during the transition can jeopardize the learning. In either case, the self transforming organization has to face up to the following irreducible risk: When turnover is high, learning is unlikely to stick or can t take place at all. In such an organization, attempts to change skills or to introduce redesigned procedures are an exercise in futility. They may even act perversely to accelerate the rate of employee turnover. "
" The key question about organizational learning is not it is done but When an organization changes itself as much as the Amazon.com example suggests, there has to be a small but active learning center that conceives of, designs, and directs the change. This kind of ambitious change can t be invented by a committee or by the organization as a whole. The locus of early change activitythe learninghas to be located somewhere on the organization chart. Where?
It's tempting to say that it happens at the top. But tops of organizations, in our experience, are not so much focused on day to day operations. Presidents of large to medium size companies, for example, may spend most of their time making acquisitions or fighting them off.
There is a nice, egalitarian ring to the notion that the learning center might be at the bottom. But don't count on this happening in the real world. People at the bottom are typically too constrained by the organizational boundaries, and might be blind to important possibilities. In any event, they rarely have the power to effect change.
If the key learning doesn t happen at the top and it doesn t happen at the bottom, then it has to occur somewhere in the middle. That means the most natural learning center for most organizations is at the level of that much maligned institution, middle management. This squares exactly with our own observation that successful learning organizations are always characterized by strong middle management.
It's worth pointing out that downsizings, when they happen, are almost always targeted at middle management. In other words, the proverbial "tightening ship" activity that has its vogue every few years is often at the expense of organizational learning. After such an exercise, an organization s learning center may be destroyed. Flattening the org chart by gutting middle management is a sure recipe for decreased learning. "
However, middle management is a necessary but not sufficient condition for learning. "Middle managers must communicate with each other and learn to work together in effective harmony." This is rare.
"As we observed earlier, applying the word to a group doesn t assure that it will have any of the characteristics of a team. It may still be a poorly knit collection of individuals who have no common goals, common values, or blended skills. This is usually the case with most so called management teams. A good helping of the teamicidal effects we noted in Chapters 20 and 27 is at work on "teams" of managers: Group members are made defensive, burdened by bureaucracy, assigned fragmented tasks, physically separated, pressured to work over time, and goaded into competition with each other. With all that going against them, they are unlikely to merge into a meaningful whole. To make matters worse, they don t have the one thing that any team needs in order to jell: common ownership of the work product. Anything that gets accomplished in such a group is like ly to be the accomplishment of one of its members, not the group as a whole. The more competitive the managers are, the more pronounced this effect. We have even encountered extreme cases in which the rule was: "If something looks good, grab it; if you can't grab it, kill it." The Management Team is, most often, a sad misnomer... "
" ...if middle managers can act together as the redesigners of the organization, sharing a common stake in the result, then the benefits of learning are likely to be realized...Organizations in which middle managers are isolated, embattled, and fearful are nonstarters in this respect"
wasting people's time
" It sounds like this should be an easy sin to avoid, but it isn't. You have some needs of your own as a manager, and these needs may run squarely against your intention to preserve and use wisely the time of the people working under you."
e.g.
"Organizations have need of ceremony. It's perfectly reason able to call a meeting with a purpose that is strictly ceremonial, particularly at project milestones, when new people come on board, or for celebrating good work by the group. Such meetings do not waste anyone's time. They fulfill real needs for appreciation. They confirm group membership, its importance and its value. Ceremonial meetings that only celebrate the bossness of the boss, however, are a waste. "
" When staff is brought on too quickly at the beginning of a project, there is almost always a waste of people's time.
Again, you might think this is an easy sin to avoid: Just figure out how quickly the work can absorb new people, then bring them on, only at that rate. Although this makes perfectly good sense, it is often politically infeasible.
Projects begin with planning and design, activities that are best carried out by a smallish team. When design is important (as it is for anything but a simple formula project), it can require as much as half the full project duration. This suggests an ideal staffing plan that resembles the following: For a two year project, the bulk of the staff would not come on board until the project is six months to a year under way.
The problem makes itself apparent when the project is under a time constraintand what project isn t? If the client and upper management have decreed, for example, that only a year is allowed for the work...better consider now whether it will look better or worse for you not to have added the extra staff that upper management is willing to furnish early in the project. Even if that early staff allocation turns out to be wasted, your political situation may be safer with all those people on board early than if you were to proceed leanly staffed through the first six months...How common is it that projects are overstaffed early for such political reasons?...Probably ...ninety percent of all projects suffer from early overstaffing...When people s time is wasted in unnecessary meetings or by early overstaffing, they ll know it. They ll be frustrated and they ll know why. If there is enough of such waste, they ll probably let know about it, too. So these problems, though serious, are at least not invisible.
" ...fragmenting any knowledge worker's time over many differ ent tasks assures that he or she will be thrust into two or more dif ferent work groups, none of which is likely to jell into a real team....Fragmented time is almost certain to be teamicidal, but it also has another insidious effect: It is guaranteed to waste the individual s time. A worker with multiple assignmentsa little new development, some maintenance of a legacy product, some sales support, and perhaps a bit of end user hand holdingwill spend a significant part of each day switching gears. This time is largely invisible. The worker sets aside a design task to field a telephone call, works with the caller for twenty minutes to offer guidance about reconfiguring a database on one of the company s early products, and then turns back to the design task. If you were standing beside this person with a stop watch, you would probably have noted no wasted time at all. The waste is con cealed in the slow restart of his or her design work, the direct result of interrupted flow. Fragmentation is particularly injurious when two of the tasks involve qualitatively different kinds of work habits. Thus, the mix of a design task which requires lots of immersion time, relative quiet, and quality interaction time with a small group with a telephone support task which requires instant interruptibil ity, constant availability, quick change of focus is sure to make progress on the more think intensive of these tasks virtually impossible. The time wasted continually trying to get restarted is perceived only as frustration by the worker. You may never hear about it, because the people who suffer from this problem are all too likely to blame themselves "
"what great managers do best"
the chapter provides few tangible pointers, tho. they give an example of a company that "built itself around a school" through 5th grade for children of employees, where "every afternoon...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."
