Operando eficientemente a escala

Por Brian Armstrong, director ejecutivo y cofundador

A medida que las empresas escalan, generalmente se ralentizan y se vuelven menos eficientes. Se necesitan más dólares, más personas y más tiempo para hacer cualquier cosa. Los vientos en contra de la coordinación aumentan, surgen vetocracias, la tolerancia al riesgo se desvanece y los equipos se enfocan internamente en lugar de permanecer enfocados en sus clientes.

Si bien esta trayectoria es natural, no es inevitable. Todas las grandes empresas, desde Amazon hasta Meta y Tesla, encontraron formas de retener su energía fundacional junto con los controles apropiados, incluso cuando escalaron para ser mucho más grandes de lo que es Coinbase en la actualidad. Las grandes empresas mantienen su mentalidad insurgente, por miedo a volverse complacientes e irrelevantes con el tiempo.

Es por eso que nos estamos enfocando en impulsar una mayor eficiencia en Coinbase. Después de 18 meses de crecimiento de empleados de ~200 % anual, muchas de nuestras herramientas internas y principios de organización han comenzado a tensarse o romperse. Por eso, hemos estado investigando para identificar el conjunto de cambios que necesitamos hacer para ayudarnos a tener éxito en esta nueva escala.

El primer paso fue frenar significativamente nuestro crecimiento y tomar la difícil decisión de reducir el tamaño de nuestro equipo actual, que anunciado el mes pasado. En el futuro, seguiremos buscando formas de hacer que Coinbase sea más eficiente y volver a la mentalidad y el enfoque que nos hizo exitosos. Creo que estos pasos nos llevarán adelante.

Utilizamos DRI (individuos directamente responsables) para ayudarnos a ejecutar más rápido. Los DRI equilibran los aportes del equipo y toman decisiones claras de manera oportuna.

Pero ahora que somos una empresa más grande con muchos productos en lugar de uno, debemos ajustar la forma en que tomamos decisiones, empujando la mayoría de las decisiones hacia abajo en la organización, eliminando cuellos de botella y empoderando a nuestros líderes de productos.

Los DRI a menudo tienen la tentación de empujar la toma de decisiones hacia arriba en la cadena cuando no están seguros o no quieren correr riesgos. A veces tienen miedo de ser despedidos si la decisión no sale bien. Es por eso que, siempre que sea posible, nos enfocamos cada vez más en identificar DRI de "subproceso único". Un solo subproceso es una jerga tecnológica que simplemente significa centrado únicamente en una sola área. El DRI de un solo subproceso es la persona de mayor rango cuya , solamente trabajo es ejecutar un producto o iniciativa determinada, por lo general será un líder de ingeniería o gestión de productos. No pueden ser DRI de subproceso único si son DRI de múltiples áreas.

Esto puede significar que no todas las decisiones son perfectas. Pero eso está bien si podemos escalar nuestro impacto y empoderar a los expertos en la materia que están más cerca de los productos y de nuestros clientes.

Cada uno de nuestros productos tiene competidores bien financiados que son empresas dedicadas. Creemos que la forma correcta de competir es incentivar a nuestros líderes de productos para que también ejecuten sus productos como una empresa independiente. Las empresas deben lograr un crecimiento rentable en un horizonte de tiempo razonable. Con el tiempo, podremos brindarles a los líderes de productos una visibilidad directa de sus P&L, para que puedan mover su producto hacia márgenes positivos y tomar mejores decisiones sobre dónde invertir, mientras que a nivel ejecutivo continuaremos observando el desempeño consolidado.

Si bien los líderes de productos pueden operar de forma independiente, a menudo hay elementos comunes en todos los productos. Hemos compartido servicios sobre cómo los clientes se incorporan, administran sus cuentas, almacenan criptomonedas, agregan métodos de pago, intercambian criptomonedas y más. Si se hacen mal, los servicios compartidos pueden ralentizar y frustrar a los equipos de productos. Pero cuando funcionan bien, pueden crear sinergias sorprendentes entre los productos y una integración más profunda de los productos.

No se debe exigir a los equipos de productos que utilicen un servicio compartido a medias. Pero una vez que un servicio compartido está maduro, es posible que se requiera que todos los productos lo usen. Descubrimos que a menudo ayuda comenzar un servicio compartido con un producto principal en mente. Cuando queda claro que estamos duplicando esfuerzos o creando una experiencia de usuario inconsistente en todos nuestros productos, los servicios deben convertirse en servicios claramente separados que cualquier producto pueda aprovechar.

Los equipos pequeños son más eficientes. Por eso es importante establecer un tamaño máximo en los equipos, para que no crezcan demasiado y se ralenticen.

Estamos comenzando a implementar un nuevo concepto que llamamos "grupos" para crear más estructura en torno al tamaño adecuado de un equipo. Dentro de cada producto, definiremos grupos de <10 personas que trabajan en una característica o área específica. Si un grupo crece hasta tener más de 10 personas, será el momento de dividirlo en dos y asignar a cada uno un objetivo o enfoque más específico. Los pods también deben tener un enfoque y una métrica de estrella polar que se vincule con las métricas generales de la empresa.

Dentro de las empresas en crecimiento, existe el peligro de que los equipos de producto e ingeniería comiencen a enviar excelentes diapositivas en lugar de excelentes productos. Puede ser tentador “manejarse bien” y sentir que una reunión salió bien con un hermoso mazo mostrado a los superiores. Pero nuestros clientes nunca ven las presentaciones de diapositivas que creamos. Solo ven el producto.

Por lo tanto, estamos experimentando con la prohibición de presentaciones de diapositivas en las revisiones de productos e ingeniería. En lugar de una plataforma de diapositivas, puede mostrar:

