To Shoot the Moon, Work Beneath a Ceiling

Understanding and respecting throughput ceilings is a prerequisite to maximizing scale and delivery of product development teams

Working as a management consultant, I move in and out of technology and data-focused units of large, complex enterprises. These organizations are always highly stressed, since nobody calls the cavalry until the situation is pretty grim. The specific circumstances of these scenarios represent a rich cross-section of market pressures, swiftly changing technical landscapes, difficult circumstances, and organizational dysfunction. One through-line I have come to recognize across many of these enterprises, however, is the lack of an established operational ceiling for simultaneous activity of the product development team. In the name of brevity, I refer to this as a ‘throughput ceiling’.

Why a Ceiling?

Nobody thrives in a pressure cooker. In order to capture the most benefit from the workforce, clear limits must be established for how much simultaneous activity any product development group can scalably metabolize. Metabolization of volume can be represented on a curve that shows increasing velocity followed by a steep drop-off as the team reaches saturation. As soon as saturation is surpassed, resources become exhausted, morale crashes, the strongest players head for the exits, and the spiral becomes self-sustaining. Optimizing throughput requires recognizing, understanding, and managing this resource utilization curve. The most important step to managing the curve is understanding and calibrating around the ceiling for simultaneous activity in the shop.

Agile Origins

I first became familiar with the concept of establishing and adhering to a throughput ceiling while making the transition to Agile about a decade ago. Like so much in Agile, this concept isn’t specifically defined or called-out by that methodology. Rather, the pragmatic, ‘from-the-resources-up’ process through which Agile was developed addressed this need organically. If there are only x number of SCRUM teams in the group, each has a historically-established velocity of y, and the authority to self-manage scope in their own sprint z, a throughput ceiling is automatically generated without being formally recognized as such. Whether or not leadership is able to appreciate, respect, and operate under this ceiling is — interestingly — among the key attributes that define whether or not Agile can be successful in any enterprise. More about leadership and ceilings, later in this post.

…Even in Waterfall

Working on large data management projects within global Fortune 50 enterprises, I seldom have the freedom to mandate completely Agile project methodologies. These companies are simply too large, process policing is too entrenched, the shared service matrixes too layered, and the cross-project inter dependencies too tightly coupled to tolerate the kind of meandering path that is among the key attributes (and strengths!) of Agile. But just because we can’t push our methodology any further than tepid scrummerfall doesn’t preclude us from establishing and benefiting from clear throughput ceilings. Establishing these guardrails really has more to do with the rules of engagement between leadership and its workforce than it does about specific product development methodologies. I have deployed throughput ceilings in enterprises across the gamut, from the most waterfall right up to fully Agile, to excellent effect. A waterfall methodology makes this management process less convenient, but that’s no excuse to throw in the towel.

Practical Application

In practice, the throughput ceiling manifests itself as a planning and tracking methodology that compares resource bandwidth against ongoing demand. Trusty ‘ole MSProject, with its Resource Leveling functionality, is a great way to get started. A model is established to juxtapose bandwidth vs. demand, and squawk as soon as an overage is detected. Recognizing this problem, senior leadership has the right and responsibility to mitigate risk by unwinding the overage. Typical unwinding activities include:

• Shuffling order of operations across projects
• Reorganizing resources against the project portfolio
• Negotiating scope in order to shorten duration of specific projects
• Canceling underperforming projects

All of these are healthy activities for the enterprise to engage in, anyway, and it is a happy byproduct of throughput ceilings that they engender these conversations. Compare this to a world without these ceilings, wherein leadership continues to ladle-on the work, unceasingly dividing the attention of already frantic resources until no progress can be effectively generated amid all the task-switching churn.

All of these are healthy activities for the enterprise to engage in, anyway, and it is a happy byproduct of throughput ceilings that they engender these conversations

Project managers have been leveraging these techniques for years on individual initiatives. Establishing throughput ceilings simply scales this philosophy up to the departmental level.

A Question of Leadership

Establishing and managing throughput ceilings can be accomplished at the departmental/program level, but it is with leadership that the rubber hits the road. Either leaders will understand and accept the physics around available team bandwidth, or they won’t. Those who refuse to embrace these concepts mandate ever-more parallelization in the name of increasing velocity to match incoming demand. What they fail to recognize, however, is that once they pass the saturation threshold, efficiency plummets and with it their bottom-line throughput.

Successful leaders recognize that in order to shoot the moon, they must establish, understand, and adhere to throughput ceilings across their enterprises.