Verlo como una empresa de software

• La idea central de “Seeing Like A State(Verlo como un Estado)” de James C. Scott es que las organizaciones intentan aumentar la “legibilidad (legibility)” de sus sistemas para que todo pueda medirse y reportarse
• Pero en la práctica, el “trabajo ilegible” que no puede rastrearse ni predecirse es indispensable, y enfocarse solo en la legibilidad puede terminar reduciendo la eficiencia
• En especial, las grandes empresas vuelven el trabajo legible mediante procesos como planificación trimestral, OKR y Jira, pero eso paradójicamente reduce la eficiencia, y una empresa pequeña puede ser 20 veces más eficiente que una gran corporación
• Las organizaciones permiten áreas temporales e ilegibles como los "tiger teams" para responder a emergencias, y la colaboración informal mediante canales paralelos entre ingenieros cumple un papel tan importante como los procesos formales
• El éxito de una empresa tecnológica depende de mantener el equilibrio entre procesos legibles y trabajo práctico ilegible; con solo uno de los dos, la organización no funciona bien

---

Introducción: la idea central de “Seeing Like A State”

• La idea central del libro “Seeing Like A State(Verlo como un Estado)” de James C. Scott puede resumirse en tres puntos
  • Las organizaciones modernas transforman sus sistemas en formas con máxima “legibilidad (legibility)”, de modo que todas sus partes puedan controlarse para ser medidas y reportadas
  • Pero estas organizaciones dependen de una enorme cantidad de trabajo “ilegible (illegible)”. Es decir, existe mucho trabajo que no puede rastrearse ni planearse, pero que es esencial
  • Aumentar la legibilidad a menudo perjudica la eficiencia, aunque otros beneficios que aporta —como control, planificación y transparencia— se consideran una gran ventaja
• La legibilidad se refiere a trabajo predecible, con resultados rastreables y que no depende de recursos humanos específicos. Ejemplos: gestión de cronogramas, OKR, Jira, etc.
• La ilegibilidad se refiere a trabajo improvisado o basado en conocimiento tácito: colaboración que no puede ponerse por escrito ni formalizarse, cambios repentinos o trabajo que depende de relaciones humanas

El caso de “verlo como un Estado”

• Scott usa el caso de los “bosques ordenados” de la Alemania del siglo XIX para explicar el intento de las organizaciones de controlar y estandarizar en nombre de la eficiencia
  • Se esperaba que, al gestionar el bosque de modo que todos los árboles pudieran verse de un vistazo, mejoraran la planificación, las transacciones y la asignación de recursos
  • En la práctica, se ignoró la diversidad del bosque y el papel de la vegetación baja, lo que redujo la productividad y volvió al sistema más vulnerable a enfermedades y parásitos
• Es decir, se buscaban tanto eficiencia como transparencia, pero la búsqueda excesiva de legibilidad terminó perjudicando la eficiencia

Legibilidad e ilegibilidad en las empresas de software

• En las empresas de software ocurre algo parecido: los equipos pequeños o incluso individuos pueden ser más eficientes
  • Entre ingenieros de software es casi sentido común que un solo ingeniero trabajando por su cuenta puede ser más eficiente que cuando trabaja como parte de un equipo
  • El trabajo impulsado por ingenieros avanza mucho más rápido que el trabajo dirigido desde arriba, porque no hace falta traducirlo a una forma significativa ni comunicar activamente en todas las direcciones
• La razón por la que una pequeña empresa de software puede ser mucho mejor entregando software que una grande es que aunque la gran empresa ponga 10 veces más ingenieros, no importa si la pequeña es 20 veces más eficiente
• En las grandes empresas, se introducen diversas herramientas y procedimientos para volver “legible” el trabajo de los ingenieros
  • Esto ayuda a planear, medir y reportar el trabajo, pero puede reducir la productividad real del desarrollo de software