• Un tablero con sus métricas; de todos modos, con suerte su equipo lo verá al menos una vez por semana.
• maquetas de figma
• Pero lo más importante... ¡muestra el producto en sí y utilízalo en vivo!

Está bien incluir una agenda de una página para capturar elementos de acción, o vincular a cualquier lectura previa como documentos de diseño técnico. Pero el mejor uso del tiempo en las revisiones de productos e ingeniería es compartir su pantalla y recorrer el producto real en el móvil o en la web. Podría ser la versión de producción o una versión de ensayo. Lo importante es ponerse manos a la obra con el producto, ver lo que el cliente está viendo (o está a punto de ver) y mejorarlo.

Mientras hacemos esto, debemos evitar pasar demasiado tiempo hablando de lo que va bien en las reuniones. Podemos compartir lo que va bien en la lectura previa y tomarnos un momento para celebrarlo, pero la mayor parte del tiempo en las reuniones debe centrarse en lo que no va bien, para que podamos mejorar el producto.

Es difícil exagerar este punto. Dentro de las empresas, hay muchas cosas que se sienten como trabajo, pero que en última instancia no mejoran la experiencia del cliente, desde los ciclos del mercado y la prensa negativa, hasta los esfuerzos de políticas, la política/el drama interno, los títulos y la compensación. Contamos con equipos que se enfocan en estas áreas, para que la gran mayoría de la empresa (más del 80 %) pueda permanecer enfocada en hablar con los clientes y crear mejores productos.

Las empresas más grandes también se ven ralentizadas por reuniones interminables sobre priorización y solicitudes de funciones. Necesitamos pasar a un modelo en el que todos los equipos de productos e ingeniería (no solo los servicios compartidos) publiquen API para que otros equipos puedan beneficiarse de lo que están creando. sin necesidad de programar una reunión. En otras palabras, necesitan convertir sus servicios en productos y permitir que otros equipos los utilicen de manera autoservicio.

Esto requiere que adoptemos un catálogo interno de API en el que cualquier ingeniero de Coinbase pueda buscar para encontrar un servicio adecuado. Sin esto, es difícil para cualquier ingeniero saber si existe una API, lo que genera trabajo duplicado. Todos los servicios deben diseñarse utilizando "carreteras pavimentadas", lo que significa bibliotecas e idiomas coherentes para la autenticación, el registro, la instrumentación, etc. Muchas de estas API aparecerán en Coinbase Cloud también para clientes externos, haciéndolas aún más sólidas.

En última instancia, mucho de esto se reduce a mantener la mentalidad de fundador dentro de la empresa y actuar como propietarios. La mayoría de las empresas comienzan siendo antisistema, buscando corregir algunos errores en el mundo. Pero a medida que crecen y tienen más éxito, comienzan a convertirse en el nuevo establecimiento. se vuelven complacientes, sintiendo que han ganadoy se instala la burocracia.

En Coinbase, uno de nuestros valores es la innovación repetible, lo que significa que siempre queremos ir más allá. Utilizamos un modelo de asignación de recursos 70/20/10 en el que invertimos el 70 % de nuestros recursos en nuestro negocio principal y el 20 % en esfuerzos estratégicos. También nos aseguramos de que el 10 % de nuestros recursos siempre se destine a nuevas y ambiciosas apuestas. Y siempre tratamos de hacer productos que sean los más confiables y fáciles de usar, para que podamos atraer a mil millones de personas a la criptografía. Esta es la mejor manera de cumplir nuestra misión de aumentar la libertad económica en el mundo.

El éxito de Coinbase siempre se ha basado en la capacidad de operar de manera eficiente con una mentalidad de inicio. Ahora, a medida que nos adaptamos a nuestra nueva escala, debemos volver a las cosas que nos hicieron exitosos: impulsar una mayor eficiencia y deshacernos de la autocomplacencia que puede colarse en una empresa más grande. Necesitamos capacitar a nuestros líderes para que tomen decisiones y a nuestros equipos para que entreguen excelentes productos a los clientes. No será fácil, y tendremos que seguir ajustándonos. Pero llegamos hasta aquí y confío en que si tomamos decisiones inteligentes ahora, solo será el comienzo.

Las empresas abordan este problema de disminución de la eficiencia de diferentes maneras, para adaptarse mejor a su situación. Nos hemos alineado en la implementación de estos cambios y herramientas después de realizar una investigación significativa sobre cómo otras empresas han navegado por esto. Aquí hay algunos libros y recursos excelentes que me ayudaron a educarme sobre este tema:

• Amplíalo: Frank Slootman tiene una gran del blog sobre esto que se convirtió en un libro. El mensaje central es que cuando alguien dice que te responderé la próxima semana, di qué tal mañana. Cuando alguien diga que tomará seis meses, pregunte cómo lo haríamos en seis semanas o seis días si tuviéramos que hacerlo.
• Dar la vuelta al barco: El mensaje central de este libro es que en lugar de preguntarle a su gerente qué debe hacer, dígale lo que debe hacer. la intención de hacer, y editarán su pensamiento si es necesario. Aún necesita informar, pero es su responsabilidad decidir el mejor camino.
• Mentalidad de fundadores: El mensaje central es mantener una mentalidad insurgente, con un sesgo por la acción, una misión audaz, defensa del cliente y más. Prueba el examen para más información.
• Vientos en contra de la coordinación: Las organizaciones escaladas deben estar débilmente acopladas y estrechamente alineadas. En otras palabras, alinee una misión, valores y métricas de alto nivel, luego empodere a los líderes para que sigan su propio camino con una toma de decisiones más localizada.