I went to London for Fast Flow Conf in September 2024. This had all kinds of ideas and experience reports related to Team Topologies, and was a great way to learn about how people are putting things into practice.

Connecting ideas

I’ve done a fair bit of reading / thinking about how to help supporting functions work more effectively with software teams. Earlier this year I wrote notes after Jen Oliver’s Agile in the Ether, IRL: Hacking bureaucracy workshop, which helped me find all kinds of helpful articles and viewpoints.

At Fast Flow Conf, Manuel Pais’ Beyond engineering: the future of platforms talk (video, slides) gave me lots more ideas on this theme – all the good advice for platform teams in Team Topologies can be used for functions like procurement, legal, and more. He shared several practical examples of how companies have made these self-service as much as possible, and be open to changing their platform as they collaborate with teams to understand how best to meet their needs.

One very interesting example was “leadership as a service” – where one org, Capra, has offered self-service tools and tailored support around:

• How can teams figure out themselves how to align to the goals of the company?
• Strategy Miro boards, to walk through how to link your work and make decisions
• Offer a metrics service: help teams choose and measure

Manuel shared some more links: Capra’s leadership-as-a-service story, and some background on their journey (in Norweigian, but browser translation works OK).

Platform teams need to do a fair bit of enabling too; in all these examples, in addition to documentation and tools, it can be useful for specialists to spend time with teams and equip them to be more self-sufficient in future.

Getting ideas picked up and used

Steve Pereira (video) talked about “hitting a wall” when he’s talked about Team Topologies and tried to translate it into action, and how playing with different narratives has helped people understand what he’s trying to get across. Different people in an org are listening for different things: lots of people don’t care what tech you use, or how teams are arranged, but they do care about how things look from the user’s perspective. Give them something they recognise, and work backwards to the teams and tech.

A great quote was “mapping is a collaborative act”: for mapping networks of value streams, or any other view of the org, it’s best to do it in a group with a range of stakeholders. Sometimes it can feel easier and faster to just work it out ourselves – but if you show someone a lovely map and it’s not drawn from their perspective, it can fall flat. People might be polite but they won’t see where you’re coming from.

Susanne Kaiser (video) had similar practical advice about meeting people where they are: starting from the users and their needs, working from their to the reasons why we have any of our components and teams, can help all kinds of stakeholders get more engaged with the reasons fast flow of value matters and how the current way teams are set up might be impacting that.

She illustrated how an “architecture for flow” canvas can help explain and explore ideas from Team Topologies, Wardley maps, and Domain Driven Design – and help agree both how to change how your teams are set up today, as well as plan the future landscape. How do you expect things to evolve over time? What’ll that mean for technology and teams?

Kenny Baas-Schwegler’s talk (video) covered lots of different mapping tools and techniques -but stressed that the goal of any collaborative modelling session is not to learn the tool, it’s to grow the “pool of shared meaning” (a term from the Crucial Conversations book). Getting all the relevant people together at once, to talk and map out things together, is hugely beneficial – but it doesn’t automatically work well.

Dealing with humans is a hard problem. To help groups work well, you need to learn all kinds of skills. Kenny recommended lots of topics to look into if you’re going to be facilitating this kind of work:

• ranking theory
• dealing with conflict
• cognitive biases
• polarities (e.g. action vs planning)

It’s a huge topic, but worthwhile to dig into!

I’ve seen Susanne and Kenny talk before, and wrote about them in Notes from Lean Agile Scotland 2023.

Some other measures of success

Sarah Wells (video) talked about the tricky challenge of keeping things up-to-date once you have a successful system. Modern software needs a lot of upgrades and patching, and occasional tough decisions to make major migrations. She shared a story of a system rewrite that they decided to cancel many months into it – and accepted as a business that this was absolutely the right thing to do. It was only once they’d gotten fairly far into it that they learned how much they’d underestimated the complexity, overestimated the benefits, and been unaware of other work that would limit the organisational capacity to put enough attention into this work. It’s often very hard to change course once costs are sunk, so this kind of honest and appreciative view is something we need more of. What have you stopped, and what did you learn from it are measures we could all put more attention on.

Varuna Venkatesh (video) shared a disheartening story of trying to make a simple change at a big organisation: Looking into a slow-running endpoint, she found ownership was divided between multiple teams all working on one big coupled system underneath. Making the change would need analysis, prioritization against other work, scheduling with each team, development by each team, integration, before the end user sees any difference. Very few individual pieces of work promise enough value to justify all this coordination.

Varuna managed to find a solution: a working group took people out of their usual teams and gave them a remit to get this problem solved. A working group is sort-of like an Enabling Team in Team Topologies: deep expertise, specific remit to help, and leaves teams with more knowledge and capability than they had before.

Often, teams know there’s better ways to make changes, but feel trapped: this is how we’ve always worked with this monolith, it’s what we do. The working group changed that: a specific remit to make this kind of change easier in future, to put the hard work in now. The group was made up of same people from those teams who’d felt trapped, but this was different. It worked so well that it spawned more – far more good ideas than there was time to work on.

They now have slack in their teams: every team’s planning assumes one person will be out of the team at all times. That’s generally an overestimate, most teams don’t have someone missing that often… but building in this slack has freed the org up to achieve lots with these working groups and other initiatives.

How have you found space to improve things? Felt like a good challenge for all orgs to consider.

Further reading

Lots of these speakers have written or co-written books!

• Manuel Pais: Team Topologies
• Steve Pereira: Flow engineering
• Susanne Kaiser: Architecture for flow
• Kenny Baas-Schwegler: Collaborative software design
• Sarah Wells: Enabling microservice success

And for further watching, there’s lots more talk videos on the Fast Flow Conf YouTube channel.