Peopleware

Peopleware: Reading Notes

This is my document to write down things I feel like are important from the book Peopleware

The main premise of the book is: The biggest problems in development are sociological, not technological

Part 1: Managing Humans

It is easy to see people as parts of a machine, and treat them as modular components. However, the uncomfortable truth is that people are complicated, and very non-modular. The good news is that accounting for people's diversity will bring many benefits.

Development vs Production

Development is different to production work in that the workers of a production line are not supposed to think In other words, robots would be better production line workers than humans Development, however, inherently involves thinking, creativity, nuance, experimentation, mistakes, and change This means that it depends on the human-y side of workers

As a result, measures that would be useful for production or robots, will make thinking workers less effective

Here is a list of things that make a good production line

• No mistakes
• No goofing off
• Treat workers as interchangeable
• Optimize the steady state
• Standardize procedures
• No experimentation If you take any point, and do the opposite, you are on your way to a good development environment

Here is a more detailed explanation of what to do in development:

1. Allow mistakes (or even encourage them)

truth: Not allowing mistakes makes people defensive, and never try anything new This slows development, and in some cases, makes it impossible

what to do about it: Make sure people know that making mistakes is ok Ask what mistakes they have made recently, and make sure they know "none" is not the best answer Celebrate mistakes, it's one of the things developers are paid to do

truth: Some designs are inherently error-prone This may or may not be possible to predict Either way, such designs are harder to maintain or repair than starting over

what to do about it: For some features, it is better to start over than to repair them

2. Management is what the word means (not ruling, violent enforcement or exploitation)

truth: Using force to make people do their work will suck out all creativity, novelty and thoughfulness from the product

what to do about it: If there are motivation or productivity issues, find the root of the issue Don't try to pressure people into doing their work

3. Developers are unique

truth: People will have different needs and preferences Trying to force all developers into the same mold (including Ausstattung, workspace, etc.) will make people feel stifled and unhappy

what to do about it: There's no need to be threatened by individuality Seriously consider individual requests whenever possible

truth: Adding new people to a team will take time, and some people may just not work well together

what to do about it: // todo

4. Development is more than Writing Code

truth: There needs to be time planned in for brainstorming, finding new solutions, optimization, reading, training and "just goofing off" Without this time, quality will suffer No one will realize that what they are doing, actually doesn't matter

what to do about it: Actively plan in time for these things If these are not planned in, they will not be done because of the pressure to deliver on deadlines and products

Productivity: Limited or Createable Value?

There are two approaches to value: limited or createable value The limited value approach sees value as something that exists, and can only be more efficiently extracted The createable value approach sees value as something which can be found, developed, created, and expanded using ingenuity or technology

In history this lead to two approaches The Spanish "believed in limited value", and thus exploited workers and stole gold, which only ended up causing inflation. The English "believed in creatable value", and did so via the industrial revolution.

In management, this applies as well Some managers see productivity as getting people to work extreme overtime in an attempt to get more of the "value" a person has Overtime is basically just sprinting You can sprint for small amounts of time, but no one can sprint for long And no one should sprint at the beginning of the race

Clever managers realize how destructive this is They know that workers doing overtime will create more, but lower quality work They know that eventually, overworked workers will burn out or quit, looking for the meaning in life beyond simple work

DeMarco and Lister finish this chapter with emphasis on the fact: "People under time pressure don't work better­ they just work faster"

Quality

There are several instinctive, basic human values that are hardwired into our brains: survival, reproduction, self-esteem, territory, etc. In the workplace, the most common reason for strong emotion comes from our need for self-esteem And for the most part, workers tie their self-esteem to the quality of the work they deliver, not the quantity (even if that's what's required at the moment)

The problem is the natural tension between what users ask for: the product as soon as possible, and what the developer wants to accomplish: a product which is more or less the best they have yet accomplished

The good news is that this tension is one which dissipates when quality is given space Quality is an investment which more than pays for itself First of all, letting developers set their own quality standards improves productivity To prove this, DeMarco and Lister list several examples, including Japan, known for quality and productivity (Hitachi, Fujitsu, where developers have the power to veto release in order to bring quality up to standards) And Hewlett-Packard

