Descentralizar la toma de decisiones con Shawna Martell y Dan Fike
- Aisha Washington
- hace 2 horas
- 8 min de lectura
Las organizaciones de ingeniería suelen decir que quieren que los equipos actúen de forma autónoma. En la práctica, las decisiones siguen escalando, se estancan en reuniones o dependen de qué arquitecto sénior esté disponible. Shawna Martell y Dan Fike describen un modelo diferente desarrollado en Cartek: establecer una estrategia de ingeniería explícita y, después, facultar a líderes técnicos de confianza —llamados Navigators— para ayudar a los equipos a aplicarla.
Su enfoque considera la descentralización como algo más que delegar autoridad. Las personas necesitan principios compartidos, suficiente contexto local, acceso a asesores experimentados y una forma de cuestionar o mejorar la estrategia. Cuando estas piezas funcionan en conjunto, los colaboradores individuales pueden tomar decisiones importantes sin obligar a que cada cuestión pase por la dirección o por una función de arquitectura centralizada.
Por qué la autonomía requiere una estrategia de ingeniería
Martell y Fike remontan el programa Navigator a un problema recurrente: los ingenieros querían una orientación más clara. Sin un marco acordado, los equipos no podían evaluar de forma fiable opciones técnicas contrapuestas ni saber qué prioridades organizativas debían prevalecer.
El resultado no era necesariamente una mala ingeniería. Era una ingeniería inconsistente. Dos equipos que enfrentaran compensaciones similares podían llegar a conclusiones incompatibles porque cada uno usaba un estándar diferente, en gran medida implícito. Los mismos debates resurgían repetidamente, consumiendo tiempo sin generar conocimiento organizativo duradero.
Aprobar cada elección de forma centralizada habría resuelto la inconsistencia creando un cuello de botella. En cambio, Cartek buscó hacer que la base de las buenas decisiones estuviera ampliamente disponible. Su estrategia de ingeniería se convirtió en un punto de referencia compartido: una explicación documentada de cómo la organización evalúa las compensaciones y qué suele valorar en circunstancias concretas.
Fundamentalmente, la estrategia surgió como respuesta a ingenieros que pedían contexto. Martell y Fike no la presentan como un mandato inventado de forma aislada por los ejecutivos. Su propósito era dar a los colaboradores la confianza para actuar, manteniendo al mismo tiempo sus decisiones conectadas con una dirección más amplia.
Empezar por la realidad, no por un cartel aspiracional
Una parte destacable del proceso de Cartek fue su énfasis en documentar cómo ya se estaban tomando las decisiones. El equipo no empezó describiendo una organización futura ideal. Primero examinó el estado actual, incluidas prácticas que parecían inconsistentes o difíciles de defender.
Este tipo de arqueología organizativa importa porque todo grupo de ingeniería ya tiene una estrategia, incluso cuando nadie la ha escrito. Vive en decisiones repetidas: si los equipos optimizan el rendimiento inmediato o la escalabilidad futura, aceptan complejidad operativa para aumentar la flexibilidad o amplían un sistema existente en lugar de crear un nuevo servicio.
Los documentos de diseño y los registros de decisiones de arquitectura anteriores pueden revelar estos patrones. Un registro útil recoge las alternativas consideradas, los beneficios y costes de cada una y la razón por la que una opción prevaleció. Varios registros analizados conjuntamente revelan los valores que hay detrás de esas elecciones.
Martell y Fike distinguen esos valores de las decisiones en sí. Una decisión dice qué ocurrió en un caso. Un principio ofrece orientación condicional que puede trasladarse a otro caso: en efecto, «Cuando se apliquen estas condiciones, favorece esta respuesta». Extraer tales principios puede requerir volver a consultar a las personas y las circunstancias detrás de decisiones anteriores, especialmente cuando los documentos registran un resultado pero omiten su justificación.
Empezar con honestidad también hace que el cambio sea medible. Una estrategia idealizada puede sonar inspiradora mientras oculta la distancia entre la política y la práctica. Una descripción del sistema real crea una línea de base a partir de la cual la organización puede mejorar deliberadamente.
Los Navigators ayudan a los equipos a leer el mapa
El nombre del programa refleja una importante división de responsabilidades. La estrategia de ingeniería funciona como un mapa; los Navigators ayudan a las personas a interpretarlo en terreno desconocido. Contribuyen a la estrategia, pero su función principal no es emitir un plan maestro ni decidir personalmente cada cuestión técnica.
En el momento analizado, aproximadamente una docena de Navigators respaldaban a una organización de ingeniería de unas 400 personas. Procedían de varias disciplinas técnicas, entre ellas ingeniería de front-end y back-end, fiabilidad y seguridad. Sus posiciones en la jerarquía formal variaban: algunos trabajaban profundamente integrados en los equipos, mientras que otros operaban más cerca de la alta dirección.
La selección dependía menos del cargo que del juicio demostrado, la profundidad técnica y la influencia. Martell y Fike describen una red informal que existe junto al organigrama de gestión. Ciertos ingenieros se convierten naturalmente en las personas a quienes sus colegas consultan cuando un problema es ambiguo. El modelo Navigator reconoce y conecta a esas figuras de confianza, en lugar de asumir que la autoridad fluye únicamente a través de las líneas de reporte.
Los Navigators necesitan un contexto considerable sobre los productos y sistemas que los rodean. Deben saber qué decisiones están en curso, reconocer cuándo el trabajo entra en conflicto con la estrategia e intervenir cuando un equipo necesita ayuda. Eso no significa tomar el control. Un Navigator puede guiar al equipo a través de la compensación, identificar principios relevantes o llevar una cuestión no resuelta al grupo más amplio de Navigators.
También transmiten información en ambas direcciones. La estrategia ayuda a los equipos a tomar decisiones locales, mientras que las dificultades que encuentran los equipos revelan dónde está incompleta la estrategia. Por tanto, los Navigators son tanto intérpretes como contribuyentes importantes a su revisión continua.
Asesoramiento sin un cuello de botella de arquitectura
Cartek evita deliberadamente convertir a un arquitecto formal en la puerta de entrada obligatoria para las decisiones técnicas. Los ingenieros de plantilla pueden realizar trabajo de arquitectura cuando sea necesario, pero la organización no quiere un rol permanente que concentre la autoridad para decidir en un único lugar.
En cambio, su modelo se parece a un proceso de asesoramiento arquitectónico. Un ingeniero puede tomar una decisión después de consultar a las personas afectadas, a colegas con experiencia relevante, a la estrategia escrita y a un Navigator cuando sea necesario. La autoridad permanece distribuida, pero se espera la consulta.
La estrategia sirve como una fuente colectiva de asesoramiento. Ofrece incluso a los ingenieros menos experimentados un estándar con el que pueden poner a prueba una propuesta. Por ejemplo, puede aclarar cómo la organización pondera el rendimiento frente a la escalabilidad o el coste de mantenimiento frente a la velocidad de entrega.
No todas las cuestiones pueden reducirse a una orientación universal. Martell y Fike mencionan decisiones como si una capacidad pertenece a un monolito existente o justifica un nuevo servicio. Una organización puede tener una dirección general sin una regla lo bastante precisa para cada situación. En esos casos, la estrategia debe reconocer la ambigüedad y orientar a los ingenieros hacia una consulta informada.
Esto preserva el juicio en lugar de sustituirlo por burocracia. El objetivo no es codificar todas las respuestas futuras. Es facilitar las decisiones rutinarias, sacar a la luz las que son realmente difíciles y dar a las personas una forma coherente de razonar sobre las excepciones.
La estrategia debe volverse gradualmente menos errónea
Martell y Fike plantean la estrategia como un instrumento en evolución, no como una doctrina terminada. Los principios iniciales contendrán lagunas. Algunos serán demasiado amplios, mientras que otros podrían fallar en condiciones que sus autores no anticiparon.
Las decisiones reales proporcionan la retroalimentación necesaria para mejorarlos. Los equipos comparan una opción con la estrategia, descubren dónde la orientación ayuda o deja de funcionar y comunican esa evidencia a través de sus Navigators. Con el tiempo, tanto las decisiones individuales como el marco compartido pueden volverse menos erróneos.
Permitir una ambigüedad limitada forma parte del diseño. Los equipos aún necesitan espacio para desarrollar «microestrategias» locales adecuadas para sus sistemas y limitaciones. Los Navigators ayudan a garantizar que esos enfoques locales sigan siendo compatibles con la dirección más amplia de la organización sin obligar a todos los equipos a adoptar una implementación idéntica.
Las relaciones entre los propios Navigators fortalecen este ciclo de retroalimentación. No son colectivamente propietarios de cada decisión, pero pueden consultar a sus pares cuando un problema abarca varios dominios. Su combinación de una amplia conciencia organizativa y conocimiento especializado profundo resulta especialmente útil para cuestiones que atraviesan la seguridad, la fiabilidad, la arquitectura de plataforma y el desarrollo de productos.
La descentralización también es un sistema de mentoría
Distribuir la autoridad solo funciona si más personas aprenden a ejercerla. Por ello, el rol de Navigator incluye una responsabilidad implícita de enseñar: cómo identificar compensaciones, buscar el asesoramiento adecuado, documentar el razonamiento y decidir con información incompleta.
Esto es especialmente importante para ingenieros a quienes antes no se les ha confiado decisiones de alto impacto. Decirles que «asuman la responsabilidad» es insuficiente si luego un grupo sénior inaccesible revoca cada propuesta relevante. Los Navigators pueden hacer visible el proceso de razonamiento y apoyar a quienes contribuyen, manteniendo la decisión cerca del trabajo.
Martell y Fike también distinguen la perspectiva de Navigator de la perspectiva de gestión. Los gerentes deben equilibrar a las personas, la entrega y la ejecución del equipo. Los Navigators aportan un criterio técnico profundo y conectan las decisiones locales de ingeniería con la estrategia de toda la organización. Ambas perspectivas deberían complementarse en lugar de fusionarse en un único rol.
Los candidatos son reconocidos por su contribución existente y nominados por líderes sénior, en lugar de postularse mediante un proceso convencional. La credibilidad técnica por sí sola no basta. A alguien que no esté dispuesto a desarrollar a otros o compartir su criterio le resultaría difícil cumplir el propósito del programa.
Medir el éxito mediante mejores decisiones
El valor de la descentralización se aprecia en resultados concretos de las decisiones. Martell y Fike describen a un equipo que consideraba un nuevo servicio de plataforma compartida para un problema presente en múltiples dominios. Una respuesta superficialmente razonable habría sido construir una solución universal e iniciar un largo esfuerzo para lograr el acuerdo de todas las partes interesadas.
Un Navigator comparó la propuesta con la estrategia de la organización y concluyó que una plataforma única para todos no era la dirección preferida. Como la estrategia ya representaba una opción predeterminada acordada, el Navigator pudo resolver el asunto sin reconstruir todo el argumento desde cero.
Esto ilustra un cambio significativo en la carga de la prueba. En vez de que los defensores tengan que convencer repetidamente a otros de que una dirección es correcta, la estrategia documentada proporciona el punto de partida. Las desviaciones siguen siendo posibles, pero requieren una explicación convincente.
Entre los indicadores útiles de progreso se incluyen decisiones más rápidas, menos escalaciones innecesarias, razonamientos más claros en los documentos de diseño y una mayor confianza entre quienes contribuyen. Las señales cualitativas también importan: los ingenieros deberían sentirse menos perdidos, y los debates recurrentes deberían producir cada vez más principios reutilizables en lugar de otro compromiso temporal.
Cómo pueden empezar los líderes de ingeniería
Martell y Fike dejan claro que nombrar Navigators antes de articular una estrategia probablemente no funcione. Sin un mapa compartido, las personas de confianza podrían simplemente distribuir sus preferencias personales de forma más eficiente.
Los líderes pueden comenzar revisando decisiones de arquitectura anteriores y documentos de diseño actuales. Deberían identificar compensaciones recurrentes, poner por escrito primero los principios menos controvertidos y examinar la brecha entre los valores declarados y el comportamiento observado. La incomodidad ante ese historial es una evidencia útil: señala prácticas que la organización quizá quiera cambiar.
Una secuencia práctica consiste en:
documentar decisiones representativas y su razonamiento;
extraer principios condicionales de patrones recurrentes;
identificar áreas en las que la práctica actual entra en conflicto con la dirección deseada;
encontrar colaboradores técnicos respetados que ya asesoran a otros;
ubicar a esas personas donde puedan conectar el trabajo local con la estrategia organizacional;
revisar el marco a medida que las decisiones reales revelen omisiones o contradicciones.
La lección más profunda es que la descentralización depende de una infraestructura para el criterio. Los principios escritos aportan coherencia, los Navigators proporcionan contexto y mentoría, y los equipos aportan la evidencia que mantiene el sistema conectado con la realidad. En conjunto, estos mecanismos permiten que la autoridad se acerque al trabajo sin que la organización se fragmente en direcciones técnicas incompatibles.
