Business driven mindset

Lee este post en inglés aquí.

Mientras trabajaba en Mercadona Tech empecé a llamarme a mi mismo Ingeniero de Producto. Miquel Torres escribió un post muy guay sobre esto. Gergely Orosz, llegó a las mismas conclusiones por su cuenta y también escribió un post explicándolo en detalle.

Pero luego empecé a trabajar en Creditas. Y me di cuenta de que una mentalidad de producto no era suficiente. Siempre pensé que Creditas era un poco diferente por lo innovadores que son sus modelos de negocio: una empresa impulsada y guiada por el negocio. Business driven. Pero hace unos días, el CEO de Creditas me dijo algo que nunca olvidaré:

Todas las startups son empresas business driven. - Sergio Furio

Este es el tipo de frase que tiene consecuencias muy profundas. Pero, ¿qué significa realmente? Porque una startup no es solo un negocio. También es tecnología. Y también es personas. ¿Cómo puede el negocio impulsar y guiar la tecnología y las personas? ¿Y cuáles son las implicaciones de esta mentalidad a gran escala?

Comparte este post en 🐦 twitter o suscríbete a mi newsletter With a grain of salt para recibir un email con novedades cada cierto tiempo.

De pirates a marina

Reid Hoffman habla en su libro Blitzscaling sobre lo que sucede cuando una empresa ha estado escalando agresivamente durante un tiempo. En algún momento tiene que pasar por una transición: de piratas a marina. Si no sabes de lo que estoy hablando, puedes escuchar el capítulo de Masters of Scale en el que habla de esto mismo.

Pero la metáfora ha sido muy mal interpretada. ¡Déjame explicar por qué ☝️! Esto es lo que aparece en la mente de las personas cuando escuchan sobre la diferencia entre piratas y marina:

Piratas Marina
Sin forma ni estructura. Estructura con alto control.
Caos. Rutina.
Software de poca calidad programado a golpe de machete. Soluciones empresariales altamente escalables.
Improvisan la mayor parte del tiempo. Tienen un plan estructurado.
Velocidad. Más despacio imposible.

Todos estos son prejuicios. Porque Reid habla principalmente de cambios en la ética, moral y cultura a gran escala. No habla de cambios en la calidad, la velocidad, la manera de planificar, la forma de crear metas o el empoderamiento. Sí que habla de cambios en la estructura; ahí es más fácil equivocarse al escalar. Pero, ¿qué tiene que ver la estructura con el negocio? ¿Y qué es la estructura realmente?

En el mismo libro habla de las 5 etapas de una startup: familia (de 1 a 9 empleados), tribu (decenas de empleados), aldea (cientos de empleados), ciudad (miles de empleados) y nación (más de 10000). Nunca he estado en una empresa en fase nación, así que no tengo nada que decir al respecto. Pero he estado en todos las demás y he pasado por un par de transiciones. Así que veamos cómo una empresa evoluciona su estructura de familia a ciudad.

Estructura

¿Has visto ya el montaje de la Liga de la Justicia de Snyder? Si sí, ya sabes lo que pasa cuando juntas las tres cajas: destrucción. Pero con la estructura pasa exactamente lo contrario. Si no ha visto la película, no te preocupes. Te lo explico.

La estructura se puede descomponer en tres partes fundamentales: estructura del negocio o del producto, estructura social y estructura de sistemas. La estructura de sistemas también se conoce como arquitectura. El grado de sincronización de estas tres es un indicador de la salud de una empresa: la estructura social debe coincidir con la arquitectura, la arquitectura debe coincidir con el negocio y la estructura del negocio debe coincidir con la estructura social. En teoría, hay muchas formas en las que la estructura puede cambiar con el tiempo. Pero recuerda: business driven.