• Las empresas pequeñas pueden responder de inmediato a problemas o adaptarse rápidamente a cambios (una capacidad ilegible)
• La razón por la que las grandes empresas mantienen procesos complejos en lugar de esa eficiencia tiene que ver con grandes contratos enterprise. Los clientes grandes exigen previsibilidad y confiabilidad de sus proveedores
• Para colaborar con esos clientes, la legibilidad es indispensable: planificación de largo plazo, compromisos de funcionalidades y documentación del progreso
• Los procesos se mantienen porque el valor que aporta la legibilidad (medido en dólares) es mayor que la capacidad de producir software de forma más eficiente

El valor práctico de la legibilidad para las grandes empresas

• En una gran empresa de software, la legibilidad significa que
  • Incluso un ingeniero individual puede entender todos los proyectos en curso
  • Puede generarse de inmediato una lista de los proyectos completados el trimestre pasado
  • Es posible planificar el trabajo con al menos un trimestre de anticipación (o más)
  • En una situación urgente, puede movilizarse todo el recurso del departamento para asignarlo de inmediato a una tarea prioritaria
• Una empresa pequeña de software difícilmente cumple estos requisitos, salvo por su capacidad de reaccionar con flexibilidad e inmediatez
• Las grandes empresas son fuertes para registrar, clasificar y planear a largo plazo, pero su capacidad de respuesta rápida (movilizar recursos organizacionales de inmediato) puede debilitarse
• Asegurar esta legibilidad cumple un rol clave sobre todo en la confianza con clientes enterprise, contratos y colaboración de largo plazo

Supuestos para asegurar la legibilidad y sus límites

• En el proceso de impulsar la legibilidad, las grandes empresas hacen los siguientes supuestos simplificados
  • Suponen que todos los ingenieros del mismo nivel rinden más o menos igual
  • Suponen que reubicar o reorganizar ingenieros no produce pérdida de productividad
  • Suponen que si un equipo mantiene la misma cantidad de ingenieros, su nivel de productividad se mantiene con el tiempo
  • Suponen que los proyectos pueden estimarse de antemano con cierto margen de error
• Pero en la realidad
  • Incluso entre personas del mismo nivel hay grandes diferencias de capacidad, y la especialización y los intereses generan variaciones importantes en la productividad de un proyecto
  • El tamaño del equipo y la productividad solo tienen una correlación débil
  • La estimación de proyectos es casi una ilusión, y en la práctica a veces la forma de trabajar cambia para ajustarse al calendario estimado
• Aun así, estos supuestos son útiles para la comunicación interna, los acuerdos con grandes empresas externas y la planificación del negocio

Áreas temporalmente autorizadas de ilegibilidad

• En las grandes empresas, los procesos para crear legibilidad provocan retrasos graves
  • idea de producto → etapa de planificación en la organización de producto → revisión técnica en la organización de ingeniería → negociación de asignación de equipos entre VP y senior managers → entrada al backlog de planificación del equipo → backlog de tickets del equipo → entrada al sprint → inicio real del trabajo
• Es una estructura totalmente incompatible con el trabajo que debe hacerse de inmediato
• Para resolver este problema, se permiten áreas temporales e ilegibles como “equipos virtuales”, “strike teams” o “tiger teams”
  • Están formadas por ingenieros seleccionados en quienes la organización confía
  • A menudo no se les asigna ningún manager y un ingeniero muy senior dirige el proyecto
  • Se les da una misión laxa y se les permite hacer básicamente lo que sea necesario para cumplir el objetivo
• Esto es un compromiso inteligente entre la ilegibilidad total y la legibilidad total
• Aunque esquivan el proceso formal, no operan de forma permanente, sino solo de manera temporal
• Incluso la ilegibilidad autorizada coexiste de forma incómoda con el resto de la organización, y otros ingenieros pueden sentir envidia o verlo como un riesgo al observar esa libertad de trabajar sin la carga del proceso

Áreas permanentes y no autorizadas de ilegibilidad

