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

Hola, soy Swiss, y vamos a hablar sobre escalar rápidamente y algunas de las lecciones de ingeniería que aprendí en los últimos 15 años haciendo startups de tecnología.

Has construido algo que la gente quiere, y está creciendo súper rápido. ¿Ahora qué vas a hacer? Hay tres cosas que vas a necesitar para escalar. Vas a tener que escalar el negocio, el equipo y la tecnología.

Escalar el negocio es bastante simple, pero sigue siendo un trabajo duro. Realmente solo hay dos maneras de escalar. Puedes hacer más ventas o puedes hacer ventas más grandes. Y por eso todo es una suscripción o se dirige a empresas en estos días. La razón por la que te importa esto como ingeniero es porque sin el negocio, no hay ingeniería. La ingeniería se trata de construir la cosa correcta en el momento correcto para la situación correcta. Y no importa lo que intentes, no puedes salvar un mal negocio con mejor tecnología. Y también el negocio es el combustible para todo lo que haces. Los números que quieres saber son el costo de adquirir clientes y su valor de vida. Y tu objetivo es construir tecnología que se ajuste a estos números. Pero honestamente, eso es principalmente lo que van a estar haciendo los de negocios. Lo que realmente estás haciendo es esto. Estás construyendo las vías antes de que el tren se detenga. Y estás tratando de ir, básicamente estás tratando de ir lo más rápido posible para asegurarte de que la ingeniería nunca sea el cuello de botella que detenga el negocio. Y no importa lo que escuches en Twitter o en internet, la ingeniería es solo una herramienta que el negocio usa para lograr sus objetivos. No es lo principal que, en su mayor parte, no es lo principal que el negocio está haciendo. Lo que estás tratando de hacer es construir esa flor. Pero lo que estás vendiendo a los usuarios son nuevos usuarios que pueden hacer cosas increíbles. Sé que amo mi tecnología, pero a los usuarios no les importa un carajo lo que estás haciendo. Solo quieren usar tu cosa y seguir con su vida. Así que eso es sobre escalar el negocio.

Escalar el equipo también es algo importante, aunque no hablamos mucho de eso como tecnólogos, porque muchos problemas tecnológicos son secretamente problemas de personas. Tu arquitectura y el proceso que usas para construir productos va a reflejar la estructura de tu equipo. Así que, por ejemplo, si pones QA en un equipo separado, vas a pasar mucho tiempo esperando que QA te dé su feedback. Y vas a tener ingenieros que están lanzando cosas por encima del muro en lugar de asegurarse de que su código funcione. Y luego tienes mucho ida y vuelta al final después de que el código está escrito, lo que te ralentiza y es realmente molesto para todos los involucrados.

Y lo peor que he visto que las startups hacen es que organizan equipos basados en la tecnología en lugar de basados en el objetivo o el propósito de lo que estás construyendo. Así que si organizas tus equipos de esa manera, vas a terminar pasando mucho tiempo bloqueado. Principalmente vas a estar esperando. Construyes la cosa, construyes tu parte de la cosa, y luego va a otro equipo y luego a otro equipo y terminas con un proceso muy lineal y lento.

Mientras que si puedes orientar tus equipos basados en su propósito, basados en su objetivo, como un equipo de administración que posee usuarios de administración, un equipo de compradores que posee compradores, un equipo de crecimiento que se enfoca en hacer crecer el producto, vas a pasar mucho menos tiempo bloqueado por otros equipos y siendo capaz de construir proyectos o nuevas características, de principio a fin como parte de un solo grupo. El objetivo de hacer eso es que quieres entregar valor sin ser bloqueado. Y hay muchos nombres diferentes para este tipo de estructura de equipo. Algunas personas los llaman equipos empoderados equipos extremadamente alineados, equipos centrados en la capacidad de negocio. Es todo un libro de capacidad de consultoría, y solo depende de qué libro leas.

