Escalando Rápido: Lecciones de Ingeniería de ~15 Años de Startups Tecnológicas

Gracias. Entonces, ¿qué sigue? ¿Qué sucede en ese punto de inflexión donde pasas de un crecimiento lento a un crecimiento acelerado? Lo primero que debes recordar es que la tecnología es una carrera de la Reina Roja. Eso significa que debes aprovechar ese crecimiento explosivo ahora mismo mientras está sucediendo porque ningún modo dura para siempre, y si has encontrado algo que vale la pena perseguir, al menos hay otras cinco empresas intentando hacer lo mismo mientras persigues este crecimiento.

Entonces, para mantener el ritmo del crecimiento, tendrás que escalar tres partes de tu empresa. Tendrás que escalar el negocio, el equipo y la tecnología. Ahora, escalar el negocio es bastante simple. Olvídate de lo que te dicen todos los empresarios. Aquí solo hay dos cosas que puedes hacer. Puedes vender más productos a más personas. Por eso todo es una suscripción en estos días. O puedes vender productos a un precio más alto. Por eso todas las empresas comienzan como B2C y luego pasan a B2B y Enterprise, o si sigues a algún influencer o creador independiente, comienzan con un eBook de diez dólares y eventualmente tienen un curso en video de varios miles de dólares. Es lo mismo.

Pero cuando estás escalando el negocio, debes tener cuidado con la curva S. Cada negocio o producto alcanza un punto de saturación donde tu rotación y la adquisición de clientes comienzan a equilibrarse y dejas de crecer. Y ahí es cuando tienes que encontrar algo nuevo. Debes lanzar más productos, encontrar nuevas audiencias o simplemente, tienes que encontrar algo nuevo que hacer cuando alcanzas el punto de saturación. Pero como ingeniero, creo que todos somos ingenieros aquí, ¿por qué te importaría algo de esto? Porque el lado empresarial es tu combustible. Quieres que el negocio crezca porque luchar contra el mercado significa que no estás luchando entre ustedes dentro de la empresa. Cuando tu negocio crece, ahí es donde vienen las promociones, ahí es donde vienen más desafíos de ingeniería. Tu carrera crece, tu CV se ve más impresionante. Todo lo bueno viene de hacer crecer el negocio y obtener esos resultados empresariales. Y si no tienes crecimiento, si estás en un negocio estable con un crecimiento bajo, tu carrera se convierte en un juego de suma cero. Tienes que robar tu promoción a alguien más que no está siendo promovido. Tienes que, ya sabes, todo se convierte en un juego de suma cero. Entonces, los números principales de los que debes preocuparte cuando piensas en el negocio son el costo de adquirir un cliente y su valor de por vida. La diferencia entre esos dos números impulsa todo lo demás en tu negocio. Ahora, mientras los empresarios se encargan de ese lado, tú te ves así como ingeniero. Solo estás tratando de construir lo más rápido posible para no ser el cuello de botella de la empresa. El único objetivo que tienes como equipo de ingeniería en una startup que atraviesa ese punto de inflexión es no ser la razón por la que el negocio tenga que frenarse.

Y recuerda, la ingeniería es la herramienta, no el objetivo. Estás construyendo esa flor, pero lo que estás vendiendo son esas personas increíbles que pueden hacer cosas geniales que antes no podían hacer. Entonces, una cosa, esto nos lleva a escalar el equipo. Porque muchos problemas tecnológicos, cuando los miras de cerca, en realidad son problemas de personas. Sí, puedes escribir un código realmente increíble que haga cosas maravillosas y te haga sentir súper inteligente, pero sería mucho más fácil tener una conversación de cinco minutos y preguntar, ¿sabes por qué la API no está devolviendo los datos que necesito? Porque si puedes resolverlo de esa manera, esa conversación de cinco minutos puede ahorrarte una semana de trabajo. Es mucho más rápido. Es mucho más rápido resolver problemas técnicos de esa manera.

