Leadership Insights From Growing 2X in 8 Months

Mucha gente me pregunta, ¿cómo sabes que tienes ajuste producto-mercado? Bueno, si tienes que preguntar, no lo tienes. El ajuste producto-mercado se siente como si el mercado te arrastrara, pateando y gritando mientras los usuarios piden más y más cosas. Me uní a una empresa con PMF el año pasado y en un momento un entrevistado me preguntó cómo se siente trabajar aquí. Honestamente, se siente como si hubiera entrado en una licuadora y alguien sigue presionando el botón de mezclar. Hemos triplicado el equipo de ingeniería, duplicado la empresa, y nos estamos quedando sin espacio de oficina y aún no podemos mantenernos al día. El mercado simplemente quiere más.

Así que esta charla es mi intento de dar un paso atrás y escribir algunas de las cosas que he aprendido. Espero que encuentres algo útil para aplicar en tu equipo. Así que hay este juego, sigue hablando y nadie explota. Dos jugadores desactivan una bomba. Uno tiene las instrucciones, uno tiene la bomba. Tu objetivo es trabajar juntos. Cuando jugué este juego con mi pareja, intentamos ambos roles.

Cuando ella tenía la bomba y yo tenía las instrucciones, el juego apestaba. Seguíamos discutiendo y peleando y perdimos el juego. Ambos nos sentimos en pánico y fuera de control. Pero cuando yo tenía la bomba y ella tenía las instrucciones, ganamos. Ambos nos sentimos en control, tranquilos y las palabras fluían. Cuanto más hablas, más fácil es desactivar la bomba. Así que me siento en control cuando hago el trabajo, mi pareja se siente en control cuando entiende las instrucciones.

Hacer crecer el equipo es muy parecido a ese juego. Cuanto más hablas, más ganas. Porque no puedes hacer todo. Tienes que dejar que otros hagan el trabajo o serás tú quien explote. Y la peor parte de esto es que pasas de sostener la bomba a sostener las instrucciones, lo cual para mí es difícil. A medida que otros hacen más del trabajo, necesitan a alguien que sea el pegamento y mantenga a todos tirando en la misma dirección. Y eso es un poco aterrador. Es desorientador. La mitad del tiempo sientes que tienes media idea de lo que está pasando. La otra mitad, tienes todas estas ideas y no hay tiempo para hacerlas realidad.

Así que, como el miembro más experimentado del equipo, vas a las áreas con menos certeza. Surfeas al frente y creas claridad para los demás, averiguas qué se necesita hacer, qué tecnologías quieres usar, con quién necesitas hablar, encuentras todos los incendios e intentas ir donde hay incertidumbre. Por eso se siente como una licuadora. Estás constantemente confundido, saltando entre niveles de abstracción. Un minuto estás en los detalles, ayudando a depurar un problema de base de datos. Al minuto siguiente estás respondiendo, Oye, ¿cómo va esa iniciativa para el trimestre? Como, no lo sé, hombre. El software vuela como un garabato, pero eres responsable. Tienes que saber. Y si intentas saltar, y si intentas rebotar en el tiempo con todo este salto, solo crearás montones de trabajo sin terminar esperándote.

Así que el simple hecho es que no puedes hacer todo y no puedes estar en todas partes. La lista de prioridades y buenas ideas nunca termina. Cuanto más creas, más los usuarios piden, y más ideas tienes. La solución que encontré es dejar de pensar en cómo hacer el trabajo y centrarme en quién está haciendo el trabajo. ¿Tienes una idea? Genial. Eso es para Jane. ¿Tienes una solicitud de función? Genial. Esa es para Joe. ¿Error? Alice conoce todo el código. Cada pieza de trabajo va a otra persona. Puedes sostener las instrucciones, pero ya no puedes sostener la bomba. Hay demasiadas bombas.

Así que te conviertes en el especialista en misiones secundarias. Como ya no puedes trabajar en cosas críticas, te conviertes en el especialista en misiones secundarias. Eso todavía es seguro para ti. El tipo de proyectos donde no importa si tienes que dejarlos por unos días o semanas, a veces meses. Por ejemplo, acabo de implementar una idea en la que comencé a trabajar en febrero. Es bastante genial, pero era un poco de vanguardia y la tecnología aún no estaba lista. Tuve que dejar que se cocinara durante unos meses, pero ahora estoy realmente feliz. Así que ese es el tipo de cosas que puedes hacer como el especialista en misiones secundarias. Ideas a largo plazo con viabilidad dudosa o proyectos súper cortos que desbloquean algo para mañana para que tu equipo no se distraiga.