• La forma oficial en que un ingeniero del equipo A solicita trabajo al equipo B es crear un issue en el backlog de “planificación”, pasar por un proceso de 12 pasos y esperar hasta que entre al sprint, lo que puede tardar de semanas a meses
• La solución oficial sería que el equipo A anticipe en el proceso de planificación el trabajo que necesitará del equipo B, pero eso es absurdo, porque no es posible prever todos los cambios meses antes de escribir el código
• La solución real son los canales paralelos ilegibles
  • Un ingeniero del equipo A le pide a uno del equipo B: "¿puedes hacer este cambio de una sola línea?"
  • El ingeniero del equipo B lo hace de inmediato y crear un ticket es opcional
  • Es ilegible porque depende de relaciones interpersonales entre ingenieros
• Los canales paralelos existen constantemente en todos los niveles de la empresa
  • Canales paralelos entre equipos de ingeniería, dentro del mismo equipo, entre managers y entre product managers
  • Cuando una pregunta se plantea en un espacio formal, muchas veces ya fue ensayada y revisada en privado con quien va a responder
• Los canales paralelos pueden salir mal y a veces se usan para beneficiarse a costa de un ingeniero ingenuo

Sociópatas, ingenuos y perdedores

• El “principio de Gervais” de Venkatesh Rao divide a las organizaciones en tres grupos
  • Los “sociópatas” de la cima usan cínicamente las reglas de la organización para su propio beneficio
  • Los “ingenuos (clueless)” del management intermedio creen en las reglas oficiales de la organización y no perciben que encima de ellas se juega un juego más profundo
  • Los “perdedores (losers)” que están debajo reconocen que el juego existe, pero no quieren participar en él
• Estas categorías pueden leerse desde la perspectiva de la legibilidad
  • Tanto los sociópatas como los perdedores participan en el mundo ilegible de la organización
  • Los “ingenuos” solo participan en procesos legibles y, cuando quieren ascender, consultan la escalera formal de carrera y planean cómo encarnar cada valor del siguiente nivel
• Llamarlos “ingenuos” es excesivamente cínico
  • Los procesos legibles siguen siendo muy importantes y representan una gran parte de lo que hace la organización
  • Mejorar los procesos formales sigue siendo trabajo de altísimo apalancamiento
• Pensar en las personas con estas categorías ayuda a entender que muchas zonas frecuentes de conflicto en las empresas de software provienen de la fricción entre estos grupos

Reflexión final

• Es importante reconocer y aprovechar el mundo ilegible dentro de las organizaciones
• He escrito mucho sobre reconocer y usar la ilegibilidad en empresas tecnológicas
  • Romper reglas formales y legibles es a veces lo correcto
  • Los product managers pueden abusar de canales ilegibles para sacarle trabajo a ingenieros ingenuos, y hay que tener cuidado con eso
  • Un ingeniero competente debe trabajar en “apuestas paralelas” fuera del proceso normal de planificación
  • Ascender a Staff o más arriba casi no tiene relación con la escalera formal de carrera
• Los consejos sobre procesos ilegibles entran en la categoría de “consejos peligrosos”
  • Si anuncias públicamente que completas trabajo por canales paralelos en lugar de seguir el proceso formal, la organización te castigará
  • Te castigará incluso si la cadena de mando quería que lo hicieras
• Recibo muchos comentarios negativos que dicen que nunca se deben saltar los procesos formales, pero el autor considera ingenua esa postura
• Todas las organizaciones tienen un lado legible y un lado ilegible
  • El lado legible es importante a partir de cierta escala y hace posible la planificación de largo plazo y la coordinación con otras organizaciones grandes
  • El lado ilegible es igual de importante: permite trabajo de alta eficiencia, ofrece una válvula de escape para procesos que no encajan con la situación actual y satisface la necesidad humana natural de chisme y consenso informal

[GN⁺]

Opinión de Hacker News