En la fase familiar, estas tres partes casi siempre coinciden. Incluso sin querer. Un equipo con un objetivo de negocio liderado por el equipo fundador. La gente mantiene su enfoque en lograr ese objetivo. La mayoría de las veces, si no se logra, la startup muere. Hay algo de especialización: backend, frontend, mobile, diseño, producto, etc. que no es lo ideal pero funciona en esta etapa. También es más barato y más fácil encontrar personas especializadas que generalistas. A pesar de esto, la ley de Conway no juega malas pasadas. Todavía.

Las organizaciones dedicadas al diseño de sistemas […] están abocadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones - Melvin E. Conway

El error que más he visto cometer a los fundadores con bastante frecuencia es tratar a los miembros no fundadores como meros ejecutores. No involucrar al resto del equipo en las decisiones del negocio es el punto de partida para una cultura sin ninguna apropiación real sobre el resultado. La apropiación sobre lo producido es solamente una ilusión que involuntariamente crea una separación entre la estructura del negocio y la estructura de sistemas. Pero a partir de este momento, una startup puede tomar dos caminos. O corrige su rumbo y crece hacia una ciudad saludable o continúa con sus malos hábitos atravesando una cadena de hechos desafortunados que conducen a una cultura sin una apropiación real. Déjame pintar ambos escenarios.

Hacia una ciudad sana

El valor de una startup radica en su crecimiento. Y después de un éxito moderado, una startup necesita acelerar ese crecimiento. Eso se traduce en objetivos de negocio más ambiciosos. Lo que naturalmente conduce a dividir esos objetivos en otros más pequeños que deberían estar desacoplados pero alineados. Esto no es más que diversificar la inversión para reducir el riesgo. La diversificación lleva a múltiples enfoques. Y todo el mundo ya sabe que quien persigue dos liebres no atrapa ninguna. Entonces, de repente, se crean varios equipos a través de Dynamic Reteaming; cada uno con su propio objetivo. Al mismo tiempo, la arquitectura evoluciona de forma iterativa en función de objetivos de negocio iterativos. El negocio es como la gravedad para las personas y como una brújula para la tecnología.

Con los años, en Systen Design hemos tenido que tratar con las consecuencias de separar responsabilidades. Centrarse en un único objetivo hace que la complejidad de cada equipo sea pequeña pero, a un nivel superior, la estructura social comienza a parecerse cada vez más a un sistema distribuido. Esta es una de las razones por las que las startups comienzan a establecer algunos estándares sobre cómo las personas se comunican, cómo documentan sus decisiones y cómo colaboran. Esto ayuda a sincronizar las estructuras de negocio, social y de sistemas.

Y así, una startup alcanza el tamaño de una tribu. Matthew Skelton y Manuel Pais en Team Topologies usan el término Stream Aligned Team para definir un equipo multidisciplinar con un objetivo de negocio claro. Suelen centrarse en clientes externos. Pero en esta fase empiezan a aparecer otro tipo de equipos cuyos clientes son internos. Los equipos de plataforma actúan como empresas SaaS cuyos clientes son sus propios compañeros.

Un día en la vida de un equipo business driven puede parecer extraño para la mayoría de las personas en nuestra industria. ¿Por qué? Porque no hay nadie dictando qué hacer. Lo único que se tiene es un objetivo de negocio que, eso sí, está vinculado a una visión. Tienen que investigar, diseñar, probar, documentar, implementar, desplegar, lanzar y medir el impacto por sí mismos. Design Thinking tiene mucho que ver con esto. No significa que todo el mundo necesite todas las habilidades para hacer todo por su cuenta. Simplemente significa que todos están involucrados en el ciclo de vida completo del producto. El equipo está formado por personas con habilidades en forma de T. Todos se comunican en su día a día sin barreras y toman decisiones juntos. Esto tampoco significa que sea una democracia. Simplemente significa que el equipo trabaja en un modo de alta colaboración todo el tiempo. La gente todavía tiene responsabilidades individuales en algunas áreas.

