Tópico 7.0 — Estruturas de equipe, papéis e responsabilidades

Em uma frase: A entrega em saúde digital tem sucesso ou fracassa conforme a forma como vocês traçam as fronteiras entre as equipes e a clareza com que nomeiam quem faz o quê — estruturem, portanto, as equipes para um fluxo de valor rápido e seguro, componham-nas de forma multidisciplinar e tornem explícitas as responsabilidades.

Por que isso importa na saúde e nos cuidados#

A forma como vocês organizam suas equipes torna-se a forma como seus serviços se comportam. A Lei de Conway — segundo a qual o projeto de um sistema espelha a estrutura de comunicação da organização que o construiu — não é uma curiosidade na saúde e nos cuidados; é um risco à segurança do paciente. Equipes fragmentadas produzem prontuários fragmentados, integrações frágeis e transferências em que o risco clínico se esconde.

No NHS e nos cuidados sociais, vocês também gastam dinheiro público e carregam deveres estatutários: segurança clínica sob a DCB0129/DCB0160, governança da informação sob o UK GDPR e o dever de confidencialidade da common law e obrigações de acessibilidade. Esses deveres não podem ser acrescentados no fim. Precisam ser representados dentro da equipe, por pessoas nomeadas, com autoridade e tempo para cumpri-los.

Acertem a estrutura e as equipes multidisciplinares entregam software funcionando, em que os clínicos confiam e que os pacientes conseguem usar. Errem e terão especialistas ocupados otimizando o próprio silo enquanto o serviço como um todo empaca — o padrão clássico por trás de programas digitais atrasados, estourados em orçamento e silenciosamente abandonados.

Conceitos centrais#

Equipes multidisciplinares (EMDs). Uma equipe de entrega digital deve conter todas as disciplinas necessárias para projetar, construir e operar um serviço sem dependência externa constante — produto, entrega, design, pesquisa, engenharia, dados e as perspectivas clínica e de governança. Isso espelha o conceito de EMD clínica que a equipe já conhece: expertise mista, responsabilização compartilhada por um resultado.

Team Topologies. Um modelo (Skelton & Pais) que reduz o projeto eficaz de equipes a quatro tipos fundamentais e três modos de interação, todos a serviço de um fluxo rápido de valor:

• Equipe alinhada ao fluxo (stream-aligned) — organizada em torno de um único fluxo valioso de trabalho (um serviço, uma jornada do usuário, um produto) e dona dele de ponta a ponta. É o tipo de equipe padrão; a maioria das pessoas deve estar em uma.
• Equipe de plataforma — fornece capacidades internas de autosserviço (infraestrutura compartilhada, um motor de integração, um serviço de login, uma API de prontuário de cuidados compartilhado) para que as equipes alinhadas ao fluxo andem mais depressa sem reinventá-las.
• Equipe habilitadora — uma equipe de especialistas com prazo definido (p. ex., segurança clínica, acessibilidade, automação de testes) que treina os outros para elevar uma capacidade e depois se retira.
• Equipe de subsistema complicado — é dona de uma parte que exige conhecimento especializado profundo (um algoritmo de pontuação de risco, uma interface com a NHS Spine) que sobrecarregaria uma equipe generalista.

Os três modos de interação governam como duas equipes quaisquer se relacionam: colaboração (trabalhar de perto por um período definido, de alta largura de banda, tolerando alguma ineficiência para descobrir coisas), X-como-serviço (uma equipe consome a capacidade de outra com o mínimo de atrito, o padrão de baixo atrito em escala) e facilitação (uma equipe ajuda outra a aprender). Nomear o modo previne a ambiguidade que gera atrasos e culpa.

Carga cognitiva. Uma equipe só consegue manter tanta coisa na cabeça. O Team Topologies defende limitar o domínio que cada equipe possui ao que ela consegue raciocinar com segurança — um princípio decisivo quando o domínio é clínico.