Entonces, cómo escalas el equipo realmente afecta todo lo demás en tus procesos de ingeniería. Y el error que muchas empresas cometen en esta etapa es que construyen equipos horizontales en lugar de equipos verticales. Así que terminas con un equipo de front-end y un equipo de back-end, tal vez algunas personas de administración de sistemas. Y esta es una forma realmente excelente de asegurarte de que todos siempre estén bloqueados por alguien más. Siempre estás esperando, como el equipo de front-end siempre está esperando al equipo de back-end para que terminen su trabajo. El equipo de back-end siempre está esperando al equipo de front-end. Siempre alguien está esperando a los administradores de sistemas. Y la única forma en que esos equipos no se bloqueen entre sí es si sus hojas de ruta están cuidadosamente sincronizadas y nada lleva más tiempo de lo planeado. Porque los proyectos de ingeniería siempre toman exactamente el tiempo que planeas para ellos, ¿verdad? Entonces, lo que realmente quieres son equipos verticales. Deben estar organizados por el dominio empresarial que están abordando. La idea aquí es que organices tus equipos por lo que están haciendo, no cómo lo están haciendo. Hay diferentes nombres para esto. Como, cada consultor que habla sobre equipos y cosas tiene un nombre diferente para este concepto. Algunos los llaman equipos de producto empoderados, equipos alineados con el flujo, equipos centrados en la capacidad empresarial, pero como sea que lo llames, siempre tienen el mismo objetivo. ¿Cómo podemos tener equipos que entreguen valor por sí mismos sin ser bloqueados por otros equipos? El objetivo es que cada equipo, o tú en un equipo, pueda asumir tu destino, asumir tu desorden y comprender tu dominio. Asumir tu destino significa que puedes enviar valor desde la idea hasta la producción. Tienes una idea, como tu equipo tiene una idea y puede llevarla hasta la producción, entregando valor a los usuarios. Asumir tu desorden alinea los incentivos y significa que eres responsable de mantener tu código en producción, asegurándote de que funcione y todas esas cosas. No se trata de escribir un código y lanzarlo a través de la pared a QA y equipos de implementación, y así sucesivamente. Debes hacerte cargo de eso porque así te importará más. Puedes sentirte orgulloso de lo que has construido porque estás ahí para ver el impacto que tiene en tus usuarios, y con esa propiedad a largo plazo, obtienes experiencia en el dominio donde realmente comprendes a los usuarios a los que estás resolviendo problemas y los problemas que tienen, lo que luego desbloquea una colaboración realmente buena entre el producto y la ingeniería donde puedes trabajar en este ciclo de desarrollo de productos donde te enfocas en cruzar el agua, no solo en construir un puente. La idea aquí es que los equipos de ingeniería, especialmente los equipos de ingeniería de productos, se involucren temprano en el proceso, lo más temprano posible, e ideen junto con el producto para desarrollar la mejor solución al problema, no solo una solución que alguien más pensó. Puedes hacer esto porque comprendes el dominio y comprendes tu... ups, no quería presionar eso todavía.

Lo que obtienes de esto es que los ingenieros entienden por qué están construyendo lo que están construyendo, lo que les permite priorizar los resultados comerciales en lugar de simplemente escribir un código genial y distraerse en largos debates sobre cuál es la mejor manera de escribir un bucle for o cualquier otra cosa. Todas las cosas que ves en Twitter, la mayoría de esos debates en realidad no importan en absoluto. Cuando tienes ingenieros que comprenden su dominio, puedes comenzar a delegar decisiones, no solo tareas. Este es probablemente el mayor punto de apalancamiento que puedes utilizar al escalar un equipo o escalar una empresa, ya que las personas que están más cerca del problema, las personas que están más cerca del dominio con el que están trabajando, probablemente saben mejor cuál es la solución correcta. En última instancia, no puedes tener un único tomador de decisiones central que piense por todos en el equipo. Esto es muy común al comienzo de las startups, como el fundador o eventualmente el jefe de producto propone todas las ideas y todos los demás solo construyen, y lo que obtienes es un cuello de botella muy fuerte que tiene que involucrarse en cada pequeña cosa y está bloqueando a la empresa completa o todos los productos y todo en lo que estás trabajando para avanzar. Desafortunadamente, o afortunadamente, esto también significa que tendrás que dejar de lado tu ego cuando estés lidiando con la revisión de código, y tendrás que fusionar algún código imperfecto, porque está bien, está bien. El código que funciona siempre supera al código que es perfecto. Así que haz revisiones de código rápidas, un proceso de revisión de código lo más corto posible, y levanta la mano si mides el tiempo de revisión de código en minutos. ¿Dos manos? Bien. ¿Horas? ¿Algunos? De acuerdo. ¿Quién ha estado en una revisión de código que ha llevado varios días o semanas para fusionar algo? Lo siento por todos ustedes. El trabajo en progreso es la forma más rápida de matar todo tu progreso. Cuando tienes código obsoleto por ahí, se vuelve cada vez más difícil fusionarlo y resolver eso, conflictos de fusión, todas esas cosas, especialmente cuando te encuentras en una situación en la que tienes varios equipos trabajando juntos en el mismo producto, o tienes equipos trabajando en diferentes microservicios que se comunican entre sí. Si tienes código que simplemente está por ahí en el limbo de la revisión de código, se vuelve más y más difícil de aterrizar. Entonces, una forma de acelerar eso es hablar entre ustedes antes de escribir el código. Antes de que se escriba cualquier código, lo que nos gusta hacer en mi equipo es reunirnos para cada nuevo proyecto, ponernos de acuerdo en el diseño, ponernos de acuerdo en la solución antes de que se escriba cualquier código para que cuando hagamos revisiones de código, sea solo una verificación rápida. Podemos hacer la mayoría de nuestras revisiones de código en dos o tres minutos. Obtienes a dos personas que lo revisen, una prueba rápida, tal vez, y dices, bien, se ve bien para mí. Si está roto en producción, lo arreglaremos más tarde.

