Success Patterns for Adaptive Organizations
Join the authors of two of the most influential books on creating adaptive organizations, EDGE: Value-driven Digital Transformation and Team Topologies: Organizing Business and Technology Teams for Fast Flow, for a discussion on the success patterns they've recognized while consulting with organizations investing in building business agility.
Next steps for adaptive organizations
Download our free PDF mini-book Finding boundaries for fast flow to gain insights into using Team Topologies and Domain-driven Design (DDD) to reshape teams and systems for flow.
Take this 5-minute survey to assess your organization’s readiness for fast flow and Team Topologies: https://survey.teamtopologies.com/tt-assessment
Webinar recording
Q&A from the webinar
1 - What do you think of intentionally increasing the cognitive load on a team to stimulate the reduction of complexity? I observed good results following that strategy to reduce complexity with some teams (mature teams)
Matthew: This question seems to suggest that if the team cognitive load is too low that teams might get distracted by lower level complexity rather than focusing on core business problems. Certainly, there needs to be a strong ethos in the team of avoiding becoming distracted by details too far removed from the core business mission of the team. The key thing is to make space for the team to focus its mission, with autonomy to use services from outside the team (ideally from a platform). Reward teams for the inverse of lines of code they write: the fewer lines of code they write, the better the team’s performance metric; obviously, this needs to be balanced with other metrics!
2 - How do you balance the need of individuals for or of the platform? With relational and organizational or systemic needs? More than 1 can be valid and in tension with each other.
TBC
3 - I have a doubt when Service teams become a silo. Does everyone depend on the Services team is it a matter of the Collaboration and/or Domain Driven Design model or even more opinionated services?
Matthew: Dependencies are a fundamental fact of modern life, and certainly a fact of modern software systems. However, it’s important to separate dependencies into two flavors: blocking dependencies and non-blocking dependencies. Blocking dependencies cause one team to wait on another team to do something before they can move ahead. By contrast, non-blocking dependencies can be consumed in a self-service manner by the dependent team, so they are not blocked in their work. We certainly can use DDD and similar techniques to find good service boundaries to help avoid blocking dependencies.
4 - how can you change the outcomes and the remuneration funding attached, in a way that reduces middle level resistance?
Matthew: Great question! In many organizations currently, middle managers are tasked with managing and dealing with complex cross-team and cross-department dependencies. In the context of fast flow and Team Topologies, we aim to avoid complex dependencies via a combination of techniques: the 4 team types and 3 team interaction modes, Domain-driven Design (DDD), team dependency tracking, the Independent Service Heuristics for finding flow-aligned boundaries, User Needs Mapping, and so forth. All this means that managers might feel a bit nervous that their skills might not be used BUT it’s all fine, because we can put managers’ skills to excellent use in finding and adjusting flow boundaries, unblocking flow, coordinating changes in team interaction modes, and a whole bunch more things related to improving flow.
5 - What are the heuristics we can use to determine when a team has too much cognitive load?
Matthew: The heuristics or clues for to-high team cognitive load are both quite simple and quite involved. On the one hand, we can can simply ask team members to rate different aspects of their work on a 1 to 5 scale in terms of how different activities affect their ability to learn and focus on the main domain area of their team. But also of course there are many different things that affect team cognitive load: the stage of development, whether the team is in Collaboration mode with other teams, whether they are refactoring substantially, whether they have a high number of live service problems, and also just the more mundane things like filling in timesheets. So to get a basic indication is quite straightforward but to measure team cognitive load effectively is quite difficult.
6 - That definition of Platform sounds quite similar to the concept of scaffolding…i.e. Scaffolding cognition
Matthew: Indeed, and that’s not at all surprising given the focus on team cognitive load - and therefore aspects of human learning and cognition - that we emphasize in the Team Topologies book. We’ve seen that many organizations have found the Team Topologies definition of a platform to be quite refreshing and helpful. It gets away from an obsession with technology and actually helps us apply the TT ideas to areas outside of IT, such as marketing, HR, sales, legal, support helpdesk, and so forth.
7 - Platform teams might try to reduce the cognitive load to zero by making everything be part of the platform. How do you control that tendency towards a monolith?
Matthew: A key success indicator for Platforms (in a Team Topologies sense) is that the platform should enhance flow in Stream-aligned teams that use the platform. If the platform somehow “grabs” all the services then the metrics of the teams using the platform will suffer, and therefore the platform metrics will suffer. However, more fundamentally, over time we do expect a platform to take on more and more of the “plumbing”, allowing Stream-aligned teams outside the platform to focus on ever more valuable things, meeting new customer needs as parts of the technology and services landscape become more available as utility or commodity services.