Personal notes: I think there are two reasons for why this is the case:

1. People are more motivated since they have the freedom to improve the product in ways that they want to
2. People are less constrained by existing, poor quality work This is a driving factor in the other book I am reading, Clean Code, which explains the draining power of bad code

Work Does Not Expand to Fill Time (Parkinson's Law)

Parkinson's Law was invented by a comedian to describe government agencies Bureaucracies have this problem because working there is soul-draining work Studies have shown, time and time again, that Parkinson's Law does not apply to the majority of occupations

This means that adding tight deadlines, and putting pressure on people to finish work will not get work done sooner (or if it does, with large quality ramifications) It means you will stress and demotivate your workers

This has been studied specifically for software development, with fascinating results Developers are least productive when estimates/deadlines are set by managers Developers are somewhat more productive when estimating/setting deadlines with their managers Developers are marginally more productive when estimating/setting deadlines by themselves Developers are more productive when estimate/deadlines are set by analysts (experienced, third parties) And most surprisingly: Developers are majorly more productive when there simply are no estimates or deadlines (University of South Wales: Michael Lawrence and Ross Jeffery, in a study spanning the 80s and 90s)

Productivity by Estimation Result: +-------------------+-------------------+---------------+ | Estimate by | Avg. Productivity | # of Projects | +-------------------+-------------------+---------------+ | Management | 6.6 | 23 | | Devs + Management | 7.8 | 16 | | Devs | 8.0 | 19 | | System Analyst | 9.5 | 25 | | (No estimate) | 12.0 | 24 | +-------------------+-------------------+---------------+

Bad or tight estimates are demotivating, which directly affects productivity This is why a System Analyst can create better results than Devs or Devs with Management Management creates pressure for tight estimates, and Devs are optimistic These both lead to unreliable results, where a System Analyst has neither pressure not optimism, only realism The surprising factor is how much of a difference no estimate creates

The takeaway that DeMarco and Lister give is this, Parkinson's Law is very accurate, if you simply slightly variate the wording: "Organizational busy work tends to expand to fill the working day."

Empty Promises of Quick Fix Solutions

There are 3 indications that some promised solution is fake:

1. There is some new trick that will send productivity soaring You are not dumb enough to miss something so fundamental Anything which will so drastically increase productivity is already being done

Personal note, I think this depends on what you mean by "soaring" We started more strictly applying Scrum rules, specifically setting sprint goals, and it majorly improved productivity

2. Technology is moving so swiftly that you are being passed by Not really "High Tech" is moving swiftly, but software development is mostly static You analyze, define requirements, plan, code, test, release These things don't change that drastically very often

3. Changing languages will majorly improve productivity Simply not true Languages only affect the implementation, not analysis, requirements or planning New languages require a new project, or redoing major amounts of work New languages also require teaching developers the new language, with lots of productivity lost

Generally, new languages are not more than 3-5% more productive (for the implementation!) This is good, and probably worthwhile for such big changes, but it's not the change advertised

Finally, there is one interesting note that DeMarco and Lister mention: A manager's job is not to make people work, it's to make it possible for them to work

Part 2: Office Environment

The working environment has a huge impact on development Distractions waste time, and in the worst case, may take up the whole day "There are a million ways to lose a workday, but not even a single way to get one back"

Furniture

Often, the people in charge of furniture are only considering the cost This misses the impact that furniture has on the productivity of people

Also, not allowing people to individualize their workspace will frustrate and annoy them

Distractions and Interruptions

When you listen to developers, you often hear about the problems of having too much going on in the workplace:

• "I can work best early before anyone else arrives"
• "In one evening, I can do 2 or 3 days worth of work"
• "After 16, things have usually quieted down enough to get some work done" Unfortunately, often nothing is done about complaints about noise or distractions.

TODO: I think this needs to be extracted to somewhere else, but it's going here for now because this is where it is in the book

DeMarco and Lister offered the Coding War challenges, along with surveys, in order to measure productivity in relation to various factors There were some interesting results (which were repeated each year the Coding Wars were done), which were basically true for all metrics of performance:

• The best performers were 10 times more effective than the worst performers
• The best performers were 2.5 times more effective than the median performers
• The better half were 2 times more effective than the worse half Metrics included productivity as well as things like number of defects.

From the surveys connected to the challenge, some interesting factors were found which did not have an impact on their productivity:

• Language (except when using assembler)
• Years of experience (unless the participant had less than 6 months experience with the language they were using)
• Defects (in fact, participants with no defects had on average a slightly faster completion time)
• Salary (to be precise, the better performers only had a slightly better salary, less than 10% more)

A major factor that did matter was that participants who were in the same organization scored similarly DeMarco and Lister quote Harlan Mills: "While this [10:1] productivity differential among programmers is understandable, there is also a 10 to 1 difference in productivity among software organizations." This has been concluded by studies that investigated competing companies as well.

This is unsettling, it means one or more of the following is true:

• The organization makes it impossible for people to work
• The organization is not finding and keeping capable workers

DeMarco and Lister were able to use results from their survey to compare the best and worst performers: +---------------------------+---------------+---------------+ | Environmental Factor | 1st quartile | 4th quartile | +---------------------------+---------------+---------------+ | dedicated work space | 7.2m^2 | 4.3m^3 | | acceptably quiet? | 57% yes | 29% yes | | acceptably private? | 62% yes | 19% yes | | are silenced phones ok? | 52% yes | 10% yes | | frequent interruptions? | 38% yes | 76% yes | +---------------------------+---------------+---------------+

The Cost of Space vs The Cost of Good People

There is (personal note: was when the book was written) a general trend towards smaller, noisier, less private work environments. The obvious reason for this is that it cuts costs. The problem with this is that costs are generally cut without investigating the effect on performance. Generally, you spend around 15$ on a developer per 1$ you spend on the work space. When you add benefits, this is then approximately 20$ for developers to 1$ work space. Considering the 20 to 1 difference, it should be very critically examined whether the space savings will affect performance. Even if you halve the amount you spend on office space, if it decreases performance by 5%, you've lost money.

Unfortunately, open, crowded, noisy offices have become the norm. This was accepted because marketers said that it would increase productivity. Since it was cheaper, managers wanted to believe them. However, studies have proven otherwise.

In particular, IBM conducted its own study in order to determine the most cost effective arrangement for a new facility. They concluded, that per worker, they needed:

• 9.3m^2 dedicated space
• 2.8m^2 work surface
• noise protection using enclosed offices, or 6 foot high partitions And IBM actually implemented these standards in their Santa Teresa Laboratory.

The Coding Wars also produced evidence of the issues created by sub-par workplaces. In one company with many participants, there was a major difference between those who reported acceptable noise levels, and those who did not. 66% of workers who produced products with 0 defects reported the noise level as acceptable. However, only 8% of the workers who produced one or more defects reported the noise level as acceptable. In other words, if employees complain about the noise, ignoring them will lead to defects.

Unfortunately, some developers work in companies where noise levels are bad. In order to cope, they may hide away in places where they won't be disturbed. If you wander around and find people working in unexpected people, If you have trouble finding your employees (they probably aren't engaged in workplace romances or off planning political coups) "Saving money on space may be costing you a fortune"