Entonces eso es escalando el equipo. Ahora, ¿cómo escalas la tecnología? No pienses demasiado en la tecnología. La tecnología es en realidad la parte más fácil de escalando un negocio. En su mayor parte, solo estás resolviendo problemas conocidos con soluciones conocidas.

Esto se encuentra en el libro Cómo se Hacen las Grandes Cosas. Es un libro realmente bueno. No se trata de ingeniería de software, pero trata sobre proyectos de ingeniería a gran escala. Habla sobre cómo China puede construir un montón de puentes y plantas de energía al año, mientras que Estados Unidos no puede. El factor principal del que hablan es que en China tienen como diez diseños estándar para todo, y luego los ingenieros llegan, analizan la situación y simplemente eligen el diseño más apropiado para aplicarlo a esa situación, y aquí está la cosa.

Ajustan la situación para que se adapte al design. No ajustan el design de un componente listo para usar para que se adapte a la situación. Es al revés. Cambian el problema para que se ajuste a la solución que ya tienen, y de esa manera pueden construir mucho más rápido y están guardando sus fichas de innovation para las cosas que son realmente nuevas y diferenciadoras en su empresa. Lo que nos lleva a simplemente resolver el problema, no un problema diferente y más difícil. Lo más difícil de hacer en ingeniería de software es construir una solución genérica, especialmente cuando todo lo que tienes es un problema específico.

En general, es una buena idea, o más bien lo diré de esta manera. Cuanto más viejo me hago, más se parece mi code a un proceso muy simple paso a paso. No impresiona a nadie. Es súper aburrido de ver, y personalmente, creo que el mayor cumplido que puedes recibir sobre tu code es cuando alguien lo ve y dice, espera, ¿eso es todo? Así es, eso es todo. Es simple, fácil de entender y fácil de mantener. Porque siempre tienes que rechazar la complejidad. La ingeniería es una lucha interminable contra la complejidad, y a veces eso significa decir no a un architecture astronauta que intenta construir un framework genérico para resolver un problema para siempre cuando solo necesitas, ya sabes, necesitamos lanzar este code mañana, ni siquiera sabemos qué estaremos construyendo en diez días, y estás tratando de construir un framework.

Solo soluciona el problema, resuélvelo y continúa. Y esto también significa que, nuevamente, porque comprendes tu dominio, porque tienes propiedad a largo plazo de las cosas que estás construyendo, también puedes resistirte a tu producto, a tus gerentes de producto. Muy a menudo, tienes un requisito que arruina toda la historia y la hace mucho más difícil de lo necesario. Por lo general, puedes resistirte a tu PM y decir, oye, esta cosa está dificultando mucho nuestro trabajo, y ellos dirán, oh, sí, mierda, en realidad no necesitamos eso, no nos importa. Simplemente elimina ese requisito y ahora puedes usar una solución muy simple. Y de dónde proviene la mayor complejidad en un proyecto de ingeniería de software no es realmente el code que estás escribiendo, es la architecture que estás creando. Si piensas en tu code como una serie de cajas interconectadas, las cajas son como tu code, esas son clases, modules, servicios, como quieras llamarlos, y las líneas son cómo se comunican entre sí. Cuanto más conectadas estén estas líneas, cuanto más entrelazado esté todo, más complejo será.

