Review do Livro - Team Topologies

Existem alguns problemas fundamentais que empresas de todos os tamanhos precisam resolver para escalar e principalmente para ganharem agilidade estratégica. Um desses problemas é a estrutura organizacional.

Embora a estrutura organizacional seja importante, ela é ao mesmo tempo um dos problemas mais desdenhados pelas empresas, principalmente empresas em fase de growth. Isso é irônico, dado que uma estrutura organizacional bem pensada no início seria um dos fatores que potencializaria o crescimento sustentável da empresa.

Um problema adjacente que deriva deste problema da estrutura organizacional, é que geralmente a empresa foca no desenho da estrutura e não na essência que a estrutura precisa pra funcionar:

• Comunicação
• Colaboração
• Autonomia
• Alinhamento

Esses e outros pontos importantes são feitos no livro Team Topologies, do Matthew Skelton e Manuel Pais. Talvez o melhor livro que já li sobre o assunto.

Fico muito estimulado quando leio livros que conseguem materializar muito bem argumentos e racionais complexos sobre assuntos que embora você possa conhecer muito bem, as vezes falta a aquela conexão entre assuntos, que é essencial para explicar para times inteiros.

O livro não te explica nada totalmente novo, que talvez você não tenha visto em outros livros, mas a explicação das topologias e quais as propostas que cada topologia se propõe a resolver, é magistral.

Com uma série de referências de estudos, teorias e análises, o livro monta um racional bem leve de como times de tecnologia devem ser organizados e mantidos em qualquer tamanho de empresa, estimulando a comunicação e a colaboração entre os integrantes dos times.

Ele mostra 4 topologias de times e suas principais responsabilidades e conexões:

• Stream-aligned team
• Enabling team
• Complicated-subsystem team
• Platform team

Não vou detalhar esses tipo pra não dar spoiler e estragar uma leitura obrigatória para todo mundo (não apenas líderes ou gestores, mas principalmente integrantes de times) que trabalha com desenvolvimento de software.

Alguns highlights:

• organization is a sociotechnical system or ecosystem that is shaped by the interaction of individuals and the teams within it; in other words, that an organization is the interaction between people and technology. — location: 332
• Organizations should be viewed as complex and adaptive organisms rather than mechanistic and linear systems. —Naomi Stanford, Guide to Organisation Design — location: 370
• By empowering teams, and treating them as fundamental building blocks, individuals inside those teams move closer together to act as a team rather than just a group of people. On the other hand, by explicitly agreeing on interaction modes with other teams, expectations on behaviors become clearer and inter-team trust grows. Over — location: 445
• Conway’s law: “Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”6 — location: 488
• Dan Pink’s three elements of intrinsic motivation: autonomy (quashed by constant juggling of requests and priorities from multiple teams), mastery (“jack of all trades, master of none”), and purpose (too many domains of responsibility). — location: 526
• The Agile, Lean IT, and DevOps movements helped demonstrate the enormous value of smaller, more autonomous teams that were aligned to the flow of business, developing and releasing in small, iterative cycles, and course correcting based on feedback from users. — location: 545
• Alan MacCormack and colleagues at Harvard Business School undertook studies of various open-source and closed-source software products and found “strong evidence to support the hypothesis that a product’s architecture tends to mirror the structure of the organization in which it is developed.”2 — location: 596
• Ruth Malan: “if we have managers deciding . . . which services will be built, by which teams, we implicitly have managers deciding on the system architecture.”11 — location: 698
• As Fred Brooks points out in his classic book The Mythical Man-Month, adding new people to a team doesn’t immediately increase its capacity (this became known as Brooks’s law). — location: 880
• Teams should be stable but not static, changing only occasionally and when necessary. — location: 888
• The Tuckman model describes how teams perform in four stages: Forming: assembling for the first time Storming: working through initial differences in personality and ways of working Norming: evolving standard ways of working together Performing: reaching a state of high effectiveness — location: 894
• Note that team ownership of code should not be a territorial thing. The team takes responsibility for the code and cares for it, but individual team members should not feel like the code is theirs to the exclusion of others. Instead, teams should view themselves as stewards or caretakers as opposed to private owners. Think of code as gardening, not policing. — location: 915
• Reward the Whole Team, Not Individuals — location: 941
• Instead of structuring teams according to technical know-how or activities, organize teams according to business domain areas. —Jutta Eckstein, “Feature Teams—Distributed and Dispersed,” in Agility Across Time and Space — location: 1286
• Stream-aligned team Enabling team Complicated-subsystem team Platform team — location: 1608
• A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona. — location: 1634
• Each team is fully responsible for developing and operating its own service (whereby a service can be seen as one or more features of Amazon.com or AWS products). Each service is provided through an API, either for internal or external consumption; teams do not interfere or make any assumptions on other teams’ services architecture or technology. — location: 1662
• But how can a stream-aligned team with end-to-end ownership find the space for researching, reading about, learning, and practicing new skills? Stream-aligned teams are also under constant pressure to deliver and respond to change quickly. An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap. — location: 1721
• The end goal of an enabling team is to increase the autonomy of stream-aligned teams by growing their capabilities with a focus on their problems first, not the solutions per se. — location: 1733
• The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy. — location: 1824
• The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services. — location: 1825
• A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.12 — location: 1828
• platform team’s value can be measured by the value of the services they provide to product teams.”14 In practice, platform — location: 1838
• Organizations that optimize for a safe and rapid flow of change tend to use mixed-discipline or cross-functional teams aligned to the flow of change—what we call stream-aligned teams. — location: 1960
• A good platform provides standards, templates, APIs, and well-proven best practices for Dev teams to use to innovate rapidly and effectively. A good platform should make it easy for Dev teams to do the right things in the right way for the organization; this applies to all kinds of product development, not just those involving software. — location: 1973
• In many organizations, poorly defined team interactions and responsibilities are a source of friction and ineffectiveness. — location: 2471
• Collaboration: working closely together with another team X-as-a-Service: consuming or providing something with minimal collaboration Facilitating: helping (or being helped by) another team to clear impediments A combination — location: 2493
• For example, let’s say Team A is a stream-aligned team working on software for managing personal finances. They may use the collaboration mode to interact with Team B on new cloud-monitoring tooling, and use the X-as-a-Service mode to interact with Team C, which provides the platform on which the software runs — location: 2502