El objetivo principal, el punto principal que todos intentan transmitir cuando hablan de esto es que quieres un equipo que pueda lanzar características de principio a fin sin ser bloqueado. Y parte de eso, mi parte favorita de eso es que puedes hacerte cargo de tu propio desorden. Así que usé QA como ejemplo. Um, si tienes ingenieros que se hacen cargo de su propio desorden y que son responsables de las cosas que lanzan, vas a tener muchos menos errores. Se siente más lento, pero en realidad vas a tener muchos menos, muchos menos problemas. Así que, por ejemplo, hace un par de días, me llamaron como a las 3am, me sacaron de la cama, fui a ver las alertas, y era algo increíblemente estúpido y tonto. Ahora adivina qué me aseguré realmente de que se arreglara al día siguiente. Um, sabes, me llamaron, arreglé el error en un día y el error, y eso no va a volver a suceder, lo cual es mucho más rápido de lo que muchos, muchos equipos logran hacerlo. También un poco más estresante. Uh, la otra parte de tener equipos verticales que pueden hacerse cargo de su dominio es que puedes enfocarte en una mejor asociación de ingeniería de producto donde los ingenieros trabajan en llevarnos al otro lado del agua, no solo construyendo el puente.

Así que terminas con este ciclo de retroalimentación circular en lugar de un proceso lineal donde puedes trabajar junto con el producto para construir las, para construir esas flores que, um, que los clientes quieren para moverse más rápido. Te permite, te permite construir más rápido, um, usando ciclos de retroalimentación, y puedes iterar en soluciones. Yo, personalmente, lo encuentro muy gratificante como ingeniero cuando puedo hablar con los clientes, entender sus necesidades, diseñar, diseñar mi código y mis productos como una forma de resolver esas necesidades de usuario y luego, um, devolvérselo a ellos e iterar en esas soluciones. La idea es que puedes construir cosas que puedes construir la solución apropiada para tu caso de uso, no solo algo de lo que escuchaste en la charla. Y de eso se trata realmente la ingeniería. Lo que eso significa es que sí, a veces vas a tener que fusionar código realmente malo que apesta, uh, porque al final del día, tu código no necesita ser perfecto. Solo necesita funcionar. Así que vas a tener que dejar ir tu ego y dejar que otras personas experimenten con diferentes enfoques. Está bien si alguien escribe código de una manera que, uh, de una manera diferente a como tú lo harías porque está bien, siempre y cuando funcione. Y siempre y cuando esos ingenieros se hagan cargo de su propio desorden, uh, si se rompe, lo van a arreglar. Si funciona, es genial.

Y no pasaste un montón de tiempo discutiendo sobre pequeños detalles que al final no importaron de todos modos. Uh, la razón por la que eso importa es que el trabajo en progreso mata tu progreso. Quieres evitar tener un montón de PRs obsoletos y ramas de larga duración y cosas así por ahí porque tienden a acumular polvo. Um, y cuanto más tiempo tengas código que no se ha fusionado o que simplemente ha estado ahí, más difícil se vuelve fusionarlo, más ideas tienes. Oh, pero aún podemos mejorar esto o, oh, podemos ajustar eso. Siempre puedes ajustar, ajustar cosas y mejorar tu código más tarde. Ahora mismo deberías simplemente terminar el, terminar el trabajo, sacar la característica, ver si a los usuarios les gusta y concentrarte en arreglarlo mejor, uh, en arreglarlo más tarde. Y el mejor truco que he encontrado para, uh, tener ciclos de PR más lentos y hacer que sea más fácil fusionar rápidamente es hablar sobre lo que estás haciendo antes de comenzar a escribir el código. Sé que somos ingenieros, odiamos las reuniones, pero te prometo que una conversación de cinco minutos sobre cómo vas a abordar un problema, cómo vas a, uh, escribir el código, cuáles son los compromisos, um, asegurarte de que todos entiendan todo lo que está involucrado es mucho más rápido y mucho más fácil que tener una discusión de PR de tres días donde escribes el comentario, luego trabajas en tu propio código, y luego vuelves tres horas después cuando responden y, ya sabes, solo ten esa conversación de cinco minutos y mantén la revisión de código y las solicitudes de extracción como solo una verificación rápida al final.

