Watch the replay here:

• Learn why poor productivity doesn’t come from lazy teams and how other organisations are becoming more productive through the application of approaches defined in Team Topologies.

• Understand the causes of waste and low productivity in engineering teams: rework, waiting time, dependencies on other teams, managing dependencies rather than eliminating them, and limitations on the flow of change.

• Learn how to spot the characteristics of these behaviours within your organisation.

• Understand how to begin applying the Team Topologies approach.

Following the success of our Multi-team Software Delivery Assessment, Ben Dodd and Matthew Skelton discussed how to meet the productivity challenge many organisations are facing as we enter 2023.

In the session, Matthew & Ben talked about how common it is to have significant amounts of effort wasted through the delivery of features that are never used, how much time is wasted through cross-team dependencies and common reasons that the flow of change is impaired. Learn where to start on addressing these productivity challenges.

Webinar Q&A responses:

• How do we get started?

  Take a look at the infographics at https://teamtopologies.com/infographics - and talk to organisations like Conflux and Armakuni :)

  Aim to get a shared understanding, between leaders and change agents, of all the themes discussed in the book. This can take time, however there is real value in a shared terminology and vision for the future. Running book clubs is an interesting way of doing this and there are open source templates for doing this.

  We often see organisations focus on only one of the themes and, for example, mistake TT for a point-in-time org chart tool, before starting to work as individuals to embark on a programme of change

  We often see organisations mistake TT as a “big bang” approach, requiring a single point-in-time implementation. TT has iteration at its core and it’s valuable to start with a smaller number of candidate teams.

• Are there other artefacts, books, videos, conferences, communities that we can join, read, attend?

  Have a look at the materials on https://teamtopologies.com/ - Also see the upcoming conference Fast Flow Conference https://www.fastflowconf.com

• If the value stream lacks leadership, where should the stream aligned teams go to for support and direction?

  There are a number of approaches to building the vision and direction of a stream aligned team.

  The first question would be “Who is the customer or recipient of the value we’re creating?” and “Can we talk to them?”. The answers to these questions will be different depending on the context, but the fundamentals of a customer-centric mindset should be at the core of what and how the team will deliver that value.

  Armakuni always runs a pre-inception discovery and inception workshop when a team is forming and repeatedly on a roughly quarterly basis. There are several components in this process that focus on who the customers are, who are the stakeholders, how to get laser clarity on the “What, when and why?” and how we’ll get feedback on the progress and value the team is delivering.

  Approaches, such as the Team API, also enable others to “pull” the vision and purpose from the team and better enable discussions around leadership and where to focus next https://github.com/TeamTopologies/Team-API-template

• I struggle with the concept of "Complex subsystem teams" - e.g. the book says to avoid them but you still include them as a team type; and surely every team wants to think they deal with complex stuff. So how should we think about them, and when should we best use them, and when should we avoid them?

  First, the focus of a Complicated Subsystem Team is “complicated “ work in the Cynefin sense: needing expertise but still mechanistic, not emergent (hence “Complicated subsystem”, not “Complex subsystem”). The purpose of a CA team is very similar to the purpose of a platform: to improve flow in Stream-aligned teams by reducing team cognitive load.

  So as we mention in pp.91-92 of the TT book, you should introduce a Complicated Subsystem Team ONLY when there is a need to improve flow and reduce cognitive load.

  Say that your organisation needs (really needs) to build a video processing algorithm. Can that work be handled effectively by a Steam-aligned team, at least to begin with? If so, great - let those maths wizards deal with all the matrix maths and calculations for as long as it does not distract them from their core mission.

  But as soon as the cognitive load of dealing with video processing details starts to reduce their flow and domain focus, think about spitting off that video aspect to a Complicated Subsystem team.

• Is there a typical/recommended team/department size that is best to introduce a platform team?

  This is a good question but it’s sort of the wrong question :) The thing that determines a need for a platform is not the number of people in the department but the team cognitive load present due to the processes, tools, technologies, business domain, etc.

  You could get value from using TT platform thinking at an organisation size of 6 people or 50 people depending on the cognitive load factors.

  But for any organisation larger than about 15-20 people, you are almost certainly going to get some value from considering how to address team cognitive load.

• The application of standards and subjective views are particularly difficult blocking issues to remove. Are there any blocking issues that cannot be converted to non-blocking?

  Ask “what would it take to turn this into a non-blocking check via a platform?”

  Often, this surfaces misunderstandings (or politics) around a topic and helps to move the discussion forward.

  Look for new and emerging technologies (especially cloud services) that help with niche compliance or other testing as a service.

• How would you advise concepts like Flow can be embedded into an organisation (from Exec/SLT to engineers). It seems like a simple and sensible concept/approach however would require massive step change/transformation.. which often will be practically very difficult/unachievable esp when the BAU have to be met and delivery cannot be stopped or slowed.

  At Conflux, we work with Exec/C-level teams over 2-3 years to help shape their thinking and confidence with fast flow approaches. These group learning sessions are particularly effective at shifting perspectives and catalysing change.

  We often find that there are many initiatives that can be paused or stopped to help make space for more effective ways of working.

• How do you measure cognitive load? How do you tell when a team is reaching its limit?

  Good question. Take a look at https://github.com/TeamTopologies/Team-Cognitive-Load-Assessment as a suggestion for a starting point.

  We're also working on a formal Team Cognitive Load Assessment

• Who is good at applying the Team Topologies in industry and why do you hold them up as exemplars ?

  Take a look at the examples at https://teamtopologies.com/examples - the organisations here use TT to continuously adapt and evolve their organisations and capabilities, not to create a static/fixed organisation.

  Also see the upcoming conference Fast Flow Conference which is practitioner focused and has experience reports and insights from the leading implementers of TT https://www.fastflowconf.com

Meet our speakers

Matthew Skelton, Founder at Conflux

Matthew Skelton is co-author of Team Topologies: organizing business and technology teams for fast flow. Recognized by TechBeacon in 2018, 2019, and 2020 as one of the top 100 people to follow in DevOps, Matthew curates the well-known DevOps team topologies patterns at devopstopologies.com. He is Head of Consulting at Conflux and specializes in Continuous Delivery, operability, and organization dynamics for modern software systems.

• Mastodon: @matthewskelton@mastodon.social

• LinkedIn: matthewskelton

Ben Dodd, CTO & Co-founder, Armakuni

Ben Dodd, Armakuni’s CTO & Co-founder, is a thought leader in Cloud Native software development and digital transformation. A true change agent, Ben has a proven track record of leading both public and private organisations’ adoption of DevOps principles and culture, using his technical expertise at ground level to drive the change while also acting as a strategic advisor to the C-suite.

• LinkedIn: Ben Dodd