My reflections on “Team topologies” – Organising business and technology for fast flow

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.

Team topology

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.

Some thoughts on “Remote (office not required)”

Being in IT and SW development for quite some time I thought there is little (if anything) to add to my wide list of DOS and DON’ts in making a remote team work.

Yet, a recent reading added few more things to pay attention to. “Remote” is a book authored by the founders of 37Signals (the creator of Basecamp). Big thanks to Carsten Neuendorf (VP Engineering at Searchmetrics) for giving me that hint.

Jason and David walk you through all the innerworkings of a remote team, and believe me they know how to do it – their 50 colleagues are spread across 32 locations. So I highly recommend reading it from cover to cover and not limiting yourself to my notes.

Woman working from balcony

Hiring

  • Hire people you trust so you can avoid the caveat of having to exert control on their work. As Richard Branson once said:

To successfully work with other people, you have to trust each other. A big part of this is trusting people to get their work done wherever they are, without supervision.

  • Hire by doing a paid test project – in my practice I have often seen tests or test days being used but I find the idea of doing a paid test project also a great way to reward candidate’s time and test her/his skills for the job.

Productivity

  • When working remotely be very available. This avoids the black box impression of many remote teams I have either managed or dealth with in the past. Also, get your client constantly involved in the project – in the end it is their project. Yet, the best way to ensure high visibility is to do an exceptionally good work and show you progress often.
  • If your teams are working in very different timezones, ensure that teams have an overlap of some hours (IMHO 4 hours is a good number) for maintaining communication. For example: arrange for teams to start some hours earlier or later their work in order to get that overlap.
  • Remote workers tend to overwork (who hasn’t been tempted to read work emails in bed?) and it needs some effort to cultivate the equivalent of “good (and sufficient) work” so the day can be considered well spend by your remote workers.
  • Ergonomics – get all the necessary and healthy equipment to ensure people are enabled to do their best work while doing the best for their health.
  • The unealthy paradox of saving time on commute to the office and still not exercising enough. A study by insurance company Aetna showed that remote workers tend to be heavier. This can be easily fixed by finding routines to get you out of the home office and let you do your daily steps e.g. go out for lunch.
  • Give control away – step away from the established traditional ways and allow more freedom on deciding when to take holidays (“be reasonable”) – let others know and time well with your work, and how to deal with spending (“spend wisely”, no limitations set).

Socializing

  • Get the team together several times a year – be creative and organise workshops and all-hands in all sort of funny or exotic locations. Why not meet in Egypt if you have a remote worker there?
  • Create human experiences – when working remote you miss many of the social interractions in a “normal” company headquarter so there is a need to catch up in some way. So why not with memorable experiences – this is why 37Signals sponsor very diverse holiday gifts e.g. hobby-related, family-related etc.

Do not miss on this book, hope you enjoy it too! I am moving on to my next recommendation from Carsten: Team Topologies – Organising business and technology teams for fast flow by Matthew Skelton and Manuel Pais.

The startup Echometer: Making agile transformations succeed

Corporates are changing – just read the news around VW, Volvo and the ING bank to name a few. There is a simple reason – accelerating changes in global markets makes corporates’ agility a strategic priority.

Statistics confirm that 50% of german companies have started implementing agile methods and frameworks. But here comes the problem: Roughly ⅔ of such transformations fail.

How is that? Well, according to the “State of Agile” Study 2019, the biggest blocker for successful agile transitions are cultural issues – resistance to change and inadequate management support and sponsorship.

And this is where the startup Echometer comes in. It is a company I met recently as part of my advisor role at the Founders Foundation. As a Spin-off from the psychological department of the University of Münster, the startup has a unique perspective on agile: Focusing on employees and teams mindset. Echometer helps fostering the agile mindset in two ways.

The Founders team of Echometer, currently in the Accelerator program of the Founders Foundation (Bertelsmann Stiftung): Jean Michel Diaz, Robin Roschlau & Christian Heidemeyer.

Firstly, scrum masters and agile coaches, the change agents in such agile transformations, are supported in so called “retrospectives”. Retrospectives are regular team workshops, where teams come together to continuously improve. In these retrospectives, Echometer as a “digital coach” helps developing the team using scientific findings from psychology combined with artificial intelligence.

Echometer helps adopt agile methods in teams (retrospectives) as “digital coach”. As a by-product, the progress of the teams and overall transformation becomes measurable for agile coaches and management.

Secondly, by using the tool in retrospectives, the development of the team and transformation can be made visible – not only on team, but also on organizational level. That way, Echometer ensures that agile transformations become measurable in a way that is combinable with the agile philosophy of self-responsibility. Teams and managers get specific hints and tips about how they can help their teams grow – based on the Echometers learning algorithm in the background.

The Center of excellence of a leading high-end domestic appliances manufacturer has put the use of Echometer this way: 

“We use Echometer to gain transparency about cultural developments and to enable purposeful team discussions.” Source: Echometer

Co-Founder and CEO Jean Michel Diaz adds:

“While many companies have no clue, about how the transformation is going on an operational level, our customers have real-time insights and can be sure that agile teams support the transformation with a buttom-up continuous improvement process (!) – which is even more important.” Source: Echometer

Christian Heidemeyer, organisational psychologist and one of the Co-Founders of Echometer, recently visited the Barcamp of the ING (see picture). While the bank is one of the most popular examples of a corporate implementing agile methods and frameworks company-wide (see McKinsey, 2017), they agreed that agile mindset is a huge field to continuously work on.

Keine alternative Textbeschreibung für dieses Bild vorhanden
Christian Heidemeyer, organisational psychologist and Co-Founder of Echometer, was invited as a guest to present Echometer at the ING Barcamp in January 2020.

Seems like Echometer is heading in the right direction.

If you want to learn more about Echometer, check out www.echometer.de or follow them on LinkedIn, Facebook or Twitter.