A Lei de Conway e a Manobra Conway Inversa. Como a arquitetura segue a estrutura organizacional — uma visão de sistema sociotécnico que trata equipes e tecnologia como um só projeto —, moldem deliberadamente as equipes para produzir a arquitetura que vocês querem. Se querem um prontuário de cuidados modular e interoperável, não o construam com uma única equipe monolítica.

Boas práticas#

1. Componham uma equipe multidisciplinar completa em torno de cada serviço. Incluam, no mínimo, um gerente de produto, um gerente de entrega, um pesquisador de usuários, um designer de serviço/interação, engenheiros e uma capacidade de dados/análises, além de contribuição nomeada de segurança clínica e de governança da informação. Uma equipe a que falta uma disciplina ou esperará por outra pessoa ou pulará esse trabalho — e o trabalho pulado, na saúde, costuma ser segurança, acessibilidade ou governança.

2. Façam da maioria das equipes equipes alinhadas ao fluxo e deem-lhes propriedade de ponta a ponta. Organizem em torno da jornada de um usuário (p. ex., "encaminhamento ambulatorial") e não de uma camada de tecnologia (p. ex., "a equipe do banco de dados"). A propriedade de ponta a ponta encurta os ciclos de retroalimentação e elimina as lacunas de transferência em que o risco clínico se acumula.

3. Construam plataformas como produtos, consumidas como serviço. Tratem o seu motor de integração, serviço de identidade ou API de prontuário de cuidados compartilhado como um produto interno, com equipe, roteiro e usuários próprios. Publiquem-no "como serviço" para que as equipes alinhadas ao fluxo se autoatendam, em vez de abrir chamados e esperar.

4. Usem equipes habilitadoras para espalhar a expertise escassa, e não para entesourá-la. Responsáveis pela segurança clínica, especialistas em acessibilidade e engenheiros de segurança são raros. Destaquem-nos para treinar as equipes de entrega a um padrão mais alto e depois seguir adiante, em vez de se tornarem um gargalo permanente em que toda equipe faz fila.

5. Nomeiem explicitamente cada papel e seus direitos de decisão. Usem um modelo de responsabilidade — RACI (Responsável, Accountable/Aprovador, Consultado, Informado) ou uma divisão mais simples "decisor/conselheiro" — para as decisões que importam: aprovação de segurança clínica, entrada em produção, aprovação de governança da informação, gasto. A ambiguidade aqui é onde a responsabilização evapora.

6. Deem ao Responsável pela Segurança Clínica autoridade real e tempo real. A DCB0129/0160 exige um Responsável pela Segurança Clínica (CSO) nomeado e devidamente treinado, capaz de barrar uma versão. Tornem o papel explícito na equipe, protejam o seu tempo e garantam que ele possa dizer não — um CSO apenas no nome é uma falha de governança à espera de ser descoberta por um incidente.

7. Gerenciem a carga cognitiva delimitando o domínio. Se uma equipe é dona de serviços demais ou de um domínio clínico complexo demais, dividam-na. Fiquem atentos ao sinal: uma equipe que já não consegue explicar com confiança as implicações de segurança da própria mudança está sobrecarregada.

8. Apliquem a Manobra Conway Inversa deliberadamente. Tracem as fronteiras das equipes para corresponder à arquitetura e à interoperabilidade que vocês querem — equipes modulares para sistemas modulares e baseados em padrões (p. ex., HL7 FHIR). Não deixem um organograma acidental projetar o seu prontuário por vocês.

Perguntas para discutir com a sua equipe#

