A la segunda todo sale bien: La recetita

Este es el segundo post de la serie “qué pasa cuando montas una startup y no es la primera.”

Si hay una receta que siempre funciona es la del fracaso, dicho de otra forma, la que usas cuando quieres solucionar un problema complejo siguiendo pasos sencillos.

Si quieres recibir el siguiente episodio y algún que otro post de vez en cuando, ya sabes, esta no es tu primera vez.

He visto fallar y he fallado muchas veces, la mayoría de veces no tengo ni idea del porqué, pero no quita para que me sea fácil identificar cuando alguien, incluido yo, aplica una recetita. Sé con total seguridad que la hostia será proporcional al tiempo que tardes en darte cuenta que estás haciendo algo sin pensar. Solo tienes que esperar, es matemático. Y lo peor no es que lo hagas sin pensar, no todo puede estar razonado, lo peor es que lo haces con aplomo. Muy de machos alfa esto.

Lo habitual cuando montas una empresa es que no tengas ni idea de la mayoría de cosas. De las que sabes te las apañas como buenamente puedes, de las que no buscas recetas porque te aceleran. En teoría.

Unos ejemplitos que te van a sonar: no sabes de ventas, sin problema, manual de ventas, BDRs, account executives, salesforce (nadie es despedido por poner salesforce) y a correr. Que nada de tecnología? un repositorio, test unitarios, kubernetes, SRE, unos full stack, microservicis, IA, cloud y a producir. Marketing? Hubspot (sí, correcto, nadie es despedido por poner Hubspot), content marketing, SEO, automatic content generation, whatever generation y a meter gallina en ads y medir el ROI en base a una métrica que parece que aporta al negocio (como número de usuarios que se dan de alta sin saber porqué)

Pero eso no es todo, otro problema es que las recetas suelen venir con métricas y terminas haciendo “data driven” y poniendo unos OKR como la catedral de Valladolid (la que tenían pensado construir, no la que hay): “ya tiro y con datos veo si estoy tomando buenas decisiones” es el plan perfecto, sin fisuras. Así que te haces unas medias y unas gráficas con 100 data points y tomas decisiones en base a casualidades. Cuando ya tienes algo de experiencia, sabes que las recetas son como cupones de lotería, tocan bastante poco.

Ya cuando te haces mayor del todo, lo que llaman mediana edad, te das cuenta que antes de aplicar la receta tienes que encontrar tu versión de la receta, la que puedes hacer con los ingredientes que tienes. Tienes que empezar pequeño, construir intuición, validar y ver qué cuando aprietas mas, sacas mas, que no solo la persona que ha creado el proceso es capaz de ser exitosa y ya entonces, y solo entonces, te coges el manual y aplicas lo que sabes, porque te lo ha dicho la receta, que mas o menos funciona a escala.

No hay mayor pena que ver como despues del dolor de aplicar la receta, algo falla miserablemente, ni mayor alegría y satisfacción de ver como algo que empezó pequeño, dando valor desde el día cero, es capaz de crecer modelándolo día a día.

Las recetas, para montar una franquicia, ser influencer en LinkedIn y hacer hilos en twitter, bien, para una startup, toca pensar.

Puede chatGPT trabajar en Tinybird?

Hoy he estado jugando con chatGPT, si no sabes de que va, lee el anuncio de OpenAI. No había hecho mucho caso a GPT3 y mucho menos con todo el rollo generativo de imágenes que ha habido últimamente, que como juguete y movimiento cultura está bien, pero tal cual no veo mucho recorrido salvo como entretenimiento infantil y para ahorrarse unos euros en ilustradores si quieres hacer algo poco original. Ya veremos a donde nos lleva, la mayoría de cosas grandes empiezan como simples “juegos”.

Estoy bastante seguro que este post va a envejecer mal y muy rápido, pero me viene bien para reflexionar sobre el tema. Ahí vamos.

Thanks for reading Javi Santana! Subscribe for free to receive new posts and support my work.

Al asunto, me registro en chatGPT y como soy un incredulo he empezado por preguntarle gilipolleces y me sorprende lo bien que responde. Pero bueno, son gilipolleces. Como no tenía mucho tiempo para andar con tonterías he pasado directamente a algo más serio: le he mandado responder el test técnico de data engineer para Tinybird (por aquí tienes un poco de contexto del porqué de la prueba). He copiado y pegado el texto, nada más. No te digo como lo ha respondido, te lo enseño.

Luego le he preguntado si lo podría hacer sin spark y ha usado pyarrow, también lo ha portado a C++ y le he pedido hacer un servicio web para este código que ha clavado el muy cabrón.

Y ahora viene la parte dura: es mejor que el 90% de las respuestas de humanos que recibo. Si yo me dedicase a programar empezaría a preocuparme (oh! mierda)

Lógicamente las pruebas técnicas que hago son para que las personas pregunten por el contexto y por suerte, de momento, el chat no pregunta, se limita a seguir órdenes. En otras palabras, la prueba técnica es de encontrar las preguntas correctas.

