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

Así que te invitamos a unirte a mí para dar la bienvenida a uno de los oradores a la sala. Y, por supuesto, estoy seguro de que todos están emocionados de escuchar sobre qué va a hablar.

Scaling rápido, lecciones de ingeniería de unos 15 años de startups tecnológicas. Puede que sea viejo. Entonces, tus usuarios están yendo... ¿Y ahora qué haces? ¿Qué sucede a continuación? Entonces, ¿qué sucede en ese punto de inflexión donde pasas de un crecimiento lento a un crecimiento rápido? 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 encontraste algo que vale la pena perseguir, al menos hay otras cinco compañías tratando de 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 todas las personas de negocios. Aquí solo puedes hacer dos cosas. 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 compañías comienzan como B2C, y luego pasan a ser B2B y Enterprise, o si sigues a algún influencer o creador independiente, comienzan con un libro electrónico de $10 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. Tienes que lanzar más productos, encontrar nuevas audiencias o simplemente, tienes que encontrar algo nuevo que hacer cuando llegues al punto de saturación. Pero como ingeniero, creo que todos somos ingenieros aquí, ¿por qué te importaría cualquiera 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 de bajo crecimiento, 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 alimenta todo lo demás en tu negocio. Ahora, mientras las personas de negocios 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 ralentizarse. 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. Muchos problemas técnicos, cuando los miras de cerca, en realidad son problemas de personas. Sí, puedes escribir un código increíble que haga cosas maravillosas y te haga sentir muy inteligente, pero sería mucho más fácil tener una conversación de cinco minutos y preguntar, ¿sabes por qué la API no me devuelve los datos que necesito? Porque si puedes resolverlo de esa manera, esa conversación de cinco minutos puede ahorrarte una semana de trabajo y 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, por lo que terminas con un equipo de front-end y un equipo de back-end, tal vez algunos administradores de sistemas, y esta es una forma realmente excelente de asegurarte de que todos siempre estén bloqueados por alguien más. 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 planeaste para ellos, ¿verdad?

Entonces, en lugar de eso, 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 por cómo lo están haciendo. Hay diferentes nombres para esto. 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 sea 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 ser dueño de su destino, ser dueño de su desorden y comprender su dominio. Ser dueño de tu destino significa que puedes enviar valor desde la idea hasta la producción. Tu equipo propone una idea y puede llevarla hasta la producción, entregando valor a los usuarios. Ser dueño de tu desorden alinea los incentivos y significa que eres responsable de mantener tu código funcionando en producción, asegurándote de que funcione y todas esas cosas. No se trata de escribir un código y lanzarlo al equipo de control de calidad y los equipos de implementación y demás. Debes hacerte cargo de eso porque así te importa más. Puedes sentirte orgulloso de lo que has construido porque estás ahí para ver el impacto que tiene en tus usuarios. 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 buena colaboración entre producto e ingeniería donde puedes trabajar en este ciclo de desarrollo de productos donde puedes enfocarte en cruzar el agua, no solo 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 juntos con el producto para desarrollar la mejor solución para el problema, no solo una solución que alguien más pensó.

No pretendí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 sobre simplemente escribir un código genial y distraerse en debates largos 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 esos ingenieros que entienden su dominio, puedes comenzar a delegar decisiones, no solo tareas.