1. Onde o nosso organograma atual já está projetando a nossa arquitetura por nós — e é essa a arquitetura que de fato queremos? A Lei de Conway não é opcional: seja qual for a forma das nossas equipes, os sistemas passarão a espelhá-la; o primeiro movimento honesto é, portanto, olhar para o prontuário, as integrações e as transferências que já temos e perguntar que fronteira de equipe produziu cada costura. Num ambiente de saúde e cuidados, essas costuras são onde o risco clínico se esconde — um prontuário fragmentado, uma interface frágil com a Spine, um caso de segurança de que nenhuma equipe é dona —, de modo que esta é uma conversa sobre segurança do paciente, e não estética. A tensão a debater é que redesenhar as fronteiras das equipes para obter a arquitetura que queremos (a Manobra Conway Inversa) é disruptivo, ameaça feudos estabelecidos e atravessa estruturas de financiamento e de linha de gestão que podemos não controlar por inteiro. Considerem mapear duas ou três das suas integrações mais dolorosas de volta às equipes donas de cada ponta e perguntar se uma fronteira alinhada ao fluxo teria eliminado a transferência por completo. Uma boa resposta nomeia ao menos uma fronteira concreta que vocês moveriam, é honesta sobre quem resistiria e por quê e distingue as mudanças que valem a disrupção daquelas em que uma interface como serviço resolveria o atrito a um custo menor.

2. Os nossos especialistas escassos — segurança clínica, governança da informação, acessibilidade — ficam dentro de equipes com autoridade real, ou são portões externos atrás dos quais todos fazem fila? Todo serviço desta família carrega deveres estatutários (segurança clínica DCB0129/0160, UK GDPR e o dever de confidencialidade da common law, a lei de acessibilidade) que não podem ser acrescentados no fim, mas essas capacidades são raras e caras, o que puxa as organizações a entesourá-las centralmente. A concessão é genuína: incorporem um Responsável pela Segurança Clínica em cada equipe e vocês diluirão a expertise escassa até enfraquecê-la; centralizem-na e criarão o gargalo heroico em que uma pessoa é Consultada sobre tudo e toda versão espera. O padrão da equipe habilitadora — especialistas com prazo definido, que treinam as equipes a conduzir os próprios workshops de perigos e depois se retiram — é a resolução proposta, mas só funciona se a liderança proteger o tempo dos especialistas para ensinar em vez de fazer. Olhem com honestidade para o seu histórico de versões: quantas vezes uma entrada em produção escorregou esperando uma única pessoa nomeada, e essa pessoa tinha a autoridade e o tempo protegido para dizer não com segurança? Uma resposta forte encara a escassez de frente, adota uma posição deliberada de incorporar versus habilitar para cada dever e nomeia a autoridade específica (o poder de barrar uma versão) que jamais deve ser diluída, por mais que se espalhe a capacidade.

3. Como saberíamos que uma equipe assumiu mais carga cognitiva do que consegue carregar com segurança — e o que de fato faríamos a respeito? A carga cognitiva é o governador silencioso da entrega segura: uma equipe só consegue raciocinar sobre tanto domínio clínico e tantos serviços antes que a confiança nas implicações de segurança das próprias mudanças comece a erodir, e na saúde essa erosão é invisível até que um incidente a exponha. A dificuldade é que a sobrecarga raramente se anuncia — parece uma entrega um pouco mais lenta, mais defeitos, mais "deixa eu confirmar com alguém", e as equipes sob pressão tendem a absorvê-la em vez de sinalizá-la, sobretudo quando dividir uma equipe é politicamente custoso ou o quadro está congelado. Debatam quais seriam os seus sinais de alerta precoce (uma equipe que já não consegue explicar com confiança o caso de segurança da própria versão é um sinal forte) e se vocês têm hoje algum mecanismo que traria a sobrecarga à tona antes que a entrega empaque visivelmente. Considerem também a contrapressão: dividir equipes cria novas fronteiras e transferências, de modo que a cura pode reintroduzir o risco de fragmentação da primeira pergunta. Uma resposta honesta combina sinais concretos e observáveis, e não um vago "sentiríamos", nomeia quem tem a autoridade de delimitar o domínio de uma equipe ou dividi-la e admite a concessão entre o alívio da carga e a proliferação de fronteiras.