Una lección que he aprendido es que siempre puedes cambiar cómo funciona una caja autocontenida. Puedes eliminar todo el code y escribir nuevo code que sea más limpio o mejor o lo que sea, pero es muy difícil cambiar esas conexiones. Y una forma de limitar esa complejidad es organizar tu code verticalmente en lugar de horizontalmente. Así que en lugar de dividir componentes, hooks, tipos, utilidades o lo que tengas en tu o no sé qué stack uses, pero si en lugar de eso divides tu code por todo lo que va en un panel de control, cualquier cosa que vaya en un perfil de usuario, en una lista de tareas, entonces tienes módulos o cajas que no están tan entrelazados. Y son esas APIs claras las que hacen todo más fácil.

Así que un truco que me gusta usar es el desarrollo impulsado por tipos o contratos, donde de antemano hablamos sobre las diferentes piezas móviles de una historia que estamos construyendo, y luego hablamos sobre cómo van a comunicarse entre sí, y luego todos los que escriben el code tienen la capacidad de construir la implementación interna de la manera que deseen. Desafortunadamente, o afortunadamente, el uso de módulos verticales puede significar que tendrás que copiar y pegar algo de code. Y esta es probablemente una de mis opiniones más controvertidas, que reducir el code, no repetirse a uno mismo, en realidad es malo. Y siempre que sea posible, debes centrarte en la separación de responsabilidades más que en reducir tu code, porque cuando reduces tu code, tu arquitectura termina viéndose así, si lo reduces demasiado. Todo se superpone, obtienes componentes o servicios que requieren diez parámetros booleanos para configurar su comportamiento, y cambias algo aquí y de repente algo completamente diferente en lo que ni siquiera estabas pensando se rompe. Cuando eso te sucede, significa que tu, mierda, se me está acabando el tiempo, eso significa que tu code está interconectado de una manera que te causa problemas.

Entonces una de las cosas en las que me gusta enfocarme, especialmente cuando hablo de arquitectura, es enfocarme en tus datos y tus estructuras de datos, cómo organizas los datos en tu base de datos, cómo organizas los patrones de acceso a los datos, cosas así, porque resulta que cuando obtienes los datos correctos, tu code es tan fácil de implementar que casi parece que no tienes nada que hacer todo el día, y cuando obtienes tus datos incorrectos, cuando no se ajustan a tu modelo de dominio, parece que tienes que hacer todo lo posible para que las cosas encajen. Y por eso quieres utilizar equipos verticales que escriban code vertical, porque significa que tú como equipo tienes el control de tu API, el control de tus datos, el control de tu UI, y puedes diseñar todo para que encaje, resuelva tus problemas, y no algún ejemplo genérico que encuentres en internet y del que la gente está hablando. Así que esa fue mi charla. Estoy convirtiendo todo esto en un libro. Si usas ese código QR, puedes obtener más información sobre lo que estoy haciendo, y gracias.

