Speaker

Manuel Pais is an independent DevOps and Continuous Delivery Consultant, focused on team design, practices and flow. He helps organizations define and adopt DevOps and Continuous Delivery (both from technical and human perspectives) via strategic assessments, practical workshops and coaching. Also InfoQ lead editor. Co-curator of DevOpsTopologies.com. Co-author of the books “Team Guide to Software Releasability” (Conflux Digital, 2018) and “Team Topologies” (IT Revolution Press, 2019). Answers by @manupaisable at Twitter and Medium.

Quick Q&A With Manuel Pais

We had a chance to catch up with Manuel and ask him a few questions about teams and his editorial work.

Miguel Alho: Hi Manuel! You have created a pretty large body of work related to the team aspect of our work, whether through the devopstopologies.com website or through your upcoming book Team Topologies… How did you come to focus on this aspect?

Maunel Pais: Hi! That’s a great question. Well, in the last 5 years I took part in several consulting engagements where clients wanted to adopt DevOps and Continuous Delivery. Often they expected new technology and practices would solve their problems but their effectiveness was limited by the way teams interacted (or not) or unclear team responsibilities. For example, if you adopt infrastructure-as-code but only the infrastructure team can make modifications and provision new resources, they will remain a bottleneck that decreases the flow of work.

On the other hand, back in 2015 I found out about Matthew Skelton’s DevOps Topologies which resonated to me and many other people as a great visualization of common patterns and anti-patterns in team structures and interactions. As I worked with Matthew at different clients worldwide, we further identified behavior patterns and associated context that led to a faster flow without compromising quality (in fact, usually improving it).

In short, I know from experience that we need to start with team interactions and flow of work to make substantial improvements in the way organizations build and run modern software.

MA: Do you see in your work a lot of companies misapplying these patterns? Why does that tend to happen?

MP: I wouldn’t say misapplying but rather many companies are still not thinking about these issues. It’s hard when we’re talking about changing behaviors and getting people out of their comfort zone, including at the management level. There’s often no space for organizational learning, i.e. finding out iteratively what are the right teams and responsibilities to go faster. It’s hard when you’re in a constant whirlwind of market and technology changes. But that’s the very reason why it’s necessary to think harder about team design and clarify responsibilities and expectations.

The advice I would give is to start with the DevOps Topologies to kickstart conversations in and around teams on how they see themselves in the spectrum of patterns presented. Just raising awareness can be super valuable. Management support is critical to make more sweeping changes (again, this should be learning-driven, not big bang re-org) but even without it teams can start by clarifying what are their responsibilities and prefered ways of working and communicating (kind of a “Team API”) with other teams.

On the other hand, we start to see more and more companies that have bought into the model of autonomous product teams but are not seeing the value yet because these teams are expected to learn and become high performing teams without any supporting structures in place. That is extremely complicated in any organization beyond 30-40 people.

That’s why I’m talking about why “Product Teams Need a Family Too” at DevOpsDays Portugal on June 3, meaning they need a support system that really allows the kind of speed and reliability organizations are striving for today. Tip: it doesn’t come true just by saying we have autonomous teams now. This talk is based on the Team Topologies book that me and Matthew Skelton have written for Gene Kim’s IT Revolution Press, but only starts shipping in September, so this will be an early look into these ideas :)

MA: Your editing for InfoQ must give you great visibility on the trends. Where do you see moving towards?

MP: I’ve been the DevOps lead editor at InfoQ for several years now, and it’s amazing how much has changed, from infrastructure-as-code to Docker and Kubernetes, or the rise of microservices architectures.

We actually put out a “DevOps and Cloud Trends Report” on a regular basis at InfoQ where we discuss trends and place technologies and practices on the adoption hype cycle. We see adoption of DevOps, containers and infrastructure-as-code as having established their value, so organizations lagging behind need to look into how to make use of them right now (again, with a learning mentality, not big bang). Then you have technologies like Kubernetes and approaches like self-service platforms, DevEx (caring about the developer experience), ChatOps becoming more widespread. On the “innovator” side are those things we tend to associate only with the Netflixes and Googles, like chaos engineering or AIOps.

Of course, as the saying goes “your mileage may vary”. There’s such a wide spectrum of maturity levels across organizations, it’s hard to make predictions. I believe forward-thinking organizations are moving towards resiliency of both live systems and their development toolchains, via easy-to-use internal platforms but which make strong use of external cloud and other service providers. Kubernetes is a hot topic of course, but the learning curve and ops skills required to run in-house are still high, making the case for adoption difficult for companies with low engineering and/or organizational maturity.

MA: Awesome work there, and best of luck with the book!"