4. Quais das nossas capacidades compartilhadas devem ser operadas como plataformas consumidas como serviço, e as estamos de fato dotando de recursos assim — ou apenas rebatizando uma fila de chamados? A promessa de uma equipe de plataforma é que as equipes alinhadas ao fluxo se autoatendam de um motor de integração, de um serviço de identidade ou de uma API de prontuário de cuidados compartilhado sem abrir um chamado e esperar, de modo que o sistema inteiro ande mais depressa; a falha é chamar algo de "plataforma" enquanto continua sendo uma função central subdimensionada em que todos ainda fazem fila. A concessão é real: construir uma capacidade como um genuíno produto interno significa dar-lhe equipe, roteiro, documentação e usuários próprios, o que é um investimento sério que compete com lançar funcionalidades voltadas ao usuário e, num NHS de caixa limitado, é fácil adiá-lo indefinidamente. Na saúde e nos cuidados o que está em jogo é mais agudo porque as capacidades compartilhadas costumam ser as críticas para a segurança — o índice de correspondência de pessoas, as interfaces FHIR, a trilha de auditoria —, em que uma equipe de plataforma enxuta se torna um ponto único de falha para todo serviço que há por cima. Olhem as capacidades de que várias equipes já dependem e perguntem, para cada uma, se a interação é de fato um X-como-serviço de baixo atrito ou uma colaboração disfarçada com esperas ocultas. Uma resposta honesta nomeia quais capacidades justificam genuinamente investimento em plataforma agora versus depois, é clara sobre quem as financia e dota de pessoal e resiste à tentação de declarar uma plataforma que não tem dono de produto, roteiro nem via de autosserviço.

5. Onde dependemos de fornecedores contratados ou de pessoal emprestado, e quais papéis devemos manter internamente para continuar sendo um cliente inteligente e não um esvaziado? Boa parte da entrega digital na saúde e nos cuidados é terceirizada, e um fornecedor pode trazer capacidade e especialização depressa — mas, se a propriedade do produto, a garantia técnica e a aprovação de segurança clínica saírem do prédio com o contrato, a organização perde a capacidade de julgar o que lhe é vendido, de especificar o que precisa ou de ser dona do resultado com segurança. A tensão está entre a velocidade e a capacidade: a ampliação de pessoal e as construções chave na mão colocam algo no ar depressa, mas podem erodir em silêncio o músculo interno que permite cobrar um fornecedor, e muitas vezes entregam estruturas em forma de componentes e pesadas em transferências, em vez de equipes alinhadas ao fluxo que são donas de um resultado. Neste domínio, os papéis inegociáveis a manter se agrupam em torno de responsabilizações que não podem ser delegadas — o Responsável Sênior (SRO), o Responsável pela Segurança Clínica que aprova a entrada em produção, o dono do produto que decide as prioridades e garantia técnica suficiente para inspecionar o que os fornecedores constroem. Examinem a entrega atual e perguntem que capacidades vocês não conseguiriam reconstituir se um fornecedor fosse embora amanhã. Uma boa resposta distingue o trabalho que é genuinamente aceitável contratar do núcleo de cliente inteligente que deve ficar internamente, insiste que as equipes contratadas sejam cobradas por propriedade de resultados e não por fornecimento de mão de obra e nomeia as decisões de segurança e de governança que devem sempre repousar em suas próprias pessoas responsáveis.

