Book Review 13: Flow and Gel

Whatever you name these people related problems, they’re more likely to cause you trouble on your next assignment than all the design, implementation, and methodology issues you’ll have to deal with. In fact, that idea is the underlying thesis of this whole book: The major problems of our work are not so much technological as sociological in nature.

Page 4

In December of 2003, while on vacation, I dove into Excel. I sat in an aging recliner, with a notebook in my lap, and wrote macros, built formulae, and taught my self to write in visual basic. The 6 or 7 hours flew by, and by the end of the evening I had turned a detailed weekly reporting system into a beautiful automation tool that would save me an hour or more per week.

Whether it was wise or not to work on vacation I’ll leave to another discussion. But I distinctly recall what a joyful process it was to dive in to Excel and make something.

I had achieved flow.

During single-minded work time, people are ideally in a state that psychologists call flow. Flow is a condition deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: “I began to work. I looked up, and three hours had passed.” There is no consciousness of effort; the work just seems to, well, flow. You’ve been is this state often, so we don’t have to describe it to you.

Page 63

That wasn’t the first or only time I have hit that flow state. In my job, I often have to drop in to that realm. Fortunately, I have the luxury not going into a corporate cubicle environment.

In Peopleware: Productive Projects and Teams (2nd Edition) Tom DeMarco and Timothy Lister take modern corporate management to task for the way it destroys productivity in software development. The book is well structured, easy to read, and entertaining. The authors talk about some theory, but much of the discussion is drawn from their own experiences as consultants. The book is filled with actual stories and with tips managers can start using right away to help their developers succeed.

In a modern US economy that celebrates the triumph of the knowledge worker DeMarco and Lister focus on how business treat them like assembly line factory workers. While corporations push their products toward the 21st century, they often mange worker like it’s still the 19th century.

The authors cover a lot of ground in supporting the thesis I mentioned in the introduction, but most of the material focuses on two areas – flow and gel.
They contrast development work with the factory production challenges.

Steady-state production thinking is particularly ill-suited to project work. We tend to forget that a project’s entire purpose is to put itself out of business. The only steady-state in the life of a project is rigor mortis.

Page 10

Everything at a fast food restaurant can be reduced to steps and those steps can be made to maximize efficiency. The equipment can be modified and relocated to maximize efficiency. Workers don’t need special skills because all they need to do is continually execute a set of predefined steps. Management’s role to keep workers focused on task and steps, and workers are as easily replaceable as a damaged fryer.
But that doesn’t work for developers.

These would be reasonable approaches if you were in the fast food business (or any production environment), but you’re not. The “make a cheeseburger, sell a cheeseburger” mentality can be fatal in your development area. It can only serve to damp your people’s spirits and focus their attention away from the real problems at hand. This style of management will be directly at odds with the work.

Page 7

And they have a point. There is a difference between creative work and repeatable work. There is an undertone of elitism in that passage, though, and it continues through the book. They seem to feel software developers are a special breed. They are better, more important, more reliable, and more valuable that other employees.
While I have never been accused of radical egalitarianism, there is something distasteful in the attitude the authors seem to adopt.

But it is forgivable. Their background is in the software development and project management business. They are advocating on behalf of the developers. They believe developers really want to work and produce great products, almost as if it is a calling.

And given the salaries many developers make, corporations should probably treat them that way.

DeMarco and Lister compare the investment in salaries to the investment airlines make in airplanes. An airline only makes money if the planes are in the air. They are loathe to spend millions of dollars on hardware, only to leave it sitting on the tarmac.

The human capital invested in your work force also represents a ton of money. If your company employs a few thousand knowledge-workers, it could easily have enough invested in them to be the equivalent of a modern wide-body aircraft. Wasting the time of that huge investment is money poured down the drain.

Page 221

DeMarco and Lister make a compelling argument that interruptions are the biggest destroyer of productivity in the development world. The state of flow is essential to producing quality work quickly, but flow can’t be achieved on a moments notice. It takes time to drop into that state, and each time a worker is interrupted, they come out of the flow state and lose time dealing with both the interruption and the time required to get back into flow. Hopefully they get there before they face another interruption.

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 interruptibility, 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 hears about it, because the people who suffer form this problem are all too likely to blame themselves.

Page 220

The authors heap much of their derision on the ever present telephone.

When electronic mail was first proposed, most of us thought that the great value of it would be the saving in paper. That turns out to be trivial, however, compared to the saving in reimmersion time. The big difference between a phone call and an electronic mail message is that the phone call interrupts and the email does not; the receiver deals with it at his or her own convenience. The amount of traffic going through these systems proves that priority “at the receiver’s convenience” is acceptable for the great majority of business communications.