Tampoco chatGPT es capaz de crear sistemas complejos, solo plantear una solución a un problema tan cerrado como este, pero seamos sinceros, la gran mayoría de programadores hacen trabajo repetitivo por mucho que nos miremos a nosotros mismos como ”craftmanshipsers”.

Si yo tuviese 20 años estaría mirando muy fuerte a lo que está pasando ahora mismo y estaría llamando a la puerta de OpenAI o similar suplicando cada semana que me contratasen (*), está claro que el cambio está a punto de despegar y es el momento donde se puede salir a pescar. Esto sí que creo que es un cambio de marcha y no los 15 años que llevamos perdidos en reimplementar en javascript todo lo que java ya había resuelto (esto se estudiará en los libros de historia, como movimiento cultural y en documentales como super construcciones).

Pero ojo, tampoco me las quiero dar de VC aquí, falta integrar estos sistemas en los flujos de trabajo de las personas y los sistemas, estamos cerca pero creo que no nos quemamos todavía. Sigo muy de cerca aigrant que creo que ha llegado en el momento adecuado, con el mensaje adecuado (los fundadores son inversores en Tinybird, gente con criterio, ya sabes)

Por cierto, voy a añadir a la prueba técnica que no se puede usar GPT (salvo que lo hayas desarrollador tú, claro)

(*) con 40 también

Thanks for reading Javi Santana! Subscribe for free to receive new posts and support my work.

A la segunda todo sale bien: el end-to-end developer

Todo el santo día de Dios hablamos de desarrolladores frontend, backend, full stack, también hay perfiles de sistemas, devops, QA, managers etc etc a diario. Hay ofertas de todos esos puestos para parar un tren de mercancías.

Todos esos perfiles comparten algo, clasifican a la gente en vertical, es decir, te colocan según qué capacidades tiene una persona dentro de un equipo. Y este tipo de clasificación está muy bien para determinado tipo de empresa, es fácil buscar, medir conocimientos y cuantificar en cierto modo la labor humana. Pero cuando hablamos de una empresa en fase inicial lo que realmente necesitas son “end-to-end developers”

Que dices chaval y qué haces inventándote nombres. Déjame que te explique. Un end-to-end es un desarrollador que trabaja en horizontal, es decir, coge un problema y lo lleva de principio a fin sin importar las barreras entre departamentos o equipos. Son personas con una carencia: no ven las fronteras del departamento, equipo, feature, incluso empresa. Solo ven el final del túnel. Son unos tarados.

Que usas un proyecto open source que te está matando por un bug? no pasa nada, hace el fix, manda la PR, persigue el problema para que se mezcle, actualiza dependencias, habla con las 3 personas de los equipos implicados, sin importarle los galones y lo arregla.

No les importa comer lo que otros llaman mierda, si hay que arreglar un bug, se arregla, si hay que hablar con un cliente, se habla. Hay que aprender algo, se aprende. Tienes que hacer una reunión de seguimiento todos los días para que algo salga? la pone y no ceja hasta que la cosa ha salido como dios manda. Se tienen que convertir en backend? lo hacen. Toca hacer soporte? se hace y con alegría.

Tienen además una peculiaridad, suelen rescatar gente por el camino. Mientras van saliendo del túnel son capaces de hablar con quien tengan que hablar para quitar el obstáculo. Hacen grupo mientras buscan la salida. Si hay que cavar para crear la salida del túnel, exacto, son los primeros en coger el pico y liarse.

Se les conoce también porque los listos se fijan en ellos, forman equipo y todos salen por la puerta de los ganadores. Sus managers los quieren como si fuesen sus hijos. Los tontos les critican y tratan de ponerles piedras en el camino.

Pero espera, no solo por eso, también puedes identificarles porque están valorados, su opinión se respeta, no tienen problema en sacar a relucir las mokitas, son los que cuando te ponen una reunión y te dicen “mira, en esto la estás cagando”, lo siguiente que haces es pedir perdón y te vas a solucionarlo. Suelen, además, ser los que cuando hay despidos masivos, ni les afectan (o si les afectan, les vuelven a llamar). Ni les importa más allá de lo que les afecte a sus compañeros.

Valen para todas las fases de la empresa? son esos famosos 10x? no no, ni por el forro amigo, nada tiene que ver con capacidad técnica, ni velocidad. De hecho al primer asalto en un neo-corporate caen por KO.

El problema? No hay forma de identificar a esta gente en una entrevista ni puedes hacer una prueba técnica que te marque el tick de “end-to-end developer”. Por eso buscamos backend/frontend developers y veces tenemos la suerte de que aparece uno de estos ejemplares (que normalmente identificas los 2 primeros días de trabajo)

Cuando arranques tu empresa, no busques un CTO, no busques un full stack, busca un end to end. He aprendido más de estos seres de luz que de todos los podcast de naval juntos.

Thanks for reading Javi Santana! Subscribe for free to receive new posts and support my work.

Customer Success

Llevo unos meses liderando lo que llamamos en Tinybird un equipo de “Customer Success”. Antes se llamaba de otra forma que ni recuerdo.

