Monday, May 31, 2010

Fighting For Flow

"And George, while his intelligence was way above normal, had a little mental handicap radio in his ear. He was required by law to wear it at all times. It was tuned to a government transmitter. Every twenty seconds or so, the transmitter would send out some sharp noise to keep people like George from taking unfair advantage of their brains." - Harrison Bergeron, by Kurt Vonnegut

Flow is the highest-productivity mental state of which humans are capable.

A person operating in flow can be vastly more productive than a person who is not in flow.

A person in flow often starts working in the morning when it is light, and snaps out of flow late at night when it is dark, with no sense of the passage of time.

A person in flow sometimes forgets to eat.

A programmer in flow can do a week's worth of work in an afternoon, and a month's worth of work in a couple of days.

A company that makes it easy for programmers to work in a state of flow has a strategic advantage over companies that have not figured this out.

A programmer who learns to maintain a state of flow has a career advantage over programmers who have not learned how to do this.

Unfortunately, it is becoming increasingly difficult to maintain a state of flow.

Some of this is the fault of programmers. It is easy to be seduced by email, IM, Twitter, etc.

Fortunately, this can be rectified by self-discipline. Shut down email, log out of IM and Twitter, turn off the cellphone, and focus.

But companies also contribute to the problem. Perversely, they seem to go out of their way to squander programmer productivity. Instead of uninterrupted blocks of time, days are broken up with meetings. Instead of quiet offices, they stick programmers in noisy "pods". Instead of encouraging working at home, they disproportionally terminate remote workers during layoffs (then wonder why so few employees become remote workers).

It can become pathological. Several companies ago, a colleague took two weeks of vacation so he could come to work every day and focus on something he'd been trying to get done for over a year. If anyone stopped by to ask him something, he'd tell them he was on vacation, and tell them to go away.

I didn't make that up.

Programmers need to fight back. It's a matter of self-preservation.

Just complaining won't change anything. You'll just be seen as a "troublemaker".

But there is one stick big enough to beat management over the head with to get them to listen.

Money.

Programmers cost money. They cost more money than anything else in the budget. A Silicon Valley programmer, fully burdened, can cost $250k/year.

Wasting programmer productivity is fiduciary irresponsibility.

Mechanisms that preserve programmer productivity deliver tangible benefits to the bottom line.

The industry average for under-the-headphones actual coding--and this is criminal--is only about 12 hours/week. Not per day. Per. Week.

That's crazy.

There are 168 hours in a week.

Where do the rest of the hours in the week go? WoW? Air hockey? American Idol?

Now suppose instead you can eke out a whopping 16 hours/week. That doesn't seem like much, but it's a 33% improvement. It's like being able to hire 33% more programmers without spending another penny. Think what the company could do with that much additional engineering resource! They could deliver more features. They could fix more bugs. They could crush their competition.

But it's not even just a 33% improvement, because you're shooting for achieving 16 hours a week of hours in flow, so the productivity gains are much higher than a mere tally of hours indicates. Both the number of hours and the quality of hours increase. It's a force multiplier.

Now you're talking a language management understands.

So go to management, and make the business case. Tell them you want to help the company be more successful by removing obstacles to programmer productivity. List the obstacles, and suggest how each could be eliminated.

Start with something small, so their heads don't explode with concerns about "risk". I recommend starting with this.

Then when you show that the small change resulted in a measurable improvement, move to the next obstacle.

Your team will be vastly more productive than teams that still suffer from the obstacles. Other managers will start to panic and want to know what the "secret" is, and start removing obstacles as well. Management will stop muttering about reducing costs by "offshoring" (because you found a way to reduce costs while keeping the jobs local).

Related: http://www.paulgraham.com/makersschedule.html

1 comment:

  1. The unfortunate reality for those of us who work across teams is that the coding often can't be done during the day at all, and the only sacred time is in the evening. Poor quality of life, but it sure is relieving to get your code done and checked in before coming to "work" the next morning.

    One truth about large organizations, is that teams that want to work together need to be able to "talk to someone", and this causes the need for some, if not most, of the meetings. There's more organization required to truly move or reduce the meeting load. For example, if management is really committed to this, you'll want to create small productive teams that span (ignore) BU boundaries so that alignment and communication meetings can be reduced to daily stand-ups.

    So I think flow time can be increased in an org, but it's more than just moving around calendars. Management needs to be taught how, and it does take discipline and the organizational willingness to change. Moving calendars is part of the solution, but getting your team structures straight - and in the process, transcending the normal organizational boundaries allows you to actually not just move meetings around, but eliminate (some of) them.

    ReplyDelete