Page 73

More important than any gimmick you introduce is a change in attitude. People must learn that it’s okay sometimes not to answer their phones, and they must learn that their time – not just the quantity but its quality – is important.

Page 74

It is natural that the telephone should have reshaped somewhat the way we do business, but it ought not to have blinded us to the effects of the interruptions. At the least, managers ought to be alert the effect that interruption can have on their own people who are trying to something done. But often, it’s the manager who is the worst offender. One of the programmers in the 1985 Coding War Games wrote on his environmental survey, “When my boss is out, he has his calls switched to me.” What could the manager have been thinking? What was going on in the mind of the systems department head who wrote this in a memo:

“It has come to my attention that many of you, when you are busy, are letting your phone ring for three rings and thus get switched over to one of the secretaries. With all these interruptions, the secretaries can never get any productive work done. The official policy here is that when you’re at your desk you will answer your phone before the third ring….”

Page 72

The phone is not the only problem, though. They spend a great deal of time talking about modern office furniture. The book is a great indictment of the modern cubicle work space:

Today’s modular cubicle is a masterpiece of compromise: it gives you no meaningful privacy and yet still manages to make you feel isolated. You are poorly protected from noise and disruption; indeed in some cases, sources of noise and disruption are actively piped into your space. You’re isolated because that small lonely space excludes everyone but you (it’s kind of a toilet stall without a toilet). The space makes it difficult to work alone and almost impossible to participate in the social unit that might form around your work.

Page 86

While DeMarco and Lister offer solutions to the ever present flow challenges, they also tackle the other key element of a development project – team cohesion. Their focus is on how to help teams gel.

It may seem contradictory at first. The first part of the book is all about empowering the individual worker to excel by hitting the flow state. Then the second half of the book talks about what it takes to make the developers work together.

The authors do a nice job of blending these concepts. Changes to the office that accommodate flow can also accommodate team work. The key is that workers on a team that gels, or achieves a high level of cohesion end up working together well, and then working by themselves well – on essentially the same schedule.

One of the most valuable sections of the book was the one where they introduce their recommendations for how to prevent teams from gelling. And it really had nothing to do with the main point.

Back to brainstorming mode: we began looking for “Six Things You Can Do to Make Team Formation Possible.” It was still hard. At last, in desperation, we tried a trick called inversion, described in Edward deBono’s Lateral Thinking. When you’re stuck trying to solve a problem, deBono suggest that rather than looking for ways to achieve your goal, look for way to achieve the exact opposite of your goal. This can have the effect of clearing away the brain’s cobwebs that keep you from being creative. So instead of looking for ways to make team formation possible, we began to think of ways to make team formation impossible. That was easy.

Page 133

Inversion is a simple idea with the potential to deliver powerful results. I plan to use the next time I am stuck for ideas.

I don’t agree with everything DeMarco and Lister discuss. They have howl at things like motivational posters.

These motivational accessories, as they are called (including slogan mugs, plaques, pins, key chains, and awards), are a triumph of form over substance. They seem to extol the importance of Quality, Leadership, Creativity, Teamwork, Loyalty, and a host of other organizational virtues. But they do so in such simplistic terms as to send an entirely different message: Management here believes that these virtues can be improved with posters rather than by hard word and managerial talent. Everyone quickly understands that the presence of the posters is a sure sign of the absence of hard work and talent.

Page 178

When I see those things, I don’t get that same impression. While I can see the point DeMarco and Lister are making, I find those tools can be useful for reminding me about the broader context. They are so much about teaching the concepts of Creativity, Teamwork, Loyalty, or Perseverance. The are more of a reminder that it’s not just about the email I’m sending, of the document I’m writing, or the presentation I’m preparing. It’s all about something bigger -- the quest to the job well for the sake of doing the job well. Those motivations accessories become a touch point for deeper thought. They are a reminder to not forget why I work hard.

And it’s possible I see the differently simply because I work in marketing, rather than the software development field DeMarco and Lister are writing about.

In general, the authors feel that effective management is really about getting out of the way:

Sharon knew what all good instinctive managers know: the manager’s function is not to make people work, but to make it possible for people to work.

Page 34

Peopleware: Productive Projects and Teams will be most valuable to those managing engineering and development teams. Others will also benefit from the discussions of the work process. It’s a fascinating look at what works and what doesn’t work with knowledge workers today.

If you’re interested in a book of specific how to tips to help people do their work better – and one that is backed up with some theory—this is a great choice. It’s fun, easy to ready, and practical