Tema 7.0 — Estructuras de equipo, roles, y responsabilidades

En una frase: La entrega de salud digital tiene éxito o falla según cómo dibujas los límites entre equipos y cuán claramente nombras quién hace qué —así que estructura los equipos para un flujo de valor rápido y seguro, dótalos multidisciplinariamente, y haz explícitas las responsabilidades.

Por qué esto importa en la salud y la atención#

La forma en que organizas tus equipos se convierte en la forma en que se comportan tus servicios. La Ley de Conway —que el diseño de un sistema refleja la estructura de comunicación de la organización que lo construyó— no es una curiosidad en la salud y la atención; es un riesgo de seguridad del paciente. Los equipos fragmentados producen registros de atención fragmentados, integraciones frágiles, y traspasos donde se oculta el riesgo clínico.

En el NHS y la atención social también estás gastando dinero público y llevando deberes estatutarios: seguridad clínica bajo DCB0129/DCB0160, gobernanza de la información bajo UK GDPR y el deber de confidencialidad del derecho consuetudinario, y obligaciones de accesibilidad. Estos deberes no se pueden añadir al final. Deben representarse dentro del equipo, por personas nombradas con la autoridad y tiempo para cumplirlos.

Acierta la estructura y los equipos multidisciplinarios envían software funcionando en el que confían los clínicos y que los pacientes pueden usar. Equivócala y obtienes especialistas ocupados optimizando su propio silo mientras el servicio en su conjunto se estanca —el patrón clásico detrás de los programas digitales tardíos, sobre presupuesto, y silenciosamente abandonados.

Conceptos clave#

Equipos multidisciplinarios (MDT). Un equipo de entrega digital debería contener cada disciplina necesaria para diseñar, construir, y operar un servicio sin dependencia externa constante —producto, entrega, diseño, investigación, ingeniería, datos, y las perspectivas clínicas y de gobernanza. Esto refleja el concepto de MDT clínico que el personal ya conoce: experiencia mixta, responsabilidad compartida por un resultado.

Team Topologies. Un modelo (Skelton & Pais) que reduce el diseño de equipo efectivo a cuatro tipos fundamentales y tres modos de interacción, todos al servicio del flujo rápido de valor:

• Equipo alineado al flujo —organizado alrededor de un único flujo valioso de trabajo (un servicio, un recorrido de usuario, un producto) y poseyéndolo de extremo a extremo. Este es el tipo de equipo predeterminado; la mayoría de las personas deberían estar en uno.
• Equipo de plataforma —proporciona capacidades de autoservicio internas (infraestructura compartida, un motor de integración, un servicio de inicio de sesión, una API de registro de atención compartido) para que los equipos alineados al flujo vayan más rápido sin reinventarlas.
• Equipo habilitador —un equipo con límite de tiempo de especialistas (p. ej. seguridad clínica, accesibilidad, automatización de pruebas) que entrena a otros para elevar una capacidad, luego se retira.
• Equipo de subsistema complicado —posee una parte que necesita conocimiento especializado profundo (un algoritmo de puntuación de riesgo, una interfaz de NHS Spine) que sobrecargaría a un equipo generalista.

Los tres modos de interacción gobiernan cómo se relacionan dos equipos cualesquiera: colaboración (trabajar estrechamente durante un período definido, de alto ancho de banda, tolerando algo de ineficiencia para descubrir cosas), X-como-servicio (un equipo consume la capacidad de otro con mínimo alboroto, el predeterminado de baja fricción a escala), y facilitación (un equipo ayuda a otro a aprender). Nombrar el modo previene la ambigüedad que genera retrasos y culpa.

Carga cognitiva. Un equipo solo puede mantener tanto en su cabeza. Team Topologies argumenta que deberías limitar el dominio que posee cada equipo a lo que puede razonar de forma segura —un principio decisivo cuando el dominio es clínico.

La Ley de Conway y la Maniobra Conway Inversa. Dado que la arquitectura sigue la estructura organizacional —una vista de sistema sociotécnico que trata a los equipos y la tecnología como un solo diseño— da forma deliberadamente a los equipos para producir la arquitectura que quieres. Si quieres un registro de atención modular e interoperable, no lo construyas con un equipo monolítico.

Buenas prácticas#