• Coincido con la mayor parte, pero quiero cuestionar la suposición de que el liderazgo automáticamente asume que la legibility vale todos los costos. Si un CEO tuviera que prestar atención a cada detalle del trabajo (por ejemplo, la paralelización de pruebas unitarias), sería como si el cerebro tuviera que ser consciente de cada vez que mueve un dedo, y no podría hacer nada. En la práctica, un CEO, es decir, la cabeza de una empresa, solo puede controlar alrededor del 7% del total. El resto lo completan los empleados, y esa persona solo cumple el papel del cerebro, no del cuerpo entero. Pero los líderes tienden a confundirse y pensar que son lo más importante, y cuando les falta tiempo o no tienen experiencia en un área (por ejemplo, la diferencia entre un ingeniero brillante graduado del MIT y un ingeniero promedio salido de un bootcamp), simplemente lo dejan pasar. Incluso cuando se habla del éxito de Google, suele dársele el crédito solo a los dos fundadores o al CEO, en vez de a las decenas de personas brillantes que hicieron el trabajo real

  • Creo que el ejemplo de "que el cerebro sea consciente cada vez que respira" es un poco un hombre de paja. Un CEO competente sabría que no necesita encargarse personalmente de la gestión de pruebas unitarias dentro del equipo de desarrollo. En la práctica, el nivel de legibility al que apuntan las empresas está dentro de un rango mucho más razonable

• Parte de esto es cierta, pero no me parece tan extremo. Trabajo en una empresa de unas 5000 personas (no es pequeña, pero tampoco al nivel de Amazon). La mayoría de las reglas tienen razones bastante válidas. Por ejemplo, pedir 2 revisores de código sirve para evitar errores. No se rechazan tantas revisiones, pero si desplegáramos sin revisión, probablemente habría más incidentes. Estas reglas obligan a verificar las cosas aunque sea a la fuerza. Claro, alguna vez puede tocar romper la regla (por ejemplo, si la mayoría del equipo está fuera por una incidencia grave). En esos casos, lo razonable es permitir excepciones alineadas con la intención de la regla. Pero en lugares llenos solo de reglas puramente burocráticas e incomprensibles (el típico caso de alguien aferrado a su propio proceso que solo repite "tu forma está mal"), uno termina yéndose. Si el entorno valora más el proceso o el ego personal que el progreso y los resultados reales, lo mejor es cambiarse de trabajo

• Después de TDD, se volvió muy fuerte la tentación de pensar que "si no se puede testear, entonces no está implementado". La palabra legibility encaja muy bien para describir eso. En Tritium pusimos cientos de pruebas unitarias, pero recién al construir un blog quedaron expuestos errores cualitativos que las pruebas unitarias no podían detectar (cosas difíciles de verificar con tests); ver https://tritium.legal/blog/eat. Quizás por eso el desarrollo indie de videojuegos resiste mejor la lógica del mercado. Los desarrolladores de juegos usan su propio producto directamente (food-dogging) y logran mejoras cualitativas. No necesitan la superficie excesiva de legibility que suele tener el software de grandes empresas. La clave es que se necesitan tanto métricas cualitativas como cuantitativas

  • Las pruebas, especialmente las unitarias, son vulnerables al "efecto farola". Mientras más trivial o menos importante sea algo, más fácil suele ser testearlo, y por eso uno termina testeando solo lo fácil. Si una organización se obsesiona únicamente con métricas fáciles de medir, como el line coverage, existe el riesgo de que queden fuera las verificaciones verdaderamente significativas (y difíciles). También son importantes las evaluaciones cualitativas, como la revisión de alguien con mucha experiencia

  • El desarrollo de videojuegos tiene ciclos de retroalimentación mucho más cortos que otras áreas de software. Por ejemplo, si hay una fuga de memoria, el problema se hace evidente de inmediato cientos de veces por segundo. El código lento también se percibe enseguida como tirones visuales, así que eso obliga a prestar atención al rendimiento, incluyendo coherencia de caché, uso o no de GC, etc.

  • Me gusta TDD, pero al final las pruebas manuales también son indispensables. Si no pruebas las cosas tú mismo, aparecen con frecuencia problemas inesperados. Sobre todo en temas como la facilidad de uso, eso solo se nota de verdad al usarlo