Y esta es probablemente la palanca más grande que puedes accionar cuando estás escalando un equipo o escalando una empresa, es 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 esté pensando por todos en el equipo. Eso es muy común al principio de las startups, como el fundador o eventualmente el jefe de producto propone todas las ideas y todos los demás solo están construyendo, 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 entera o todos los productos y todo en lo que estás trabajando para avanzar. Y, desafortunadamente o afortunadamente, esto también significa que tendrás que dejar a un 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. Ten PRs cortos, 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. Vale. ¿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 dando vueltas, se vuelve cada vez más difícil fusionarlo y resolver eso, como conflictos de fusión, todas esas cosas, especialmente cuando estás en una situación en la que tienes varios equipos trabajando en el mismo producto juntos, o tienes equipos trabajando en diferentes microservicios que se comunican entre sí. Si tienes código que simplemente está dando vueltas en el purgatorio de la revisión de código, se vuelve más y más difícil de aterrizar, por lo que 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 de antemano, antes de que se escriba cualquier código, para que cuando hagamos revisiones de código, sea solo una verificación muy rápida. Podemos hacer la mayoría de nuestras revisiones de código en dos o tres minutos. Consigues que dos personas lo revisen, tal vez una prueba rápida, y dices, bien, se ve bien para mí, si está roto en producción, lo arreglaremos más tarde. Eso es escalar 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 escalar un negocio. En su mayor parte, solo estás resolviendo problemas conocidos con soluciones conocidas. Esto está en Cómo se hacen las cosas grandes. Es un libro realmente bueno. No se trata de ingeniería de software, pero trata sobre proyectos de ingeniería a gran escala y habla sobre cómo China puede construir un montón de puentes y plantas de energía por año, mientras que Estados Unidos no puede. El factor principal del que hablan es que en China tienen como 10 diseños estándar para todo, y luego los ingenieros llegan, analizan la situación y 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 diseño.

No ajustan el diseño de un componente listo para usar para adaptarlo a la situación. Es al revés. Lo adaptan a la solución que ya tienes, y de esta manera puedes construir mucho más rápido, y estás ahorrando tus fichas de innovación para las cosas que son realmente nuevas y diferenciadoras en tu 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 solo tienes 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 mira y dice, espera, ¿eso es todo? Sí, eso es todo. Es simple, es fácil de entender y es 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 enviar este code mañana, ni siquiera sabemos qué construiremos en diez días, y estás tratando de construir un framework. Simplemente soluciona el problema, resuélvelo y continúa.

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 parte de la complejidad en un proyecto de ingeniería de software no es 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, más entrelazado se vuelve todo, más complejo es.

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. Entonces, en lugar de dividir componentes, hooks, tipos, utilidades o lo que tengas en tu stack, no sé qué stack usas, pero si en su lugar divides tu code por todo lo que va en un panel de control, todo lo que va en un perfil de usuario, en una lista de tareas, entonces tendrás modules o cajas que no están tan entrelazados. Y son esas APIs claras las que hacen todo más fácil.

Un truco que me gusta usar es utilizar el desarrollo impulsado por tipos o contratos, donde de antemano hablamos sobre cuáles son 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 modules 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 la duplicación de code, no repetirte a ti mismo, en realidad es malo. Y siempre que sea posible, debes apoyarte en la separación de responsabilidades más que en reducir la duplicación de tu code.

Porque cuando se seca demasiado el código, la arquitectura termina viéndose así si se seca demasiado. Todo se superpone. Obtienes componentes o servicios que requieren 10 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 código está interconectado de una manera que te causa problemas.

Entonces, una de las cosas en las que me gusta enfocarme, especialmente al hablar de la arquitectura, es enfocarme en tus datos, y en 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 código 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 malabares para que todo encaje.

Y es por eso que quieres utilizar equipos verticales que escriban código vertical, porque significa que tú y tu equipo tienen 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.

Entonces, 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. Gracias. Gracias.

Vamos a hacer esto. ¿Cómo evitas que el code imperfecto que fusionaste hoy ralentice el progreso dentro de un par de años? ¿Cuál? ¿El primero? El segundo. ¿Cómo evitas el code imperfecto? ¿Este? Sí. De acuerdo. Sí. ¿Cómo evitas el code imperfecto hoy? Uno de los desafíos es que la solución rápida que haces hoy se envía a producción y se convierte en el código heredado que mantendrás en un par de años. No creo que eso sea realmente un gran problema.