Entonces, vamos a construir nuestra API de una manera muy genérica en caso de que tengamos más clientes en el futuro. Genial. Haces eso, pasas mucho tiempo extra debatiendo tu diseño, debatiendo cómo hacer que sea genérico y todo eso. Lo envías y estás muy feliz. Luego, seis meses después o dos años después, realmente obtienes ese segundo cliente y generalmente te das cuenta de que tu abstracción está equivocada y necesitas desechar esa API de todos modos porque la hiciste genérica de una manera que solo se ajusta al cliente que tenías, no al nuevo cliente que creaste. Entonces, diría que es una respuesta un poco evasiva, pero depende. En su mayor parte, si te enfocas en obtener tus datos correctos y obtener tu arquitectura correcta, es muy fácil desechar más tarde el código que es malo y reemplazarlo con un mejor código, pero es muy difícil cambiar la arquitectura si la tienes mal. Entonces, me enfocaría principalmente en la modelización de dominio y en hacer esa parte correctamente en lugar de tener un código súper limpio. Creo que la siguiente pregunta es, mi empresa piensa en equipos clásicos, front-end, back-end, desarrollar una experiencia más profunda en su aplicación específica. ¿Cómo asegurar esto también en los equipos de producto? Entonces, ¿cómo aseguras la experiencia en los equipos de producto? Creo que es un tipo diferente de experiencia. Soy un firme defensor de tener equipos de producto. Entonces, puedes tener un equipo de producto que en conjunto sea experto en su dominio y en su problema o conjunto de problemas o en su tipo de usuario o lo que sea, pero luego dentro de ese equipo, puedes tener personas que se centren más en el front-end, personas que se centren en el móvil, personas que se centren en el back-end. Entonces, juntos, tienen experiencia en el dominio y por separado, tienen experiencia en la pila tecnológica para sus partes específicas de la pila. Luego, si tienes la organización vertical de tu código, en realidad no necesitas saber qué están haciendo las otras partes de tu aplicación, porque tienes APIs bien definidas, de modo que no necesitas conocer los detalles. Creo que esa es mi respuesta allí. Experiencia en el dominio sobre la experiencia específica del código y APIs limpias para no necesitar conocer esos detalles tanto. La siguiente pregunta, gracias. ¿Cómo evitas que el código imperfecto que fusionaste hoy ralentice el progreso? Un par... Creo que ya respondimos a esta. Un par de años después. Creo que respondimos a esa primero. No, creo que cerré la primera. Está fuera de sincronización. No funciona. ¿Te gusta algo más? No realmente. La siguiente. ¿Cómo equilibrar DRY y la duplicación de tu código? Creo que en términos de equilibrar DRY y la duplicación de tu código, me gustaría tener ingenieros senior o alguien a quien le importe cuidar de tu base de código, así que me gusta permitir que los patrones se desarrollen, animar a las personas a no preocuparse demasiado por secar el código, simplemente construir lo que necesitas construir, y luego tener un proceso en segundo plano que observe lo que la gente está haciendo, buscando patrones que están surgiendo y luego convertirlos en frameworks.

Entonces, cuando tienes como cuatro o cinco soluciones diferentes para una misma cosa, se va a volver muy obvio qué abstracciones se necesitan y qué partes del code realmente se pueden secar y cuáles no. Es muy difícil predecir eso de antemano, y honestamente, el peor, más difícil de mantener, código más horrible que he escrito en mi vida siempre fue intentando secar algo que parecía similar pero que en realidad se estaba divergiendo en diferentes direcciones de desarrollo, y luego es muy difícil desenredarlo después. Pero si lo dejas seguir su propio camino primero, y luego lo respaldas más tarde, eso lo hace más fácil. La siguiente, elegí equipos de características de producto sin incluir la gestión de productos. ¿Buena o mala idea? Siento firmemente que los productos deben ser parte de los equipos de ingeniería de productos. Tienes equipos de plataforma donde puedes tener un equipo cuyos interesados son usuarios internos, como React es un muy buen ejemplo de un equipo de plataforma en Facebook que está desarrollando un framework de front-end y sus interesados son otros ingenieros. Luego tienes, como, y creo que en realidad tienen gerentes de producto en el equipo que se enfocan en la parte de la plataforma. Entonces, sí, supongo que lo que estoy tratando de decir es que si es posible, deberías tener a alguien que desempeñe el rol de gerente de producto en cada equipo. No necesariamente tienen que tener el título de gerente de producto, puede ser un líder técnico o un gerente de ingeniería, pero alguien cuyo trabajo sea hablar con los interesados, verificar que las cosas que has construido estén resolviendo sus problemas, potencialmente traducir el dominio al lenguaje de ingeniería, el lenguaje de negocios al lenguaje de ingeniería, y cosas así. Al construir en segmentos verticales, ¿cómo evitamos el infierno de dependencias con bibliotecas compartidas y modelos que requieren cambiar todos los segmentos cuando uno de ellos cambia? Este es un muy buen ejemplo de secar tu código demasiado pronto. Si has separado algo en una biblioteca y te encuentras constantemente teniendo que trabajar en ambos, la biblioteca y el producto al mismo tiempo, eso significa que tu biblioteca no es realmente una biblioteca, es una preocupación del producto y debería fusionarse de nuevo en el producto. Una señal de una biblioteca exitosa es que al principio, cuando la creas por primera vez, tienes que trabajar en ambos juntos porque la biblioteca es nueva, pero eventualmente deberías hacer menos y menos cambios en tus bibliotecas, y más y más solo en tu producto. Esa es una señal de una buena abstracción. En realidad, separarlas en un repositorio diferente es un truco muy bueno para animar a los ingenieros a no filtrar preocupaciones del producto en tus bibliotecas. Esa fricción es realmente útil, diría yo, porque te anima a evitar poner preocupaciones del producto en la biblioteca. Muchas gracias. Siempre hay preguntas, aplaudamos a Fizik.