1. Dotar de personal a un equipo multidisciplinario completo alrededor de cada servicio. Incluye, como mínimo, un gerente de producto, un gerente de entrega, un investigador de usuarios, un diseñador de servicio/interacción, ingenieros, y una capacidad de datos/analítica, más aporte nombrado de seguridad clínica y gobernanza de la información. Un equipo al que le falta una disciplina o esperará a alguien más o se saltará ese trabajo —y el trabajo saltado en la salud generalmente es seguridad, accesibilidad, o gobernanza.

2. Hacer que la mayoría de los equipos estén alineados al flujo y darles propiedad de extremo a extremo. Organiza alrededor del recorrido de un usuario (p. ej. "derivación ambulatoria") en lugar de una capa tecnológica (p. ej. "el equipo de base de datos"). La propiedad de extremo a extremo acorta los bucles de retroalimentación y detiene las brechas de traspaso donde se acumula el riesgo clínico.

3. Construir plataformas como productos, consumidas como servicio. Trata tu motor de integración, servicio de identidad, o API de registro de atención compartido como un producto interno con su propio equipo, hoja de ruta, y usuarios. Publícalo "como servicio" para que los equipos alineados al flujo se autoservicio, en lugar de levantar tickets y esperar.

4. Usar equipos habilitadores para difundir la experiencia escasa, no acumularla. Los oficiales de seguridad clínica, especialistas en accesibilidad, e ingenieros de seguridad son raros. Despliégalos para entrenar a los equipos de entrega a un estándar más alto y luego seguir adelante, en lugar de convertirse en un cuello de botella permanente detrás del cual todos los equipos hacen cola.

5. Nombrar cada rol y sus derechos de decisión explícitamente. Usa un modelo de responsabilidad —RACI (Responsable, Aprobador, Consultado, Informado) o una división más simple de "decisor/asesor"— para las decisiones que importan: aprobación de seguridad clínica, puesta en marcha, aprobación de gobernanza de la información, gasto. La ambigüedad aquí es donde se evapora la responsabilidad.

6. Dar al oficial de seguridad clínica autoridad real y tiempo real. DCB0129/0160 requiere un oficial de seguridad clínica nombrado y adecuadamente entrenado que pueda detener una versión. Haz explícito el rol en el equipo, protege su tiempo, y asegúrate de que pueda decir no —un CSO solo de nombre es un fallo de gobernanza esperando ser encontrado por un incidente.

7. Gestionar la carga cognitiva delimitando el dominio. Si un equipo posee demasiados servicios o un dominio clínico demasiado complejo, divídelo. Vigila la señal: un equipo que ya no puede explicar con confianza las implicaciones de seguridad de su propio cambio está sobrecargado.

8. Aplicar la Maniobra Conway Inversa deliberadamente. Dibuja los límites de equipo para que coincidan con la arquitectura e interoperabilidad que quieres —equipos modulares para sistemas modulares y basados en estándares (p. ej. HL7 FHIR). No dejes que un organigrama accidental diseñe tu registro de atención por ti.

Preguntas para debatir con tu equipo#

1. ¿Dónde ya está nuestro organigrama actual diseñando nuestra arquitectura por nosotros —y esa es la arquitectura que realmente queremos? La Ley de Conway no es opcional: sea cual sea la forma de nuestros equipos, los sistemas llegarán a reflejarla, así que el primer movimiento honesto es mirar el registro de atención, las integraciones, y los traspasos que ya tenemos y preguntar qué límite de equipo produjo cada costura. En un entorno de salud y atención esas costuras son donde se oculta el riesgo clínico —un registro fragmentado, una interfaz Spine frágil, un caso de seguridad que ningún equipo posee— así que esta es una conversación de seguridad del paciente, no una estética. La tensión a debatir es que redibujar los límites de equipo para obtener la arquitectura que queremos (la Maniobra Conway Inversa) es disruptivo, amenaza feudos establecidos, y atraviesa estructuras de financiación y gestión de línea que quizás no controlemos completamente. Considera mapear dos o tres de tus integraciones más dolorosas de vuelta a los equipos que poseen cada extremo, y pregunta si un límite alineado al flujo habría eliminado el traspaso por completo. Una buena respuesta nombra al menos un límite concreto que moverías, es honesta sobre quién resistiría y por qué, y distingue los cambios que valen la disrupción de aquellos donde una interfaz como servicio arreglaría la fricción más barato.

