I work for a large company. Number 2 is the most appealing and intuitively just seems right. And yet I don't see how it could work in a company with complex roadmaps and dependencies among teams.
The reason it doesn't is because the companies that produces those team structures with complex roadmaps and team dependencies focus on better coordination (more meetings, time spent planning etc. ) to fix poor collaboration (asking and getting help when you need each other).
a follow-up here could be to explore how this feels, is supported/managed from people outside the "team". Interactions will be different and most organizations are setup for one of these. Enabling a team thus impacts a lot of people "outside" the team.
Hi John - I found this really eye-opening - I really hadn't considered this from the point of the underlying beliefs before. This finally make sense of some of my past experience, and helps enormously with my current situation :-)
I've twice had the experience of moving to a backlog-centric team after being part of a highly successful mission-centric team, and struggled both times. The first time I had to (re)learn the backlog-centric ways of working, and they felt like a big step backwards, but I had to adopt them to become an effective member of the team. The second time, I was coming in as an engineering manager trying to introduce mission-centric practices to backlog-centric teams, and causing a lot of trouble and pain in the process!
With this new insight about beliefs, I can now make sense of this...
In particular the belief that developers should only take on well-vetted and validated work (and this usually goes hand-in-hand with a belief that work should be prepared such that any developer can pick up the next ticket) - once you've worked in a mission-centric team, these beliefs feel like anti-patterns - but they are fundamental to making the backlog-centric team work, and so you mess with them at your peril! The level of stress and the reaction can be intense - for example if you do anything that prevents the slick functioning of the grooming process, some of the team may almost think you are out to kill them.
With time, you can replace this pair of beliefs with a preference for working x-amigos style for collaborative understanding of the problem and generation of possible solutions - and once everyone is on board with that, no one wants a whole-team grooming session or tasks that are ready for any developer ever again - but it can take a few months to get there!
(I had one question also - at the end of the backlog centric team, did you mean that developers' responsibility is to "build the right thing right", or just to "build the thing right"? In my experience, the backlog-centric team's processes aren't optimised for identifying the right thing to build - they kind of assume someone else has done that for them...)
My team's paradigm is 1, but I feel the disconnect between designers and builders impairs our results. Is there a way to move towards 2? What does it take?
In my experience #1 is not sustainable as it accumulates tech debt (and product debt).
#2 has probably the best potential for keeping tech / product debt in check as the whole team feels the pain of it and there’s a shared understanding of the source and the cost of the pain.
Awesome summary! I got a feeling that the Engineering-Centric category will get more popular in the recent climate of recession & layoffs. That is exactly the type which can look more 'lean and efficient' from the top. I'm not sure that's true most of the cases though, especially for more old-fashioned companies, just as you wrote down there - great for FAANG, risky for non-tech companies.
John, incredibly clear and succinct. Just sent this to our CTO and his VPs as we're undergoing a reshuffling of teams to better support our strategy. Gold. Thank you
My product team falls into the Team and Mission-Centric bucket. We've worked in other types of teams. From experience, the Team and Mission-Centric types are the most enjoyable to work with because of trust being built, friendships, passion for the mission, aligned principles and values, and of course, leaning into conflict. This type of team falls into an empowered team, and these outcomes are powerful and more profitable for everyone.
Could you give examples of companies that following these models ? For e.g I dont know any successful company that follows model 1. ditto for the 3rd model. But I could be wrong
For me model 2 is best every time even though I agree it’s variable to project and team. The con I believe is that great collaboration is difficult to facilitate because most don’t know: (a) at what points in process do I need a collaboration? (b) what exactly do we do while together/how do we make progress vs talking in circles? (c) whose responsibility is it to lead / answer a and b. And in figuring that out people may likely panic about progress and/or get offended about ownership. But it’s the best if you get someone comfortable to lead.
Once again, so terribly well put.
I suspect the first two may also reflect different stages in a product lifecycle. I think the last one is nonsense as a general approach.
I work for a large company. Number 2 is the most appealing and intuitively just seems right. And yet I don't see how it could work in a company with complex roadmaps and dependencies among teams.
It can work.
The reason it doesn't is because the companies that produces those team structures with complex roadmaps and team dependencies focus on better coordination (more meetings, time spent planning etc. ) to fix poor collaboration (asking and getting help when you need each other).
a follow-up here could be to explore how this feels, is supported/managed from people outside the "team". Interactions will be different and most organizations are setup for one of these. Enabling a team thus impacts a lot of people "outside" the team.
This sythesizes what I have observed but failed to put to words myself. Completely spot on. Thanks!
Hi John - I found this really eye-opening - I really hadn't considered this from the point of the underlying beliefs before. This finally make sense of some of my past experience, and helps enormously with my current situation :-)
I've twice had the experience of moving to a backlog-centric team after being part of a highly successful mission-centric team, and struggled both times. The first time I had to (re)learn the backlog-centric ways of working, and they felt like a big step backwards, but I had to adopt them to become an effective member of the team. The second time, I was coming in as an engineering manager trying to introduce mission-centric practices to backlog-centric teams, and causing a lot of trouble and pain in the process!
With this new insight about beliefs, I can now make sense of this...
In particular the belief that developers should only take on well-vetted and validated work (and this usually goes hand-in-hand with a belief that work should be prepared such that any developer can pick up the next ticket) - once you've worked in a mission-centric team, these beliefs feel like anti-patterns - but they are fundamental to making the backlog-centric team work, and so you mess with them at your peril! The level of stress and the reaction can be intense - for example if you do anything that prevents the slick functioning of the grooming process, some of the team may almost think you are out to kill them.
With time, you can replace this pair of beliefs with a preference for working x-amigos style for collaborative understanding of the problem and generation of possible solutions - and once everyone is on board with that, no one wants a whole-team grooming session or tasks that are ready for any developer ever again - but it can take a few months to get there!
(I had one question also - at the end of the backlog centric team, did you mean that developers' responsibility is to "build the right thing right", or just to "build the thing right"? In my experience, the backlog-centric team's processes aren't optimised for identifying the right thing to build - they kind of assume someone else has done that for them...)
Is it a challenge to build the systems around (2) and then build the operations within those subsystems as (1). Yes.
But worth a bet.
My team's paradigm is 1, but I feel the disconnect between designers and builders impairs our results. Is there a way to move towards 2? What does it take?
You can add structure to 2. by using 1. with Team as customer. Or, add team goals to 1. by allocatong certain story points to Team.
In my experience #1 is not sustainable as it accumulates tech debt (and product debt).
#2 has probably the best potential for keeping tech / product debt in check as the whole team feels the pain of it and there’s a shared understanding of the source and the cost of the pain.
Awesome summary! I got a feeling that the Engineering-Centric category will get more popular in the recent climate of recession & layoffs. That is exactly the type which can look more 'lean and efficient' from the top. I'm not sure that's true most of the cases though, especially for more old-fashioned companies, just as you wrote down there - great for FAANG, risky for non-tech companies.
John, incredibly clear and succinct. Just sent this to our CTO and his VPs as we're undergoing a reshuffling of teams to better support our strategy. Gold. Thank you
My product team falls into the Team and Mission-Centric bucket. We've worked in other types of teams. From experience, the Team and Mission-Centric types are the most enjoyable to work with because of trust being built, friendships, passion for the mission, aligned principles and values, and of course, leaning into conflict. This type of team falls into an empowered team, and these outcomes are powerful and more profitable for everyone.
Great article.
Could you give examples of companies that following these models ? For e.g I dont know any successful company that follows model 1. ditto for the 3rd model. But I could be wrong
most of "big tech" (FAANG et .) veers into 3rd model
Lots of non-digital product companies are suitably competitive with #1.
3rd reminds me a lot of Facebook
For me model 2 is best every time even though I agree it’s variable to project and team. The con I believe is that great collaboration is difficult to facilitate because most don’t know: (a) at what points in process do I need a collaboration? (b) what exactly do we do while together/how do we make progress vs talking in circles? (c) whose responsibility is it to lead / answer a and b. And in figuring that out people may likely panic about progress and/or get offended about ownership. But it’s the best if you get someone comfortable to lead.