Ley de Gall, y lo que tiene que ver con las startups

Me di cuenta de algo fascinante el otro día: me di cuenta de que, como emprendedor y fundador de una startup, soy un constructor de sistemas.

En otras palabras, todo mi trabajo como fundador es construir y conectar sistemas interdependientes que (con suerte) funcionen muy bien juntos.

Y, si puedo construir esos sistemas de una manera que sea lo suficientemente simple y accesible para ser entendido y emocionar a otros, entonces, será suficiente para convencer a personas independientes, creativas y motivadas para que se unan a mis esfuerzos para diseñar aún más sistemas (e incluso más relaciones entre esos sistemas) que eventualmente se fusionarán en la forma de una organización de clase mundial.

Quiero decir, ¿qué es una empresa sino una colección de sistemas, organizados de manera que maximicen el rendimiento, optimicen el rendimiento y produzcan resultados descomunales (es decir, beneficios)?

Y aquí es donde las startups tienen una ventaja increíble sobre las empresas más antiguas y mucho más grandes: una startup tiene la oportunidad de decidir, por sí misma, no solo cuáles serán los sistemas fundamentales y principales y cómo operarán, sino también la forma en que el La organización decide qué nuevos sistemas construir y cómo se integrarán y se agregarán al metasistema existente más grande.

Y el "meta sistema" es simplemente la colección de creencias y los comportamientos resultantes que se han generalizado y normalizado en todo el organismo. Se podría llamar a esto cultura organizacional; con suerte, se basa en la confianza.

La ley de Gall es especialmente aplicable e importante para las nuevas empresas: necesitan tomarse el tiempo necesario para pensar de manera intencionada y explícita en los sistemas que utilizan para que tengan la oportunidad de luchar para construir sus ideas que cambian el mundo en servicios reales y productos que la gente realmente quiere.

Verá, el trabajo de John Gall se ha convertido en la regla general para el diseño de sistemas y se ha utilizado como un argumento muy sólido para la subespecificación (que es donde comienzan todas las nuevas empresas):

Un sistema complejo que funciona invariablemente se ha desarrollado a partir de un sistema simple que funciona. Un sistema complejo diseñado desde cero nunca funciona y no se puede parchear para que funcione. Tienes que empezar de nuevo con un sistema de trabajo sencillo.

Aquí es donde las startups tienen que estar hipervigilantes y emocionalmente conscientes y lo suficientemente maduras para saber que pueden causar un daño irreparable y permanente a sus posibilidades de éxito si, ya sea intencional o accidentalmente, se divorcian de los sistemas fundamentales que hicieron su visión única realmente utilizable.

Lo sé porque me he hecho esto a mí mismo en el pasado: he construido sistemas demasiado complicados y diseñados y los presenté a mis equipos solo para descubrir que han hecho mucho más daño que bien.

Además, algunas empresas codifican estos principios y sistemas originales en declaraciones de misión o visión o los respaldan como parte de sus declaraciones de valor corporativo, mientras que otras no. ¡Incluso el acto de codificar un sistema comprendido y utilizado es una decisión intencionada del equipo fundador y del liderazgo!

Y la tentación de sobre-diseñar algo (¡cualquier cosa!) Ya es bastante grande; agregue un poco de impulso comercial, algunas nuevas contrataciones, una pizca (o mucho) de capital de riesgo y un producto que parece estar funcionando, y de repente se despertará una mañana y se dará cuenta de que usted y su equipo están completamente hinchado y con sobrepeso con docenas de servicios web SaaS apenas utilizados y una tonelada de procesos (inventados) que, con una mirada honesta, parecen existir por sí mismos.

Buen trabajo, fundador de una startup: te jugaste a ti mismo.

¡Y lo pasamos tan bien! Comenzó de manera simple y las cosas estaban funcionando bien y, aparentemente, de la noche a la mañana, se ha retrocedido en una compleja red de sistemas que "no se pueden reparar para que funcione". Tendrá que hacer algunas cosas para volver. la línea de base y la “joya” fundamental que estaba funcionando.