2. ¿Nuestros especialistas escasos —seguridad clínica, gobernanza de la información, accesibilidad— se sitúan dentro de equipos con autoridad real, o son puertas externas detrás de las cuales todos hacen cola? Cada servicio en esta familia lleva deberes estatutarios (seguridad clínica DCB0129/0160, UK GDPR y el deber de confidencialidad del derecho consuetudinario, ley de accesibilidad) que no se pueden añadir al final, sin embargo estas capacidades son raras y caras, lo que empuja a las organizaciones hacia acumularlas centralmente. La disyuntiva es genuina: incorpora a un oficial de seguridad clínica en cada equipo y difundes experiencia delgada hasta que se diluye; centralízala y creas el cuello de botella heroico donde una persona es Consultada sobre todo y cada versión espera. El patrón de equipo habilitador —especialistas con límite de tiempo que entrenan a los equipos a ejecutar sus propios talleres de peligros y luego se retiran— es la resolución propuesta, pero solo funciona si el liderazgo protege el tiempo de los especialistas para enseñar en lugar de hacer. Mira honestamente tu propio historial de versiones: ¿con qué frecuencia se deslizó la puesta en marcha esperando por una sola persona nombrada, y esa persona tenía la autoridad y tiempo protegido para decir no de forma segura? Una respuesta sólida enfrenta la escasez directamente, elige una posición deliberada sobre incorporar-versus-habilitar para cada deber, y nombra la autoridad específica (el poder de detener una versión) que nunca debe diluirse sin importar cómo distribuyas la capacidad.

3. ¿Cómo sabríamos que un equipo ha asumido más carga cognitiva de la que puede llevar de forma segura —y qué haríamos realmente al respecto? La carga cognitiva es el gobernador silencioso de la entrega segura: un equipo solo puede razonar sobre tanto dominio clínico y tantos servicios antes de que su confianza en las implicaciones de seguridad de sus propios cambios comience a erosionarse, y en la salud esa erosión es invisible hasta que un incidente la expone. La dificultad es que la sobrecarga raramente se anuncia a sí misma —se ve como una entrega ligeramente más lenta, más defectos, más "déjame verificar con alguien", y los equipos bajo presión tienden a absorberla en lugar de marcarla, especialmente cuando dividir un equipo es políticamente costoso o el número de personal está congelado. Debate cuáles serían tus señales de alerta temprana (un equipo que ya no puede explicar con confianza el caso de seguridad de su propia versión es una fuerte), y si tienes algún mecanismo hoy que sacaría a la luz la sobrecarga antes de que la entrega se estanque visiblemente. Considera también la contrapresión: dividir equipos crea nuevos límites y traspasos, así que la cura puede reintroducir el riesgo de fragmentación de la primera pregunta. Una respuesta honesta acuerda señales concretas y observables en lugar de un vago "lo sentiríamos", nombra quién tiene la autoridad para delimitar el dominio de un equipo o dividirlo, y admite la disyuntiva entre alivio de carga y proliferación de límites.

4. ¿Cuáles de nuestras capacidades compartidas deberían operarse como plataformas consumidas como servicio, y realmente les estamos dotando de recursos de esa manera —o solo reetiquetando una cola de tickets? La promesa de un equipo de plataforma es que los equipos alineados al flujo se autoservicio un motor de integración, un servicio de identidad, o una API de registro de atención compartido sin levantar un ticket y esperar, así que todo el sistema va más rápido; el fallo es llamar "plataforma" a algo que sigue siendo una función central sin personal suficiente detrás de la cual todos siguen haciendo cola. La disyuntiva es real: construir una capacidad como un producto interno genuino significa darle su propio equipo, hoja de ruta, documentación, y usuarios, lo cual es una inversión seria que compite con enviar funciones orientadas al usuario, y en un entorno del NHS limitado en efectivo esa inversión es fácil de aplazar indefinidamente. En la salud y la atención lo que está en juego es más agudo porque las capacidades compartidas a menudo son las críticas para la seguridad —el índice de emparejamiento de personas, las interfaces FHIR, el rastro de auditoría— donde un equipo de plataforma delgado se convierte en un punto único de fallo para cada servicio encima de él. Mira las capacidades de las que ya dependen varios equipos y pregunta, para cada una, si la interacción es verdaderamente X-como-servicio de baja fricción o una colaboración disfrazada con esperas ocultas. Una respuesta honesta nombra qué capacidades genuinamente merecen inversión de plataforma ahora frente a después, es clara sobre quién las financia y dota de personal, y resiste la tentación de declarar una plataforma que no tiene propietario de producto, ni hoja de ruta, ni ruta de autoservicio.

