Fighting the tax that drains software teams

What’s the invisible tax eating away at software teams?

Technical debt?

Meeting time?

Rummaging through Jira?

All good bets. But tech debt isn’t quite invisible, not to the teams affected by it. Often it’s even identifiable, at least directionally (“those repos”; “that codebase”). Meeting time could be a symptom of the tax in question, but this tax is both bigger than and separate from time spent only in meetings.

This particular tax is best illustrated by a story.

Once upon a time there was an eager young go-getter, newly promoted to lead his company’s tech services arm. In his eagerness, this unnamed go-getter thought the best way to prove his merit was to be agreeable to most requests that came into his team. By itself, that wasn’t the problem. The problem was that he (ok, ok: I) met many of these requests with some version of “We’ll get right on it”—these were client requests after all.

You know how the story ends.

By agreeing to do too much, we gradually started doing not enough. We were winning client approval upfront (who doesn’t love to hear “Yes”?) and losing it on the back. (”What do you mean it’s not ready?”) We—I—let too many plates get spinning at once, which meant engineers having to context-switch multiple times a day, which meant longer hours and less to show for them, which torpedoed morale... rinse, repeat.

Call this problem the Tax of Yes.

Fighting the Tax of Yes

How does the Tax of Yes make itself known? Most often, by lagging indicators: missed deadlines, “process reengineering” (a death sentence if I ever heard one), burnout, resignations.

In our own case, what saved us was a practice borrowed from kanban: WIP limits.

Setting a work-in-progress limit is a simple, powerful way to relieve the Tax of Yes. With a WIP limit, you establish how much work you’re prepared to have in flight at any given moment. As new “urgent” requests come in, your answer is easy: “We’d be glad to tackle this. But since we’re at our limit, which of our current priorities should we stop?”

I also learned there’s no real magic in the actual figure you use for your limit. We picked 15—meaning, no more than 15 client requests would be worked at any one time. (Yes, some people pushed for the number to be 42. But 42 is a tad too large for a limit.)

Why 15? I don’t remember, and it doesn’t matter. The important point was that we’d establish a ceiling for active work, and we worked to keep things at or under that ceiling.

How personal WIP limits help a team work

WIP limits are a tried and true method for surfacing bottlenecks. While the concept originated with Kanban, it works regardless of your process. In Kanban, WIP limits are typically assigned to each work phase (e.g. To Do, Doing, Done). But the same idea can be applied to people.

Capping the amount of work in progress is sensible for a number of reasons. WIP makes finding bottlenecks easier—in this case, who may be overloaded—and it affirms the simple fact that trying to do too much at once leads to less actually getting done, and more team frustration.

The simplest method is to set a limit on the number of tasks assigned to any one person. Socratic's Capacity shows how each person's workload compares to your target WIP:

The real aim is to spot outliers. People and work will naturally fluctuate in and out of balance to some reasonable degree. What you're really concerned with is those people who are over your ideal WIP, or significantly under—say by 25 percent or more.

“If you want something done,” runs the old saying, “give it to a busy person.” The idea being that the busy person has no choice but to prioritize and knock it out. That’s cute, but pretty quick, those busy people get tired of having more stuff dumped in their laps.

A personalized WIP limit recognizes a different truth: more work usually only means less done.