Bien, así que hablamos sobre escalar el negocio y escalar tu equipo y, uh, hacer que el equipo trabaje más suavemente, si esa es una palabra. Um, entonces, ¿qué hay de escalar la tecnología? Bueno, a pesar de lo que la gente dice en línea, la tecnología es realmente la parte fácil. Um, principalmente estás resolviendo problemas que tienen soluciones conocidas. Así que deberías simplemente elegir un diseño disponible, aplicarlo a tu dominio y seguir adelante. Lo que quieres evitar es gastar todas tus fichas de innovación en cosas que realmente no importan. Así que hay un gran libro llamado how big things get done, donde hablan sobre proyectos del mundo real. Y uno de mis ejemplos favoritos es por qué China construye muchas más plantas de energía nuevas, carreteras, puentes y todas esas cosas que nosotros en Occidente, tanto en los EE.UU. como, um, y en Europa. Lo que los autores identificaron es que China se mueve rápido porque tienen como 10 diseños estandarizados. Eligen el que está más cerca de la situación, de la situación con la que están lidiando. Y luego cambian la situación para que se ajuste al diseño en lugar de la forma en que lo hacemos en Occidente, donde tratamos cada proyecto como un pequeño copo de nieve único. Pasamos un montón de años innovando en un diseño completamente nuevo, luego lidiando con todas las repercusiones de tener desconocidos desconocidos y siendo sorprendidos por cosas que no predijimos. Y luego, cuando está construido, tiramos todas esas lecciones y comenzamos de nuevo desde cero la próxima vez. No estoy diciendo que no debas innovar. Lo que estoy diciendo es que deberías guardar tu innovación para las partes centrales de tu producto, donde realmente estás haciendo una diferencia. No necesitas inventar una nueva biblioteca de sistema de diseño o inventar un nuevo marco de gestión de estado o resolver todas estas cosas. Simplemente elige uno. Estamos en JavaScript. Te prometo que hay 10 o 20 bibliotecas para cada pequeña cosa que estás tratando de hacer. Simplemente elige la que funcione y sigue adelante y concéntrate en, ya sabes, concéntrate en resolver el problema, no en un problema diferente y más difícil.

Escribir una versión de framework genérico de ese mismo código que intenta ser súper flexible, predecir todo lo que va a suceder en el futuro y escalar de tus cinco usuarios actuales a los 50 millones de usuarios que esperas tener en los próximos años. Eso es realmente difícil. Y te prometo que solo estás perdiendo el tiempo. Lo más probable es que estés tratando de escalar antes de lo necesario. Y te prometo, puedo prometerte que la forma en que piensas que tu código se va a romper cuando alcances más escala no es cómo realmente se va a romper. La escala te sorprenderá. Las cosas se rompen de maneras extrañas. Y además, no necesitas hacer todo de la misma manera que Facebook, Google, Shopify o quien sea lo hace. E incluso Shopify.

Shopify es en realidad un gran ejemplo. Ellos todavía hasta el día de hoy en su escala actual, son una tienda de Ruby on Rails y usan MySQL para operar. Creo que les gusta compartir números alrededor del Día de Acción de Gracias. Hace unos años, estaban haciendo varios millones de consultas por segundo y API, varios millones de solicitudes de API y usuarios por segundo, todo en Ruby on Rails y MySQL. Así que la tecnología escalará. Y cuando llegues allí, podrás resolverlo entonces. No intentes escalar demasiado rápido porque tu trabajo principal es rechazar la complejidad. Como dije antes, estás tratando de llevarnos sobre el agua ahora mismo. No estás tratando de simplemente construir un puente porque alguien dijo, alguien pidió un puente.

Parte de eso es que cuando trabajas con tu gerente de producto y tienes esa asociación de ingeniería de producto porque posees un dominio vertical del negocio, puedes rechazar sus ideas. Si hay un requisito que arruina completamente un proyecto y lo hace tomar 10 veces más tiempo de lo que tomaría de otra manera, está bien mirar a tu gerente de producto a los ojos y decirle, oye, ¿realmente necesitamos esta parte de la característica? ¿Podemos simplemente no hacer esto y luego aún resolver el problema lo suficientemente bien? Y lo que podría sorprenderte es que muchas veces cuando encuentran, cuando les dices el costo real de sus ideas o el costo de lo que tomará construir algo, simplemente dirán, sí, tienes razón. No vale la pena. No hagamos eso. Porque realmente entiendes el código mucho mejor que tus gerentes, tus gerentes de producto. Incluso entiendes los detalles de tu código mucho mejor que tus, creo que ya no los llamamos arquitectos, que tus ingenieros principales. No conocen los detalles. Si algo es mucho más difícil de lo que parece desde afuera, tienes que decírselo a la gente y es muy probable que cambien los requisitos. Como mencionaba antes de cómo se hacen las cosas grandes, puedes modificar la situación para que se ajuste al diseño que ya existe. Eso es casi siempre más rápido que doblarse hacia atrás para mover un montón de código, reescribirlo y ajustarse a este único requisito que tal vez ni siquiera necesites. Y mucho de lo que hace que algunas cosas sean difíciles y otras no es la forma en que has estructurado tu arquitectura. El código, como el código de bajo nivel real, cambia mucho más a menudo que tu arquitectura general.