Measuring Productivity

Unforunately, although there are trends, it is hard to make precise measurements when it comes to software development. For example, how productive was work on the new app? How complex was the latest project? These questions don't have simple answers.

However, considering there is a 10 to 1 difference between the best and worst companies, you cannot afford not to know. If your competitor is 10 times better than you, you will end up out of business.

However, you have to be careful with how you measure. Measurement and assessment can be an attribute which helps developers grow and learn. The problem is that usually companies do not work this way. Information gathered is used in order for precision promoting, demoting, even firing. In this case, the employees will work hard against the data collection. They will resent being controlled and watched.

The irony is that developers would use the information to improve themselves without any outside input. They will try to learn and improve where they can. In some cases, they may decide to "fire" themselves. The lesson is, only report this data in sanitized, anonymous averages.

Work Time vs Work Done (Flow)

Personal note: I think that the industry understanding of flow, and when and how work is done has evolved a lot I don't think that every that DeMarco and Lister say in this chapter is correct I do, however, think there is a lot of value in what they say (especially considering they are the ones that first made the idea popular)

As part of the study that IBM did for its productivity study, the researchers investigated how much time developers work alone vs with others:

• 30% alone
• 50% two
• 20% three or more

In a best case, when you are working alone, you are able to achieve a state of flow During flow is when you achieve the most work, and are most productive According to DeMarco and Lister it takes approximately 15 minutes to achieve a state of flow (Personal note: browsing the internet it seems like it depends on whether you mean first reaching flow, or reachieving flow after an interruption, and the type of interruption matters) DeMarco and Lister explain that as a result, even small interruptions have a big impact 1 hour of work done in flow is worth so much more than working in 10 minute segments 6 times

