Get on Board ha sido una startup 100% remota desde el 2013. Quienes vivimos en la misma ciudad hemos coworkeado ocasionalmente — en especial en las etapas iniciales del onboarding de una persona nueva — pero en el día a día funcionamos al 100% sin que importe mucho dónde está quién.
Esto se remonta a cuando Jorge y yo nos fuimos a vivir cada uno a su ciudad de elección — Miami y Lima, respectivamente— . Nos acostumbramos a conversar asíncronamente, a vernos una o dos veces al año y a jugar de memoria. Cuando se sumó el resto del equipo, se incorporaron a esta misma dinámica.
Pero la operación de Get on Board y el codebase eran mucho más sencillos en ese momento (y además teníamos muchos menos clientes y usuarios). Hoy tenemos que pensar en montones de cosas más — growth, alianzas y auspicios, proceso de ventas, infraestructura, escalabilidad, negociaciones, fundraising — y además somos cada vez más gente (8 y contando).
Y rápidamente lo que era “jugar de memoria” pasó a ser un cuello de botella para el flujo de información, porque ciertas personas estábamos almacenando información clave en nuestras cabezas que era constantemente requerida por otras personas en el equipo.
Por eso, este año mi prioridad #1 ha sido la de documentar el conocimiento acumulado durante todos estos años, de la manera más fidedigna y escalable posible.
Manejando los riesgos escondidos (“bus factor”)
La información no inmediatamente disponible es, como le llaman los abogados, una contingencia o un liability.
Una buena metáfora es el bus factor — el riesgo de perder o interrumpir el acceso a información valiosa que sólo vive en la cabeza de alguien. Y no por el fatalismo de “qué pasa si a ese alguien le sucede algo”, sino porque sencillamente el acceso a las personas tiene el límite físico del tiempo.
La información que no está documentada no escala
Si alguien necesita conocimiento que sólo tú tienes y tú no puedes atender a esa persona porque tu agenda está llena, en términos prácticos es lo mismo que si estuvieras de vacaciones, o hubieras renunciado, o te hubiera atropellado un bus. Es decir, ese conocimiento no está disponible.
Como me decía un amigo e inversionista en Get on Board: “Yo tengo 50 personas a mi cargo. Si cada una de ellas me hiciera una sola pregunta al día, mi día quedaría completamente bloqueado y no podría hacer nada más”.
👉 No dependas de la osmosis
Desde el punto de vista de la gestión del conocimiento, a Get on Board le ha beneficiado mucho ser una startup remote-first: como no tenemos dinámicas sociales cotidianas tales como la conversación de pasillo, el “ir a tomarse un cafecito” o lanzar una pregunta al aire, las instancias de transmisión de información deben planificarse y estructurarse deliberadamente.
Por supuesto, desde el punto de vista de la integración de equipo y el fit cultural, necesitas balancear la distancia interpersonal de otras formas. Pero eso es un tema para otro artículo 🙂.
El punto es que el factor remoto nos ha obligado a poner muchas más cosas en papel de las que habríamos puesto si estuviéramos todos en la misma oficina. Por ejemplo: buenas prácticas, pautas de las (pocas) reuniones que tenemos, heurísticas de toma de decisiones, conocimiento de la lógica de negocio, de la industria o de nuestros clientes, criterios editoriales y coordinación de tareas pendientes.
Desde luego, acá las herramientas importan un montón. Nuestro stack actual de gestión del conocimiento es:
- Medium para todas las reflexiones públicas (más sobre esto abajo)
- Centro de ayuda y soporte (montado sobre Hubspot), también público, para todas las preguntas de clientes y usuarios.
- Notion para coordinación “dura”, documentación, status de procesos, inteligencia de negocio y cualquier información que no sea efímera.
- Slack para conversaciones internas, coordinación cotidiana (“blanda”) e información de corta vida.
- CRM de Hubspot para el historial de conversaciones e interacción con clientes y usuarios.
- GitHub issues para darle seguimiento al feedback procesado de usuarios y las cosas a desarrollar/mejorar en el producto.
- Comentarios de código para conocimiento contextual en el codebase.
👉 Optimiza para el equipo del futuro (incluyéndote)
Documentar hoy vuelve la información accesible mañana. Y no sólo para quienes vendrán: la memoria es frágil y el “tú” del futuro podría tener un modelo mental o un estado emocional muy diferente al “tú” del presente.
Esta parte tiene todo que ver con Arquitectura de información:
- Contexto, contexto, contexto. Desde los mensajes de commit hasta el registro de una conversación con un cliente, piensa que en 10 años más necesitarás ver esto y tendrás que poder acordarte. Documenta de dónde surgió una decisión en particular.
- Haz la información encontrable. Redáctala y etiquétala bien, expláyate, haz links cruzados y usa varias keywords diferentes. Apúntala en herramientas con un buen buscador: el de Slack, por ejemplo, es poco efectivo para estos fines porque busca mensajes individuales cuando lo que necesitas es el contexto.
- Piensa en quienes vendrán. En Get on Board toda la información de larga vida (Notion, issues de GitHub y otros) se escribe en inglés, a pesar de que todo el equipo actual habla español. La razón es, precisamente, optimizar para un futuro donde podríamos tener personas en el equipo que no hablen español y que deberán tener acceso inmediato a toda la información.
👉 Haz el upgrade de “conversaciones” a “documentación” lo más rápido posible
Yo me he formado el hábito de pasearme por conversaciones de equipo en Slack, y apenas se ponen mínimamente interesantes, preguntar “hey, esto no podría convertirse en una página de Notion o en un post del blog?”.
Las conversaciones, incluso si están escritas, se pierden fácilmente. Apenas tengan un mínimo de trascendencia deben formalizarse y transcribirse a un lugar más permanente (en nuestro caso, Notion).
👉 Público por defecto
“Público por defecto” quiere decir que sólo privatizas información cuando tienes una buena razón para hacerlo. De lo contrario, la vuelves lo más disponible posible.
Hay 4 anillos de visibilidad y los priorizamos en este orden:
- La pública (como este post)
- La company-wide (todo Get on Board se entera, pero nadie más)
- La interpersonal (sólo se enteran los involucrados)
- La personal más íntima (sólo yo)
Dos ejemplos de cómo ponemos esto en práctica:
- El blog de desarrollo de Get on Board es una manera de hacer públicos aprendizajes y buenas prácticas de desarrollo que vamos descubriendo. Anteriormente éstas eran conversaciones que se quedaban enterradas en Slack, hasta que dijimos: Oye, si este conocimiento nos es útil a nosotros, ¿no podría serle útil también a más gente allá afuera? El blog de desarrollo es una documentación interna, sólo que no tenemos ninguna razón para no compartirla hacia afuera.
- Tenemos la política de Slack de mantener los DMs al mínimo y preferir siempre los canales públicos, a menos que sea (a) información muy privada o (b) información que expira rápidamente— como coordinaciones de dos personas previas a un evento — .
La razón detrás de “Público por defecto” es que mientras más pública la información, más resiliente es. Por ejemplo, hacer públicos nuestros aprendizajes de desarrollo permite que más gente pueda beneficiarse de ellos, cuestionarlos y enriquecerlos. Quienes se sumen al equipo en un futuro tal vez ya hayan leído el blog y estén mucho más familiarizadxs con nuestra forma de trabajar. Y la información pública tiene muchas menos posibilidades de extraviarse — siempre tienes a Google para recuperarla.
👉 Wiki por defecto
“Wiki por defecto” significa que la información es directamente editable por cualquiera en el equipo e idealmente en tiempo real. La palabra “entregable” es una que casi nunca usamos porque más que una “caja” que se “entrega”, la metáfora correcta es una olla en la que todxs están aportando ingredientes, revolviendo o probando.
PDFs, documentos de Word y otros formatos estáticos sólo se usan para propuestas comerciales o contratos.
👉 Énfasis en volverse prescindible para descentralizar la toma de decisiones
Hay un cierto gustito en sentirse imprescindible en un equipo. Pero todo el punto de gestionar el conocimiento y reducir el bus factor es justamente volvernos un poco menos imprescindibles y que los aspectos clave de la operación y el crecimiento de la organización puedan llevarse sin tu presencia.
A mí me gusta mucho el approach de Ray Dalio en sus Principios y que va justamente en la dirección de este artículo: es documentar la sabiduría y el aprendizaje ganado en forma de heurísticas o algoritmos que otras personas pueden reutilizar para llegar a decisiones de calidad similar. Lograr eso significa poder escalar la toma de decisiones y eso garantiza la sustentabilidad y el rendimiento de una compañía más allá de la inspiración, visión o energía de sus founders.
Además de proteger a la organización contra algo que te suceda, documentar por defecto tiene efectos mucho más inmediatos: te permitirá tomar vacaciones más tranquilamente, aumentará la autonomía del equipo completo, y por sobre todo, permitirá que la organización crezca y escale de manera sustentable.
Lo más reciente en Blog