5. ¿Dónde estamos dependiendo de proveedores contratados o personal prestado, y qué roles debemos mantener internamente para seguir siendo un cliente inteligente en lugar de uno vaciado? Gran parte de la entrega digital en la salud y la atención se subcontrata, y un proveedor puede traer capacidad y especialización rápido —pero si la propiedad de producto, el aseguramiento técnico, y la aprobación de seguridad clínica todos salen del edificio con el contrato, la organización pierde la capacidad de juzgar lo que se le está vendiendo, especificar lo que necesita, o poseer de forma segura el resultado. La tensión es entre velocidad y capacidad: el aumento de personal y las construcciones llave en mano ponen algo en vivo rápidamente, sin embargo pueden erosionar silenciosamente el músculo interno que te permite responsabilizar a un proveedor, y a menudo entregan estructuras con forma de componente y de fuerte traspaso en lugar de equipos alineados al flujo que poseen un resultado. En este dominio los roles retenidos no negociables se agrupan en torno a la responsabilidad que no se puede delegar —el propietario senior responsable, el oficial de seguridad clínica que aprueba la puesta en marcha, el propietario de producto que decide prioridades, y suficiente aseguramiento técnico para inspeccionar lo que construyen los proveedores. Examina tu entrega actual y pregunta qué capacidades no podrías reconstituir si un proveedor se marchara mañana. Una buena respuesta distingue el trabajo que genuinamente está bien contratar del núcleo de cliente inteligente que debe permanecer interno, insiste en que los equipos contratados se responsabilicen de la propiedad de resultado en lugar de dotación de personal de taller de cuerpos, y nombra las decisiones de seguridad y gobernanza que siempre deben descansar en tu propia gente responsable.

6. ¿Cómo sabremos que nuestra estructura de equipo realmente está produciendo un flujo rápido y seguro de valor —y qué nos activaría a redibujarla? El diseño de equipo es un medio, no un fin: el punto de los equipos alineados al flujo, plataformas, y modos de interacción nombrados es la entrega más rápida y segura de valor, sin embargo las organizaciones raramente instrumentan si la estructura está entregando eso, así que las reorganizaciones suceden por política e intuición en lugar de evidencia. La dificultad es elegir señales que reflejen el flujo y la seguridad sin manipularlas —la velocidad bruta o el rendimiento de puntos de historia invita al comportamiento equivocado, mientras que las métricas de flujo (tiempo de espera desde idea hasta en vivo, frecuencia de despliegue, conteo de traspasos por cambio) y los indicadores de seguridad (cuán rápido se cierran los peligros, si los equipos poseen su propio caso de seguridad) te dicen más sobre si los límites están ayudando o dañando. Hay una tensión real con la estabilidad: la reorganización constante destruye la longevidad de equipo y el espacio cognitivo compartido que hacen segura la entrega, así que necesitas una barra alta y activadores claros antes de redibujar los límites. Discute qué evidencia te diría que un límite está equivocado —esperas persistentes entre equipos, un caso de seguridad que ningún equipo posee, una plataforma que nadie autoservicio— y quién está facultado para actuar sobre ello. Una respuesta honesta se compromete a un pequeño conjunto de señales de flujo y seguridad que realmente vigilarás, establece un umbral deliberado que protege la estabilidad del equipo, y nombra las condiciones de activación y el tomador de decisión para cualquier remodelación futura.

En la práctica: un ejemplo de salud y atención#

Un sistema de atención integrada (ICS) está desplegando un registro de atención compartido a través de agudos, comunidad, salud mental, atención primaria, y atención social.

El instinto es crear un gran "equipo de registro de atención compartido". En cambio, el ICS aplica Team Topologies. Un equipo de plataforma posee el núcleo del registro compartido: el índice de emparejamiento de personas, las API FHIR, y el motor de integración, publicados como capacidades de autoservicio. Varios equipos alineados al flujo cada uno posee un recorrido de usuario real encima de él —"ver el registro de un paciente en urgencias", "vista de salvaguardia del trabajador social", "conciliación de medicamentos del médico de cabecera"— y consumen la plataforma como servicio. Un equipo de subsistema complicado posee el algoritmo probabilístico de emparejamiento de pacientes, donde una coincidencia falsa es un incidente de seguridad genuino. Un equipo habilitador de especialistas en seguridad clínica y accesibilidad rota a través de los equipos alineados al flujo, entrenándolos a ejecutar sus propios talleres de peligros DCB0160 en lugar de hacerlo por ellos.