In a worst case scenario, people or noise is constantly interrupting you, which leads to a state of constant no-flow Worse is that this doesn't just mean less productivity, it is frustrating for employees One Coding War participant had a following work breakdown: +-------------------+-----------------------+ | worked from-to | interrupted by | +-------------------+-----------------------+ | 2:13 - 2:17 | phone call | | 2:20 - 2:23 | boss stopped for chat | | 2:26 - 2:29 | question from colleag | | 2:31 - 2:39 | phone call | | 2:41 - 2:44 | phone call | +-------------------+-----------------------+ Trying to work like this every day would be awful

As a company, it can be very valuable to start measuring uninterrupted hours of work First of all, you can use this time to identify the quality of the working environment If the number of uninterrupted hours is too low, you can set about improving things for your workers DeMarco and Lister give 40% uninterrupted to total time as a realistic goal, since it will never be possible to achieve 100% If you start to notice that people in private offices have more time in flow than people in crowded, open offices, you may realize that cutting costs wasn't worth it

Secondly, using the time logged, you can more accurately measure work that has been done For a feature that will take 300 hours, when you have 200 hours of uninterrupted hours logged, you are likely to be around 2/3rds done

And finally, by having employees log this time, it creates awareness of how important time spent in flow is They will naturally start to protect their time by clustering interruptions, getting back to people when it is convenient, not interrupting other for unimportant things DeMarco and Lister give an example of a company where the employees organically started hanging up red bandanas when they didn't want to be interrupted

Employees should have the time, space and quiet to be able to think about the problems they are working on

Telephones

I read this, but for the most part, the lesson is just, don't give developers telephones They should not be responsible for talking to customer or whomever It just ruins their productivity

The Sign of Successful Management: The Door

There are some immediate and obvious symbols of successful management One of the best is doors The worst is a PA system (speakers everywhere that are used to make announcements or call people)

Unfortunately, as work conditions got worse and worse, people didn't complain enough There was not enough evidence that open offices made productivity worse Now, however, there is evidence And additionally, the people selling open offices never proved their claims, why should developers need evidence to complain about uncomfortable work conditions?

When developers complain and ask for better space, there are generally three arguments brought up

1. People don't care about / you can't have fancy office space This is a straw man argument Nobody is asking for fancy offices They are asking for offices that they can work in without being distracted

2. Noise is a problem, but it can be fixed easily with white noise or music No, it can't A study done in 1960 discovered that people listening to music were able to program functions as well as people who did not The problem is, the people listening to music didn't notice that the output of the function ended up being the same as the input This is because the analytical side of the brain can work fine while the creative side of the brain is busy with music But when it comes to the big picture, to creativity, to noticing patterns, working with half a brain is a huge loss

