Background to the use case
At the beginning of March 2024, I was lucky enough to join the very first OrgTopologies™ training course in France with the two co-creators Alexey Krivitsky and Roland Flemm.
OrgTopologies™ map
As is often the case, ideas evaporate after training courses. However, I had the opportunity to use this beautiful tool just three weeks later, during a workshop with a group working on a banking domain's information system. The scope of this domain was account management and the management of different payment methods (SEPA; IP; Virement Gros Montants...).
The people working in this area bring together a range of fairly traditional skills, such as Business Analysis, programming in different languages, and Ops. These areas of expertise are sometimes in the same team, and sometimes in separate teams.
Setting the scene
Before the workshop, the sponsors requested to identify ways of "being more agile". I shared with them that gaining fluidity and the ability to change priorities was a way of qualifying and quantifying "being more agile".
I began the workshop by telling the story of a startup I know in the C3 archetype. This startup was launched in 2013 by its two founders, who did everything for their first customers. As it grew, the startup changed its structure and ended up with several specialized teams, losing the global vision of the product and the initial fluidity. To illustrate the Y0 archetype, I evoked the caricature of the security expert who forbids everything to everyone.
Next, I suggested that participants map out their current teams, working in groups to share their views on the place of different teams. To do this, I briefly explained the map using a 2x2 version of the map (showing only no team/team and outputs/outcomes) and then went into a finer level of detail with the map of the 16 archetypes in a 4x4 matrix.
The only people present were managers. Developers were not present. So we clarified the objective, which was to generate ideas for improvement. As many people were absent, I didn't want participants to commit to action plans involving those who were not present.
The sub-groups raised subtle questions about the granularity of the definition of "Products". On the one hand, talking about "Products" that are too small (SEPA Transfer; IP Transfer; Large Amounts Transfer...) leads to very local optimization; makes us lose sight of the global vision; leads to the accumulation of work lists, queues, the need for a layer of coordination and priority arbitration... On the other hand, talking about "Products" that are too big (the Bank) becomes too abstract and makes employees lose touch with reality.
I let them determine their approach to read the map, to encourage their involvement in the workshop, rather than adopting a "trainer" posture, which was not on the agenda.
As a result, several tickets were placed at level B (team of teams or meta-teams, multi-functional and multi-technology) when it would probably have been wiser to place them at level A (group of teams more or less focused on distinct functionalities and areas).
Other debates arose around the boundaries between columns 1 and 2 or even 3, which I have steered towards the "lower" archetypes to keep improvement options more visible.
The groups placed their tickets on the shared board and discussed to align their points of view.
I launched a few discussions around certain teams identified as A1 or A2; B2 or C2, but decided not to waste our time on unimportant details for this first workshop.
The participants appreciated this graphic representation, even if they didn't make any major discoveries, as the map was already partly in their heads.
Next, we drew lines to clarify the interactions between the different teams, which will be invaluable for the idea generation that follows.
Based on these tickets and links, participants then discussed their options for improving and restructuring the teams in order to progress towards the higher-level archetypes, towards the right upper corner of the map.
We can see here the grouping of three teams together (Business Analysts + Programmers + Ops), three times, as well as splitting an Ops team to quickly share its expertise. Ultimately, this should lead to the creation of multi-functional, multi-technology teams with broader scopes of responsibility and autonomy than initially envisaged.
I didn't reveal my magic trick until the end of the workshop, only then mentioning that I had used the Org Topologies map.
To conclude the workshop, I proposed a few questions for reflection, with a round-table discussion so that everyone could comfortably express themselves:
what did the workshop reveal to me?
What did I learn?
Knowing that many people are absent, what could MY next action be (tell them about the card; repeat a similar workshop in a few months' time)?
How do I feel now (confident; curious...)?
Conclusion
With this material produced, Roland Flemm subsequently helped me to clarify several points related to the map that emerged from the workshop, enabling me to better understand the map and improve future workshops.
We've started a movement with a fairly simple workshop thanks to the map. We now need to maintain this momentum and support our teams in moving towards these higher-level archetypes.
And you, in what context could you use this map?