Cada equipo tiene un gerente de producto nombrado, gerente de entrega, y oficial de seguridad clínica, y un RACI deja claro que la puesta en marcha es responsabilidad del propietario senior responsable pero no puede proceder sin la aprobación del CSO e IG. Cuando el equipo de urgencias necesita un nuevo campo de datos, el modo de interacción es explícito: X-como-servicio del equipo de plataforma vía una solicitud de API documentada, no una colaboración de seis semanas. La entrega es más rápida y, crucialmente, el caso de seguridad para cada recorrido lo posee el equipo que lo envía.

Perspectivas sectoriales#

Startup#

Una startup de salud digital de diez personas no puede dotar de personal a cuatro tipos de equipo distintos —generalmente es un único equipo alineado al flujo en el que una persona lleva varios sombreros (un ingeniero que también dirige la investigación de usuarios, un clínico-fundador que es el oficial de seguridad clínica de facto). La prioridad es mantener a todo el equipo dentro de un espacio cognitivo compartido para que las decisiones sean rápidas; un RACI formal es excesivo cuando todos están en la misma habitación. El riesgo real es el cuello de botella del fundador: la seguridad clínica y gobernanza de la información descansan en una persona ocupada, y las obligaciones DCB0129/0160 son fáciles de aplazar. A medida que la empresa gana su primer contrato del NHS, las primeras contrataciones de especialista deberían ser las que reduzcan el riesgo de esa puerta —un CSO nombrado y un líder de IG— antes de escalar el número de personal de ingeniería.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, o una clínica de un solo emplazamiento— tiene pacientes reales y operaciones continuas pero raramente un equipo digital o de TI dedicado, así que no hay "topología de equipo" que diseñar; el gerente de la consulta o un líder clínico es efectivamente toda la capacidad de entrega junto a su trabajo diario. El movimiento realista no es construir equipos de plataforma y habilitadores sino nombrar responsabilidades explícitamente en las personas que ya tienes —quién es el oficial de seguridad clínica para los sistemas que despliegas, quién posee la gobernanza de la información, quién aprueba un cambio— incluso si esos son sombreros a tiempo parcial en un puñado de personal. Porque los mismos deberes estatutarios (DCB0129/0160, UK GDPR, accesibilidad) aplican como lo hacen para un gran fideicomiso, el patrón práctico es apoyarse en las plataformas compartidas y apoyo habilitador de tus proveedores y tu ICS en lugar de reinventarlos, mientras retienes solo suficiente capacidad de cliente inteligente para responsabilizar a los proveedores. El mayor riesgo individual es el cuello de botella de una persona: si la única persona que entiende el sistema clínico se va, tanto la seguridad como la continuidad se van con ella, así que escribir el RACI y capacitar de forma cruzada a una segunda persona importa más aquí que cualquier modelo de equipo formal.

Gran organización#

Un gran fideicomiso del NHS o empresa de tecnología de salud tiene el problema opuesto: demasiados equipos, dibujados según líneas heredadas de componente y departamentales, con traspasos por todas partes. Aquí es donde un modelo de diseño de equipo deliberado se gana su lugar —remodelando equipos de componente en alineados al flujo, estableciendo equipos de plataforma para capacidades de registro de atención compartido e integración, y usando equipos habilitadores para difundir la escasa experiencia en seguridad clínica y accesibilidad. RACI y derechos de decisión explícitos se vuelven esenciales porque el mero número de partes interesadas hace imposible la coordinación informal. La Maniobra Conway Inversa es una palanca viva aquí: un organigrama de décadas de antigüedad ya está dando forma a la arquitectura, así que los líderes deben redibujar los límites de equipo intencionalmente en lugar de dejar que la estructura diseñe el registro de atención por ellos.

Gobierno#