La gente habla mucho de esto y se preocupa por ello, pero la programación a lo largo del tiempo es el trabajo de la ingeniería de software. Si intentas construirlo perfecto hoy, terminarás gastando mucho más tiempo. Un ejemplo común es que pensamos que vamos a necesitar una API genérica para acceder a algunos data. Pero solo tenemos un cliente. Así que vamos a construir nuestra API de una manera súper genérica en caso de que tengamos más clientes en el futuro. Genial. Haces eso, pasas mucho tiempo extra debatiendo tu design, debatiendo cómo hacer que sea genérico y todo eso. Y lo lanzas, 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 te equivocaste en tu abstracción y de que 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. Así que diría que es una respuesta un poco evasiva, pero depende. En su mayor parte, si te enfocas en obtener tus data correctamente y obtener tu architecture correctamente, es muy fácil desechar más tarde el code que es malo y reemplazarlo con un mejor code. Pero es muy difícil cambiar la architecture si te equivocas. Así que me enfocaría principalmente en el modelado de dominio y en asegurarme de que esa parte esté correcta 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 de 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. Puedes tener un equipo de producto que, en conjunto, sea experto en su dominio y en su conjunto de problemas, o en su tipo de usuario, o lo que sea. Pero 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. Así que juntos tienen experiencia en el dominio y por separado tienen experiencia en la pila tecnológica para sus partes específicas de la pila. Y luego, si tienes la organización vertical de tu code, en realidad no necesitas saber qué están haciendo las otras partes de tu aplicación, porque tienes APIs limpias y bien definidas para que no necesites conocer los detalles. Sí, así que creo que esa es mi respuesta. Experiencia en el dominio sobre experiencia específica en el code y APIs limpias para que no necesites conocer esos detalles tanto.

La siguiente pregunta, gracias. ¿Cómo evitas que el código imperfecto que fusionaste hoy ralentice el progreso un par de años más adelante? Creo que ya respondimos esa primera. No, creo que cerré la primera. Está desincronizado. No funciona. ¿Te gusta algo más? Hagamos esta. ¿Cómo equilibrar el código seco y el código duplicado? Creo que en términos de equilibrar el código seco y el código duplicado, me gusta tener ingenieros senior o alguien a quien le importe hacer jardinería en tu base de código, así que me gusta permitir que se desarrollen patterns, 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 patterns que están surgiendo y luego convertirlos en frameworks. Así que cuando tienes cuatro o cinco soluciones diferentes para una misma cosa, se va a volver muy obvio qué abstracciones necesitan ser y qué partes del code realmente se pueden secar y cuáles no. Es muy difícil predecir eso de antemano y, sinceramente, el peor, más difícil de mantener, el código más basura que he escrito en mi vida siempre fue intentar secar algo que parecía similar pero que en realidad estaba divergiendo en diferentes direcciones de desarrollo, y luego es muy difícil desenredarlo después. Pero si lo dejas ir a su manera primero y luego lo respaldas más tarde, eso lo hace más fácil.

Sí, siguiente, elegí equipos de características del producto sin incluir la gestión de productos. ¿Buena o mala idea? Siento que es muy importante que el producto sea parte de los equipos de ingeniería de productos. Entonces, 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 frontend framework y sus interesados son otros ingenieros. Luego tienes, como, y de hecho, creo que tienen gestores de productos en el equipo que se centran en la parte de la plataforma. 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 gestor de productos en cada equipo. No necesariamente tienen que tener el título de gestor de productos. Puede ser simplemente 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 resuelvan 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 cambios en todos los segmentos cuando uno de ellos cambia? Este es un muy buen ejemplo de secar tu code demasiado pronto. Si has separado algo en una biblioteca y te encuentras constantemente teniendo que trabajar tanto en la biblioteca como en el producto al mismo tiempo, eso significa que tu biblioteca en realidad no es una biblioteca, es una preocupación del producto y debería fusionarse de nuevo en el producto. Un signo 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. Eso es un signo de una buena abstracción. Y en realidad, dividirlas en un repositorio diferente es un truco muy bueno para evitar que las preocupaciones del producto se filtren 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 Zbizek.