Esta es la razón por la que la mayoría de las empresas más grandes no pueden competir con las startups mucho más pequeñas y ágiles: el costo de la ingeniería inversa o de deconstruir y desmantelar un sistema complejo y disfuncional es a menudo demasiado grande y demasiado destructivo para que valga la pena el esfuerzo.

En consecuencia, el sistema disfuncional es "suficientemente bueno" para la mayoría de las personas y la organización más grande y muy pocas personas están motivadas para "levantar la bandera blanca" y abogar por lo que realmente se requiere: comenzar de nuevo con un sistema simple y funcional.

Obviamente, las startups que han construido intencionalmente una cultura de introspección y han revisado despiadadamente sus sistemas obsoletos y anticuados obtendrán resultados mucho, mucho mejores que sus pares y, por supuesto, sus competidores empresariales más grandes.

Las empresas emergentes comienzan su vida con sistemas simples y, naturalmente, se expanden y desarrollan nuevos sistemas que generalmente están atornillados de una manera que la mayoría consideraría aleatoria y mezcolanza. La colección de sistemas simples forma sistemas complejos y algunos de estos funcionan durante mucho tiempo mientras que otros se descomponen muy rápidamente.

La organización que reconoce el delta de integraciones exitosas y no exitosas entre los nuevos sistemas y los viejos tendrá éxito (y sobrevivirá) mucho más tiempo que aquellas que ignoran intencionalmente la disfunción o asumen ingenuamente que todo saldrá bien en el camino.

Y las organizaciones que no solo reconocen rápida e intencionalmente trabajan juntas de manera activa para solucionar el problema, sino que también están dispuestas a, si la situación requiere una acción extrema, desmantelar sistemas completos para construir sistemas nuevos y más simples para soportar el peso de un nuevo y completo organización diferente (¡las startups pueden cambiar fundamentalmente cada 6 meses!).

No hace falta decir que es extremadamente difícil mantener los sistemas simples de manera estratégica y táctica mientras se les agrega de manera inteligente e intencional a medida que la organización crece.

Esto no quiere decir que sea un experto; más bien, soy lo suficientemente consciente emocionalmente como para saber (y tener evidencia empírica) que las organizaciones tienden hacia el caos y la entropía sin una revisión constante y consistente no solo de lo que se está haciendo sino de cómo se está haciendo.

Y, para ser aún más honesto, sé que tiendo a introducir la entropía en los sistemas si no tengo cuidado. De hecho, sé que incluso si hago todo lo posible, será una batalla cuesta arriba en cada paso del camino.

Lo mejor para el equipo es hacer algunas, si no todas, de las siguientes acciones:

  1. Programe el tiempo para revisar sus sistemas por equipo y / o departamento organizacional (por ejemplo, operaciones, ingeniería, marketing, ventas, etc.).
  2. Identifique, lo mejor que pueda, el principal sistema simple (original) que eventualmente se convirtió en uno complejo y aclara claramente los resultados (esperados) y las personas que deberían participar.
  3. Resuma e identifique las interdependencias del sistema que se está revisando; es decir, los demás sistemas que interactúan directamente con el de la revisión.
  4. Juzgue despiadadamente el sistema y ajústelo, pode o destrúyalo por completo y luego construya una nueva versión más simple (o tal vez vuelva a la versión Génesis).
  5. El consenso puede ser necesario o no, pero, independientemente de cómo su equipo tome las decisiones, asegúrese de que todos estén de acuerdo con el nuevo (¡y mejorado!) Sistema y que todos se comprometan firmemente con la responsabilidad.
  6. Marca el tiempo del experimento y establece un tiempo para revisar el sistema recién cambiado. Calendario en retrospectiva.
  7. Enjuague y repita.

Este es un gran problema para mi empresa y para mí, especialmente porque estamos en medio del crecimiento de nuestro equipo. También es relevante porque me he dado cuenta de que es hora de que revisemos los sistemas que hemos construido y, con un peine de dientes finos, nos tomemos el tiempo necesario para optimizar y (re) construir la base de nuestra empresa.

¿De qué otra manera llegaremos a la luna? ? ? ?

John es el ingeniero de software de YEN , una plataforma social que combina el poder de las redes sociales y múltiples intercambios de criptomonedas.