6. Como saberemos que a nossa estrutura de equipes está de fato produzindo um fluxo rápido e seguro de valor — e o que nos faria redesenhá-la? O desenho das equipes é um meio, não um fim: o sentido das equipes alinhadas ao fluxo, das plataformas e dos modos de interação nomeados é uma entrega de valor mais rápida e segura, mas as organizações raramente instrumentam se a estrutura está entregando isso, de modo que as reorganizações acontecem por política e intuição e não por evidências. A dificuldade é escolher sinais que reflitam fluxo e segurança sem serem manipulados — a velocidade bruta ou a vazão em pontos de história convida ao comportamento errado, enquanto as métricas de fluxo (tempo de espera da ideia à produção, frequência de implantação, número de transferências por mudança) e os indicadores de segurança (quão depressa os perigos são fechados, se as equipes são donas do próprio caso de segurança) dizem mais sobre se as fronteiras estão ajudando ou atrapalhando. Há uma tensão real com a estabilidade: a reorganização constante destrói a longevidade das equipes e o espaço cognitivo compartilhado que tornam a entrega segura, de modo que vocês precisam de um limiar alto e de gatilhos claros antes de redesenhar fronteiras. Discutam que evidência diria que uma fronteira está errada — esperas persistentes entre equipes, um caso de segurança de que nenhuma equipe é dona, uma plataforma de que ninguém se autoatende — e quem tem poder para agir sobre ela. Uma resposta honesta se compromete com um pequeno conjunto de sinais de fluxo e segurança que vocês de fato observarão, fixa um limiar deliberado que proteja a estabilidade das equipes e nomeia as condições de gatilho e o decisor de qualquer remodelagem futura.

Na prática: um exemplo de saúde e cuidados#

Um sistema de cuidados integrados (ICS) está implantando um prontuário de cuidados compartilhado nos serviços de atenção aguda, comunitária, de saúde mental, primária e de cuidados sociais.

O instinto é criar uma grande "equipe do prontuário compartilhado". Em vez disso, o ICS aplica o Team Topologies. Uma equipe de plataforma é dona do núcleo do prontuário compartilhado: o índice de correspondência de pessoas, as APIs FHIR e o motor de integração, publicados como capacidades de autosserviço. Várias equipes alinhadas ao fluxo são donas, cada uma, de uma jornada real de usuário sobre ele — "ver o prontuário de um paciente no pronto-socorro", "visão de proteção para o assistente social", "reconciliação de medicamentos pela clínica geral" — e consomem a plataforma como serviço. Uma equipe de subsistema complicado é dona do algoritmo probabilístico de correspondência de pacientes, em que uma correspondência falsa é um incidente de segurança genuíno. Uma equipe habilitadora de especialistas em segurança clínica e acessibilidade circula pelas equipes alinhadas ao fluxo, treinando-as para conduzir os próprios workshops de perigos da DCB0160 em vez de fazê-lo por elas.

Cada equipe tem um gerente de produto, um gerente de entrega e um Responsável pela Segurança Clínica nomeados, e um RACI deixa claro que a entrada em produção é de responsabilização do Responsável Sênior (SRO), mas não pode prosseguir sem a aprovação do CSO e da governança da informação. Quando a equipe do pronto-socorro precisa de um novo campo de dados, o modo de interação é explícito: X-como-serviço da equipe de plataforma por meio de uma solicitação de API documentada, e não uma colaboração de seis semanas. A entrega é mais rápida e, de forma decisiva, o caso de segurança de cada jornada é de propriedade da equipe que a entrega.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital de dez pessoas não consegue dotar de pessoal quatro tipos distintos de equipe — normalmente é uma única equipe alinhada ao fluxo em que uma pessoa veste vários chapéus (um engenheiro que também conduz pesquisa com usuários, um fundador clínico que é o Responsável pela Segurança Clínica de fato). A prioridade é manter toda a equipe dentro de um espaço cognitivo compartilhado, para que as decisões sejam rápidas; um RACI formal é exagero quando todos estão na mesma sala. O risco real é o gargalo do fundador: a segurança clínica e a governança da informação repousam sobre uma única pessoa ocupada, e as obrigações da DCB0129/0160 são fáceis de adiar. Quando a empresa ganha o primeiro contrato com o NHS, as primeiras contratações de especialistas devem ser as que reduzem o risco desse portão — um CSO nomeado e um líder de governança da informação — antes de ampliar o quadro de engenharia.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única — tem pacientes reais e operações contínuas, mas raramente uma equipe digital ou de TI dedicada; não há, portanto, uma "topologia de equipes" a desenhar, e o gerente do consultório ou um líder clínico é, na prática, toda a capacidade de entrega, além do trabalho diário. O movimento realista não é construir equipes de plataforma e habilitadoras, mas nomear explicitamente as responsabilidades nas pessoas que já existem — quem é o Responsável pela Segurança Clínica dos sistemas que vocês implantam, quem é dono da governança da informação, quem aprova uma mudança —, ainda que sejam chapéus de meio período em um punhado de funcionários. Como os mesmos deveres estatutários (DCB0129/0160, UK GDPR, acessibilidade) se aplicam como a um grande hospital, o padrão prático é apoiar-se nas plataformas compartilhadas e no apoio habilitador de seus fornecedores e do seu ICS em vez de reinventá-los, retendo apenas capacidade suficiente de cliente inteligente para cobrar os fornecedores. O maior risco isolado é o gargalo de uma só pessoa: se a única pessoa que entende o sistema clínico for embora, a segurança e a continuidade vão embora com ela; escrever o RACI e treinar uma segunda pessoa em múltiplas funções importa mais aqui do que qualquer modelo formal de equipes.

