The Honeycomb Model for Teams (And a fix to Agile Haiku #32)
"What injures the hive injures the bee." - Marcus Aurelius, Meditations, 6.54
(This article is part of an on-going series dedicated to developing Agile mastery. Each post offers value to students on this journey, however, there is an advantage to those who start at the beginning.)
I've worked with a lot of teams over the years. Less common, I've had the good fortune of building them from scratch. Mostly, I've inherited teams that were thrown together by someone else and needed some degree of adjustment and tuning. On very rare occasions, I've had to entirely dismantle teams and recast the talent. While dismantling may seem like a straightforward solution, it's the most difficult. It's disruptive and the knock-on effects are subtle and long-lasting. Whether starting from scratch, adjusting and tuning, or dismantling and re-building, there are several mental models I use that are common to each of these scenarios.
One of the mental models has to do with how I think about individuals and teams. The collection of strategies and tactics are bundled together in what I call the honeycomb model for teams. This model has evolved over the years as I've gained experience working with people as a technical lead, technical manager, executive, and eventually as an Agile coach. The effectiveness of the model is entirely dependent on how well the team architect knows the individuals who are or will potentially be members of a team. To illustrate, I'll look at the two dominant dimensions of the individuals and how to best to organize them as a team: Their professional expertise and personality characteristics.
Talent
I think of each team member is a hexagon. Nothing magical about this. You can use a pentagon, heptagon, or octagon if that works best for you. Teams can have a mix. I caution against using anything more than an octagon as it starts to look too much like a circle. Anything less than a pentagon lacks the sense of sided-ness the model needs. This will make more sense in a couple of minutes. (Keep reading!) The important characteristic is the number sides or interfaces each team member has.
For each side, I assign a characteristic about the individual and whether or not it's a strength or weakness. The assignments are dependent on the dimension I'm working to figure out for a team. If it's technical expertise (I'll get to personality issues next), one individual may be a strong C++ and Python coder, but less skilled in databases and unskilled with HTML and CSS. The strengths I code as green, medium skill as blue, and the others as red. I keep a legend as to what the colors mean for each individual on a separate sheet of paper.
Having done this, I then work to organize the individuals around the needs of the project as a latticework of, in this case, technical talent. As you might guess, I often print these out so I can arrange them on my physical desktop or whiteboard. This has the added bonus of "thinking with my hands" as I work out the various pairings. It's much easier to catch where I might be overlooking an opportunity or failing to fill a critical need. The map begins to look something like this:
This gives me a visual for how I might pair complimentary skills and plan for backup during employee vacations, sick days, or if I need to double up talent to solve an unanticipated challenge.
It also reveals how I might pair developers for mentoring opportunities.
Personalities
Matching professional talent is the easy part. Matching personalities is where the management gets interesting. Success depends on how well you know the people you manage as individuals independent from their work-life and professional expertise.
How well do you understand what motivates and frustrates them?
What is their tolerance for challenge and change?
How comfortable are they working with others?
Are they flexible and open to learning from co-workers or are they locked into being the expert or a rock star?
Where are they on the introvert-extrovert spectrum?
Do they prefer to work alone or as a team?
How do they perform under stress?
What stresses them the most?
Who are the connectors and who are the disconnectors?
The task is to find out who can or must work with who. If they must work together and there are potential conflicts based on history, then you have mapped out what to watch for and can work to mitigate any issues before they become problems. On this level, the team honeycomb map will look something like this, where the green are compatible traits, blue is neutral, and red is potential danger.
Of course, people are way more complicated than this. But I'm not a research psychologist, therapist, or Emperor (neither are you) so I'm looking for something better than good enough when figuring out the best way to organize people in to teams that will be expected to efficiently solve complex problems in as short amount of time as possible.
When you understand the people on your teams to this level, you can also factor in the degree to which they will need to interact with each other. In some cases, the interactions will be unavoidable. For the team illustrated above, the central figure may be the technical lead and will be expected to interact regularly with one or more team members that carry a risk for problematic communication.
Post Script
I don't write my posts in Substack. I write them in Obsidian and then cross post them to Substack. At this stage in life, it's unlikely I'll every break the pattern of keeping development separate from production. But lacking an automated CI/CD process for publishing on Substack, things sometimes get out of sync between dev, test, and prod. That's what happened with Agile Haiku #32. Haiku has an easily recognized rhythm and tempo so when I read the published post delivered to my inbox I caught the missing word in the first line immediately. Here's the now-published draft that should have gone out to subscribers:
All pieces and parts. Hub, spoke, and rim - push and pull. Together, they turn.
If you have any questions, need anything clarified, or have something else on your mind, please use the comments section or email me directly.
← Learning and Mastering the OODA Loop
Photo by Alexander Grey on Unsplash