Puedes pensar en la arquitectura como un gráfico de dependencias en tu código donde cada caja es como un módulo, función, clase, componente, como quieras llamarlos. Y las líneas son cómo esos componentes interactúan. Cuantas más líneas tengas en este gráfico, más difícil será trabajar con tu código, más tendrás que cruzar diferentes límites, tendrás que hacer que las cosas funcionen juntas, más difícil será, y más encontrarás esos pequeños, oh, ¿y si solo movemos este botón de aquí para allá? Y de repente todo explota y se desmorona.

A un nivel alto, tu arquitectura va a seguir tu estructura de equipo. A un nivel más bajo, depende un poco de lo que hagas. Idealmente, puedes usar modelos verticales donde la idea de los modelos verticales es que puedes reducir tu complejidad arquitectónica, así que tener menos de esas líneas, si organizas tu código basado en lo que hace, no basado en lo que es. Así que todo lo que necesitas para construir, el panel de control va junto, todo para un equipo va junto, todo para una lista de tareas va al menos en la misma carpeta. Y luego, si se vuelve súper complejo, puedes fractalmente dividirlo más. Lo que quieres evitar es tener una carpeta para componentes, una carpeta para hooks, una carpeta para tipos, una carpeta para utils, porque entonces todo termina dependiendo de todo lo demás, sabrás que estás en esta situación si cada archivo comienza con como 50 declaraciones de importación porque cada archivo necesita importar casi todos los demás archivos en tu código.

Así que en el cliente, vas a terminar llamando a estos módulos verticales componentes o páginas, a veces grupos de páginas. En el back end, estás buscando algo como una arquitectura orientada a servicios. Puedes hacer esto con un monolito. Los monolitos son geniales. De hecho, soy un gran fan de los monolitos, pero los monolitos pueden ser difíciles de mantener limpios y de realmente hacer cumplir esas separaciones. Así que si tu equipo realmente no puede mantenerlo limpio, y si estás creciendo mucho, está bien usar microservicios o micro frontends, pero esos en realidad traen mucha complejidad propia que al menos en una startup, puedes evitar por mucho más tiempo del que necesitas.

A todos les gusta usar Amazon y AWS como un ejemplo de, oye, deberíamos solo comunicarnos entre nosotros a través de APIs y todo debería ser un microservicio. Solo hicieron eso cuando tenían, creo, más de 500 o 600 ingenieros trabajando en el mismo producto. He estado en startups donde comenzamos a dividir todo en microservicios cuando éramos como 10 ingenieros. Eso es demasiado pronto. No necesitas microservicios o micro frontends si solo hay 10 de ustedes y se están pisando los talones un poco. Usa carpetas. Están bien.

Con modelos verticales, lo que realmente ayuda es que te da una API clara. Porque no todo está cruzado e importando otras cosas, puedes definir una API clara o una interfaz clara. Lo que me gusta usar para esto es el desarrollo basado en contratos o tipos así que el desarrollo basado en contratos o tipos básicamente significa que defines la interfaz primero y luego construyes los internos de esa interfaz. Esto automáticamente te obliga a diseñar modelos verticales y también te obliga a tener esas discusiones arquitectónicas desde el principio cuando las cosas aún son flexibles y fáciles de cambiar, no más tarde en tus PRs cuando estás discutiendo sobre el código.

Lo principal que estás tratando de evitar es ser golpeado por la Ley de Hiram que establece que si alguien puede depender de algo en tu código, lo hará. Y así es como obtienes esos super cruzados, esa es una gran parte de cómo obtienes esos APIs cruzados que son poco claros y terminas rompiendo código que ni siquiera te diste cuenta que estaba conectado. Mi opinión controvertida aquí es que si haces esto bien, necesitarás escribir muchas menos pruebas de las que haces si todo está interconectado porque los límites del módulo ya están garantizando que no estás rompiendo código que no parece estar relacionado con lo que estás haciendo.