3. Enclosed spaces reduce cooperation between programmers, they are a step in the wrong direction Programmers probably shouldn't be in offices by themselves They should be grouped by teams or people that they work with most If two programmers work together 50% of the time, they should share an office However, using this as an argument to not seperate anyone will hurt productivity, since those 2 people talking will distract everyone else Best case, the programmers are allowed to rearrange cubicle walls as they see fit

The Ideal Workplace

It may not seem to make sense to consider an ideal workplace, especially if you are in a terrible office currently. Nonetheless, it is helpful in case you get the chance to provide input on a new office, or even just for redesigning the current layout. Generally speaking, DeMarco and Lister believe that Christopher Alexander has the best, comprehensive guide to ideal building and interior design.

The first point they refer to, is Alexanders principle of Organic Growth Most buildings are giant, modular, repetitive structures. A company can design them once, and build 200 of them. Although this is cost effective, they are demoralizing and depressing to work in or look at. The places where people feel most comfortable, is in places that have evolved organically into the places they are.

In order to achieve this, Alexander has a meta plan for how to develop a space:

• A philosophy of piecemeal growth
• A set of shared patterns or design principles tying elements together
• Local control of the people occupying the space This is very abstract, and can best be understood with an example. Alexander explains it by referring to the University of Cambridge. The university evolved over time, and colleges were added one after another. The result is several (campuses?) with shared design principles, which are grouped together loosely in the city. They each have an opening onto the river, they all are connected to the main street, they all have courts and a bridge. But they are all unique and have their own character. As a result they are all interesting in their own right, but maintain their connection to each other.

The next point that they refer to is Alexander's principle of Patterns. Alexander has written an entire book of design patterns for architectural/interior design. These patterns lay out rules, based on surveys and analysis, for comfortable spaces. The patterns emerge, and show up again and again, because they are in harmony with people. His pattern 183 (which is fascinating) is about the workspace enclosure. In it, he lays out several rules, which have been condensed to these below:

