It’s all about ‘the people’. How often do we hear that expression when we discuss projects, changes and IT implementations? In our first blog of 2017, we ask industry expert Dr. M.N. Key to explain a little bit more about tribalism in organizations.
ITSM and the Monkeysphere
Imagine your first day in a new IT service management (ITSM) job, waiting in reception, fidgeting with your jacket sleeves, uncomfortable in the plastic chair. “Come this way please” beckons a member of staff.
Once alone in a brightly-lit white room the staff member gets a tape measure and wraps it around your head stating “Twenty-three inches, 180 Dunbars.” Your picture is taken, your ID card issued, and you are led into an office of 150 people.
What on earth is happening?
Enter the Monkeysphere
In the 1990s, the anthropologist Robert Dunbar suggested a correlation between primate brain size and average social group size. His theory was later built on by others, suggesting that there’s a cognitive limit to the number of people with whom one can maintain a stable social relationship:
- Malcolm Gladwell discussed this “Dunbar Number” – a suggested cognitive limit to the number of people with whom one can maintain stable social relationships – in his popular 2000 book The Tipping Point: How Little Things Can Make a Big Difference. He described the company W. L. Gore and Associates, now known for the Gore-Tex brand. There, by trial and error, the leadership discovered that if more than 150 employees are working together in one building, different social issues will occur
In 2007, David Wong took the theory and applied it to society and work, in his essay What is the Monkeysphere?
This Monkeysphere has important implications for work, especially in large complex organizations and organizational set ups such as ITSM, where staff might have to work with more people than can safely fit inside their Monkeysphere. In particular, the issue is exacerbated by the take-up of social platforms such as Twitter and Slack where individuals not only have to physically face off to more than 150 people, they also have hundreds (or thousands) more online avatars to deal with.
How IT service management is a collection of Monkeyspheres
ITSM is by popular definition a collection of people, processes, and technology working together for the greater business good. The people are organized into functional, process-oriented groups such as service desk, change management, and problem management, and will also deal with other people who might be developers or in other IT operations roles. The size of these groups can be, either deliberately or unintentionally, aligned to Dunbar’s Number so that co-operation inside the team works well and good relationships are formed.
The problem starts when a dependency emerges between two discrete teams, such as problem management needing change management to approve a fix, or change management being responsible for causing a problem. Such a clash of Monkeyspheres is interesting:
1. When one Monkeysphere needs another to complete a task, phrases such as “We’re not a priority to them!” and “They just don’t understand what we need!” emerge.
2. If a member of one Monkeysphere has made a mistake and this is discovered by the other Monkeysphere, then the first Monkeysphere will go to extreme lengths to cover up and protect the mistake, and the other will go to extreme lengths to persecute the member of the other Monkeysphere.
Thus Monkeyspheres help teams or “towers” to work better internally, but can cause issues when these towers have dependencies and must interact. With these dependencies unavoidable in an ITSM organization because one process will more than likely traverse multiple towers.
So is there another answer to tower-based ITSM?
Inverting the ITSM Organizational Matrix from Towers into ‘Tribes’
Instead of having an ITSM process traverse multiple towers via inter-Monkeysphere dependencies and interactions that are most likely friction-filled, some cloud-native organizations such as Amazon, Netflix, and Spotify have taken a different approach.
They seek to create autonomous Monkeyspheres called “tribes” which have as few dependencies on other teams as possible, with constant efforts to eliminate any dependencies that arise. Each tribe is focused on delivering a product and has its own approach to managing changes and problems without having to rely on a change or problem management tower. Interactions between the tribes are limited to the sharing of skills and experiences via “guilds.”
The acknowledgment of the social impact of Monkeyspheres, and the resulting organizational approach, has helped these and other companies to produce high-quality online systems with low outage rates and high rates of change. And organizations such as Amazon, Netflix, and Spotify consequently score highly (in terms of performance) in research.
Reduce Monkeyspheres with the Cloud
As Gladwell reported in The Tipping Point, changing the organizational structure away from towers and into tribes is one way to acknowledge and work with the limitations of Monkeyspheres.
Another approach, which is one of the factors driving the take up of cloud, is to recognize that if you consume a cloud service such as Infrastructure-as-a-Service (IaaS) through a programmatic API then your interaction with the Monkeysphere that produces that service (that is, the cloud service provider) is limited and likely to be friction free.
The alternative to using IaaS is to have an in-house Monkeysphere dedicated to buying, provisioning, patching, and managing infrastructure. It has been this way for decades and is now more and more likely to be considered a bad model in light of more modern alternatives. If it’s typical for a corporate server deployment to take weeks or months, then you can imagine the friction this causes between two competing Monkeyspheres.
Understand your own Monkeysphere
We all have our own Monkeysphere but thankfully, if aware of it, we can better control it. For instance, we can choose our own relationships and, more dramatically, the organizations for which we work.
However, if you are currently working in a traditional, tower-structured ITSM organization it’s inevitable that tensions will arise as non-sympathetic Monkeyspheres collide. Things will change over time though, as the success of DevOps in particular helps to change corporate approaches to ITSM and organizational structures in particular.
And so ITSM practitioners have a choice: to continue to work within the status quo and patiently await the change, to elicit organizational change within their organization, or to join cloud-native companies which already use the tribe approach. What are you doing?
Dr M.N. Key
