(Team Design) Minimum Size, Minimum Participants, Maximum Capacity: Holons
Consider three stairs of standard dimensions.
This should not be difficult to visualize: I’m pretty sure every town, city, or community has at least one stairway with three steps.
Obviously, they were created to facilitate pedestrian traffic from one elevation to the next, but in the eyes of a skateboarder or similar athlete, the stairs represent an athletic and acrobatic challenge.
A canvas, if you will, upon which they might engage in acts of improvisational creativity.
Taking nothing but memories, leaving nothing but aluminum, as the saying goes.
Within this exist three constraints, worthy of consideration:
- minimum size
- minimum participants
- maximum capacity
Minimum size: the canvas itself must facilitate adequate physical activity.
For example, in order for a skateboarder to achieve enough speed to jump down three steps, they are likely going to need about 30 linear feet (~10 meters), ideally.
Likewise, in order to land safely, at the bottom of the stairs, they’re probably going to need about the same empty space at a minimum, hopefully more.
Stairs are usually at least 6 or 8 feet (~2–2.5 meters) wide, so from there you get a basic idea of the minimum size in terms of an athletic canvas.
As it is, this translates pretty well to a skateboard ramp or a swimming pool, as the minimum sizes are about the same: 1,100–1,500 square feet (139 square meters) or so.
Minimum participants gets bit more tricky. Technically, all you really need is a single skateboarder, but in general that depends upon the participants’ intrinsic motivations.
Observing skateboarders and their ilk in the wild, one quickly discovers that they almost never session alone. More frequently, they are in groups of three to five, and they play off one another in a collective commitment to inspire one another towards ever greater acts of athletic ability.
In my observations, the minimum is two, more ideally three. Maybe five. Diminishing returns begin at seven or more.
Consider a stairway of three steps, and two to three skateboarders.
One jumps on his board, kicks twice, does the trick down the stairs, and rolls away. It takes about eight to ten seconds, and then the next one follows, and so on.
This would represent an extremely high-tempo session, which is not uncommon in the context of the habitual need to get in and get out quickly before security or the police arrives, but the point is: a high-tempo session with a small number of participants enables everybody to experience adequate athletic engagement.
Maximum capacity demonstrates that in practice, there IS such a thing as too many people in a single area.
I find that the quality of these sessions begin to diminish after seven to ten participants, simply because there will always be somebody who is not sufficiently engaged, and they tend to wander off and start skating on something else; an adjacent canvas.
Of course, this is metaphor.
Minimal canvas (domain size)
Minimum participants
Maximum capacity
I should not have been surprised to realize that these observations translates fairly well to many other domains, inclusive to software development, grassroots teams, ad hoc collections of hackers, etc.
Minimal canvas (domain): it’s important for the team to select a footprint which is realistic to their endeavors, or else they will either become frustrated, or find that they are in competition with other groups trying to use the same space.
Indeed, this is my contention with large public skateboard parks: they represent a profiteering orientation circa 1977, and does not actually reflect how skateboarding exists in the wild.
Skateboarders in the wild consume challenges in far smaller increments, and in sizes better calibrated to the size of their diverse, ad hoc groups.
By contrast, a large public skateboard park is basically one huge canvas expected to be shared among many participants, which creates usage contention (overly large domain canvas).
There will be small pools of participants are focusing on specific areas, but inevitably there’s the guy on a bicycle or skilled skater who tears through the entire park, knocking kids down.
The author would like to acknowledge that he is one of these people, in the spirit of full disclosure and transparency.
That aside, the size of the canvas should be ideally calibrated to the capability of the team, and in the context of software development, this normally takes the form of a properly defined scrum team.
The properly defined scrum team is one which is responsible for a specific domain of technical and functional capability, which enables them to execute with effectiveness, without being overextended.
Likewise, properly defined scrum teams are ones which are not forced to share a particular domain space, for that causes massive confusion.
In the context of software development, a properly defined scrum team is typically three to five people, specifically focused on one particular functional or technical capability.
Why? Basically: the more members you have, the more communication channels that require ongoing maintenance, which creates cognitive/social contention.
This is likewise true among highly effective grassroots advocates. Or hackers. A finite domain space, and a finite team; the two properly calibrated.
Which brings us back to reconsidering maximum capacity, in the context of the metaphor being applied to software and grassroots domains.
Consider three skateboarders who have found a really exciting place to skateboard, and then they tell their friends.
Suddenly, there’s 30 kids trying to skateboard within an area that can only really facilitate seven to ten maximum participants, and tenuously at that.
Of course, the overflow participants begin seeking out challenges within the adjacent space, while concurrently contributing to contention for the resource.
This phenomena is so frequently prevalent that it’s nearly a cliché: Too many kids show up at a skate spot, and they get everybody busted because they start skating in an adjacent area.
This is likewise true within both software teams and grassroots advocacy groups.
Indeed, this is why we say that growth is sometimes more dangerous than any other phenomenon which may face a team, although that might seem counter-intuitive.
We are conditioned to believe that any problem can be solved with more resources, which typically translates to money and people, but that’s completely untrue.
Logically, this is akin to concluding if two aspirin will make your head feel better, then 30 aspirin will really make your head feel better.
Or, as I like to say: build a man a fire and he stays warm for the night, but if you catch a man on fire he will stay warm for the rest of his life.
Consider a high functioning grassroots political team of three participants whose efforts are well calibrated to the problem space, for example: the relationships which might exist between the homeless and the residents of a specific neighborhood association of finite size.
This might be working extremely well, until 30 additional advocates are added to the mix.
The same phenomenon occurs: there is resource tension within the domain space, and therefore advocates become compelled to look for things to do within the adjacent space.
Keeping your teams properly calibrated is an act of intentional discipline, and therefore requires leadership.
Diplomacy, even.
Let’s return to the skateboarding example. Consider how this might play out as a skateboarder, where you and two friends are enjoying three stairs, and seven additional skateboarders approach.
What are you going to say?
Of course, you could try to tell them to get out of here, but that will play out just exactly as you might imagine.
Likewise, if you and 2 coworkers have been satisfied with your stewardship of a domain of software functionality, and you learned that management has given you 7 new eager programmers, you can’t exactly say, Get the out of here.
So what do you do?
Stick or Carrot? Which approach is most effective?
I used to run a nonprofit, and we had over 1,700 members who were participating in grassroots political advocacy, and it was a royal pain in the ass.
We certainly accomplished a lot, but I’ve spent the past 20 years ruminating on how I might’ve done things differently, and here is one thing I’d have done differently:
I would’ve been a lot more disciplined about curating, igniting, and helping people learn how to sustain highly effective teams within communities of finite size.
In practice, this would’ve looked like two to three people of roughly evenly-diverse personality distribution and experience, focused on a particular domain space, such as a neighborhood association.
What I did learn, however, is that it’s pretty effective to invite overflow participants to explore adjacent areas, and not from a place of disingenuousness (carrot vs stick).
When we would receive an influx of participants, I learned that it was effective to encourage them to explore something nearby, which might engage their curiosity, and in that manner helps keep certain working groups from becoming overstaffed.
This meant that we needed to be aware of the various domain spaces, staffed and understaffed, which would enable us to defuse resources towards understaffed areas, to ensure that there was a proper calibration between minimum canvas, minimum participants, maximum capacity.
If properly calibrated, these small little teams (holons) are wicked resilient, and fairly immune to disruption.
An obvious management challenge: as indicated previously, most people are conditioned to believe that more resources will always address execution challenges, but that’s completely false.
Sure, money helps, but sometimes money seriously inhibits and can even disrupt.
I will discuss this in a separate blog, but the team needs to learn that they are able to achieve significant results by properly making use of the resources they have, and part of that is the wisdom to realize how a massive influx of resources, inclusive to money, would significantly disrupt execution and team continuity.
Here’s an interesting insight: if you would like to disrupt the capability of a small team, don’t starve them, flood them with money or resources. Nine times out of ten, they completely come undone.
Within the context of computer security, this is not unlike what is referred to as a buffer overflow attack. Without going into too much detail, imagine it’s Saturday morning, your mom has a hangover, and she has only about as much patience as three phone calls before 7 AM.
A buffer overflow attack might take the form of 1,600 phone calls before 7 AM on a Saturday morning, with the manifestation of your mother losing her temper.
There is indeed such a thing as too much, and that is absolutely true of resources, including money.
Again, I will talk about this later, but it’s helpful and productive to reward participants for their heroism and creativity under extreme circumstances, however: this does not mean starving them before this extreme performance.
Give them what they need to be successful, but don’t fall for the myth that infinite resources result in infinite success. Experience will show that diminishing returns are achieved very quickly.
Give the team what they need to survive, and really reward them for their creativity in support of delivering upon key performance indicators.
When these small little teams overlap in just precisely the same way, they create something akin to a fabric, whose aggregate capability is of irresistible ability to effect change, resistant to disruption from within and from without.
However, as previously noted: keeping these teams within proper performance parameters requires wisdom, discipline, and leadership.
With diplomacy and finesse, this can be accomplished without manipulation or coercion, for there are ample pools of opportunity of proper size within the aggregate landscape.
Stay tuned, or for more information now, head over to www.214alpha.com.