Grande organização#

Um grande hospital do NHS ou empresa de tecnologia em saúde tem o problema oposto: equipes demais, traçadas ao longo de linhas legadas de componentes e departamentos, com transferências por toda parte. É aqui que um modelo deliberado de desenho de equipes justifica o seu custo — remodelar equipes de componentes em equipes alinhadas ao fluxo, montar equipes de plataforma para as capacidades de prontuário de cuidados compartilhado e integração e usar equipes habilitadoras para espalhar a expertise escassa de segurança clínica e acessibilidade. O RACI e os direitos de decisão explícitos se tornam essenciais porque o grande número de partes interessadas torna impossível a coordenação informal. A Manobra Conway Inversa é uma alavanca viva aqui: um organograma de décadas já está moldando a arquitetura; os líderes devem, portanto, redesenhar as fronteiras das equipes intencionalmente em vez de deixar que a estrutura projete o prontuário por eles.

Governo#

Um órgão nacional (NHS England, DHSC) ou uma autoridade local define os padrões frente aos quais os outros dimensionam as equipes — o Government Digital and Data capability framework, o Service Standard, a DCB0129/0160 — e responde perante o Parlamento e o público pela forma como o dinheiro compra capacidade de equipe. As estruturas aqui são moldadas pelas regras de aquisição e financiamento: boa parte da entrega é terceirizada a fornecedores; os papéis cruciais a reter internamente são, portanto, os de cliente inteligente (propriedade do produto, garantia técnica, aprovação de segurança clínica), que evitam o esvaziamento da capacidade. A responsabilização é formal e auditável — um Responsável Sênior (SRO) nomeado, controles de gasto publicados, deveres de transparência —, de modo que os modelos de responsabilidade são questão de registro público, e não higiene opcional. O risco característico é que a estrutura se ossifique em conselhos de programa e portões permanentes que estrangulam o fluxo; a contramedida é cobrar dos fornecedores equipes alinhadas ao fluxo e donas de resultados, e não agências de fornecimento de mão de obra.

Modos de falha comuns#

