I'm a bit late to this party but I had a few thoughts.
The first is around staffing work to the team (bring the work to the team, not people to the work).
In a dynamic and fast moving company there is a need to scale up and down value streams. I like to think of it as - for a given period (year, quarter, etc) we want to fund this team or set of teams with the objective of achieving X. However next quarter we might need to invest in another set of problems.
So at any given moment, I want to see each team, their roles, and the folks mapped to them, but I also what are the capabilities of these teams.
I think of teams as t-shaped (just like the individuals on the team). The company might want to invest in a few different areas. I want to see what teams are best suited to tackle these problems. You can imagine a team that says here are our current roles, but also here is what we are passionate about, the problems we like to solve, and our capabilities and skillset. This is also helpful when looking to level up teams, what skills should be helping our teams learn.
The other thought I had was more about folksonomy vs taxonomy. Especially when you are having everyone in the company update the structure, what you will find is that everyone has a slightly different mental model of how best to categories or assign things.
What I think would be cool, would be a tool that would support multiple views of this data structure. Some might want to view in a way that maps to holocracy other might want a view of leadership, others how teams interact. I think having one size fits all is part of the problem. I feel the same way about IDEs and project structure of codebases. Some love hierarchy others want more flat structures.
What I see in most big and medium companies nowadays are three layers of representation:
1. The traditional org chart (always present).
2. The fuzzy, helpless, mostly useless Spotify-like organizational layer of squads, tribes, chapters, guilds and so on (almost always present because is a proxy of "doing Agile").
3. The real value stream of work, with cross-team and cross-department, cause of a million dependencies and coordination overhead (never, ever represented in any form).
For this reason I don't really buy into the idea that the most granular item in a networked representation of a company should be the team: at the moment I'm only seeing teams with shared people in them, meaning that each team member of any team also work for other two or three teams.
So, in order to describe a real value stream - which is what wins the bread for the company at the end of the day - you should be connecting people first (using their primary domain knowledge or skill as a "marker", not their role), and infer where team should "emerge" only later.
The problem I see of mapping out an organization starting from teams is that teams you are going to find are almost always a by-product of the traditional org chart even when they are represented with a hybrid, pseudo-Spotify, matrix-based model. What's worse is that layering a Spotify model on top of the traditional org chart is going to fracture the value stream even more.
What you are going to find has biases and a certain level of organizational debt already built-in.
So, back to your features.
"1. I can see my entire company visualized as a network, where the nodes are teams.": yes, and there should be a more granular level to start with, one taking into account people.
"2. I can see dependencies between teams and the nature of each dependency.": yes, and for tat I would borrow the activity/knowledge/architecture types of dependencies from Dominica DeGrandis' Making Work Visible.
"3. I can see all decision rights each team owns.": not sold on how much this one should be relevant, decision rights sits at the level of the traditional org chart most of the time, it's something I would add later (I'm thinking in terms of actually doing this as a real mapping exercise).
"4. I can see the roles that make up each team.": yes, and see point 1., I think that domain knowledge and skills are far more important than roles.
"5. I can see the team member that fills each role.": yes, see above, I would put this one earlier in the process.
"6. Anyone can update this network instantly.": YES, PLEASE.
"7. Anyone can see all changes made to the network, sort of like git blame or Google Docs version history.": I WANT IT ALL.
"So, in order to describe a real value stream - which is what wins the bread for the company at the end of the day - you should be connecting people first (using their primary domain knowledge or skill as a "marker", not their role), and infer where team should "emerge" only later."
^I love this. Hadn't thought of it that way. If the org design we're trying to create is optimized for delivering value, I agree.
I guess I implied this in the vision I was describing: the team, by default, is already organized around value. This is getting me to realize a flaw in this vision: this hypothetical new org chart only serves orgs already organized around value. The challenge is if the org's teams aren't organized around value. This org chart I'm proposing wouldn't fix that because they would recreate their own traditional structure, to your point.
I'd love your take on this David: when you consult with orgs that aspire to reorganize their teams around the work, at what point do you start to redraw the org chart?
Disclaimer: I am always dealing with teams that are definitely NOT organized around value and I have to build my case toward organizations that are not ready for what I want to tell them.
Lately I've been working with lots of big companies in traditional sectors (telcos, banking, insurance): they are usually at their third or fourth round of "agile transformations", so I always inherit at least one or more broken "middleware" structures ("Spotify Model" or SAFe and LeSS-inspired).
Let's say that "aspiring to re-organize teams around the work" it's something that I as a consultant aspire to, but most companies don't.
It takes a lot of work and time to gather the data and build the case to make that aspirational goal evident to a company. Implementing it it's another story that I can't yet tell 😀
I've seen glimpses of it, like reshuffling team members and shifting from purely functional to goal-oriented structures (for example: re-teaming around churn and revenue, while they were previously organized toward specific customer targets and market channels), but never saw something like that happening at scale. Yet.
Usually I have to do months and months and months of "archeological" work between many teams and "tribes" in order to observe and dig out evidence of how a company really works: at that point what I propose as first steps are changes in the communication flow between teams (less meetings, better meetings, better usage of tools, common roadmaps) and changes in the workflow and practices inside and between the teams (usually from Scrum to Kanban, or an integration of the latter in the former).
Over time better comms flow and better workflow lead to a re-framing and re-shuffling of teams and the "middleware map" might be re-drawn.
I see the traditional org chart as something with a different purpose and speed of change: it ends up being the very last thing that gets updated, and I'm fine with that, provided that you have alternative views for each of the different layers of the org.
Having seen how traditional org charts get mangled, I'm more than happy not to touch one ever but as you have topological and topographical maps, I think that a healthy organization should have three maps:
1. one for hierarchy (traditional org chart)
2. one for structure (middleware stuff like "Spotify model", SAFe, LeSS)
3. and one for flow (I like very much the concept of Team Topologies for this level because it can be mapped against a value stream once you spotted it with Lean/Kanban practices).
I think the map you are proposing could be a merge of 2. and 3.
P.S. My way of working obviously exposes me to the risk of my work being snatched out by one of the big consultancy firms, those ones are usually more willing to do armchair organization design — but that's how I roll, I didn't get into this business to hide behind PowerPoint slides.
>> I can see my entire company visualized as a network, where the nodes are teams.
Exactly what I am looking for. But I want to zoom in and see people. I am wondering how to represent people who belong to multiple teams - say partial allocations to multiple product teams.
I'm a bit late to this party but I had a few thoughts.
The first is around staffing work to the team (bring the work to the team, not people to the work).
In a dynamic and fast moving company there is a need to scale up and down value streams. I like to think of it as - for a given period (year, quarter, etc) we want to fund this team or set of teams with the objective of achieving X. However next quarter we might need to invest in another set of problems.
So at any given moment, I want to see each team, their roles, and the folks mapped to them, but I also what are the capabilities of these teams.
I think of teams as t-shaped (just like the individuals on the team). The company might want to invest in a few different areas. I want to see what teams are best suited to tackle these problems. You can imagine a team that says here are our current roles, but also here is what we are passionate about, the problems we like to solve, and our capabilities and skillset. This is also helpful when looking to level up teams, what skills should be helping our teams learn.
The other thought I had was more about folksonomy vs taxonomy. Especially when you are having everyone in the company update the structure, what you will find is that everyone has a slightly different mental model of how best to categories or assign things.
What I think would be cool, would be a tool that would support multiple views of this data structure. Some might want to view in a way that maps to holocracy other might want a view of leadership, others how teams interact. I think having one size fits all is part of the problem. I feel the same way about IDEs and project structure of codebases. Some love hierarchy others want more flat structures.
Anyway, great article!
What I see in most big and medium companies nowadays are three layers of representation:
1. The traditional org chart (always present).
2. The fuzzy, helpless, mostly useless Spotify-like organizational layer of squads, tribes, chapters, guilds and so on (almost always present because is a proxy of "doing Agile").
3. The real value stream of work, with cross-team and cross-department, cause of a million dependencies and coordination overhead (never, ever represented in any form).
For this reason I don't really buy into the idea that the most granular item in a networked representation of a company should be the team: at the moment I'm only seeing teams with shared people in them, meaning that each team member of any team also work for other two or three teams.
So, in order to describe a real value stream - which is what wins the bread for the company at the end of the day - you should be connecting people first (using their primary domain knowledge or skill as a "marker", not their role), and infer where team should "emerge" only later.
The problem I see of mapping out an organization starting from teams is that teams you are going to find are almost always a by-product of the traditional org chart even when they are represented with a hybrid, pseudo-Spotify, matrix-based model. What's worse is that layering a Spotify model on top of the traditional org chart is going to fracture the value stream even more.
What you are going to find has biases and a certain level of organizational debt already built-in.
So, back to your features.
"1. I can see my entire company visualized as a network, where the nodes are teams.": yes, and there should be a more granular level to start with, one taking into account people.
"2. I can see dependencies between teams and the nature of each dependency.": yes, and for tat I would borrow the activity/knowledge/architecture types of dependencies from Dominica DeGrandis' Making Work Visible.
"3. I can see all decision rights each team owns.": not sold on how much this one should be relevant, decision rights sits at the level of the traditional org chart most of the time, it's something I would add later (I'm thinking in terms of actually doing this as a real mapping exercise).
"4. I can see the roles that make up each team.": yes, and see point 1., I think that domain knowledge and skills are far more important than roles.
"5. I can see the team member that fills each role.": yes, see above, I would put this one earlier in the process.
"6. Anyone can update this network instantly.": YES, PLEASE.
"7. Anyone can see all changes made to the network, sort of like git blame or Google Docs version history.": I WANT IT ALL.
David, thank you for your thoughtful response!
A response and a question below.
"So, in order to describe a real value stream - which is what wins the bread for the company at the end of the day - you should be connecting people first (using their primary domain knowledge or skill as a "marker", not their role), and infer where team should "emerge" only later."
^I love this. Hadn't thought of it that way. If the org design we're trying to create is optimized for delivering value, I agree.
I guess I implied this in the vision I was describing: the team, by default, is already organized around value. This is getting me to realize a flaw in this vision: this hypothetical new org chart only serves orgs already organized around value. The challenge is if the org's teams aren't organized around value. This org chart I'm proposing wouldn't fix that because they would recreate their own traditional structure, to your point.
I'd love your take on this David: when you consult with orgs that aspire to reorganize their teams around the work, at what point do you start to redraw the org chart?
Disclaimer: I am always dealing with teams that are definitely NOT organized around value and I have to build my case toward organizations that are not ready for what I want to tell them.
Lately I've been working with lots of big companies in traditional sectors (telcos, banking, insurance): they are usually at their third or fourth round of "agile transformations", so I always inherit at least one or more broken "middleware" structures ("Spotify Model" or SAFe and LeSS-inspired).
Let's say that "aspiring to re-organize teams around the work" it's something that I as a consultant aspire to, but most companies don't.
It takes a lot of work and time to gather the data and build the case to make that aspirational goal evident to a company. Implementing it it's another story that I can't yet tell 😀
I've seen glimpses of it, like reshuffling team members and shifting from purely functional to goal-oriented structures (for example: re-teaming around churn and revenue, while they were previously organized toward specific customer targets and market channels), but never saw something like that happening at scale. Yet.
Usually I have to do months and months and months of "archeological" work between many teams and "tribes" in order to observe and dig out evidence of how a company really works: at that point what I propose as first steps are changes in the communication flow between teams (less meetings, better meetings, better usage of tools, common roadmaps) and changes in the workflow and practices inside and between the teams (usually from Scrum to Kanban, or an integration of the latter in the former).
Over time better comms flow and better workflow lead to a re-framing and re-shuffling of teams and the "middleware map" might be re-drawn.
I see the traditional org chart as something with a different purpose and speed of change: it ends up being the very last thing that gets updated, and I'm fine with that, provided that you have alternative views for each of the different layers of the org.
Having seen how traditional org charts get mangled, I'm more than happy not to touch one ever but as you have topological and topographical maps, I think that a healthy organization should have three maps:
1. one for hierarchy (traditional org chart)
2. one for structure (middleware stuff like "Spotify model", SAFe, LeSS)
3. and one for flow (I like very much the concept of Team Topologies for this level because it can be mapped against a value stream once you spotted it with Lean/Kanban practices).
I think the map you are proposing could be a merge of 2. and 3.
P.S. My way of working obviously exposes me to the risk of my work being snatched out by one of the big consultancy firms, those ones are usually more willing to do armchair organization design — but that's how I roll, I didn't get into this business to hide behind PowerPoint slides.
>> I can see my entire company visualized as a network, where the nodes are teams.
Exactly what I am looking for. But I want to zoom in and see people. I am wondering how to represent people who belong to multiple teams - say partial allocations to multiple product teams.