Un organismo nacional (NHS England, DHSC) o autoridad local establece los estándares contra los cuales otros dotan de personal —el Government Digital and Data capability framework, el Service Standard, DCB0129/0160— y es responsable ante el Parlamento y el público de cómo el dinero compra capacidad de equipo. Las estructuras aquí son moldeadas por reglas de contratación y financiación: gran parte de la entrega se contrata a proveedores, así que los roles cruciales a retener internamente son los de cliente inteligente (propiedad de producto, aseguramiento técnico, aprobación de seguridad clínica) que previenen que la capacidad sea vaciada. La responsabilidad es formal y auditable —un propietario senior responsable nombrado, controles de gasto publicados, deberes de transparencia— así que los modelos de responsabilidad son un asunto de registro público, no higiene opcional. El riesgo característico es que la estructura se osifique en juntas de programa permanentes y puertas que estrangulan el flujo; el contramovimiento es responsabilizar a los proveedores según equipos alineados al flujo que poseen resultados en lugar de talleres de aumento de personal.

Modos de fallo comunes#

• La trampa del equipo de componente. Los equipos divididos por capa tecnológica ("equipo de front-end", "equipo de base de datos") crean traspasos en cada función y no poseen ningún resultado. Reorganiza alrededor de flujos de valor.
• Cargo-cult Spotify. Copiar "escuadrones, tribus, temas, gremios" como etiquetas sin la autonomía, alineación, e inversión de plataforma subyacentes. El modelo Spotify fue una instantánea de una empresa en un momento —incluso Spotify siguió adelante. Toma prestados principios, no el organigrama.
• El cuello de botella heroico. Un CSO, un arquitecto, o un líder IG como parte Consultada en todo, así que cada equipo espera. Conviértelos en una capacidad habilitadora que eleva la competencia de todos.
• Gobernanza como idea de última hora. Seguridad clínica e IG representadas como puertas externas en lugar de miembros de equipo incorporados, así que sus preocupaciones llegan demasiado tarde para actuar barato.
• Equipos sin límites. Un equipo que sigue absorbiendo servicios hasta que nadie entiende el todo. La sobrecarga cognitiva se muestra como entrega ralentizándose y confianza de seguridad erosionándose.
• Colaboración permanente. Dos equipos "colaborando" indefinidamente generalmente es un límite faltante. Pon límite de tiempo a la colaboración y muévete a una interfaz limpia como servicio.

Modelo de madurez#

Lista de verificación#

• Cada servicio tiene un equipo alineado al flujo que lo posee de extremo a extremo.
• Cada equipo contiene, o tiene acceso nombrado a, producto, entrega, investigación, diseño, ingeniería, datos, seguridad clínica, y gobernanza de la información.
• Un oficial de seguridad clínica nombrado y entrenado por equipo tiene tiempo protegido y autoridad para detener una versión.
• Las capacidades compartidas (integración, identidad, API de registro de atención) se operan como plataformas internas consumidas como servicio.
• Los especialistas escasos trabajan a través de equipos habilitadores con límite de tiempo, no cuellos de botella permanentes.
• Existe un RACI (o equivalente) para aprobación clínica, puesta en marcha, aprobación IG, y gasto, y realmente se usa.
• Cada dependencia entre equipos tiene un modo de interacción nombrado (colaboración / X-como-servicio / facilitación).
• Los dominios de equipo están delimitados a una carga cognitiva manejable; los equipos sobrecargados se dividen.
• Los límites de equipo se eligen deliberadamente para producir la arquitectura e interoperabilidad que quieres.

Fuentes clave#

• Team Topologies — Matthew Skelton & Manuel Pais (cuatro tipos de equipo, tres modos de interacción, carga cognitiva): teamtopologies.com
• NHS Digital Service Standard y NHS Service Manual — roles de equipo multidisciplinario y formas de trabajar
• GOV.UK Service Manual (GDS) — "Set up a service team" y orientación de entrega ágil
• Government Digital and Data (anteriormente DDaT) Profession Capability Framework — definiciones de rol: ddat-capability-framework.service.gov.uk
• Estándares de gestión de riesgo clínico DCB0129 (fabricación) y DCB0160 (despliegue), NHS Digital — rol de oficial de seguridad clínica
• Ley de Conway — Melvin Conway, "How Do Committees Invent?" (1968)
• Cultura de ingeniería de Spotify (Henrik Kniberg) — escuadrones/tribus/capítulos/gremios, léelo críticamente como un modelo de un momento en el tiempo

Referencias#

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

Véase también el Tema 7.2 — Planificación de la fuerza laboral, el Tema 7.3 — Estrategia de fuerza laboral, el Tema 7.5 — Desarrollo de personas y organizacional, y el Tema 8.1 — Gestión del cambio.