• A armadilha da equipe de componente. Equipes divididas por camada de tecnologia ("equipe de front-end", "equipe do banco de dados") criam transferências a cada funcionalidade e não são donas de resultado algum. Reorganizem em torno de fluxos de valor.
• Spotify por culto de carga. Copiar "esquadrões, tribos, capítulos, guildas" como rótulos, sem a autonomia, o alinhamento e o investimento em plataforma por baixo. O modelo Spotify foi um retrato de uma empresa num momento — até o Spotify seguiu adiante. Tomem emprestados os princípios, e não o organograma.
• O gargalo heroico. Um CSO, um arquiteto ou um líder de governança da informação como parte Consultada em tudo, de modo que toda equipe espera. Convertam-nos numa capacidade habilitadora que eleve a competência de todos.
• Governança como reflexão tardia. Segurança clínica e governança da informação representadas como portões externos e não como membros incorporados da equipe, de modo que suas preocupações chegam tarde demais para agir a baixo custo.
• Equipes sem limite. Uma equipe que continua absorvendo serviços até que ninguém entenda o todo. A sobrecarga cognitiva aparece como desaceleração da entrega e erosão da confiança na segurança.
• Colaboração permanente. Duas equipes "colaborando" indefinidamente costumam ser sinal de uma fronteira ausente. Deem prazo à colaboração e passem a uma interface limpa de serviço.

Modelo de maturidade#

Lista de verificação#

• Todo serviço tem uma equipe alinhada ao fluxo que é dona dele de ponta a ponta.
• Cada equipe contém, ou tem acesso nomeado a, produto, entrega, pesquisa, design, engenharia, dados, segurança clínica e governança da informação.
• Um Responsável pela Segurança Clínica nomeado e treinado, por equipe, tem tempo protegido e autoridade para barrar uma versão.
• As capacidades compartilhadas (integração, identidade, APIs de prontuário de cuidados) são operadas como plataformas internas consumidas como serviço.
• Os especialistas escassos atuam por equipes habilitadoras com prazo definido, e não como gargalos permanentes.
• Existe um RACI (ou equivalente) para a aprovação clínica, a entrada em produção, a aprovação de governança da informação e o gasto, e ele é de fato usado.
• Cada dependência entre equipes tem um modo de interação nomeado (colaboração / X-como-serviço / facilitação).
• Os domínios das equipes são delimitados a uma carga cognitiva administrável; as equipes sobrecarregadas são divididas.
• As fronteiras das equipes são escolhidas deliberadamente para produzir a arquitetura e a interoperabilidade desejadas.

Fontes-chave#

• Team Topologies — Matthew Skelton & Manuel Pais (quatro tipos de equipe, três modos de interação, carga cognitiva): teamtopologies.com
• NHS Digital Service Standard e NHS Service Manual — papéis de equipes multidisciplinares e modos de trabalho
• GOV.UK Service Manual (GDS) — "Set up a service team" e orientações de entrega ágil
• Government Digital and Data (antes DDaT) Profession Capability Framework — definições de papéis: ddat-capability-framework.service.gov.uk
• Padrões de gestão de risco clínico DCB0129 (fabricação) e DCB0160 (implantação), NHS Digital — papel do Responsável pela Segurança Clínica
• Lei de Conway — Melvin Conway, "How Do Committees Invent?" (1968)
• Cultura de engenharia do Spotify (Henrik Kniberg) — esquadrões/tribos/capítulos/guildas, lida criticamente como um modelo pontual no tempo

Referências#

1. Conway's law — Wikipedia — https://en.wikipedia.org/wiki/Conway%27s_law
2. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
3. Responsibility assignment matrix (RACI) — Wikipedia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
4. Interdisciplinarity — Wikipedia — https://en.wikipedia.org/wiki/Interdisciplinarity
5. Sociotechnical system — Wikipedia — https://en.wikipedia.org/wiki/Sociotechnical_system
6. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais — https://teamtopologies.com
8. NHS Service Manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk
9. Service Manual — Government Digital Service (GDS), GOV.UK — https://www.gov.uk/service-manual
10. Government Digital and Data Profession Capability Framework — GOV.UK — https://ddat-capability-framework.service.gov.uk
11. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
12. "How Do Committees Invent?" (1968) — Melvin E. Conway — http://www.melconway.com/Home/Committees_Paper.html

Ver também Tópico 7.2 — Planejamento da força de trabalho, Tópico 7.3 — Estratégia da força de trabalho, Tópico 7.5 — Desenvolvimento de pessoas e da organização e Tópico 8.1 — Gestão de mudanças.