• Suelo disfrutar los textos de Sean, y también coincidí con este en muchas partes del ámbito de producto. Por ejemplo, hace como un año, varias personas de producto e ingeniería quisieron construir algo que también pudiera ayudar a otros equipos. En ese momento, conseguir aprobación por los canales formales (legible channel) no era realista dada la estructura existente, así que se hizo de manera informal (illegible channel), basándose en confianza y respeto. Se impulsó como un esfuerzo de base (grassroots) y, de hecho, ganó tracción rápidamente dentro de la empresa de boca en boca. Al final, ahora la dirección usa este caso como si fuera una historia de éxito suya, pero cuando después intentan meter todos los procedimientos formales (legible channel) y la justificación posterior, el proceso se vuelve bastante doloroso. Aun así, como el riesgo de fracaso se redujo muchísimo, resulta más llevadero. Ha sido uno de los proyectos más gratificantes y divertidos en los que trabajé en los últimos años

• Cuanto más tiempo paso en la vida corporativa y expuesto a la política de oficina (office politics), más me parece que se parece a la geopolítica (geopolitics) o a la diplomacia. Y si uno sigue tirando del hilo, también puede ver paralelos con las relaciones sociales y románticas. Supongo que es por mi tendencia medio matemática a querer construir modelos abstractos

  • Mi tema favorito justamente es la política. Me encanta leer libros, revistas y todo tipo de material sobre eso y, la verdad, la política interna de oficina no me incomoda demasiado. La clave es que, al final, los seres humanos se comportan como seres humanos. Toda persona (y toda organización también) tiene cosas que desea y cosas que teme, y equilibrar ambas es, en cierto sentido, divertido. Es casi como resolver un problema de ingeniería, solo que los requisitos son "personas". El proceso mismo de resolver ese tipo de problemas me parece interesante

  • Recién hace poco me di cuenta de esto. Al principio veía la diplomacia como el resultado de un sistema complejo creado por cientos de diplomáticos, pero en realidad no es más que una red de relaciones humanas entre unas cuantas personas con poder. Se puede abordar casi igual que lo que pasa en un jardín de niños

  • Esto es algo instintivamente natural. Se parece todavía más entre las grandes empresas y los gobiernos que en las relaciones sociales o románticas. Las empresas suelen ser mucho más autocráticas (autocratic) o feudales (feudal). Hay muchas diferencias, pero cuanto más crecen, más tienden a parecerse a un gobierno. Una de esas similitudes es precisamente la burocracia sofisticada

  • Wiki de teoría de juegos

  • Viendo que muchos políticos modernos empezaron en trabajos administrativos comunes, tampoco tiene nada de raro

• Trabajo en seguridad informática, y aquí esta situación se ve todavía más marcada. Me pregunto si existe alguna alternativa que no sea usar métodos no oficiales (back channel) cuando nos toca aceptar "solicitudes que no ayudan directamente a las métricas" de nuestro equipo. Si alguien conoce alguna, me interesa saberla

  • Puedes hacer intercambios: asignar a un ingeniero de tu equipo a trabajo o ítems de roadmap que el otro equipo quiere, a cambio de que ellos hagan lo que tú necesitas

• Es un buen texto, pero quiero mencionar algo que casi nunca se trata. El artículo me dejó la sensación de que representa a los ingenieros de software (SWE) solo como hojas del árbol, algo así como operarios de una línea de ensamblaje, y eso me parece una pena. Pero, como también aparece en la parte de "Legible assumptions", en la práctica los ingenieros también cumplen un "rol gerencial" al extender con "código" las conexiones de la estructura organizacional. El objeto de aplicación cambia, pero los dilemas son bastante parecidos

  • Para subir de nivel como IC, como en el caso de un Senior Engineer, también se espera que cumplas funciones propias de un gerente real. No basta con escribir buen código. También se pide gestión de proyectos, arquitectura, liderazgo de equipo, capacidad de persuasión y dejar evidencia documentada

