![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
Difference between revision 2 and current revision
No diff available."
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?