O puedes hacer el trabajo preliminar incierto, dejar las cosas a medio hacer, y luego dejar que otros se encarguen y terminen la función. Esto es divertido pero muy poco gratificante. Nunca llegas a un punto en algo y dices, Yo hice eso. Eso fui yo. Esa función, la hice yo, porque no lo hiciste. El equipo lo hizo, tú solo estabas hablando de ello. Pero lo que puedes hacer que es muy gratificante es que puedes mentorear mucho, lo que sea que eso signifique. Honestamente, todavía no sé cómo señalar con el dedo la mentoría. No es como si tuvieras una reunión en tu calendario que diga mentoría o un elemento en tu lista de tareas diarias. La mentoría es esta cosa que sucede entre el trabajo. Algunos días pasas tres horas trabajando con alguien y cambia cómo abordan el trabajo. Otros días, haces un comentario desechable y la gente sigue citándote para siempre y se convierte en parte de tu cultura. Si haces esto bien, la gente seguirá acudiendo a ti durante años, incluso después de que ambos trabajen en diferentes empresas. Al menos eso es lo que hago. Acabo de hablar con mi mentor la semana pasada y ni siquiera estoy seguro de que se diera cuenta de que es mi mentor. Así que asegúrate de mantenerte en contacto con todos tus mentores. Realmente significa mucho para ellos. Así que no puedo señalar la mentoría para ti, pero aquí hay algunas cosas que creo que hago que cuentan como mentoría. La primera es que siempre debes explicar tu razonamiento en los comentarios de PR, en los documentos de diseño, al tomar decisiones rápidas en Slack. Dedica los 30 segundos extra para explicar tu pensamiento. Esto te ayuda a verificar tu trabajo. Les da a otros la oportunidad de decir, oye Suez, esa suposición es incorrecta. Estás lleno de mierda. Y les ayuda a tomar buenas decisiones más tarde. Necesitas confiar en tu equipo para que maneje las cosas sin ti. De lo contrario, el enfoque de quién no cómo no funcionará. Si no explicas tu razonamiento, solo te convertirás en el cuello de botella que tiene que tomar todas las decisiones para siempre. Y lo siguiente es siempre mentorear una cosa a la vez. Si estás enseñando a alguien cómo diseñar un sistema distribuido robusto, no puedes también enseñarles cómo descomponer una gran historia de usuario en la misma conversación. Sí, necesitarán hacer ambas cosas.

Pero si mantienes tu retroalimentación enfocada, realmente podrán implementarla. Les ayudarás a mejorar todo con el tiempo. Pero si haces que todo parezca importante hoy, solo se perderán y no podrán implementar nada de lo que les estás diciendo.

La otra cosa es que los novatos necesitan ánimo mientras que los expertos quieren retroalimentación. Hay investigaciones reales sobre esto. Olvida el sándwich de mierda. El sándwich de mierda es para perdedores. Necesitas evaluar dónde están las personas en su ciclo de novato a experto y ajustar tu enfoque. Una persona puede estar en diferentes etapas para diferentes habilidades. Esta parte es importante.

Así que cuando alguien es un novato, necesitas animarlos. No hables sobre los errores. Enfócate en las cosas buenas y anímalos a hacer más de eso. Los novatos pueden mejorar su rendimiento promedio simplemente mejorando en las cosas en las que ya son buenos. Pero cuando alguien es un experto, tienes que enfocarte en sus puntos débiles. No pueden mejorar en las cosas que ya están dominando. La manera de aumentar el rendimiento promedio es mejorar lo que no pueden hacer.