• ¿Alguien está de acuerdo con la parte del artículo que dice: "¿Por qué una empresa pequeña puede arreglárselas sin esto, pero una gran empresa de software sí lo necesita? No es mi especialidad, pero supongo que es por los proyectos para grandes corporativos"? Me interesa escuchar opiniones

  • Más que por cerrar tratos con grandes corporativos, creo que se trata del flujo de información interno (communication at scale). Se puede comparar una organización con m empleados a una matriz de comunicación m*m. Cuando hay pocas personas, casi todas las celdas son 1 (comunicación estrecha), pero a medida que crece, la mayoría pasan a ser 0 (desconexión) o 0.5 (comunicación informal). Pero la información, al final, es la empresa misma. Por eso se vuelve indispensable una estructura donde los managers y los procesos formales se hagan responsables de ese "flujo". La planeación, las promociones, las revisiones, todo eso existe para asegurar esa legibility

  • Trabajo con proyectos para grandes empresas en una empresa pequeña, pero no hace falta exigir una legibility estricta también puertas adentro para cerrar esos tratos. Frente al cliente sí se necesita legibility en la gestión del proyecto, pero eso no significa interferir en detalle con la forma interna de desarrollar. En conclusión, las empresas grandes se obsesionan con la legibility porque ya son grandes corporativos o porque aspiran a serlo

  • Estuve mucho tiempo en el área de imágenes médicas, y la mayoría de los dueños de negocio en realidad no entienden bien que están en la industria de servicios/soluciones de TI. La capacidad real de servicio de TI era el factor de éxito. Más que el diagnóstico en sí, lo que más pesó fue que personal no radiológico trabajara para mejorar la usabilidad y eficiencia de la plataforma

  • Por grande que sea la organización, siempre tiene que estar preparada para múltiples auditorías (audit), internas y externas. Los auditores tienden a querer ver la mayor cantidad posible de documentación de procesos. Por ejemplo, en el peor caso, un auditor incluso puede "despedir" a su cliente, como en este caso

  • Esa parte (que se debe a los tratos con grandes corporativos) también me suena algo peculiar. Como alguien que viene de startups y hoy es mando medio en una empresa mediana, creo que mientras más crece una organización, más necesita al menos una estructura mínima que indique cómo hacer el trabajo. Por mucho que odies los procesos, una vez que pasas el número de Dunbar, la empatía y la comunicación informal ya no alcanzan. La excepción extrema sería Steam, pero incluso ahí seleccionan solo cierto tipo de talento y la política interna es muy intensa

• La elección de la palabra legibility ya de por sí es interesante. Se siente como una dicotomía entre procesos formales e informales. Cuando la empresa es pequeña, las formas informales funcionan bien, pero una vez que se cruza cierto umbral, no queda otra que introducir reglas y procesos formales. A largo plazo, aparece el fenómeno de que las reglas se rigidizan y no logran seguir el ritmo del cambio. Poco a poco se empieza a obsesionar más con el proceso mismo que con el objetivo. No es fácil salirse de esa rutina y conservar la novedad. En las empresas se suele decir que el dinero es como la sangre, pero en realidad pocas veces es la raíz de la motivación. El dinero es una condición necesaria, sí, pero no creo que sea la razón de ser en sí misma

• Siempre es un tema de equilibrio. Fui engineering manager durante 25 años y trabajé en una empresa fuertemente orientada a procesos. Era frustrante, pero también tenía ventajas, porque lograban fabricar hardware de clase mundial de manera consistente (software no). La documentación y cosas así son necesarias, pero si se vuelven demasiado estrictas, existe el riesgo de que el proyecto se congele. El sobrecosto de comunicación es el problema más serio. Por eso, cuando un grupo pequeño y competente trabaja junto durante mucho tiempo, puede alcanzar una productividad enorme, y el tribal knowledge realmente es un acelerador muy importante. Escribí un texto llamado Concrete Galoshes justamente para abordar estos elementos estructurales y de rigidez. La mayor lección es: "no hay que vestir todos los proyectos con la misma ropa". Cada proyecto necesita distintas estructuras y distintos niveles de sobrecarga

  • El sobrecosto de comunicación sí es el problema real. Si aumentas el número de personas en un equipo, las necesidades de comunicación dentro del equipo crecen exponencialmente, y lo mismo pasa cuando aumenta la cantidad de equipos en toda la organización. El secreto para volverse un equipo extremadamente eficiente es la confianza y el entendimiento mutuo. Con el tiempo, cada quien aprende las fortalezas y debilidades de los demás, y se construye confianza entre los integrantes. Lo ideal es que ese tribal knowledge acumulado se transmita bien mediante documentación, mentoría, charlas, etc.