Como “manager” soy lamentable. No es falsa modestia, podéis preguntar a cualquier persona que me haya sufrido como jefe. Hacedlo en privado, en público ya sabéis que nadie dice la verdad, no vayamos a quedar mal. No pasa nada, no hay mejor cosa que asumir tus limitaciones y dejarte de gilipolleces de “superar tus miedos” o “dejar tu zona de confort”.
Y soy malo porque, además de tener un nivel de empatía más bien bajo y tampoco me motiva mucho mejorarlo, la gente me aburre. No me aburre en el sentido “soy un ser superior y tu conversación carente de sustancia intelectual es desmotivante”, más bien en el de “me cuesta estar con gente porque tengo que hacer un esfuerzo extra en no parecer tonto”. Esta escena de “Pulp Fiction” define bastante bien mi relación con las interacciones humanas.
El caso es que, por desgracia, en esta vida te toca ser “manager” en alguna ocasión.
A mi hija, en edad de ir justito para andar, le gusta bajar y subir escaleras. Las baja por el lado donde no está la barandilla, el cerebro humano a veces tiene estas cosas. Me mata tener que cogerla y bajar las escaleras, porque me cuesta creer que nadie nazca para que le guste cargar con un ser de 15 kilogramos arriba y abajo. Mientras llora y te manda en la dirección contraria a la que vas.
Algún día va a hacerlo sola, se va a calzar la hostia del siglo y me tocará llorar. Eso pensé un día hace unos meses en el que, gracias a la entidad superior que controla este tinglado, justo leía esta maravilla, del libro Art & Fear (que parece de arte pero en realidad habla de la vida), que te pego aquí:
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.
His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity.
It seems that while the “quantity” group was busily churning out piles of work - and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay
Así que me dije, cuantas más escaleras suba y baje, con o sin barandilla, menos probabilidad de que me toque pasar la angustia de esos segundos, que parecen meses de confinamiento, entre que oyes el golpe y empieza a llorar. Y con sinceridad, así me deja un rato tranquilo.
Empecé a dejarla bajar y subir las escaleras. Yo simplemente miraba desde 3 escalones más abajo, para en más de una ocasión cogerla al, literalmente, segundo bote. Meses más tarde me pide que me vaya más abajo, que ella puede sola. Cuando ve las orejas al lobo pone el culo en tierra, porque aprender a usar la barandilla no lo llevamos en los genes, pero lo de ahorrarnos dolor parece que sí. No tengo la certeza de que haya bajado las escaleras ella sola, pero tampoco tengo la duda. Y ese creo que era el objetivo.
Y me doy cuenta que esa ha sido y es mi estrategia de gestión: echar a los leones tantas veces como sea posible y ver si sobreviven. Cuando sobreviven, y lo hacen la mayoría de las veces, ya no te necesitan, aunque te odien un poco por no haberles ayudado.
En Tinybird empezamos al revés que muchas empresas de producto: por la parte de monetizar. Antes de meternos 100% a desarrollar producto y luego ir viendo (pivotar lo llaman) decidimos empezar facturando con un producto muy pequeño y haciendo servicios profesionales.
El tema de servicios profesionales es un tema un pelín tabú, ya sabes, la métrica estrella de cualquier SaaS B2B es el MRR (la gallina que entra de forma recurrente al mes) y claro, los servicios profesionales no son, en teoría, recurrentes y tampoco escalan bien. Bien en el sentido de que necesitan personas, y somos caros y tenemos sentimientos, cosa que una máquina en amazon no. Por suerte nuestros clientes son personas y prefieren a alguien humano del otro lado.
Pero la realidad es que la mayoría de productos tienen una parte de servicios profesionales y son necesarios para cerrar clientes que paguen pasta. Hay muchas razones, la más importante es que hemos idealizado tanto las empresas de producto, gracias a esos blog post de americanos vendiendonos el mejor humo, que hemos perdido el norte y nos hemos pasado de vendernos a nosotros mismos.
Pero el troleo, que de verdad me apetece, no es para este post, ahora vengo a hablar de como organizamos internamente la gestión de estos servicios. Sí, es un post sin historia, símplemente te explico aquí lo que hacemos por si te sirve de algo en tu empresa. También lo escribo para mi yo pasado (y futuro, como todo lo que uno escribe), me hubiese gustado que alguien me explicase esto hace 10 años.
Somos una empresa remota, así que todo el proceso intenta ser lo más asíncrono posible. Sería gilipollas si dijese que es 100% asíncrono, pero sin duda molaría mucho más. Por otro lado, toda la gente en servicios profesionales son desarrolladores, nada de “perfiles más baratos”, “más de negocio” o “recursos intercambiables”.
Ahí va, tenemos:
Un proyecto en basecamp por cada uno de los clientes. A veces no son clientes y son simples (y muchas veces cortas) pruebas de concepto. Hacemos pruebas de concepto para ver si el producto resuelve tu problema, todavía no somos confluent y todo mundo usa nuestro producto aunque no lo necesite. Da igual. Nosotros usamos basecamp porque nos acerca un poco al sueño de vivir en La Zagaleta y tener vehículos prohibitivos en el garaje, pero cualquier cosa que tenga una especie de foro (guiño al IT de los 90) donde la información se divida por temas y no permita escribir más de 1 vez por minuto, va que bufa. Es decir, no te dispares en el pie con un chat por proyecto. Di no al chat.
Cada proyecto tiene asignadas dos personas, la que manda y el telonero. La que manda lleva la voz cantante, el telonero está para ayudar y por si el primero falla (vacaciones, enfermedad, personas a cargo…). Esta persona actualiza un hilo “worklog” cada vez que hay una interacción. Todo el mundo recibe notificaciones cuando hay cambios, puedes o no leerlas. A veces las lees de pasada, pero cuando lees de pasada la misma cosa 200 veces al final queda y cuando tienes que priorizar problemas todo es mucho más fácil. Así nos enseñaron las tablas de multiplicar (para los milenials: son como una minicalculadora, la que va en el móvil, pero en tu cabeza) y es verdad que fue un peñazo, pero ocho por cuatro son treinta y dos.
Cuando hay eventos o temas importantes, que se salen fuera del “worklog” usamos hilos específicos para comentar. Un problema grave, una solución que creemos que puede ir a producto, un evento específico. En general el truco es escribir lo que pasa, sin más.
Una vez a la semana hacemos una reunión de proyectos. En un Google Doc pone la fecha y se enumeran los proyectos actuales con los links a los últimos updates ANTES de llegar a la reunión. Normalmente cuando llegamos todo el mundo ya sabe que ha pasado porque han leído los updates, así que, aunque refresquemos la memoria, no suele haber dudas. Además, incluímos los proyectos nuevos, comentamos de que van, damos contexto y decidimos la persona que manda y el telonero. Se abre el proyecto de basecamp y se deja una descripción de lo que hay que hacer.
Estas reuniones la mayor parte de las veces son de coordinación técnica-negocio, es decir, siempre hay cosas que hay que negociar, decisiones que pueden afectar para cerrar un cliente, quizá hay que dar un toque a alguno para ver qué tal lo llevan…
Si hay algo que necesita tiempo especial hacemos reunión específica sobre ello previa actualización en su correspondiente proyecto.
Nada nuevo bajo el sol, seguramente la mayor parte de empresas de consultoría tengan un proceso mucho más depurado y haya herramientas maravillosas para este tema, pero la clave está en no olvidar que los servicios profesionales en empresas de producto también necesitan organización y procesos, especialmente 100% remoto.
Casi ya poniendo la guinda al año es un buen momento para parar a recapitular. Y no hay mejor forma de reflexionar y ordenar tu cabeza sobre algo que escribiéndolo. La madre de dios, ni un post sin aroma a Coelho en este blog.
Si llegas aquí sin saber que es Tinybird, es una empresa que fundamos hace un año y pico en la que hacemos un producto que permite analizar cantidades ingentes de datos en tiempo real. Échate un ojo a estos posts que escribí hace tiempo
En los anteriores posts hablaba de tecnología, aquí voy a cambiar el tercio, vamos creciendo y aunque la tecnología sigue siendo ciudadano de primera, hay otras cosas destacables importantes.
Al tajo.
No hemos casi cambiado el stack, prácticamente usamos lo mismo pero estamos haciendo una cosa que normalmente hacen empresas mucho más maduras: refinar. Nuestro stack es sencillo al máximo y eso hace que en vez de hablar de tecnología, hablamos de cómo solucionar problemas con tecnología.
Cuando haces un producto y la gente empieza a usarlo, por muy bueno que seas (incluso les pasa a los norteamericanos) hace aguas. Y lo hace porque los usuarios se meten por caminos que no esperas. Y está pero que muy bien, no hay nada más sencillo a nivel de producto que resolver donde tus clientes tienen problemas porque es precisamente para lo que arrancas tu proyecto,
Hemos subido un escalón. Hemos atacado proyectos de los de quedarse hasta las 3 de la mañana que nos han hecho mejorar. No estoy orgulloso de quedarme hasta las 3 de la mañana, es un error y es síntoma de no saber hacer algo, pero es también el reflejo de que la cosa no era fácil. Si procesar 12 trillones de filas en un solo día no es el siguiente escalón ya no sé qué será.
Hemos crecido el equipo en la primera mitad del año contratando a gente clave y sobre todo, vamos acompañando con procesos y formas que son de empresa mucho más madura. Seguramente el ser 100% remoto hace que sea prácticamente obligatorio, pero que sea la segunda o tercera vez que lo hacemos tenga algo que ver, aunque siempre haces cosas fatal. Seguramente explique en un post las cosas que estamos haciendo diferentes sobre procesos.
Seguimos siendo poquitos (11 según escribo esto) manteniendo la eficiencia. Esto ha pasado en parte porque levantamos el pie al ver el tema del puto virus y por otra porque hemos preferido poner bien el cimiento. La prueba del algodón: podemos dejar un proyecto o feature en manos de cualquier persona del equipo y lo va a sacar adelante con nota.
Además he estado probando alguna nueva forma de contratar y de llegar al público objetivo: streams en twitch hablando de temas técnicos, explicando ofertas de trabajo, haciendo ofertas un poco diferentes…
No hemos hecho ruido (o eso creo). Salir en el periódico, ganar premios y demás está muy bien, te sube la moral, eres el jefe, “putos amos son esta gente”, pero no da de comer ni hace que tu producto sea mejor.
En vez de eso, foco en los clientes: responder rápido, meternos hasta la cocina en sus problemas, entender bien lo que duele. Esta frase también la podría soltar cualquier consultora internacional pero yo no llevo corbata y me puedes preguntar el modelo de datos de cada cliente.
Foco en que el producto sea útil y rápido. En aumentar el ingreso recurrente y la facturación.
Foco en que la gente del equipo vaya cogiendo las partes del negocio fundamentales con onboardings, videos, cursos, trabajo en común y machacar todos los santos días con lo mismo.
Hemos agachado las orejas cuando la hemos liado parda, que ha sido unas cuantas veces.
Cerramos un año bastante bueno a todos los niveles, aunque como siempre miramos mucho más a donde no hemos llegado que a lo que hemos conseguido.
Mira que me había prometido que no volvería a hablar de cómo contratar pero pensaba que no estaba de más explicar cómo lo hemos hecho esta última vez. Y soy gilipollas porque cuando hice aquella promesa fue porque me dieron por todos los costados (no sé si con razón o no, compruebalo tú misma), y yo soy una persona sensible, me afecta cuando me sacuden.
En general si lees posts de como contratar que hay por ahí terminarás por: 1) contratar a la misma gente que contratan el resto (que puede ser bueno o no) y 2) montando un arco de iglesia tremendo que muy seguramente no necesites para contratar. Estas dos cosas también son aplicables al resto de cosas y así ves empresas con kubernetes y 154 microservicios para aguantar una carga que no despeinaría una raspberri pi alimentada por energía solar.
Y después del anterior párrafo que me podría haber ahorrado, pero que me apetecía meter, pasa que cada empresa y cada momento necesita contratar de una forma (en mi opinión, claro). Y el momento para Tinybird es el de una empresa de 10 personas donde todo el mundo hace casi de todo y que sobretodo, las personas que entren ahora formarán los pilares culturales y serán las referencias de los que vengan detrás de ellas. Si en una casa haces mal un tabique se arregla y punto, si pones mal un cimiento no te imaginas como acaba la historia.
Hasta ahora habíamos tirado de personas cercanas, es decir, personas que eran y siguen siendo para nosotros referencias. Esta es la opción fácil y la mejor al arrancar, pero claro, tiene un problemón: no sales de tu círculo, es más difícil que nadie te venga a decir “pero qué estáis haciendo pin-pin-es” y terminas haciendo todo igual que lo hiciste en el pasado.
Así que en las siguientes contrataciones nos planteamos hacerlas con gente de fuera de nuestros círculos, gente que no conociesemos. Es fácil, es seguir el pesadísimo flujo habitual: sacas una oferta, esperas que llegue gente, los entrevistas y haces una oferta si todo va bien. Sin embargo hay una cosa que valoramos y es que la gente tenga interés por lo que hacemos y no por quienes somos.
Halaga una barbaridad que publiques una oferta de trabajo y te lleguen personas que quieren trabajar contigo símplemente por ser tú, pero la realidad del invento es que tú te conoces mejor que ellos y sabes que el personaje de internet no dice nada del como será el trabajo. Así que para conseguir personas realmente interesadas publiqué un tweet preguntando si la prueba técnica que pedíamos para una supuesta oferta laboral era complicada o no.
Recibí buen feedback de la oferta, pero ese no era el objetivo. Hubo gente que le interesó y se molestó en buscar lo que hacíamos, si buscábamos gente y enviar un correo preguntando. No hay nada mejor que la gente que pregunta (de hecho el test técnico es de preguntar más que de resolver) porque son los que realmente están interesados. Porque ojo, estar interesado en hacer kubernetes con microservicios y loquesea es faćil porque es lo que te dicen en hackernews, pero meterte en una empresa donde se dedican a crear APIs que atacan a billones de registros con tiempos de respuesta de menos de unos pocos cientos de milisegundos no es lo que se ve todos los días.
El resultado ha sido muy bueno: el interés y la calidad de las personas que se han presentado al puesto de backend que buscabamos ha sido altísima y solo nos ha llevado 1 mes cerrar el puesto con muy poco tiempo invertido. Esto parece una payasada que suelto para que la historia termine bien, pero es importantísimo para una empresa que los fundadores puedan ver a los candidatos, ahora, si lleva mucho tiempo al final delegarás eso (y puede que con 50 personas tengas que hacerlo, pero no con 10) porque es un verdadero tostón.
El otro día Elon Musk tuiteaba esto (es interesante leer las respuestas, sobre todo las suyas)
Tesla is developing a NN training computer called Dojo to process truly vast amounts of video data. It’s a beast! Please consider joining our AI or computer/chip teams if this sounds interesting.
— Elon Musk (@elonmusk) August 14, 2020
No es que Elon sea el más coherente tuiteando ni el que más me guste, pero hay que reconocer que el amigo ha creado algo que hará cambiar industrias completas, que hará que nuestra prole quiera aprender machine learning, física, aeronáutica y otras tantas cosas que estaban dadas por hechas, en vez de ser tiktokeros. No tengo nada en contra de los tiktokteros pero el beneficio de un tiktoktero no es compuesto y sinceramente, no hay tanto espacio para hacer sketchs de especial de nochevieja continuamente.
Me despisto, el caso es que es el CEO de una gran compañía hablando de Inteligencia Artificial con criterio, es decir, sabe qué está diciendo, no son palabras vacías escritas por un comité de discursos para tranquilizar a tu accionariado haciendo ver que estás a la última cuando tu capitalización bursátil se va al garete. Repito, Elon no es el CEO típico y no creo que sea ejemplo de muchas cosas, pero sabe de que habla y pone dinero en ello (porque en software también es cosa de echarle dinero).
Cuando hablamos de transformación digital no tengo muy claro lo que quiere decir, pero creo que se parece mucho más a seguir haciendo lo mismo pero siendo “más digitales”. Cuando yo leo transformación digital lo que pienso es una reestructuración completa de, empezando por el CEO, con un enfoque pensado desde la tecnología. Pero esto, como sabemos es algo casi imposible y seguramente las empresas que hoy nacen digitales serán los nuevos bancos, los nuevos fabricantes de coches, etc.
Sabes que voy a contar una historia, así que no lo demoremos: hace un tiempo tuve la oportunidad de hablar durante un buen rato con el CEO de una empresa top del IBEX35. Yo no soy muy listo pero lo suficiente para saber que cuando yo estaba yendo, él ya había ido y venido media docena de veces. De hecho me quedé impresionado del conocimiento técnico que tenía. La pregunta entonces es, si hay personas tan capaces en puestos muy influyentes, por qué las empresas Españolas, por poner un ejemplo, no terminan de pasar de usar tecnología a ser tecnológicas? la razón -que escribo aquí como si estuviese totalmente seguro de que es así- es que ser alguien sobresaliente no es suficiente, además tienes que entender bien la tecnología (y además todo ese rollo de tener suerte, claro). No me refiero a poder hablar con alguien de tecnología, quiero decir, entender con profundidad la tecnología, tenerla interiorizada. Además, saber de negocio, marketing y otras cosas imprescindibles que todos los libros de emprender describen perfectamente.
Vamos a ilustrar esto con una anécdota, como hace la gente que escribe libros de cientos de páginas. Hace 5 años el CTO, entonces, de Tesla da una charla magistral, no solo por el contenido, si no por saber condensar y explicar la estrategia tecnológica de la empresa de forma tan clara (después de verla piensa si serías capaz de hacer lo mismo con la tuya). Hay una parte de la charla que dice (extracto de los subtítulos de youtube, editado por mi para que se entienda todo a mi favor, si quieres verlo, en vez de leerlo, el extracto empieza aquí):
We've worked with several other make a automotive oems with both Daimler and Toyota and others and it's really fascinating trying to interact with them especially around software electronics because there's a huge fear they just don't totally trust it they don't totally understand it and they kind of treat it like this thing that's to be contained and managed very carefully
There's one story I remember where we had a motor that was controlled by software and there was a concern, what if the motor goes too far [...] what if it over drives in one direction or the other direction, how are we ever gonna prevent that.
We said well can't you know we should just make sure the software doesn't do that and we'll put the appropriate checks and the software and you know write it very carefully and test it.
They said no, you know we can't ever be sure the software will work so they actually put a mechanical bracket around the motor so that they didn't have to care about the software. [...] to me that's kind of just this totally different approach you know if you can't trust the software and you just say you're not even gonna try and make it correct and then put a bunch of mechanical stuff around it you know it's it's a different mindset.
La mejor parte es justo antes de empezar a contar la historia, donde explica el porqué ellos apuestan por el software y dice “this was possible because of the culture of the company”. Eso es, no puede ser de otra manera.
Y para poner la guinda a la historia, sabéis que venía de hacer el menda en cuestión? pues una modificación de un porsche para convertirlo en eléctrico (con un rango de 44km) en 2002. Por favor, si vas a dedicar 2 minutos, que sea a ver como era el prototipo en vez de terminar de leer este post. Es un clarísimo ejemplo de la eficiencia de lo cutre
El problema es que la tendencia actual es ir al extremo opuesto, cuanto menos tengas que saber de programar y de tecnología, mejor. Usemos herramientas “No Code” o “Low Code” (en las que en realidad inviertes tu tiempo en aprender un pseudo lenguaje de programación propietario en vez de invertirlo en aprender algo standard, abierto y que durará más allá de la quiebra de la empresa “no code”), no importa el modo mientras lleguemos al destino, aunque hayamos quemado todos los puentes por el camino. Estas herramientas, los cursos de 3 meses y demás familia tienen su sentido, son muy útiles, pero no creo que nos podamos conformar con ello. No creo que todo el mundo en Tesla sepa como ajustar los parámetros de una red neuronal, pero necesitamos gente que imprima cultura de la tecnología y esa por suerte o desgracia se aprender con esfuerzo y trabajo. Lo peor es que las barreras de entrada en muchas ocasiones las ponemos la propia gente que trabajamos en tecnología, sobre complicando y haciendo tecnología por la mera tecnología.
Aprende a programar, aunque sea un poco.