More on Thermodynamics and Organizational Batteries
All of this undelivered work is a source of stress for the organization. There is almost always tremendous pressure to deliver these requirements. That pressure may be expressed a few different ways. It could be monetary pressure, expressed in terms of financial obligations. It could be emotional pressure, expressed in terms of a stakeholders eagerness to deliver to the expectations of the market. So the very act of “storing” work like this creates a sense of pressure within the organization that demands to be released.
So let’s look at how we might release that stored potential. In the software world the mechanism for expressing requirements is a team of people who do the work. Of course not all teams are created equal. Some teams can accomplish work with relative ease, and other teams are only able to deliver with a considerable amount of resistance. I like that term ‘resistance’. Some teams use practices that help reduce the resistance of work flowing through the team. For example, there are teams that use continuous integration with their version control in conjunction with practices like test driven development. Using these practices the team can deliver code relatively easily compared to teams that don’t use these practices (teams that don’t use these practices usually have hand-offs and other impediments that slow them down).
Of course in the real world it’s not uncommon to find that we have our wires (or teams or value streams) crossed:
And of course, not all teams can carry the same amount of work due to resistance, so we’ll have to account for that to:
So, if we know that we have teams that have high resistance (many impediments) then we can also infer that, like a wire with high resistance, the work will not travel as far in a team like this. On the other hand, a team with low resistance will be able to have a large amount of work flowing smoothly. That’s assuming these metaphors/models hold true. So, what practical utility can we derive from this? First, if the team can be characterized as high-resistance (for whatever reason), then its harder to get the work from our battery to flow through it. So we can either reduce the size of the work, or we can increase the frequency with which the team restores it’s work from the battery. In essence, the team could either process smaller units of work or they can shorten the duration of their iterations (i.e. shorten the length of the pipe).
So far, this model has explanatory utility. I can use it to describe how a system might work and to describe certain functions or dysfunctions of that system. That’s useful for sharing ideas and helping others to see the system in a constructive way. However, with some validation, I think this model can have predictive utility as well.
For example there are many subjective and objective measures that we could use for understanding the size of a battery and its impact on the emotions of the team doing the work. It’s not a huge stretch to incorporate the notion of polarity here. We can have positive and negative emotions – why not have positive and negative attributes for our wires/teams? We can also use subjective measures to assess the impact of resistance or impedance on a team. All of this is testable.
At this point I’m guessing that you’re probably in one of two camps:
Hey, this is really cool, I might be able to use this.
Dude, you are full of pop-physics BS
Welcome to the fringe. That’s right, welcome to the island of misfit ploys. This is where the interesting ideas are. This is where the fun stuff lies. It takes a little courage to put out ideas like these. Like most models it’s going to be wrong. After all, it’s the peculiar love-child of three wildly different domains: physics, dog-training, and organizational transformation. I have to admit that even for me it’s a stretch. I guess that’s what good though leadership really is – taking genuine risks with esoteric new combinations of ideas and putting them up for review.