patrickwilsonwelsh.com

Your Heads-Down Cubicle-Dwellers are Mostly Wasting Their Time

This one has a “rant” tag, because it’s not a friendly post. I have seen too much pain and needless waste resulting from this problem at various large enterprises.

The larger the percentage of their workdays your individual programmers spend heads-down in their cubicles, cranking away on their keyboards, the more screwed-up your software development operation is. You may not be measuring it well, but I guarantee you that if your programmers are heads-down cubicle-bound code-crankers 90% of the time, then much of that time is wasted. They are either blocked much of the time, whether they or you notice it, implementing requirements poorly (building the wrong thing, or building the right thing poorly), not refactoring their code adequately, doing lots of rework, re-inventing lots of wheels, devising algorithms and designs that are completely out of synch with the person in the cubicle next door, or all of the above. I can’t remember all of the other ways they are likely suffering. I ran out of breath.

Your continuously heads-down coders are wasting a huge amount of their time and your money, because they are trying to play baseball as if it were remote, fantasy-league baseball. They are playing what is fundamentally a team sport, as if it were a network game simulation of a team sport. This is likely because you, as a manager, are insufficiently familiar with the lean manufacturing concept of muda. Read up on it, and learn how to measure and avoid its 7 deadly sins.

Furthermore, if you continually monitor who is heads-down coding in their cubes and who is not, trying to herd them back to their cubes, you are creating disincentives for people to learn, solve problems collectively and creatively, work consistently, and share. You may in fact be helping to create a culture of fear, which is the death of true productivity, much less excellence.

Without Good, Cohesive Teams, You Are Throwing Money Away

Software development managers and executives, listen up. Again, I have no interest in being gentle here. After 28 years, I am just sick and tired of the individualism and mushroom treatment I see people continuing to give their programmers.

Individual programmers that work in teams cannot accomplish anything truly useful on their own. Stop asking them to. Stop worrying about how much time they spend in each others’ cubicles, trying to learn from each other, trying to get unstuck, trying to work consistently, trying to eliminate waste and rework, trying to estimate better, trying to make sensible commitments. Even your most skilled “power-programmers” have knowledge that they must convey, problems that get them stuck, and requirements they misunderstand. And if those “silos of knowledge” leave you someday, do you want them to take all of their knowledge with them? That is what I usually see happen.

Only the entire team can actually deliver the most, best, best-tested features per release or per iteration. Only the entire team can get the job done best, at least cost. Let me repeat that: only the entire team can get the job done best, at least cost. Let your teams of programmers actually be teams. Let them be cohesive and self-organizing, and reward them for that. Let them teach and learn from one another. Let them interrogate the business-side stakeholders and customers thoroughly and continuously, to figure out what the requirements really mean. Let them work creatively together, get inspired and imaginative together, and celebrate successes together.

By all means, hold them accountable! But hold them accountable at the team level. The team and their codebase are your software factory, not the individuals. If the entire team commits to an estimate, and they come up short, ask the entire team to devise a solution (better estimating, more spikes, more lunch n’ learns, more books, more training, more time in each others’ cubicles). Don’t second-guess or micromanage, even if you are a pretty darned good coder in your day. The new demands, the new practices, and the new technologies are different than what you remember. Let the team determine how best to deploy them.

Please also consider going the extra step of letting your teams sit in open team rooms. Preferably rooms whose walls are slathered wall to wall and floor to ceiling with white-boards. If you have read this far, then you deserve this prize: simply locating your team in a single open room (one that balances public and private space, but insists that real production code be written in a central, open workspace), you’ll likely double your team’s productivity. Amazing! There, don’t say I never gave you anything.

Once you’ve experienced what a genuinely empowered, self-organizing team can do for you, you’ll never go back. You’ll never treat your staff the same way again.