Funnel developer book club - Team Topologies
Amongst other employee lead initiatives here at Funnel, there is a developer book club. We recently discussed Team Topologies. It was an interesting book that should be extra useful now when everyone is working remote. Here are some thoughts on it.
Team topologies
Conway’s law states that software architecture will mirror that of the organisation. Team Topologies stress the importance of self-contained and independent teams that can work with as few interactions with other teams as possible. Excessive interaction between teams can be a sign of incorrect team responsibilities or inadequate system architecture. The reverse Conway maneuver means that you shape the organisation the way you want to shape the architecture. These two will eventually converge. Having small, independent teams with limited cognitive workload improve productivity and speed.
In recent years, organisations have increasingly tried to abandon old software monoliths in favour of a decoupled micro services architecture. This enables teams to deploy software often and in small batches - like we do here at Funnel. However, breaking up monoliths can be more difficult than it seems. It is possible to be left with a complex landscape of strongly coupled micro services. Team Topologies presents a way of clearly visualising organisational dependencies, discussing them, thus increasing team independence and productivity. The authors Manuel Pais and Mathew Skelton do this by identifying four fundamental team types and three ways teams can interact with each other.
Four team types:
The stream aligned team
The authors identify this type of team as the primary team type in an organisation. A stream aligned team will work on a specific stream in the business. This can be a specific customer, business-area or user personae to name a few. The team work on the complete delivery circle, from problem description to test and support.
The enabling team
A stream aligned team will need training and proper tools to make their daily work flow as smooth as possible. Enabling teams consist of specialists in different areas. Their task is to investigate ways of improving tooling and to support the stream aligned teams. The goal for the enabling team is for the stream aligned teams not to rely on them, avoiding a situation where the enabling team becomes an ivory tower of knowledge.
The complicated subsystem team
Some aspects of the tech stack may require specialist knowledge. In order to decrease cognitive load of the stream aligned teams, complicated subsystem teams will take responsibility for especially complicated parts of the system. Team Topologies mentions video processing codecs and face-recognition engines as possible candidates for this type of team. It is the required level of specialised and difficult to find knowledge that decides when this type of team should be formed.
The platform team
A platform team will provide services to the stream aligned team that will help them to deploy, run and handle errors in production through well defined API’s. The platform provides services to the other teams and helps reduce cognitive load. Examples of problems solved by a platform team includes server provisioning and access management.
Three interaction modes:
Collaboration
When an organisation tries solving new problems collaboration between teams can be the most efficient way to find solutions. The authors identify two visualisations of collaboration: One where each team retains its responsibilities and one where the two teams almost merge into one. Drawbacks with this way of working can include increased cognitive load and communication overhead. On the other hand, collaboration can improve creativity.
X-as-a-service
If more than one team consumes the services of another team, x-as-a-service communication can be appropriate. The services available need to be excellent with high quality DevEx (developer experience) to make this type of interaction effective. This can be a suitable interaction model for a mature part of the system where you want to decrease cognitive load of developers consuming its artifacts.
Facilitating
The facilitating mode of interaction is associated with Enabling teams in collaboration with stream aligned teams. The latter may have problems starting to use a new tool or getting to grips with a problem. An enabling team uses the facilitating mode to help them understand this new thing. Examples of this can be adhering to security principles, understanding UX or using some new technology that the organisation is adopting on a wide scale.
Thoughts on the book
The book is structured as a manual outlining the different team and collaboration modes in an ordered way. It is easy to come back and find relevant parts for reference. Every part of the book starts with a short introduction about the chapter and concludes with a summary. This is not that necessary when reading it back to back, but is handy when using it as reference.
Team Topologies is short and to the point. This makes it easy to read and understand. In the beginning of the book, there was an issue with the problem description feeling a bit too simplified. Towards the end there are more nuances as to how and when organisations can apply this kind of thinking to their hierarchy.
The authors begin by explaining the problem with traditional organisation charts. They can be misleading as the communications between teams do not necessarily reflect the hierarchy. This in itself does not have to be a problem, as communication between departments is healthy and can improve and culture. Team Topologies also suggests improving team API:s and enforcing Conway’s law by placing teams that frequently interact with each other on different floors. Thus, an naive implementation of the ideas expressed could result in an organisation where workers are seen as resources rather than people. This is probably the result of the book being short. There is little room for ambiguity and the authors do explain their ideas in a more nuanced way in the last chapters. The focus having team size that takes Dunbar’s number into consideration and putting the team first are one of several examples on how Team Topologies takes a human centric approach, although trying to decrease communication between teams makes it seem less so to a Funneler.
Team Topologies provides a language to talk about kinds of teams and communication modes. This is in itself a very good thing. If this can be spread within an organisation they will get a tool that they can use continuously to communicate how they are forming their forces. To have a clear understanding of a team’s role and responsibilities in an organisation can clearly help to avoid confusion and sometimes conflict.
Team Topologies at Funnel
At Funnel we have very little structure and for us Team Topologies can be a good help to visualise the little structure we have and give our teams a context in which to thrive. We strive towards decoupled, independent teams that can push value to our customers without interference from other organisational parts. Our setup is following the ideas in the book quite closely and in the places that we don’t there seem to be a good reason for it. We believe that using the vocabulary of the book when we talk about the organisation would be a good help for us to continue to grow and understand ourselves. Being more aware of the different team types and interaction modes can also be helpful now when we are all working remote.
Funnel treasure informal communication, so although too much communication between teams can be a sign of software architecture that needs to be changed, the thought of wanting to decrease communication in order to reinforce an architecture feels alien to us. Whilst we appreciate that there might be a difference between having work related and more informal conversations with colleagues from different teams, the two types of interactions tend to mix. Frequent interactions also build trust. With that said, the tools in this book should make problem solving between teams more efficient and smooth.
Enjoy the reading and have a great summer!
Fredrik Rubensson and Sara Wänerskär
Devs at Funnel