Una de las principales fuentes de este código arquitectónicamente complejo altamente interconectado que he visto es intentar no repetirte. Es probablemente alguno de los peores códigos que he escrito de esa manera. De hecho, hubo un muy buen ejemplo de esto en mi nueva startup hace un par de semanas donde teníamos una función que parecía, oh, estamos repitiendo esta misma función en tres o como esta misma cosa en tres cosas diferentes en tres lugares diferentes. ¿Qué pasa si consolidamos esto y lo hacemos más fácil de usar? Así que lo consolidamos y estaba bien y luego unos días después alguien más vino y dijo, oh, esta función parece realmente útil y la movió a un lugar diferente, cambió cómo se comportaba la función y terminó rompiendo cosas completamente no relacionadas con lo que estaban haciendo porque estaban conectadas. Así que lo que sucedió allí fue que estábamos desduplicando código que parecía similar pero en realidad tenía diferentes objetivos. Así que hicimos que nuestro diagrama de arquitectura se viera así y la forma más fácil de reconocer cuando tienes dry en lugar de separación de preocupaciones, la forma más fácil de identificar eso es si alguna vez has usado un componente que para una función que toma como cinco o seis propiedades booleanas solo para especificar cómo se comporta o qué está haciendo en esta situación, eso fue probablemente una señal de que estás usando un componente que ha sido desduplicado incorrectamente y debería dividirse en múltiples componentes. Está bien tener código repetido. El código es barato. Lo que no quieres repetir es la intención y la fuente de verdad de tu lógica. Así que una forma en que me gusta identificar esto es si el código parece similar ahora pero sirve a diferentes usuarios, casi con certeza va a evolucionar de diferentes maneras. O si el código parece similar ahora pero los usuarios están tratando de lograr una tarea o un objetivo diferente al usar este código, también se va a dividir y necesitará evolucionar de diferentes maneras. Así que no deberías fusionar ese código.

Hay mucho que decir al respecto, pero esta es una charla de 20 minutos. Así que lo último que quiero decir sobre cómo puedes evitar la complejidad arquitectónica o simplemente la complejidad en tu código es realmente enfocándote en tus estructuras de datos. Si tus datos están en la forma incorrecta para lo que estás tratando de hacer, vas a tener que doblarte hacia atrás para que funcione.

En el peor de los casos, terminarás construyendo capas de traducción. Así que una vez estaba hablando con un amigo que estaba resolviendo el problema del vendedor viajero, que es súper difícil, irresoluble, como un caso tradicional de código NP-completo que es irresoluble a menos que añadas algunas restricciones. Tenían ingenieros de back-end brillantes que hicieron que todo este código funcionara, construyeron algoritmos increíbles que eran súper rápidos, pero luego la experiencia de usuario, a pesar de todo este increíble trabajo de ingeniería en el back-end, la experiencia de usuario era súper lenta porque la API del back-end devolvía datos en una forma completamente incorrecta. Así que mi amigo en el lado del cliente construyendo una aplicación de React para mostrar estos datos tuvo que hacer tantos cálculos que esencialmente reimplementaron toda la lógica difícil de resolver este loco problema en el front-end, donde terminaron teniendo que mover un montón de sus cálculos a Wasm solo para hacerlo lo suficientemente rápido para que la interfaz de usuario no se bloquee cuando haces clic en un botón. Porque llegaron a un punto donde si hacías clic en algo, tardaba de cinco a diez segundos en volver a renderizar el lado del cliente.

Así que el re-renderizado de React tardaba de cinco a diez segundos solo porque básicamente tenía que rehacer todo el trabajo que ya había sucedido en el back-end para obtener los datos en la forma correcta para lo que necesitaban. Y eso, amigos míos, es por lo que quieres tener equipos verticales que estén alineados a lo largo de tu código vertical porque puedes enfocarte en resolver problemas de usuario rápidamente, tienes control total de las características y las cosas que estás construyendo de principio a fin, puedes diseñar cómo se almacena en la base de datos, cómo se comunica con tu... cómo se almacena en la base de datos, cómo se procesa en el back-end, cómo son las APIs e interfaces, puedes hacer que se ajusten realmente bien al lado del cliente que estás construyendo, asegurarte de obtener todos los datos que necesitas. Eso hace que tu aplicación funcione más rápido, hace que todo esté alineado, y también significa que entiendes todo el dominio de principio a fin de lo que estás tratando de construir, lo que te permite avanzar más rápido y con menos errores.

Así que gracias, he estado escribiendo este libro durante mucho tiempo, pero prometo que se terminará eventualmente. He expandido todo lo que he dicho hoy en básicamente un libro. Puedes encontrar más información en scalingfastbook.com y enviarme un correo electrónico si tienes preguntas, realmente no uso DMs de Twitter.