Create the Right Team

Matthew Skelton – head of consulting at Conflux and Independent DevOps – and Continuous Delivery consultant Manuel Pais present a manual for designing successful software teams. They cite Conway’s Law, which holds that the design of software is linked inextricably to the design of software teams. Accordingly, Skelton and Pais offer a step-by-step plan for the organizational design of software teams. The books’ theme is that proper team organization and communication fuel successful technology development and productive business.

This work is written for those inside the software world, and it garnered enthusiastic reviews from those best able to appreciate it. For example, Ruth Malan, Architecture Consultant at Bredemeyer Consulting, found that it “…serves as a pragmatic guide whether forming teams and enabling them to meet their challenges or helping existing teams become more effective.” Dr. Naomi Stanford, Organization Design Practitioner, wrote that the book is “…well constructed and signposted, based in sound thinking, and challenges readers to assume, like them, that an organization is a socio-technical system or ecosystem.”

Software Teams

Skelton and Pais note that talented and tech-savvy engineers can develop software on their own, but that teams are more efficient. They stress that effective teams interact with one another.

A team learns and delivers together because when this happens, the results far outperform mere collections of individuals.Matthew Skelton and Manuel Pais

Skelton and Pais dictate that teams’ shared interactions must evolve as their software products or services evolve. How companies organize and optimize software teams – how they design and establish team topologies – the authors emphasize, directly affects these interactions.

Initial Software Delivery

Skelton and Pais warn that software delivery seldom goes smoothly at first. Their list of causes include: lack of team engagement; technology surprises;teams that can’t manage ever-expanding software products; companies that pull teams in opposing directions; and corporate reorganizations that upend team goals. But, the authors emphasize, the seminal flaw is usually poor planning of software-delivery models.

Team structures must match the required software architecture or risk producing unintended designs.Matthew Skelton and Manuel Pais

Most organizations, Skelton and Pais believe, ignore the implications of Conway’s Law, which applies to all software development. Communication, they maintain, shapes the software you create and deliver; if software teams can’t communicate internally and with each other, they can’t solve problems. 

Skelton and Pais prompt corporate managers to ensure that their team topologies – or structures – align with the team’s goals. Software team topology, the authors teach, should match the team’s intended software architectures. Skelton and Pais explain that design and implementation teams work together from the stages of planning forward.

Team Topologies

Skelton and Pais detail four team topologies: “stream-aligned;” “enabling;” “complicated-subsystems;” and “platform.” The latter three support stream-aligned teams.

Stream-aligned teams, the authors specify, adjust to the pace and nature of changes in their business. Team members rely on cross-functional skills to operate independently. Skelton and Pais show that these team don’t have to rely on other teams to be productive becausethey focus on a single stream of work. The authors identify a single stream as one product or service, “a single set of features, a single user journey or a single user persona.” These teams work independently, the authors clarify, without hand-offs to other teams.

Even performance-oriented organizations might be hindering the adoption of effective technologies and practices due to their team organization.Matthew Skelton and Manual Pais

Skelton and Pais characterize enabling teams as being made up of technical or product experts skilled at collaboration. Enabling teams, they disclose, help stream-aligned teams modify software quickly and, as the authors reveal, they don’t execute. Instead, they offer direction and support.

A complicated sub-system team, the authors detail, leverages its specialized expertise to develop complex software beyond the expected capabilities of stream-aligned or platform teams. Skelton and Pais caution that most organizations need only a few complicated sub-system teams with highly specific expertise to collaborate with stream-aligned teams as they develop a product.

A platform software team, the authors note, handles foundational, internal platforms that support stream-aligned teams.

Interaction modes

Skelton and Pais urge you to make the correct choice among three cross-team interaction modes that enhance software delivery. The authors describe a process in “collaboration mode” wherein two high-tech teams work closely to achieve a common goal, but they warn that excessive collaboration impedes flow. In “X-as-a-service mode,” Skelton and Pais show how one team supplies another with something of value, like software or a tool, but the teams engage in only limited collaboration. In “facilitating mode,” they explain, one team – usually an enabling team – helps another team learn or adopt a new approach to detecting problems.

The way teams are set up and interact is often based on past projects and/or legacy technologies (reflecting the latest org-chart design, which might be years old, if not decades).Matthew Skelton and Manuel Pais

Skelton and Pais advise companies to follow a team-first strategy to organize, manage and, if necessary, restructure their software development teams. Smart companies, the authors maintain, never regard teams as software assembly lines, but as individual and important enterprises.

The authors further recommend that insisting that all software team members communicate with all other software team members simply breeds dysfunction. They assert that successful software development demands a strong corporate culture, smart engineering practices, all the necessary funding and a clear business vision.

Functional

Skelton and Pais call their book “functional,” and they’re right. They are not writing for the general reader. The authors present a workable, prescriptive, detailed, step-by-step manual for people deeply vested in and familiar with software development. Though Skelton and Pais – remarkably – avoid jargon, much of their book requires the uninitiated to read with great focus. Still, this remains an invaluable, readable, practical guide and will likely prove canonical for those in the field: software engineers and developers, software executives and team leaders, and founders of tech startups.

Many people have never really experienced a team-first way of working, so it will feel strange to them. Take the time to explain and demonstrate the team-interaction modes.Matthew Skelton and Manuel Pais  

Other worthwhile books that address the realms of software development team-building and effective project completion include Mik Kersten’s Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework; Dominca DeGrandis’s Making Work Visible; Nicole Forsgren, Jez Humble and Gene Kim’s Accelerate: The Science of Lean Software and DevOps; and The DevOPs Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, by Kim, Humble, Patrick Debois and John Willis.