Mar 12, 2022·edited Nov 20, 2022Liked by Tim Casasola
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.
>> 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.
>> 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.