This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Aside from what's discussed in chapter 3 of TT, what are some other things you've tried in your own organizations to reduce cognitive load? What are some sources of cognitive load that are often overlooked or underestimated?
Aside from what's discussed in chapter 3 of TT, what are some other things you've tried in your own organizations to reduce cognitive load? What are some sources of cognitive load that are often overlooked or underestimated?
I thought that the statement about splitting into microteams ("they didn't have a lead anymore, empowering them to make team decisions") has interesting implications. Does the introduction of a team lead role indicate a breakdown in the functioning of a team as a cohesive unit?
I've also seen problems with older software services that goes against the classification of them as "simple" - often they were built with different context and assumptions in mind and have become brittle collections of extensions upon extensions. Especially if they have only "minor, occasional" changes the cognitive load to relearn the service can be a huge load and morale drain on a team. We consider services which are not being regularly updated and re-released to be a bad sign (heavy cognitive load ahead) rather than one that can be considered trivial "anyone could take care of this".
I've also seen problems with older software services that goes against the classification of them as "simple" - often they were built with different context and assumptions in mind and have become brittle collections of extensions upon extensions. Especially if they have only "minor, occasional" changes the cognitive load to relearn the service can be a huge load and morale drain on a team. We consider services which are not being regularly updated and re-released to be a bad sign (heavy cognitive load ahead) rather than one that can be considered trivial "anyone could take care of this".
Chapter 3/4: A couple of ideas for postmortem lines of questioning have come out of the following observations: * "similarity of team mental models is a good predictor of team performance" - so this seems like it could be a good avenue of inquiry, and * with the idea of limiting the necessary communication between different teams (if the teams are well structured), an inquiry into how the incident came to happen as well as how it was remediated from the point of view considering the inter-team communications that were involved
Chapter 4: Lots and lots of people like to cite Spotify. I appreciate that @manuel.pais and @matthew highlighted the statement "This article is only a snapshot of our current way of working—a journey in progress, not a journey completed". However, this citation and all the other ones I've heard extolling the Spotify model are all holding up this 7 year old snapshot for consideration. Presumably the company context at Spotify 7 years ago was quite different than it is today. How has it evolved since then?
Chapter 4: Lots and lots of people like to cite Spotify. I appreciate that @manuel.pais and @matthew highlighted the statement "This article is only a snapshot of our current way of working—a journey in progress, not a journey completed". However, this citation and all the other ones I've heard extolling the Spotify model are all holding up this 7 year old snapshot for consideration. Presumably the company context at Spotify 7 years ago was quite different than it is today. How has it evolved since then?
Chapter 4 (Ericsson case study): The callout of "specific roles...[working] like 'communications conduits'" seems to relate back to the question I raised a day or two ago about keeping individual stream-oriented teams mutually coordinated. I'll be interested to see how this pattern is mapped when we get further along in the book (I'm finding it really hard not to read ahead for some of these answers :-))
Just got the advert for The Unicorn Project and looked at Gene's slides (https://www.slideshare.net/realgenekim/the-unicorn-project-and-the-five-ideals) - his first ideal maps very nicely to Team Topologies and intentional team design to facilitate flow.
Just got the advert for The Unicorn Project and looked at Gene's slides (https://www.slideshare.net/realgenekim/the-unicorn-project-and-the-five-ideals) - his first ideal maps very nicely to Team Topologies and intentional team design to facilitate flow.
I just finished Chapter 3 and will have more to add to that conversation later, but since there was a lot of discussion about the importance of trust I wanted to share a short article I wrote a few years ago. It’s a thinly-veiled critique of the company where I was employed at the time, but I think the thrust of the argument is broadly applicable.
I just finished Chapter 3 and will have more to add to that conversation later, but since there was a lot of discussion about the importance of trust I wanted to share a short article I wrote a few years ago. It’s a thinly-veiled critique of the company where I was employed at the time, but I think the thrust of the argument is broadly applicable.
I found this concept very similar like Jim Whitehurst’s in his book The Open Organization https://www.goodreads.com/book/show/23258978 . Highly trusted teams collaborating together as equals leveraging innovation.