I have been looking for a long time for the right guide to building and maintaining fast flow in technology teams. I believe Matthew Skelton and Manuel Pais have managed to put together exactly that. Well, it took me quite some months to finish the book and I will try to bring some of the points I have highlighted for my work.

Cognitive load and bottlenecks for high performing teams

• Every person has a limit of how much information can process.
• Too many topics and domains result in overloading the team capacity and thus collide with the principles of Dan Pink e.g. autonomy is strangled by the many interests to consider and prioritse, mastery is dimished by the many fields of expertise to deal with and purpose is blurred due to the many domains of responsibility.
• Allow for expertise to build up and do not reshuffle team members too often e.g. not every six months.
• Small team size fosters trust between team members.

Takeaway: To maintain fast flow keep teams smalls (5 to 8 people) and the topics within sight.

Communication between teams

Many say that communication is critical for efficient team work but it can sometimes become too much and a burden.

• In a setup with many small teams, communication should be intensive inside a team, semi-intensive between collaborating teams and low between all teams as a whole.
• If two teams have to collaborate, then a good way to understand communication gaps is to sit them away from each other and follow their communication through communication tools such as MS Teams or Slack.
• Collaboration between teams is expensive (requires time and costs focus) and sometimes hides deficiencies of the udnerlying product thus should be critically assessed every now and then.

Takeaway: Contrary to the believe not everyone should communicate with everyone for a strong flow.

Ownership of a product

• Ownership of a team grows stronger with time.
• The usual phases of forming a team go though well understood stages: forming, storming, norming and performing.
• With its strengthening over time, ownership evolves over different horizons: 1. Immediate horizon of exploitation of the software, 2. Expandning the reach and uses of a product, 3. Exploration of the far-reaching development and uses.
• Strong ownership, requires a strong team and team-first mentality where individual contributors should align with team goals and unblock other team members. In a similar way also rewards should go towards the whole team and not against individual contributors.
• Limit teams to one complex and complicated domain, it raises their morale and predicatbility of the delivery.

Takeaway: Strong ownership requires a strong team (just follow the cook book above)

The four fundamental team topologies

• A stream-aligned team is focused on 1 valuable product, service, set of features etc. It is the primary unit in an organisation and should deliver value independently, quickly and reliably. “Stream-aligned” is considered better fitting term in the current technology context than using “product” or “feature” for describing team’s focus.
• Enabling teams consists of specialist in a given technical domain and cross-cut stream-aligned teams to provide missing expertise. These teams are by definition highly collaborative and help research a fitting solution as well as support a stream-aligned team to acquire in a “effort-free” method the missing knowledge for their mission. Examples for such are security, enterprise, testing capabilites.
• Compplicated-subsystem teams are rare and there are usually just a few of them even in very big orgas. These teams focus on topics requiring highly specilized knowledge such as mathematical modelling, complex algorithms etc.
• A platform team enables stream-aligned teams to achieve fast flow and operate with high autonomy. They have strong focus on usuability and reliability. Examples for platform teams are teams that abstract away infrastructure and networking, but are not limited to these.

I think it is best to stop here, but do not miss the part about collaboration between teams and the three main collaboration models. There is much to learn from this book and highly recommend it as your next reading. Also keep in mind that the summary of the book in this post is based on the authors content and intermningled with my reflections. So the credit should go the Matthew and Manuel, and not to me!

I am really thankful to Carsten Neuendorf (VP Engineering at Searchmetrics) for giving me a hint about this book.