El verdadero salto de desarrollador a CTO no ocurre cuando dejas de escribir código. Ocurre cuando conviertes tu criterio individual en un sistema de trabajo: uno donde el equipo puede decidir, entregar y responder a una incidencia aunque tú no estés disponible.
Hay un momento en la carrera de muchos desarrolladores en el que aquello que te hizo destacar empieza, paradójicamente, a convertirse en un problema.
Durante años, tu valor estaba muy claro.
Eras quien encontraba el bug que nadie conseguía reproducir. Quien entendía aquella parte del código que llevaba años sin tocarse. Quien podía entrar en producción, mirar cuatro logs y saber por dónde empezar a buscar.
Cuando algo se complicaba, alguien acababa diciendo:
Pregúntale a él.
Y eso, durante mucho tiempo, se siente bien.
Hasta que un día descubres que demasiadas cosas dependen de que alguien siga diciendo esa frase.
El salto real de desarrollador a CTO no ocurre cuando dejas de escribir código. Ni siquiera ocurre necesariamente cuando empiezas a gestionar personas.
Ocurre cuando entiendes que tu principal responsabilidad ya no consiste en resolver todos los problemas técnicos.
Consiste en diseñar un sistema de trabajo en el que el equipo pueda tomar buenas decisiones, entregar software y resolver problemas sin depender constantemente de ti.
En este artículo no vas a encontrar una lista de herramientas de gestión ni un organigrama ideal. Vas a encontrar algo más útil: un diagnóstico en cinco áreas, criterios para repartir decisiones y una secuencia de 30 días para reducir dependencias sin perder control técnico.
Este artículo es para ti si…
- lideras un equipo de desarrollo pequeño o mediano y casi todo termina escalando hasta ti;
- quieres seguir siendo un CTO hands-on sin ocupar el camino crítico;
- tu empresa necesita crecer, modernizar un legacy o repartir conocimiento antes de que la dependencia se convierta en riesgo.
Este es el recorrido:
- Durante años, tu valor estaba en resolver problemas
- El problema aparece cuando todo empieza a pasar por ti
- El cambio de mentalidad: construir capacidad, no solo software
- El mapa de autonomía técnica: cinco áreas que conviene medir
- El equipo como nueva arquitectura
- Dejar de responder todas las preguntas
- Diseñar cómo entra el trabajo
- Los procesos no son burocracia: son la memoria del equipo
- CTO hands-on: cerca del código, fuera del camino crítico
- Plan de 30 días para empezar sin paralizar al equipo
- Señales de que el sistema empieza a funcionar
- Cuándo tiene sentido pedir una mirada externa
- Preguntas frecuentes sobre el salto de desarrollador a CTO
Durante años, tu valor estaba en resolver problemas
En desarrollo de software existe un camino bastante habitual.
Empiezas resolviendo tareas pequeñas.
Con el tiempo entiendes mejor el producto, la arquitectura y el negocio. Empiezas a asumir problemas más complejos. Conoces las zonas delicadas del sistema. Sabes qué decisiones se tomaron hace cinco años y por qué.
Poco a poco te conviertes en la persona que desbloquea al resto.
- El compañero que resuelve la incidencia difícil.
- También revisas los cambios importantes.
- Sabes cómo desplegar aquel servicio antiguo.
- Conoces la configuración que nadie se atreve a modificar.
- Llevas en la cabeza la arquitectura real del sistema.
Es fácil interpretar esta situación como una señal de éxito profesional.
Y, hasta cierto punto, lo es.
El problema aparece cuando ser imprescindible deja de ser una consecuencia de tu experiencia y empieza a convertirse en una característica del sistema.
El problema aparece cuando todo empieza a pasar por ti
Hay síntomas bastante fáciles de reconocer.
- Pull requests esperando tu revisión.
- Decisiones técnicas bloqueadas hasta que vuelves de una reunión.
- Una incidencia de producción que nadie quiere tocar porque tú conoces mejor el sistema.
- Despliegues que solo sabe ejecutar una persona.
- Preguntas que podrían resolverse dentro del equipo, pero que terminan siempre llegando a ti.
Y una frase especialmente peligrosa:
Mejor esperamos a que vuelva.
En ese momento, tu capacidad técnica ya no está multiplicando al equipo.
Está limitándolo.
No porque estés haciendo mal tu trabajo, sino porque el sistema ha aprendido a depender de ti.
Y cuanto más competente eres resolviendo problemas, más fácil resulta caer en esa trampa.
Responder tú es más rápido.
Revisarlo tú es más seguro.
Arreglarlo tú lleva menos tiempo que explicarlo.
Tomar tú la decisión evita una reunión.
El problema es que esa optimización funciona muy bien a corto plazo y escala fatal.
Cada problema que solucionas exclusivamente tú refuerza la dependencia.
Las decisiones que solo existen en tu cabeza aumentan el riesgo.
Además, cualquier proceso que requiere tu intervención reduce la autonomía real del equipo.
Hasta que llega un momento en el que eres simultáneamente una de las personas más valiosas de la organización y uno de sus principales cuellos de botella.
Advertencia
Cuanto más competente eres, más invisible se vuelve el cuello de botella. Cada urgencia que resuelves refuerza el patrón, y casi nadie lo percibe como dependencia hasta el día que te vas de vacaciones, cambias de rol o, simplemente, te pones enfermo.
De desarrollador a CTO: construir capacidad, no solo software
Aquí empieza, para mí, la parte más importante de la transición de desarrollador a CTO.
Dejas de optimizar únicamente el software.
Empiezas a optimizar el sistema que produce ese software.
Eso significa seguir preocupándote por arquitectura, calidad, seguridad o rendimiento, pero ampliar el foco.
Empiezas a preguntarte otras cosas.
- ¿Cómo se toman las decisiones técnicas?
- ¿Cómo entra el trabajo al equipo?
- ¿Quién decide qué es prioritario?
- ¿Qué ocurre cuando aparece una incidencia?
- ¿Dónde se documenta una decisión importante?
- ¿Quién puede desplegar a producción?
- ¿Qué pasa cuando una persona se va de vacaciones?
- ¿Quién conoce cada aplicación?
- ¿Cómo aprende alguien nuevo cómo funciona el sistema?
- ¿Puede un desarrollador tomar una decisión sin pedir permiso constantemente?
Son preguntas menos atractivas que diseñar una arquitectura distribuida o resolver un problema de rendimiento.
Pero muchas veces tienen bastante más impacto.
Porque una buena arquitectura técnica dentro de un mal sistema de trabajo termina degradándose.
Un buen equipo dentro de un sistema bien diseñado puede mejorar progresivamente incluso una arquitectura mediocre.
Idea clave
Tu capacidad técnica deja de multiplicar al equipo el día que el equipo no puede avanzar sin ella. El objetivo del liderazgo técnico no es ser la mejor pieza del sistema, sino diseñar un sistema que funcione bien incluso con piezas normales.
El mapa de autonomía técnica: cinco áreas que conviene medir
Antes de implantar ceremonias en el paso de desarrollador a CTO, cambiar de herramienta o escribir cincuenta páginas de documentación, mediría la dependencia.
En equipos de entre tres y quince personas, los problemas rara vez están aislados. Una mala entrada de trabajo termina concentrando decisiones. Las decisiones concentradas convierten las revisiones en una cola. La cola obliga al CTO a intervenir. Y esa intervención refuerza, otra vez, la dependencia.
Para evitar diagnósticos vagos utilizo cinco áreas. No son un modelo académico ni una certificación. Son una forma práctica de localizar dónde se está perdiendo autonomía y elegir una intervención concreta.
| Área | Síntoma de dependencia | Evidencia que buscaría | Primer movimiento |
|---|---|---|---|
| Entrada | El trabajo llega por cinco canales | Tareas iniciadas fuera del backlog y cambios de prioridad durante el sprint | Unificar entrada y separar urgencias reales |
| Decisión | Todo necesita la aprobación del CTO | PRs y decisiones esperando a una persona | Definir niveles de decisión y escalado |
| Conocimiento | Cada sistema tiene un único experto | Vacaciones que bloquean, onboarding lento y preguntas repetidas | Ownership compartido, ADRs y runbooks mínimos |
| Entrega y operación | Desplegar o responder a producción da miedo | Deploys manuales, rollback incierto y alertas sin propietario | Automatizar el camino frecuente y ensayar recuperación |
| Rol del CTO | El CTO ocupa tareas críticas y revisa todo | Agenda reactiva, trabajo profundo fragmentado y equipo en espera | Sacar su código del camino crítico y delegar por contexto |
Puntuaría cada área de 0 a 2: 0 si depende de una persona, 1 si existe un mecanismo pero se incumple con frecuencia y 2 si el equipo puede ejecutarlo de forma repetible sin intervención extraordinaria.
Cómo leer el resultado
De 0 a 3 puntos: el equipo es operativamente vulnerable. De 4 a 7: ya existen mecanismos, pero la presión diaria los rompe. De 8 a 10: el sistema es razonablemente resiliente; conviene trabajar los dos puntos más débiles, no añadir procesos por añadir.
La puntuación no sirve para comparar equipos. Sirve para discutir con evidencias y no con impresiones.
De desarrollador a CTO: el equipo como nueva arquitectura
Pasar de desarrollador a CTO no elimina el diseño de sistemas de software.
Cuando empiezas a ejercer liderazgo técnico, también empiezas a diseñar sistemas humanos.
Y muchos conceptos son sorprendentemente parecidos.
- Responsabilidades claras o difusas.
- Interfaces entre personas, roles y áreas.
- Dependencias que facilitan o frenan el flujo.
- Puntos únicos de fallo.
- Acoplamiento entre decisiones y responsables.
- Mecanismos de recuperación.
- Observabilidad sobre cómo funciona el sistema.
Una organización técnica en la que nadie sabe exactamente quién decide qué tiene problemas de arquitectura.
Un servicio que solo conoce una persona tiene un punto único de fallo.
Cuando un equipo necesita escalar cualquier decisión al CTO, está excesivamente acoplado.
Si las incidencias llegan directamente por Slack a cualquier desarrollador, el proceso tiene una interfaz defectuosa.
La solución no consiste en crear un organigrama perfecto.
Consiste en introducir suficiente claridad.
- Quién es responsable de cada aplicación.
- Quién tiene ownership técnico.
- Qué decisiones puede tomar autónomamente un desarrollador.
- Cuáles necesitan contraste con el equipo.
- Cuáles afectan a arquitectura global.
- Cuándo tiene sentido escalar una decisión.
Una forma sencilla de empezar es clasificar las decisiones por nivel. No hace falta un documento de veinte páginas: basta con que el equipo comparta el mismo criterio.
| Tipo de decisión | Nivel por defecto | Ejemplo |
|---|---|---|
| Detalles de implementación | El desarrollador responsable | Un refactor interno de una función |
| Cambios dentro de una aplicación | El desarrollador, con revisión de un compañero | Adoptar una librería nueva en un servicio |
| Arquitectura compartida o integraciones | El equipo, con liderazgo técnico | Crear un servicio nuevo usado por varios productos |
| Producción, seguridad y accesos | Un proceso definido, no una persona | Cambiar la rotación de guardias o los permisos de despliegue |
Esta tabla no busca ser exhaustiva. Busca que nadie tenga que preguntar «¿puedo decidir esto?» veinte veces al día.
La autonomía no aparece simplemente diciendo:
Quiero que el equipo sea más autónomo.
La autonomía necesita contexto, límites y confianza.
Dejar de responder todas las preguntas
Esta probablemente sea una de las partes más difíciles.
Cuando sabes la respuesta, responder es tentador.
Alguien pregunta cómo implementar algo.
Tú sabes cómo hacerlo.
Respondes.
Problema resuelto.
Pero si eres siempre la respuesta, el equipo aprende algo muy distinto de lo que pretendías enseñar.
Aprende a preguntarte.
Una alternativa mucho más poderosa consiste en enseñar criterios.
¿Qué alternativas has considerado?
¿Qué impacto tendría sobre el resto del sistema?
¿Cómo lo mantendríamos dentro de dos años?
¿Qué pasaría si este servicio deja de estar disponible?
¿Tenemos ya algún patrón parecido?
Puede parecer más lento.
Y al principio lo es.
Pero estás cambiando una solución puntual por capacidad futura.
Una decisión importante explicada diez veces en conversaciones diferentes debería probablemente convertirse en una decisión documentada. Para eso existen herramientas ligeras como los Architecture Decision Records, que permiten dejar rastro del contexto y del porqué sin montar una enciclopedia.
Un problema que aparece repetidamente debería convertirse en un procedimiento.
Una solución que funciona bien debería convertirse en un patrón reutilizable.
El objetivo no es documentarlo absolutamente todo.
Es reducir la cantidad de conocimiento que solo existe en la cabeza de una persona.
Regla práctica
Si has explicado la misma decisión tres veces en conversaciones distintas, documéntala. Si un problema aparece por tercera vez, conviértelo en procedimiento. Si una solución funciona bien en dos servicios distintos, propónla como patrón del equipo.
Diseñar cómo entra el trabajo
Uno de los mayores generadores de caos en un equipo técnico no está dentro del código.
Está en la entrada.
Una petición de negocio llega por correo.
Una incidencia aparece por Slack.
Un cliente llama directamente a un desarrollador.
Alguien pide «un pequeño cambio» durante una reunión.
Producto abre una tarea.
Soporte escala un problema.
Dirección pregunta por una funcionalidad urgente.
Y todo termina compitiendo directamente por la atención del desarrollador.
Cuando el trabajo entra de esta manera, la prioridad real no la determina la importancia.
La determina quién interrumpe más.
Parte del trabajo de liderazgo consiste en diseñar esa entrada.
- Distinguir incidencias de evolutivos.
- Separar correctivos de nuevas funcionalidades.
- Hacer visible la deuda técnica, porque compite con el resto del trabajo aunque no se vea en el backlog.
- Definir mecanismos de priorización.
- Establecer cómo se gestionan las urgencias reales.
Y, sobre todo, proteger al equipo de la necesidad de renegociar prioridades continuamente.
No se trata de añadir burocracia.
Se trata de evitar que cada desarrollador tenga que convertirse también en un gestor de interrupciones.
Cuando el trabajo entra sin diseño, cada persona del equipo dedica una parte enorme de su energía a decidir qué atender, en qué orden y con qué criterio.
Y esa carga invisible no aparece en ninguna tarea.
Pero está ahí.
Un sistema de entrada bien diseñado no elimina la negociación.
La mueve de lugar.
La prioridad se discute una vez, en el momento y con las personas adecuadas, y no diez veces al día en la cabeza de cada desarrollador.
Checklist: la entrada del trabajo
- Existe un único canal visible por el que entra el trabajo técnico.
- Incidencias, evolutivos y deuda técnica se clasifican al entrar, no durante el desarrollo.
- Hay un criterio de priorización conocido por producto y por el equipo.
- Las urgencias reales tienen un camino propio que no contamina el resto.
- Se revisa periódicamente qué trabajo entró fuera del canal, y por qué.
Los procesos no son burocracia: son la memoria del equipo
Otra confusión habitual es tratar cualquier proceso como burocracia.
Existen procesos que estorban, claro.
Pero también existen procesos que sostienen.
La diferencia está en su función.
Un proceso malo controla a las personas.
Un proceso bueno guarda conocimiento que el equipo necesita para funcionar sin depender de nadie concreto.
- ADRs breves para dejar registro de las decisiones importantes.
- Runbooks de despliegue y de incidencias recurrentes.
- Rotación de revisiones para que el conocimiento no se concentre.
- Un onboarding que no dependa de la buena voluntad de una sola persona.
- Guardias con criterios de escalado claros.
Ninguno de estos procesos existe para ir más despacio.
Existen para que lo que se aprendió una vez no haya que volver a aprenderlo cada semana.
Si una incorporación nueva tarda meses en ser productiva, el problema rara vez es la persona nueva. Suele estar en cómo se transfiere el contexto, y eso es algo que se puede diseñar.
En un equipo técnico, los procesos son memoria.
Y la memoria, igual que el código, se escribe, se revisa y, cuando deja de servir, se elimina.
CTO hands-on: cerca del código, fuera del camino crítico
Una de las dudas frecuentes al pasar de desarrollador a CTO es cuánto código hay que seguir escribiendo.
Hay quien defiende que el CTO debe soltar el código por completo.
Y hay quien sigue aferrado a él como si nada hubiera cambiado.
Como casi siempre, la cuestión no es cuánto, sino dónde.
Un CTO hands-on que ocupa las tareas críticas del sprint vuelve a ser el cuello de botella de siempre con otro cargo.
Un CTO que no toca el código en meses pierde contexto, pierde criterio y pierde parte de la confianza del equipo.
La clave está en elegir contribuciones que den contexto sin bloquear a nadie.
- Herramientas internas que nadie está esperando.
- Prototipos y spikes para explorar riesgos técnicos.
- Revisiones de código centradas en criterio, no en detalle.
- Sesiones de pair programming en las zonas complejas del sistema.
- Contribuciones pequeñas y bien acotadas que no condicionan la planificación.
Tu código ya no es tu principal aportación.
Es tu manera de seguir entendiendo el sistema desde dentro.
Y de que el equipo siga viendo que entiendes de lo que hablan.
Qué haría yo
Reservaría un porcentaje pequeño y estable de tiempo técnico, y lo protegería como cualquier otra responsabilidad. Elegiría trabajo fuera del camino crítico: herramientas internas, spikes, revisiones. Y me comprometería con una regla incómoda: no ser el revisor obligatorio de todo, aunque pueda revisar mejor que nadie.
De desarrollador a CTO: un plan de 30 días sin paralizar al equipo
En la transición de desarrollador a CTO, intentar arreglar las cinco áreas a la vez suele crear un sexto problema: una transformación interna que consume la capacidad que pretendía liberar.
Yo trabajaría en ciclos cortos. Treinta días no bastan para convertir un equipo dependiente en uno autónomo, pero sí para cambiar la dirección y dejar instalados mecanismos que puedan sostenerse.
Semana 1: observar
Registrar interrupciones, decisiones que escalan, PRs detenidas, tareas fuera del canal y operaciones que solo puede ejecutar una persona. Sin corregir todavía. Primero hace falta ver el sistema real.
Semana 2: elegir
Escoger una dependencia de alto impacto y alta frecuencia. No necesariamente la más grave: la que permita demostrar pronto que otra forma de trabajar es posible.
Semana 3: transferir
Dar contexto, límites y ownership a otra persona o pareja. Documentar solo lo necesario, practicar el proceso y dejar que el equipo tome la decisión sin una aprobación preventiva.
Semana 4: probar
Retirarte deliberadamente del flujo y observar. Si el proceso falla, corregir la interfaz, el contexto o el mecanismo. No recuperar automáticamente la tarea: eso devolvería al sistema al punto de partida.
Qué no haría
No empezaría por implantar una herramienta nueva, crear más reuniones o exigir documentación masiva. Una dependencia organizativa no desaparece porque cambies Trello por Jira ni porque abras una wiki. Primero se decide qué debe dejar de depender de quién; después se elige el mecanismo mínimo que lo sostiene.
Señales de que el sistema empieza a funcionar
El cambio no se nota de un día para otro.
Pero hay señales.
- Decisiones técnicas que se toman sin preguntarte, y son buenas decisiones.
- Despliegues que ocurren mientras estás de vacaciones.
- Incidencias que resuelve alguien que no estaba cuando se escribió el código.
- Preguntas que, simplemente, dejan de llegarte.
- Incorporaciones nuevas que son productivas en semanas y no en meses.
- Un equipo que sabe explicar por qué las cosas son como son.
Y hay una señal más, quizá la más difícil de aceptar.
Que las cosas funcionen bien sin que nadie necesite contártelo.
El equipo ya no te mira como la persona que resuelve.
Te mira como la persona que hace posible que resuelvan ellos.
Cuándo tiene sentido pedir una mirada externa
Al pasar de desarrollador a CTO, no todos los equipos necesitan consultoría, un interim CTO ni una transformación formal. Si el equipo puede nombrar sus dependencias, priorizar una, asignar un responsable y reservar tiempo para corregirla, empezaría por ahí.
Una mirada externa empieza a aportar valor cuando la misma persona es a la vez parte del problema, responsable de diagnosticarlo y quien debe convencer a dirección de que existe.
- Las incidencias se repiten, pero la urgencia impide analizar su patrón.
- Producto, soporte y tecnología aplican criterios distintos para definir prioridad.
- Una migración, una modernización legacy o una etapa de crecimiento va a tensionar más al equipo.
- Existe conocimiento crítico concentrado y nadie consigue abrir tiempo para repartirlo.
- El CTO sabe que debe salir del camino crítico, pero cada intento aumenta temporalmente el riesgo y vuelve a intervenir.
La ayuda externa no debería sustituir el liderazgo del equipo. Debería hacer visible el sistema, ordenar las decisiones y dejar capacidad instalada para que el equipo continúe sin ella.
El salto de desarrollador a CTO es un cambio de identidad
Aquí está, para mí, la parte más profunda de la transición.
Porque ser la persona que resuelve no solo es útil.
Es adictivo.
Resolver da reconocimiento inmediato.
Diseñar sistemas de trabajo da resultados lentos y poco visibles.
Nadie celebra el proceso que evitó una incidencia que nunca llegó a producirse.
Nadie agradece la decisión documentada que evitó tres reuniones.
Y, sin embargo, ahí es donde está ahora tu impacto.
El salto de desarrollador a CTO es, en el fondo, un cambio de identidad.
Dejas de medir tu valor por los problemas que resuelves.
Empiezas a medirlo por los problemas que el equipo puede resolver sin ti.
Tu nuevo producto es cómo trabaja el equipo
El día que dejas de programar todo no pierdes tu capacidad técnica.
La cambias de sitio.
La pones al servicio de algo más grande: un sistema de trabajo donde las decisiones se toman con criterio, el conocimiento se comparte, el trabajo entra con claridad y nadie es imprescindible por accidente.
Ese sistema no aparece solo.
Hay que diseñarlo con la misma intención, el mismo rigor y la misma atención con la que diseñarías una arquitectura.
Porque, a partir de ahora, esa es tu verdadera arquitectura.
Si todo pasa por ti, has construido un sistema que depende de que nunca falles. Si el equipo puede avanzar sin ti, has construido algo que sobrevive a cualquier escenario.
Ahora me interesa tu experiencia
¿Dónde se concentra hoy la dependencia en tu equipo? ¿En las revisiones, los despliegues, las decisiones, la relación con producto o el conocimiento de un legacy? Cuéntamelo en comentarios. Y, si ya pasaste por esta transición, me interesa todavía más saber qué responsabilidad fue la más difícil de soltar.
¿Quieres localizar la dependencia antes de que frene al equipo?
Diseñar este sistema de trabajo no es un ejercicio teórico. Es una secuencia de decisiones sobre cómo entra el trabajo, quién puede decidir qué, dónde vive el conocimiento crítico y qué papel debe abandonar el CTO.
En una sesión de diagnóstico revisamos las cinco áreas del mapa de autonomía técnica, contrastamos síntomas con evidencias y elegimos los dos o tres movimientos de mayor impacto. El objetivo no es venderte más proceso: es que salgas con una lectura clara del sistema y un primer plan que tu equipo pueda ejecutar.
Preguntas frecuentes sobre el salto de desarrollador a CTO
¿Un CTO debe seguir programando?
Depende, pero casi nunca «todo» ni «nada». Un CTO hands-on que conserva algo de código fuera del camino crítico mantiene contexto, criterio y credibilidad. Si ese código bloquea al equipo, se ha convertido en otra forma de cuello de botella.
¿Cómo sé si me he convertido en cuello de botella?
Mira tu agenda y tu bandeja de revisiones. Si las decisiones técnicas esperan a que salgas de una reunión, si hay despliegues que solo sabes ejecutar tú o si el equipo repite «mejor esperamos a que vuelva», el sistema ya depende de ti. La prueba más rápida: qué pasaría con el equipo si te fueras de vacaciones mañana durante tres semanas.
¿Puede la autonomía del equipo generar caos técnico?
La autonomía sin contexto, límites y confianza, sí. Por eso no se declara: se diseña. Niveles de decisión claros, ownership por aplicación y mecanismos de contraste evitan tanto el caos como la dependencia. El objetivo no es que cada uno haga lo que quiera, es que nadie tenga que preguntar veinte veces al día.
¿Qué procesos mínimos necesita un equipo para ser autónomo?
Muy pocos, pero sostenidos: un canal único de entrada de trabajo, niveles de decisión conocidos, registro breve de decisiones importantes (por ejemplo, ADRs), runbooks de despliegue e incidencias y un onboarding que no dependa de una persona. Lo demás se añade cuando el equipo demuestra necesitarlo, no antes.
¿Cuánto tarda la transición de desarrollador a CTO?
No hay un plazo honesto universal, porque no es un curso: es un cambio de identidad y de hábitos. En mi experiencia, los primeros síntomas de que el sistema nuevo funciona (decisiones sin ti, despliegues sin ti, preguntas que dejan de llegarte) suelen aparecer antes de lo que se espera, si se trabajan deliberadamente la entrada del trabajo y los niveles de decisión.
¿Qué debería salir de un diagnóstico del sistema de trabajo?
Como mínimo, un mapa de dependencias basado en evidencias, una prioridad compartida y dos o tres intervenciones con responsable, señal de éxito y horizonte temporal. Si el resultado es solo una lista genérica de buenas prácticas o una recomendación de herramientas, todavía no hay un diagnóstico accionable.
Deja una respuesta