Cambié el nombre porque me parecía que lo que realmente hacíamos era eso, ayudar a los clientes a salir del paso, a quitar la roca del camino, a llegar a puerto, a luchar contra el enemigo comun, a poner en producción vaya. Siendo nuestro producto algo pensado para desarrolladores no veo otra forma más clara de tener “success” que esa.

Resulta que, después de unos meses de ver a la gente que llegaba nueva a la empresa totalmente contrariada, tuve que crear una presentación para explicar quién leches éramos, qué hacíamos y el porqué en vez de ser comerciales, somos un equipo de ingeniería.

Ahora, leyendo sobre el tema (1) y escuchando los sermones (2) de la gente que sabe del sector, veo que la métrica habitual de “Customer success” es incremendar la facturación. Nunca en mi cabeza pondría una métrica que no estuviese alineada con un cliente, pero es que resulta que esta métrica define prácticamente lo que hace el departamento. Y seguramente sea así por una muy buena razón que desconozco, imagino que a escala simplifica todo.

Así que, muy a mi pesar -ya me había costumbrado- cambiaré el nombre de nuevo, aunque sigamos haciendo lo mismo. Eso antes de poner un objetivo absurdo.

Lo complicado de esto es que el equipo no encaja en ninguna definición existente en el panorama startup. Así que o bien busco lo más parecido y me hago otra presentación para explicarlo o pongo una métrica de facturación o le pongo un nombre que genere GPT-3 en base a la descripción.

Puedo comprender el porqué las empresas tratan de poner nombres standard a departamentos, igual que se lo ponemos a los roles, pero la realidad es que tal vez estemos ajustando la empresa a los nombres y no los nombres y funciones a la realidad de la empresa y el producto. Por eso cuando veo que alguien define una oferta de trabajo por lo que hay que hacer y no por el título, incluso si la descripción es vaga, me da sensación de “esta gente sabe lo que se hace”.

(1) La wikipedia acierta bastante con la definición, la verdad.

(2) Me refiero a la primera acepción “Discurso cristiano u oración evangélica que predica el sacerdote ante los fieles para la enseñanza de la buena doctrina.”. La “buena doctrina”, ya sabes.

Alma

En el año 1999 un fulano se presentó al rally París-Dakar con un coche perdedor. El Dakar es un rally que dura unas dos semanas, pasa por caminos de cabras, dunas y otras tantas sendas donde un coche de calle no avanzaría ni un palmo.

Era perdedor porque no era 4x4, así que pasar las zonas de dunas era complicado y no tenía un equipo oficial detrás para reparar el coche después de cada etapa, ni que decir tiene que tampoco para meter la gallina en diseño y desarrollo del coche previo al rally. Hizo todo lo contrario de lo que ponía en el libro de los ganadores.

Pero lo ganó. El coche no era 4x4 pero gracias a eso era más ligero, más sencillo de reparar y tenía sistemas para hinchar y deshinchar las ruedas sin bajarse del coche que le permitían pasar las dunas fácilmente (a menos presión en las ruedas, menos te hundes en la arena). Había aprovechado el reglamento al máximo pensado para las grandes marcas que llevaban coches 4x4, los que el sentido común decía que todo el mundo llevaría.

Era un coche con alma. Y no porque ganara, si no porque el menda llevaba 10 años compitiendo con este tipo de coches (y otros 20 en otras categorías, como F1), que él mismo diseñaba. Creía en su idea y punto.

Schlesser ganó pero hay mucha gente que se cree sus ideas y nunca “gana”. Da igual, no se trata de ganar, esto no es David contra Goliat (aunque cuando lo son es aún más placenetero)

A lo largo de los años, sin realmente buscarlo mucho, me he dado cuenta que me han dejado de gustar las cosas que no tienen “alma”. Como decía Bukowski, “no tengo tiempo para cosas sin alma”. No tenía claro qué era, pero había llegado un punto que prácticamente rechazaba de forma inconsciente algo si era “mainstream”. Necesito el toque personal para que algo me resulte interesante.

Para que nos entendamos, es básicamente lo que está en el polo opuesto de “corporativo”.

Así que en vez de ver series en Netflix termino viendo videos de un fulano con 200 suscriptores grabando videos desde su granja, termino comprando a tiendas solo porque los que lo regentan son unos personajes, leo biografías de gente que hicieron las cosas de otra forma, conduzco un coche que nadie en sus cabales conduciría más allá de 100 kilómetros y uso tecnología que nació desde una necesidad y una convicción, no como forma de conseguir con objetivo.

Todo tiene un precio, habitualmente el fulano con 200 suscriptores postea 1 vez cada 3 meses en vez de tener un episodio semanal, las tiendas son más caras y los coches se rompen más, y te miran raro cuando dices que no usas kubernetes, pero la sensación de estar usando algo hecho con convicción vale seguramente mucho más que todo eso.

Lamentablemente, bueno, no, afortunadamente, las cosas con alma no suelen escalar y suelen perder el alma cuando se hacen por dinero. Así que hay que aprovecharlas mientras duren.