1. You feel more comfortable in a workspace if there is a wall behind you, and to the sides of you (50 - 75% enclosed)
2. You should have 2.5 meters of open space in front of you (so your eyes can relax and don't become strained)
3. You should have at least 5.6 square meters of workspaces so you don't feel cramped or claustrophobic
4. Every workspace should have a view to the outside, even if it is a large open space
5. No other person should work closer than 2.5 meters to your workspace (so you can talk on the phone without being overheard)
6. You should be aware of 2 to 8 people (less and you feel like no one cares about your work, more you feel like a cog in a machine)
7. You should not be able to hear noises very different from the kind of noise you yourself make in your workplace DeMarco and Lister specifically single out 4 areas where modern companies make the worst transgressions.

First, using cubicles which isolate people, without protecting them from noise. Best case, let people design their own spaces, and define for themselves who is near whom.

Second, everyone needs windows. Without them, people feel imprisoned. Also, if you make it a priority, it's not hard to accomplish.

Third, indoor and outdoor space. Companies rarely have any form of outdoor space. Any yet, after working with it, people can hardly imagine giving it up. If possible, try to allow some sort of outdoor work. It is often not more expensive, because most companies don't look for it.

Fourth and finally, a gradient of public and private space. People need private places where they can work alone, but they also need places to interact and work with others. Ideally, there is a smooth gradient of private workplaces, that slowly transition to the public areas. Private areas should be quiet and (to the rules of pattern 183) enclosed, and public spaces open, and equipped with tables and places to draw and discuss.

The issue that some companies may take with the patterns and principles, is that they are non-replicable. Two spaces, designed by two different teams, will not look the same. This shouldn't have to be an issue, but sometimes it is. If possible, take steps to move towards this right away.

One possibility is to petition to move your larger team into a different building. This has a decent chance of being approved if your company is running out of space. Look for some cheap, run down fraternity house, or garden apartment. The worst that can happen is that you will be turned down.

DeMarco and Lister finish by stating that projects that are outside of corporate space have more energy and higher success rates.

Part 3: Investing in People

In the end, the biggest factor in what and how things get done, is who does the work Management is often so focused on managing the people who are already there, that not enough focus is put on hiring the right people So:

• Hire the right people
• Make them happy so they stay
• Turn them loose!

People can change, and you have an effect on people, but as a manager, you will not be the person to change your employees to any large degree. This means that the people you hire, more or less, will have the same level of productivity, the duration of time they work for you.

Corporate Uniformity

People are instinctively aware that they should not simply hire people that are similar to themselves. Unfortunately, they often don't notice the subtle pressure to hire people that are similar to the current company employees. When you hire someone, they become part of your group, the group of your boss, and his boss, and so on. So there is pressure to find someone that they will agree with.

The more secure you and your bosses are, the easier it will be to hire unique and different people. But if the more insecure they are, the harder it is to hire people, which has a compound effect. You hire similar people, leading to more uniformity, making it harder to hire people who are different.

This leads to this general rule: "SECOND THERMODYNAMIC LAW OF MANAGEMENT: Entropy is always increasing in the organization." Where entropy is the level of uniformity. There is not much you can do about this law, but you have to fight it for the sake of your team, as well as your company.

True Leadership

True leadership is hard, which is why companies tend to talk about it more than they actually do anything about it. When they do actually do any leading, it is often simply to force people to do as much work as they can. Real leaders, however, are different.

A leader that people respect has several qualities, they:

• step up to the task
• are obviously capable of the job
• prepare ahead of time
• maximize value for everyone
• do all that with apparent good will and humour And in the best case, they are charismatic as well.

DeMarco gives as an example a leader he personally respects. DeMarco plays tennis several times a week, and the obvious leader of the group is Mike. Mike was never voted or nominated, he simply stepped up to the job, and no one questioned him because he does such a good job. Mike arranges matchups, and manages to pair people together who are always similar in skill. He finds substitutes when people are missing. He has a booming voice that you can hear from far away, and people naturally respect him. Mike doesn't get anything for his work other than appreciation, and everyone in the group simply appreciates him for what he does. This is what a leader should be.

Often, what organizations need is leaders who take charge without being appointed. These "rebel leaders", who lead without permission, are more likely to enable innovation, which in the same way, often has to happen without permission. Unfortunately, innovation is unpredicatable, and in a company that doesn't actively enable it, employees will have to take risks to achieve it.

Hiring Capable Workers

If you were going to hire a juggler, would you ask him how many balls he can juggle with, whether he can juggle knives? No, you would ask him to show you what he can do. In the same way, hiring an engineer without ever getting some presentation of their actual skills is ludicrous.

One of the best ways that you can evaluate the aptitude of candidates is by viewing some portfolio they have. Unfortunately, it is still relatively uncommon for candidates to have a portfolio of any sort.

Another option that the industry has used are aptitude tests. Unfortunately, these tend to test the skills necessary at the time of hiring. However, your employees are unlikely to keep doing exactly the same thing they are doing now in 5 years. Another drawback is that these tests tend to be focused on tools and technology, and often don't include any soft skills.

As an alternative, then, to aptitude tests, DeMarco and Lister suggest asking candidates to hold a presentation. Nowadays, the biggest problems in development are sociological, not technological. Thus, it is most important that the employees have good people skills. They recommend that the candidate prepare a 10 to 15 minute presentation on a new technology they learned, an interesting project they worked on, or a hard lesson they learned. This presentation should then be held with all members that are likely to work with this person. Once they are done, everybody should be a part of the discussion of what they think of the potential candidate.

In Lister's experience, this presentation helped to identify people who would never be able to discuss well about code. Additionally, it helped speed up the process of team bonding. Finally, it was a certification of sorts that the employees coworkers approved of them. When the new employee was then in such a meeting for another new candidate, and saw people being turned down, it served to show that they actually were wanted and their skill appreciated, rather than that anyone who applied was let in.

Integrating Diverse Teams

Contractors, outsourcers and offshore personnel add more complexity to building team. Additionally, the diversity of teams is increasing, making it all the more important to integrate teams well.

Software development has been majorly improved by the inclusion of more women in the field. They have brought innovations to team organization, team interactions, technological analogies, management techniques, and every other part of development. Any team that is homogenous in some way will be less creative and innovative compared to a team that is diverse. It is important to appreciate the new perspectives, even if it challenges existing structures.

However, in the end, it is important to keep in mind that a team has a limit to how much newness they can absorb.

The Next Generation

There are differences in the old workforce, and the new digital natives entering the workplace. Digital natives are more likely to spend their time with split attention to work and social media (continuous partial attention). Explain to them the difference between spending 20 minutes on social media once versus 1 minute 20 times. Make sure they understand the effect of leaving attention dividing things open at all times (hint: flow state). These things are bad for flow state, but they are terrible in meetings as well. Additionally, younger workers are less and less likely to check their emails regularly.

The Causes and Effects of Turnover

DeMarco and Lister have a simple test to check if you and your company are aware of the consequences of turnover. What was annual employee turnover last year, and what was the average cost of one replacement? If you do not know the answer, you fail. Actually, you pass if anyone in the company can answer the question, and yet you are likely to fail this test anyway. Most companies do not keep any records on turnover. The reason is the same as why smokers don't like talking to their doctors about the future, it's work that can only result in bad news.

Typical employee turnover ranges from 33 to 80 percent. As a result, the average employee leaves after 2 years. The cost of this is enourmous, since it includes 1-2 months salary to an agency or some employee responsible for the process, as well as upwards of 3 months time training the new employee before they do any productive work.

It gets worse though, there is a hidden side to high turnover. When people are always one foot in, one foot out, it creates a culture of short-term goals and perspectives. Rather than invest in improving conditions, people will be motivated to look good, and then get out. A good analogy is that people are eating the seed they need to plant next years crops. Since they don't plan to be around next year, it doesn't matter to them who starves.

One way that companies fight this is by promoting the good workers early. This doesn't make sense either, though. If people are promoted within their first few years, that means the people with experience will leave the actual group building software. In the end, the people doing the programming are in their 20s, with an average experience of less than two years. A true sign of a mature company, is one where promotions are late, and hierarchies are flat.

Some strong reasons that people leave companies with high turnover are:

• No feelings of long term involvement
• Feeling disposable to the company
• Feeling like loyalty would be ludicrous, since the company isn't doing what's good long term, and doesn't care about its employees anyways The problem then becomes that turnover increases turnover.

One of the most damaging things for companies to do is to move without good reason. This is often an ego trip for the higher-ups, by moving the company closer to where they themselves live. DeMarco interviewed a manager for a failed project by Bell Labs, and when asked about failures and successes, the man said, "Forget the successes, the failure was the move. You can't believe what it cost us in turnover." They lost a higher percent of people than the French in the trenches of the first World War, and that was only the people who left before the move. About a year later, another large group of employees left. This was the group that had really tried, and just didn't like the new location.

What do companies have in common that have low turnover? These companies obviously are not only low in turnover, they are good at all people-related things. They are more disalike, than they are alike, but they have a few shared qualities.

• They are all engaged in being the best
  • it is a topic in meetings, and discussions, in planning, etc.
  • the inverse is also true, companies that have high turnover do not discuss "being the best"
• There is a sense of community
  • "unnecessary" investments are made in things which have no hard value, but build up a community
  • for example, some companies have gardens (that they paid extra for) that employees tend during lunch
• The company invests heavily in employee training
  • they invest time and money
  • everyone is constantly being retrained, and people can move up because of this investment
  • people who started as one thing, are trained to work in higher, or different positions The combined message is: we are investing in you for the future, and we want and expect you to stick around.

Investment vs Expenses

There is a fundamental difference between an expense, and an investment. A building is mostly an expense. Every month, you pay a certain amount of money for air conditioning. In the spring, you don't pay anything, since it is a comfortable temperature outside. In the summer however, you pay a lot to keep the office cool. This money, once spent, is simply gone. When you buy a product, for example a computer, it is different. When you buy a laptop, you have not lost the money you spent, you have traded one form of value (money) for a different value. The laptop can be used as a tool for making more money. You don't buy a laptop, and then throw it away, because it has a value.

It is important to remember that the same is true of training for employees. If you send your employee to a seminar, or buy books, or whatever, that is money invested in your people. If you were to fire the employee the day after paying for their seminar, you are in essence throwing away a new laptop. It is important to invest in your employees, and then keep them around. Otherwise you are wasting money.

A good example of this is when an experienced worker quits. They give you three months notice, and you scramble to find a qualified worker to replace them. Unfortunately, you can only find people who are skilled, but not knowledgeable in your project. The day comes that your employee leaves, and the new hire arrives. All of a sudden, your productivity drops. The new worker has a starting productivity that is negative, because they have to read all the documents, get their computer set up, ask questions. This means they are not working, and in fact, they are holding up your other employees.

The important thing to note is that this is not a problem, it is not an expense, it is an investment. As long as the new worker stays with your company, you have invested in their potential and work. But if your company does not work hard to keep employees, then that worker might leave in two years. During this time you have paid dearly to train them, and losing them means you lose all that training.

Another question is how long it takes to train a worker. Depending on the field and how specific it is, this may take 6 months, to 2 years, or even longer. This is money you cannot afford to waste.

Part 4: Growing Productive Teams

The times that work is satisfying and fun is when there is challenge. However, for most people, the core of the satisfaction and joy is not the challenge itself. What matters most is the way these challenges brought teams together, and gave them something to achieve as a whole. People work better and have more fun when the team comes together.

Team Jell

Teams need team spirit and a shared idea of goals to work effectively. Managers are usually motivated by things from upper management, and have "bought in" on their goals. However, the employees at the bottom usually aren't interested if the company has their best quarter yet. To an employee at the bottom, this has no real impact, and it is naive to think it will or "should". Since a person will work much better if they are motivated by the company goals, it would be very useful to get them to buy into these goals. Therefore, it is interesting to note that just because a goal is arbitrary, doesn't mean that people can't be motivated for them. If they couldn't, there wouldn't be sports. However, this motivation comes from the team connection, not the goal.

There are a number of signs of a good team. Such a team...

• has a strong sense of identity
• may have many insider jokes, be somewhat exclusive, and have an air of superiority
• accomplish more together than alone
• is excited and motivated to work on things that other teams would consider dull and uninteresting
• has low turnover Such teams don't need to be managed in a traditional way. Rather, a manager will spend most of their time getting obstacles out of their way. They don't need to be motivated, because they get their motivation from their identity as a team. Even if the goals themselves are arbitrary, they will work hard for them the same way a sports team does their best to perform well. Achieving the company goal is arbitrary, and the real motivation is achieving the goal as a team.

Unfortunately, managers often don't appreciate the value of such teams. Most work is done by individuals, not by team members working together. This is because teams server to align goals, not to attain goals. A well built team is simply more organized (in addition to more motivated and happy).

Managers may also feel threatened by these teams. This is because they are not part of the team. Additionally, such a team is simultaneously a clique, and thus exclusive. Finally, the teams loyalty is to itself, not the company. This is unfortunate, but as a manager, it is important to see the value of such a team as worth the discomfort of these points.

The value of a jelled team is made evident by a story of "The Black Team". This was a fabled team that started at a company as a group of developers who were slightly better at finding bugs than the rest. The thing that was incredible about them was how much better they got over the next year. What happened was that they took joy in doing a good job, and as testers, this meant finding bugs. They began cultivating an image of being cruel, terrible destroyers of programs, who took joy in the pain and suffering of developers. They started wearing black, and laughing about bugs they found. And all the while, they got better and better at finding bugs, motivated by their team spirit as "The Black Team". The company recognized this value, and immediately replaced members who moved on to other projects and companies. By investing in this team, the company was able to preserve the culture and spirit, and continue the high quality work they did.

todo

todo

Part 5: todo

todo

todo

Part 6: todo

todo

todo