Hasta el tamaño de tribu, la principal estructura social era el equipo. Pero hacia el tamaño de ciudad, empiezan a aparecer estructuras más grandes. Algunos las llaman Unidades de Negocio, otros las llaman Tribus. Da igual. El equipo fundador comienza a actuar más como una fondo de Venture Capital y las Unidades de Negocio comienzan a actuar como startups independientes. La empresa comienza a parecerse cada vez más a un ecosistema; un hub de startups. Los equipos de plataforma pueden ser internos a una Unidad de Negocio o externos trabajando para un mercado más grande: toda la empresa.

Iniciativas a nivel de empresa siguen apareciendo de vez en cuando. Se resuelven a través de Streams of Work: colaboración entre personas de diferentes equipos o incluso de diferentes Unidades de Negocio. Estas personas se juntan para formar un equipo de corta duración. Investigan, diseñan, divergen, convergen, implementan y miden el impacto. Una vez logran el objetivo, vuelven a sus equipos.

Una cadena de eventos desafortunados

El enfoque equivocado para el crecimiento acelerado es probar tantas funcionalidades como sea posible. Pero la mayoría de las startups siguen ese camino. Lo que conduce a tener que contratar más personas: al principio más personas en ingeniería favoreciendo la especialización; y en algún momento roles inter-gerenciales como Product Owners que recogen requisitos de los miembros fundadores, escriben pseudo historias de usuario y las colocan en un backlog. La división entre negocio e ingeniería empieza a crecer.

Somos animales sociales. Tendemos a juntarnos y formar grupos. En una startup saludable, las personas generalmente se organizan en torno a objetivos de negocio. Pero sin ellos, la gente se organiza en torno a lo que tienen en común. Entonces, de repente, comienzan a aparecer equipos muy especializados de backend, frontend, mobile, diseño, producto y negocio. Establecen sus propios objetivos y comienzan a optimizar para su propio bienestar. Y a veces, de forma inconsciente, las decisiones se toman emocionalmente. Las estructuras de negocio, social y de sistemas comienzan a desincronizarse.

Un día en la vida de un equipo así se parece bastante al juego de la patata caliente. Alguien de negocio decide qué hacer, pero solo a un nivel abstracto porque no tiene conocimiento sobre las limitaciones técnicas. Alguien de producto juega al ping pong con alguien de diseño para crear una propuesta en la que tanto negocio como ingeniería estén de acuerdo. Las personas de frontend se centran en el lado de la interfaz, mientras que las personas de backend crean las APIs. Backend agrega una tarea en el ya sobrecargado backlog de alguien de infraestructura; que no tiene mucho tiempo para implementar los nuevos requisitos. Pero de repente, la persona de negocio habla con sea quien sea CTO. Quien acude al departamento de infraestructura y usa la autoridad para cambiar las prioridades. Las personas de frontend necesitan algunos cambios en las APIs. Pero eso ya no es posible porque requeriría mucho re-trabajo. La funcionalidad se lanza finalmente mucho después de la estimación original. Y el ciclo comienza de nuevo mientras analistas de datos intentan de alguna manera recopilar datos que solo se correlacionan con la funcionalidad.

Y luego, de alguna manera, la startup alcanza el tamaño de tribu. E Ingeniería comienza a utilizar un vocabulario extraño que no tiene nada que ver con el negocio. No trabajan de forma empírica y seguramente no miden su impacto. Comienzan a aparecer equipos hiperespecializados de infraestructura, seguridad, datos o QA. Negocio ahora es solo una entidad distante y sin rostro que exige funcionalidades. Ingeniería es meramente una fábrica de funcionalidades que se dedica a proyectos que nadie entiende. Product Management se convierte tristemente en Project Management.

