“I know what’s like to be good” son las palabras que me quedaron grabadas hablando con un advisor de startups, uno de esos que te ayudan a montar parte del equipo, cuando le pregunté cómo podía ayudarnos.
Estos días estoy entrevistando a perfiles diferentes a técnicos. Entrevistar a carabolis es fácil, cuando eres uno de ellos sabes de qué va todo el tinglado. Normalmente con unos minutos te hagas una idea de qué tipo de perfil tiene, donde puede o no cuadrar y en qué cosas se está vendiendo un poco. Somos malos vendiendonos, alguna cosa buena tenía que tener. Nadie te cuenta esto cuando montas una startup.
Ya me sé todo ese tema de que las entrevistas tienen que ser lo más objetivas posible, que tienes que eliminar el “bias” y demás. Nada en contra de que los procesos sean los más objetivos posible, pero la realidad es que nunca lo son, no se puede evaluar una persona objetivamente y mucho menos para algo que dista mucho de ser una cadena de montaje. No es mi intención entrar aquí, así que ahí lo dejo y me voy a lo mio.
Lo que a mi me suele pasar cuando veo un perfil bueno es que mi sexto sentido me avisa. Alguien levanta una banderita en tu cerebro y rara vez falla. Es difícil explicar objetivamente lo que es, pero hay una intuición detrás. Esa intuición de saber “qué significa ser bueno” no viene sola, se genera de años de experiencia trabajando (y contratando) con mucha gente, pasar por diferentes tipos de empresa y entendiendo lo que mueve a cada perfil.
El problema es que cuando entrevistas a alguien que está fuera de tu ámbito estás perdido. El fulano de la banderita está a otras cosas. No sabes diferenciar lo bueno de lo malo, no sabes cuando te la están metiendo doblada o qué detalles son los que van a marcar la diferencia. Cuando pregunto a un programador que me cuente el proyecto más interesante en el que ha trabajado, en medio minuto sabes si cerraba tickets o resolvía problemas. Con alguien de marketing, en ese medio minuto estoy fuera de juego.
Es cierto que hay cosas que son comunes: interés, curiosidad, capacidad de análisis y síntesis, pasión (sí, da gusto ver cuando a alguien le gusta algo) pero no vale con eso.
El caso es que cuando no tienes la intuición solo se me ocurren un par de formas de buscar al perfil adecuado:
1) Ponerte en la piel y entender bien lo que necesitas. Y aquí lo más fácil es hacer lo que se supone que esa persona haría y listo.
Os pongo un ejemplo práctico. Ahora mismo buscamos gente de comercial. Yo no he vendido en mi vida nada ni creo que lo venda, no entiendo nada del proceso de venta (más allá de lo que aprendes viendolo de fuera que te sirve para pegarte el pisto alguna que otra vez). Así que para entender lo que significa estoy haciendo algo típico en ese area: intentar vender a puerta fria.
Cuando monté Tinybird el objetivo era que el logotipo estuviese en la puerta de algún coche de competición. Creo que podemos, aún recuerdo una reunión con Alteryx en uno de los viajes a SF, de cuando se podía viajar, y en la que nos contaban que tenían más bien poco ARR. Hoy están en un coche de F1. Así que me estoy dedicando a intentar vender Tinybird a alguna marca de competición para intentar ahorrarnos pagar una pasta por un logo de tamaño minúsculo en el casco de un piloto. No he conseguido nada como ya imaginabais, pero aprendes que es más difícil de lo que parece. Solo saber a quién y cómo atacar dentro de la organización es absurdamente difícil.
2) La otra forma de generar esa intuición es no generarla y buscar a alguien del que te fíes que sepa distinguir entre el grano y la paja. Las empresas de recruiting en teoría hacen esto. En la práctica rara es la vez que tienen la misma intuición que tú.
Otra opción es buscar a alguien que haya pasado por ese puesto y te ayude a entender a quien entrevistas.
Esta segunda opción suele ser mejor, no tienen incentivo por colocarte a nadie, pero pedir a tus amigos que te entrevisten gente no es bueno para mantener la amistad. Tampoco es perfecto, hay algunas cosas que son difíciles de evaluar desde fuera de la empresa (de ahí también la diferencia de criterios con las agencias de recruiting)
Si no quieres abusar demasiado puedes preguntar sobre qué preguntas hacen en las entrevistas, qué vieron en cierta persona (que también conoces), qué guión siguen, cual son los “red flags”, que valoran muy positivamente, donde es más fácil equivocarse, qué es más difícil de ver, qué pruebas “técnicas” ponen, qué hay que preguntar y en general todos los porqués de lo que acabo de decir, es también una buena forma de hacerse una idea. Es bueno incluso hacer estas mismas preguntas al propio candidato :).
Como siempre, vas a cometer errores contratando, pero las personas no somos máquinas que podamos evaluar al milímetro con preguntas. Lo que sí sé es que cuando los fundadores de una startup no tienen claro para qué quieren contratar un perfil y sólamente lo hacen porque “es lo que toca” (que suele pasar con los VPs), es la receta infalible para el desastre.
Un buen día alguien me dejó unas gafas de ver de lejos. La gilipollez esa que haces cuando eres jóven de “a ver qué tal me quedan”.
Resultó que, lo que estaba lejos, se veía bien, nítido. No tenía ningún sentido, como algo lejano se podía ver bien? claro, estas gafas fuerzan la vista, pero no deben ser buenas a la larga. Eso pensé yo.
Siempre había visto todo borroso, la televisión, las personas, los paisajes. Es lógico, si algo está lejos, se tiene que ver mal. Punto.
Pero aguanta, esto no es lo contraintuitivo.
Pasé toda mi secundaria y bachillerato sin ver nada de lo que el profesor ponía en la pizarra, nos sentaban por apellido, así que siempre me tocaba al fondo. Pedir sentarme más cerca de la pizarra estaba fuera de mis habilidades. Hay cosas que no se solucionan con unas gafas.
Así que desarrollé un sistema para poder coger apuntes: entender lo que decían. No podía permitirme no hacerlo, copiar lo que ponía en la pizarra para entenderlo después era imposible. Como es lógico, la pizarra estaba lejos, mala suerte por apellidarme Santana.
Me crucé un día con mi madre por la calle y no la saludé. Me paró y me dijo: tú, hijo, no ves nada.
La miopía se cura? es lo primero que pregunté al señor de la óptica. Primera gran decepción de mi vida.
Aquello que a priori es una tara, resultó ser una de mis superpoderes en la universidad. La capacidad de atención y concentración que desarrollé aquellos años me permitieron seguir las clases sin problema. Tenía que estudiar relativamente poco (aunque lo hacía todos los santos días) y era sencillo asimilar todo aquello.
Toda esa capacidad se fue perdiendo con los años y sobre todo, cuando contraté la tarifa de datos de mi smartphone.
Me lo escribo para que cuando me encuentre con alguna limitación me acuerde que tal vez sea un regalo del cielo.
Hay dos extremos en el mundo de las empresas y el software libre: las que lo crean y las que lo usan. En el medio hay otras que son las que contribuyen al que crean otras empresas.
Por ejemplo, si miras las contribuciones del kernel de Linux verás empresas como Redhat, IBM, Facebook que contribuen pero no controlan el proyecto. En mi opinión esto es lo que debería pasar siempre, pero claro, no todos los proyectos tienen una fundación detrás, en este caso Linux Foundation, ni tienen tanto impacto, pero hay otras como Apache fundation que gestionan muchísimos proyectos pequeños. Tampoco hay que ser iluso, es importante mirar el “board of directors” y sobre todo en que empresas trabajan.
Luego tienes empresas como Mongo o Elastic, que crean, guían el proyecto y además tienen un negocio que basan en esa pieza de código. Todos sabemos lo que ha pasado en los últimos años con cambios de licencias de software para evitar que el gran Amazon use su software. Redis, Elastic, Mongo, Mapbox han hecho cambios de licencia relativamente duros para evitar que otras empresas aprovechen su trabajo y les hagan la competencia.
Yo que sigo creyendo en toda esa historia del software libre, pienso que hace avanzar a la humanidad, de hecho me parece que hacer software abierto es una “externalidad positiva” de libro, especialmente si lo haces con consistencia y resuelves un problema, por pequeño que sea. El otro día escuchaba un podcast donde el CEO de databricks, empresa que mantiene Spark, comentaba que su producto era usado por las científicas que han hecho posible la vacuna del puto coronavirus. A su vez spark surge como proyecto aplicando el famoso paper de map reduce de google, de cuando google compartía cosas sin ser marketing vacío. Wikipedia usa kafka (creado por Linkedin), entre otros, para velar que su contenido sea independiente, habilitando uno de los mejores proyectos que seguramente veremos en lo que nos quede de vida (y da igual cuando leas esto). Si eso no es hacer mejor el mundo que baje Dios a decirnos qué es.
Pero la triste realidad es que la mayoría de empresas lo único que hacen es usar ese software libre. Unas pocas colaboran un poco, alguna contribución de vez en cuando y ya. No pasa nada, es lo normal, muchas empresas suficienten tienen con lo suyo.
En CARTO, la empresa que era CTO anteriormente, basabamos nuestra tecnología en open source (y el producto en si también es open source). Sin embargo, aunque sabíamos como funcionaba apenas contribuíamos y eso a la larga terminó pasando factura, porque para innovar necesitas no solo saber como funciona si no cambiar lo que necesitas. Y para cambiar necesitas músculo. Así que para paliar este tema contratamos a los mejores del mundo en ese momento y pusimos unos cuantas personas de la empresa a trabajar 100% en eso.
El caso es que me creo bastante que para que una empresa de tecnología sea puntera tiene que conocer tan bien lo que usa como si lo hicieran ellos mismos. Y esto es como plantar un árbol, cuanto antes lo hagas, mejor. No tengo claro que muchas empresas “deep-tech” se den cuenta de esto a tiempo, una empresa tarda unos años en madurar a todos los niveles y unos años en tecnología es la vida. Echa la vista atrás 10 años y verás a lo que me refiero.
Por eso una de las cosas que estamos haciendo en Tinybird es contratar a gente para aportar 100% a Clickhouse, la base de datos que usamos en nuestro producto. La norma dentro de la empresa es, para entender lo que está pasando, se mira el código fuente, lo demás son conjeturas. No solo se trata de contratar gente, se trata de crear el equipo, la cultura y la dinámica que será la semilla para la mantener la parte de innovar viva dentro de unos años. Estas cosas suelen ser caras, pero más caro es quedarme mirando como otros lo hacen por ti.
Por otro lado, me quema la sangre cuando pensamos que aquí no se pueden hacer estas cosas, pero cuando hablas de tecnología puntera todos los españolitos nos cuadremos mirando a San Francisco (aunque el software open source se desarrolla muchas veces el otro lado del planeta). No es que a mi me importen las banderas o fronteras, pero verás, cuando mejor les vaya a tus vecinos, mejor te irá a tí y sus otros vecinos, también. Por suerte este juego no es de suma cero. Cierto es que en hay una parte importante de cultura y que la industria a tu alrededor cuenta, pero ahora estamos en un punto donde tener a ciertos perfiles es “sencillo” y donde la financiación entiende apuestas así.
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.