Así que si estás revisando un PR para alguien que es un principiante, señala las cosas que están haciendo realmente bien. Di, oh sí, este es un gran nombramiento de variables. Es genial cómo desglosaste esta característica en diferentes funciones. Todo eso es impresionante. Van a hacer más de eso, mejorar, y todo lo que hagan será mejor. Pero si tienes un experto, alguien que ya es realmente bueno en el código, querrás enfocarte en, oye, este código está en el lugar equivocado. Deberías moverlo a otro lugar. Oye, ese comentario que hiciste ayer durante una reunión, fue malo. No digas cosas así porque desanima a los demás. Así que sí, mantén la retroalimentación oportuna y enfócate en hablar sobre mejorar lo peor del rendimiento del experto mientras te enfocas en las buenas partes del rendimiento del novato para que puedan hacer más de eso y automáticamente mejorarán.

Recuerda, lo mismo es cierto para ti. Necesitas ánimo en las cosas que son nuevas para ti, y necesitas retroalimentación en las cosas en las que ya eres bueno. Tu otro rol como líder del equipo o lo que sea es mantener a todos enfocados en los resultados. Eres el policía malo que dice, sí, eso es genial, pero ¿qué nos ayuda a hacer? Esta es la parte que realmente apesta. Quieres jugar con toda la nueva tecnología y juguetes divertidos, pero tienes que ser el adulto que dice no. Todo lo que hagas debe llevar a un resultado. No tienes tiempo para contemplaciones, para debates sobre la estructura correcta del código, o nada de eso. Necesitas obtener resultados.

Necesitas nuevos superpoderes, nuevas características, nuevas habilidades para los interesados. Siempre debe haber un resultado para todo lo que hagas. Obviamente, deja que las personas exploren su curiosidad, pero mantenlos enfocados. Cuando encuentren trabajo que necesita hacerse, di, genial, ¿qué nos da eso? Cuando encuentren código que quieran refactorizar, di, increíble, ¿cómo exactamente te está bloqueando? Porque si no los está bloqueando realmente, no necesitan arreglarlo ahora mismo. Y siempre trata de encontrar maneras de hacer que su trabajo sea útil más pronto. Hay más personas esperando de lo que te das cuenta. Por ejemplo, acabamos de tener una característica donde uno de mis ingenieros estaba trabajando en construir nuevos anuncios para nuestro producto. Siempre encuentra maneras de hacer que su trabajo sea útil más pronto. Hay más personas esperando de lo que te das cuenta. Por ejemplo, acabamos de tener una característica donde uno de mis ingenieros estaba construyendo anuncios donde una de esas pequeñas burbujas emergentes, haces clic en ella y ves, wow, ustedes tienen una nueva característica. Esto es tan genial. A nadie realmente le importa, pero necesitas decirle a la gente sobre las nuevas características.

Así que estábamos trabajando en esto. No estábamos realmente seguros de cómo iba a ir. Y luego nos dimos cuenta, ¿sabes qué? No necesitamos construir la función de si alguien ya ha visto sus anuncios todavía. Simplemente pongamos los anuncios arriba. Y luego, cuando la gente se queje, podemos hacer que la pequeña burbuja roja desaparezca. ¿Y adivina qué? Tan pronto como lo lanzamos, al día siguiente alguien dijo, oye chicos, ¿tienen una buena manera para que pongamos algunos anuncios? Acabamos de lanzar una nueva característica de la que queremos informar a la gente. Y fue genial. Así que simplemente lanzamos esto. No estábamos seguros de a dónde iba a ir. Tan pronto como lo lanzamos, alguien tuvo un caso de uso. Y tan pronto como comenzamos a usar ese caso de uso, alguien vino y dijo, oye, ¿podemos hacer que esa burbuja roja desaparezca? Es realmente molesto. Así que ahora estamos trabajando en esa parte. Así que haz las cosas útiles antes de lo que deseas.

Hay más personas esperando de lo que te das cuenta. Y cuando se trata de eso, resulta que las historias de usuario son buenas, en realidad. Son sorprendentemente útiles para ayudar. Son sorprendentemente útiles para enfocarte en el resultado. Sí, suenan tontas, pero realmente funcionan. Como tipo de usuario, quiero lograr un resultado. Esta estructura es importante. Tienes que saber quién se beneficia de todo lo que haces. De esa manera, puedes preguntarles si funcionó, y tienes que saber el resultado que quieren lograr, de lo contrario no sabrás si funcionó. Así que quieres saber qué podrán hacer cuando no podían hacerlo antes. Evita simplemente hacer trabajo y entregar código.