Todos sabemos a estas alturas que el modelo en forma de matriz de Spotify no les funcionó ni a ellos. Pero las empresas que están demasiado perdidas todavía lo utilizan como inspiración porque no saben qué otra cosa hacer. Y así empiezan a aparecer estructuras sociales más grandes. Que se parecen más a empresas de consultoría que a Unidades de Negocio. Algunas son más especializadas que otras.

Llegados a este punto, las estructuras de sistemas, social y de negocio están muy desincronizadas. Pocas personas entienden ya el negocio. Si se les preguntara a 10 personas al azar sobre el impacto en el negocio de su última tarea, no lo sabrían. Los equipos son solo fábricas de funcionalidades. Probablemente sería más barato contratar empresas de consultoría porque no habría que gastar tiempo y dinero en la gestión. Las buenas personas se van de la empresa, mientras que las buenas que vienen, se van poco después de incorporarse.

La empresa es ahora tan grande que el caos es algo cotidiano. El caos no es malo. Pero todas las personas se sienten perdidas porque no tienen objetivos claros.

Objetivos de negocios iterativos

Supongamos que quieres crear una colonia humana en Marte. Tu primer pensamiento podría ser empezar por diseñar la nave espacial que llevará a la tripulación al planeta rojo. Pero espera. Eso sería demasiado arriesgado. Ni siquiera sabes cómo ir a la órbita de la Tierra. Entonces, en cambio, primero comienzas llevando pequeños satélites a la órbita de la Tierra con cohetes pequeños. Luego lo intentas con satélites más grandes. Tu primer objetivo sería hacer que este modelo de negocio sea sostenible mediante la reutilización de los propulsores.

Todo bien hasta aquí. Pero nunca has tenido gente a bordo. El transporte de personas es muy diferente al transporte de cosas. Por lo tanto, utilizas parte de los beneficios económicos para investigar qué se necesita para llevar a las personas al espacio. Y después de muchos intentos fallidos finalmente lo logras. Finalmente puedes llevar astronautas a la Estación Espacial Internacional.

Pero, ¿qué pasa con los viajes más largos? ¿Qué otros riesgos podrían haber? Para averiguarlo planeas un viaje a la luna. Eso debería enseñarte más sobre cómo transportar personas sin muchos riesgos. Y te permitirá probar la siguiente iteración de la nave espacial antes de hacer rutas más largas.

Creo que ya te estás dando cuenta por dónde voy con todo esto. La mayoría de las startups tienen una visión de hacia dónde quieren llegar. Pero no logran dividir esa visión en pasos iterativos más pequeños. Empiezan a trabajar directamente en los planos para la colonia en lugar de poner satélites en órbita. Empiezan a hablar de escalabilidad en lugar de evolución. Diseñan enormes sistemas, hacen reorganizaciones sin sentido mientras pierden constantemente oportunidades de negocio.

La naturaleza del desarrollo de software es mantenerlo simple, hacerlo valioso y construirlo pieza por pieza. Y tener una mentalidad guiada por el negocio es solo otra forma de decir que una startup necesita trabajar de manera empírica y colaborativa. De extremo a extremo. No existe otra forma eficaz de medir el impacto.

El negocio es como la gravedad a la hora de estructurar los equipos y como una brújula a la hora de tomar decisiones de producto y técnicas. - David Stanete

Si has llegado hasta aquí, puedes imaginar cómo evitar la triste historia. O tal vez no. Si no, puedes escribirme. Mis DMs siempre están abiertos. Todas las personas que trabajan en una startup, cualquier startup, necesitan una mentalidad guiada por el negocio. Pon mucho esfuerzo en definir objetivos iterativos. Es lo único en lo que no puedes equivocarte. Recuerda que el negocio es como la gravedad para las personas y como una brújula para la tecnología. La construcción de arquitecturas evolutivas y la reorganización dinámica solo son posibles si prestas especial atención a tener objetivos de negocio iterativos.

Comparte este post en 🐦 twitter o suscríbete a mi newsletter With a grain of salt para recibir un email con novedades cada cierto tiempo.