Enfócate en el resultado. A veces el código puede no ser la mejor manera de hacer que el resultado suceda. Podrías querer deslizar una tarjeta de crédito en su lugar. Lo más importante, cuando hablas de historias de usuario, cada ingeniero puede pensar críticamente y decidir si están cayendo en un agujero de conejo o trabajando hacia un resultado claro. Esto es súper útil para mí. Soy el tipo del agujero de conejo.

Quizás no necesito hacer esto ahora mismo. Así que tener una historia de usuario es súper útil aquí porque puedes enfocarte en a quién estás ayudando y qué les estás dando que no podían hacer antes. Y eso me recuerda, deberías escribir todo. Sentirse como si estuvieras en una licuadora proviene de tener demasiadas cosas en tu cerebro al mismo tiempo. Algo de esto es inevitable. Puedes hacer el trabajo si no piensas en ello en la ducha. Pero cuando se trata de cosas tácticas, escríbelo. Mantén notas sobre las decisiones tomadas y los insumos que se utilizaron.

Escribe tus diseños de sistema. Pon más contexto en tus historias. Mantén subpruebas para todo el trabajo en progreso. Ten documentos para hojas de ruta a medio plazo. Tienes que poder dejar las cosas y retomarlas tres meses después porque las prioridades cambian, las hojas de ruta divergen, las cosas salen mal, y podrías necesitar detener lo que estás haciendo e ir a hacer algo completamente diferente durante un mes o dos, y luego volver y retomar donde lo dejaste. No puedes hacer eso si no lo escribes. Pienso en ello como toma de decisiones sin estado. Quieres leer uno o dos documentos y tomar una decisión sin tener que recordar todo lo que sucedió en los últimos seis meses.

Porque no sé tú, pero apenas puedo recordar lo que sucedió la semana pasada. Así que esto también te permite delegar o recibir ayuda porque estás compartiendo el contexto. Es más fácil para otros intervenir y echar una mano, y es más fácil decir a otros lo que te gustaría que hicieran para que puedan ayudarte. Así que parte de esto es que necesitas establecer la visión y dar pequeños pasos. Acabo de mencionar las hojas de ruta. Quieres mantener las hojas de ruta flexibles. Tu gestor de tareas, como Asana o Jira, es demasiado rígido para la planificación a largo plazo. Cualquier cosa que sea más de unos pocos meses, deberías mantenerla como una idea en tu cabeza, un objetivo al que estás apuntando.

Va a seguir cambiando, y está bien. Habla con personas, obtén más información, sigue haciendo cambios en la vaga idea que tienes en tu cabeza. El próximo mes o dos, deberías mantenerlos en un documento. Esos documentos son fáciles de cambiar, pero son más claros que las ideas vagas. Te obligan a escribirlo, a convertirlo en algo que puedas sostener y aclara tu pensamiento si lo escribes. Así puedes hacerlo más accionable de esa manera.

Las próximas semanas, dos o tres semanas, deberían ser historias de usuario en tu gestor de tareas. Enfócalas en lograr resultados. Como tipo de usuario, quiero lograr este tipo de resultado. Hazlas pequeñas y valiosas. También apunta hacia la visión final en tu mente. Está bien desviarse del camino ideal, y siempre recuerda que el envío también cambiará tu mente. Escribe historias de usuario para que se alineen con la visión final que estás pensando y eso generalmente funciona bastante bien.

Pero tampoco tengas miedo de tirar cosas que nunca vas a hacer en el backlog. Poner cosas en el backlog las saca de tu mente y las pone en papel donde están seguras para olvidarlas. Así es. El backlog es donde pones cosas que nunca vas a hacer, y no te preocupes. Las cosas buenas volverán. Si es importante, lo vas a pensar de nuevo. Un interesado lo va a decir, va a seguir volviendo, y entonces vas a decir, oh, espera, hey, ya pensamos en esto hace tres meses, y ahora tenemos una historia de usuario que ya está casi desarrollada. La pusimos en el backlog porque no era lo suficientemente importante, pero ahora lo es. Y recuerda, básicamente eres una nueva empresa cada 12 a 18 meses.