Mañana hará dos meses que dejé CARTO. Dejar un trabajo nunca es fácil, ya lo sabes, pero en este caso ha sido especialmente complicado, han sido muchos años y mucha gente, así que después de unos meses dándole más vueltas de las debidas decidí irme.
Estos meses de retiro dan para pensar muchas cosas, entre ellas echar la vista atrás y darte cuenta de los más de 6 años han sido tan duros como gratificantes, que la decisión que has tomado no podía haber sido más acertada y que lo mejor de CARTO sigue conmigo a pesar de no estar en el día a día.
Es difícil resumir todos estos años en un post, traté de hacerlo los días antes de irme y decidí quedarme con el buen sabor de boca más que con detalles o anécdotas del pasado. Creo que el mejor resumen es el correo que envié a toda la gente que trabajaba en CARTO unas semanas antes de irme:
…
Hello everybody
You know I hate bullshit, I hate decorating things just for the sake of making them look better (and not being truly) so please, read this email with that mindset. Here it goes.
I’m leaving CARTO.
The question in your mind is probably “but why?”, let me explain. It’s been more than 6 awesome years working here and I feel tired. Because of that (and some other not so important reasons, of course) I know for sure that I will not have the kick that my position requires to take the team where it needs to get.
Next thing I’d like to say, and the most important one in this email, is thank you. Really. Having the opportunity to work here, seeing how CARTO grew from 6 guys to a big (well, medium size) company, becoming the tech leader and on top of that, sharing my time with a group of outstanding people (that happened to be working for the same company, lucky me) is something I’ll be grateful for, for the rest of my life.
New and good things are to come. I’m leaving and that gives the awesome [technical] team some more space to make their own decisions. Keep this in mind, this is the best team I’ve ever seen so I have no doubt that this company will succeed, so “look to the future and leave the past behind”. I’ll be looking to you guys (sorry about the extra pressure)
I’d like to also apologize for those moments where I didn’t act in a professional enough way, I was too rude or didn’t treat you with the right amount of human touch.
So thank you again, I’ll be around for some more weeks, happy to talk to you whenever you like.
VAMOS!
…
“Y ahora qué vas a hacer?” es la pregunta que todo el mundo me hace. Pues no lo he pensado, ni quiero, así que cuando vea algo que realmente me apetece realmente hacer, lo sabré :).
De nuevo, gracias a todo el mundo con el que he trabajado, me ha dado una oportunidad o me ha dado un collejón cuando tocaba, para bien o para mal estoy aquí gracias a vosotros.
I was checking my notes and I found this email I sent to my team some months ago when we decided to set up a dedicated team for tech “research”. You probably know that moment in which every medium-size startup acknowledges the lack of “innovation” but it’s impossible to articulate a good process to make it happen within the tech team because of the high workload. In order to get old times back and recover the magic of a 5 people team you decide to create a “research team”.
I consider these ones the backbone of a technology research team within a company. And this is a personal opinion and the way I like to do things so don’t get them as a dogma.
(I modified it a little bit to remove some not really important details about CARTO)
…
Hello team,
Investing time on important things is always a good choice. It’s like investing in your own health, you are not going to regret it. It does pay off after some time tho. It’s easy to get distracted by short-term urgent stuff (MRR driven most of the times)
People need space. That means people need time to think, make decisions and fail. You can’t pretend people to generate value if they don’t have they own opinions/ideas.
Moving data here and there is not going to push CARTO to the sky. We need to do very well at something. That something is hard by nature and hard things require time.
Long-term rather than short-term: we are too used to thinking short term, thinking long-term requires willpower and knowledge. It’s easy to think “with this shortcut we could get to production early” or “I don’t see short-term results for this and I’m going to look like a failure”.
Focus on one thing at a time. It should be the most important thing and we should own it: you shouldn’t be afraid of touching anything there because of the lack of ownership.
Everything should be though to end in production. Not only that, it should push production forward so it helps to get rid of deprecated technology, renews the internals and keeps the platform healthy.
Cheers.
Iba por el pasillo de la facultad, donde estaban los despachos de los profesores, echando un ojo a los típicas hojas pegadas en las puertas con propuestas de proyectos fin de carrera. Me llamaron la atención dos, uno para facilitar la movilidad a gente que usa silla de ruedas y otro sobre un tema agrícola. Después de hablar con los dos profesores me decanté por el agrícola, después de todo años atrás había ido con mi padre a echarle un cable en las tareas del campo, así que me tocaba un poco la patata, al final las cosas que te motivan las haces porque te tocan la fibra y no el bolsillo. Y así empezó agroguia un producto que con tecnología resolvía un problema que muchos agricultores tenían: poder medir distancias en el campo con sus tractores.
Tuve la suerte de que ese profesor, Jaime Gomez Gil, era además de agricultor e ingeniero, un tío brillante, con la cabeza sobre los hombros y con pasión por el tema. Mes tras mes trabajamos en el prototipo, de mientras trabajaba con una beca de la friolera de 400 euracos al mes en TV Castilla y León poniendo cables. Cuando terminamos el proyecto resultó no ser tan malo (algo cutre sí), decidí venderlo, total ¿por qué no? otros ponian a la venta cosas peores. Y lo hice, con unos 600€ (tuve que romper el cerdito) de inversión compramos lo necesario y a la calle a vender! creo que mejor que te lo cuente es que veas el video que creamos, creo que resume, en el técnico y emocional, lo que es agroguía.
No voy a contar de nuevo la historia de agroguía, la he contado en charlas, hemos salido en la tele, periódicos (internacionales también), blogposts, puedes buscarlas si estás interesado. Como detalle curioso cuando empecé a trabajar para Vizzuality (la empresa de donde salió CARTO) la gente me conocía por “el fulano de los tractores” o “el de las provincias” (algún día alguien me contará el porqué algunos lo usan en tono despectivo).
Este verano, después de pasar unos últimos años donde apenas habíamos dedicado tiempo y por tanto el negocio había bajado, decidimos transferir el negocio a nuestros partners y amigos Smartrural que sí pueden hacerse cargo y explotar el producto. Así que el 3 de Julio firmé lo que es el punto y aparte de un negocio de más de 12 años, significaba para mi deshacerme de algo que parí, he visto crecer y que ha sido mucho más que un producto.
Es difícil sacar conclusiones de tantos años pero en resumen estoy bastante contento aunque creo que contento no es exactamente la palabra, creo que es satisfecho.
Creamos una empresa en la que nos gustaba trabajar. No burocracia, nada forzado, trabajamos pocas horas al día. Por aquel entonces me leí “getting real” de 37signals (libro que deberías leerte) y disfruté cada página viendo como esta gente describía, de forma muy simple, lo que yo pensaba (aunque ellos lo han ejecutado mucho mejor). No molabamos nada, no usabamos tecnología puntera, pero daba igual.
Con la perspectiva de los años agroguía me parece un productazo y estoy muy orgulloso de la gestión de producto. Siempre muy enfocado, ha hecho y hace una sola cosa muy bien, hemos dicho que no a muchas cosas miles de veces. Técnicamente no es nada del otro mundo, son unas pocas miles de líneas de código, con algunos ficheros que no se han tocado en años y que ha sobrevivido durante 12 años sin despinarse pasando por varias generaciones de dispositivos móviles. Esto ahora lo llaman legacy, yo prefiero llamarlo “working code”.
Y no solo eso, creamos un negocio. No pensabamos en startups, queríamos ganar dinero resolviendo un problema que existía resolver un problema que resultó hacernos ganar dinero. Si muchas startups empezaran así ahora creo que nos iría mucho mejor, hay muchísimos problemas que resolver y por lo cuales la gente está dispuesta a pagar. Sin tener ni idea descubrimos lo que ahora llaman inbound, outbound, lead generation, SEO, venta online… y todo esto haciendo las cosas diferentes, sin mirar como lo hacían los demás, a pecho palomo (menudos inconscientes). En esa época escribía bastante en mi antiguo blog, puedes echar un vistazo a los posts. Aun recuerdo una conferencia donde el director comercial de una gran empresa de sistemas de agricultura de precisión (que por cierto nos han copiado varias veces) se reía de mi porque le dije que solo vendíamos por internet desde un pueblo de 800 habitantes en medio de la meseta.
No creamos un imperio, ni cambiamos el mundo, tampoco vendimos lo que no teníamos pero fuimos claros, hablamos con palabras que todo el mundo podía entender, hicimos la vida de algunas personas mejor, nos divertimos y aprendimos. Podría haber sido mucho más, el sector agrícola mueve muchísimo dinero, y créeme, necesitan tecnología, pero fue lo que quisimos que fuese.
Buena suerte amigos.
Hace unos meses escribía sobre cómo era la experiencia de hacer crecer un equipo en una startup y hablaba un poco sobre el tema del hiring. Si estás leyendo esto seguramente habrás escuchado en más de una ocasión “es imposible encontrar buenos técnicos”, “los buenos están todos pillados”, “hay una burbuja y todo el mundo quiere cobrar demasiado” o “tardo meses en contratar a alguien”.
Ok, es verdad, el mercado está mal, por varias razones:
Dicho esto, contratar no es imposible, símplemente es difícil, como vender tu producto, pero mientras la mayoría de startups tienen un proceso de venta o desarrollo definido (bueno, ejem) no lo tienen para el hiring. Es curioso, el asset más importante de una empresa es la gente, y por tópico que suene, es una realidad como la catedral de Burgos.
Dejadme que lo repita de nuevo, la gente en una empresa es lo más importante, así que si tienes 200 mil millones de buenas prácticas en el código, 5 herramientas de lead generation antes que alguien de recursos humanos cuidando a tu gente (y cuidar a la gente no es solo que les llegue la nómina) es que lo estás haciendo lo siguiente a mal.
Ahora déjame decirte algunas cosas que he visto durante estos últimos 6 años en CARTO relacionados con el hiring.
Primero, no estás apuntando a gente dentro de la zona central de la campana de Gauss, estás buscando en los laterales. Y para contratar a esa gente no valen cuestionarios típicos, preguntas manidas o procesos normales. No eres el empresote que contrata a miles de desarrolladores y que te permite jugar con la estadística y en donde una persona significa una mejora en un equipo pero realmente tiene poco impacto global. Quieres contratar a gente muy buena, con chispa, que impacte en tu empresa.
Como cuando vendes un producto quieres que todo sea inbound (esto es, que vengan a comprarte) o por referal (que te recomienden). Y esto se consigue muy fácil, teniendo un buen producto. Dicho de otra forma, tienes que tener una empresa que guste y funcione bien. Esto atrae a gente buena y la gente buena quiere trabajar con gente mejor aún. En CARTO la mayoría de hiring inicial se hizo tirando de contactos, de gente con la que queríamos trabajar.
No sólo se vende teniendo un buen producto, tienes que saber ponerte donde toca para que te vean y además diferenciarte. Necesitas tener una estrategia para posicionar el hiring.
Tener una estrategia no es poner 200 tweets o 15 mensajes en linkedin con “BUSCAMOS NODEJS DEVELOPER”. No. Es algo que se construye con los años, es buscar los sitios donde están las personas con las que tienes feeling, es tener un mensaje consistente durante los años, construir una red de gente alrededor de tu empresa, etc. Y ojo, lo del feeling parece algo secundario en el mundo técnico, pero en mi experiencia los equipos que funcionan mejor son en los que hay “feeling”. Te dirás, este gilipollas me dice “feeling” y se queda tan ancho, qué tal si lo describes. No puedo, seguramente me falte experiencia para materializar eso, pero google se hizo la misma pregunta y sacaron algunos resultados
En CARTO la estrategia siempre ha sido un bastante agresiva, nada de gilipolleces de frameworks del momento, nada de recetitas. Nosotros hacemos tecnología y queremos a gente que quiera hacer tecnología y no perder el tiempo siendo el mago de la tecnología del momento o que sepas responder a las preguntas de entrevista de google como el mejor del mundo.
Cuando tu gente vaya a dar charlas tiene que tener claro como orientar el mensaje, cuando se pongan ofertas tienen que seguir la misma linea, las entrevistas, a qué eventos vas, qué patrocinas, qué tuiteas, todo. Y esto no se hace con una documento interno llamado “hiring guidelines” (que no estaría de más)
Pero llega un momento que no vale con tener inbound, tienes que salir a buscar a la gente, bien porque necesites mucha gente o porque tus contactos se te han acabado. Y aquí tienes que tener un recruiter. Sabemos que el mercado de los recruiters está mal, pero está mal porque hay gente que no son profesionales, así que contrata gente profesional, que sepa establecer la conversación con un desarrollador (no un puto correo automático que va a hacer lo contrario a lo que esperas). En CARTO hubo un salto de un orden de magnitud en la calidad del proceso gracias a la llegada de Justyna, y no solo hablo de la calidad de la gente, hablo de la rapidez del proceso, salarios, seguimiento, etc… que da para otros cuantos posts y que en parte están resumidos en este blog post de Félix López sobre el proceso de hiring
El outbound es cosa de todos, de nuevo, si la gente no está preocupada con quién va a trabajar es que tienes un problema. Personalmente entrevisto a todas las personas que llegan a CARTO, pero la decisión no es mía, es del equipo que va a trabajar con él y son ellos los que tienen que sentir ese feeling.
Además de todo esto, tienes que ser un poco diferente, algunas de las cosas que yo considero importantes (que tampoco son novedosas, pero funcionan)
Y sobre todo, contrata buena gente por encima de gente técnicamente buena.
Hacer crecer un equipo técnico parece fácil a priori, hay unos 200 millones de blogpost sobre el tema y en general los desarrolladores tenemos tendencia a ser optimistas, en esto también. Estoy seguro que comparado con hacer crecer un equipo de ventas o de marketing es coser y cantar.
Sin embargo, a pesar de haber leído esos blogposts, libros y demás, hay algunas cosas que hemos aprendido en CARTO que puede que te sean útiles si piensas hacer crecer un equipo de 4 adolescentes a un equipo que funciona como un tiro.
Un equipo es algo así como una persona, pasa por la fase de crío, pasa a ser un adolescente, después a tener pareja e hijos, posiblemente pase por una etapa de madurez, jubilación y muera. En CARTO se podría decir que acabamos de tener hijos.
Aquí os dejo cada una de las fases por las que hemos ido pasando, con algunos consejos en forma de retales.
Aprender inglés cuando eres un niño es coser y cantar, cuando tienes 40 es un infierno, ya no estás para gilipolleces y tienes un montón de cosas que la sociedad te dice que tienes que hacer. Así que más vale que lo fundamental quede claro cuando sois 4, con 40 personas en un equipo no va a ser tan fácil. Estas son las cosas que yo haría si empezase desde cero:
Establece los patrones básicos, aunque te parezca matar moscas a cañonazos: control de versiones, testing, integración continua, deploy automático, trabajo en ramas. El test de Joel es un buen punto de partida (aunque es un poco killer). En serio, montar esto y acostumbrarse es 1 semana.
Aprende a trabajar con proyectos de otros. Haz que sea una práctica habitual el usarlos, valorarlos y entenderlos. Comerciales u open source.
En equipos de este tipo el KPI suele ser la velocidad. La velocidad en los equipos de desarrollo es la peor métrica posible. Chaval, un equipo de 4, apenas empezando a desarrollar el producto, es rápido como el mismísimo diablo aunque pienses que eres lento (y cuando crezcas lo entenderás). La mala hierba crece muy rápido en la tierra bien abonada. Así que preocúpate de hacer que las cosas que haces son las correctas y haz que todo el mundo sea MUY consciente de ello. Tu gente debe ser crítica al extremo, nada de chiquilladas de “esto mola, lo metemos en un fin de semana”. De otra forma estarás cavando tu tumba a ritmo de agile.
Es tan fácil añadir una gilipollez inútil a un producto que si no entrenas a tu gente para tener alergia vas a pasarlas muy putas. Esto parece que es cosa de Product managers (sí, esto te suena a consultora y tú no los necesitas, tranquilo majete en tu sillón) pero, tío, tienes gente que es capaz de entender conceptos complejísimos, enseñarles a parar y pensar no es tan difícil. Lectura obligada aquí el post del amigo txarly sobre “como lanzar un proyecto sin una línea de código”
En esta etapa el ser un pequeño dictador es posible que sea la mejor opción. Si juntas a 4 desarrolladores en una habitación se van a poner a discutir sobre espacios versus tabs (no importa lo senior que sean, hay gente que no se da cuenta que usar tabuladores es de otro siglo). Alguien que tome las directrices, buenas o malas es mejor siempre tener una directriz a no tenerla. Y más te vale tener directrices en todos los temas importantes.
Una de esas directrices es la gestión de proyectos. Usa kanban, waterfall, agile o lo que te salga de las narices, pero usa una cosa clara y que todo el mundo sepa cómo lo haces.
Si eres ese pequeño dictador, machaca todo el rato con las cosas importantes (entre otras cosas porque así te ayuda a aclarar las cosas importantes) hasta que la gente lo tenga interiorizado. Ese es el germen de la cultura que se diluirá poco a poco cuando vayas creciendo pero que servirá como base.
Recuerda, ahora es cuando casi todo cuesta casi nada, hazlo aunque parezca una gilipollez que no necesitas.
Las cosas van como un tiro, sois los putos amos y decides hacer crecer el equipo unas 10-15 personas. Todo es felicidad, estás en la adolescencia, qué esperas?
Cosas que van a pasar:
Además la empresa ha crecido un poco, hay ya alguien vendiendo, parece que hay una persona escribiendo blogposts y el fundador ahora ya firma como CEO y no como “developer and coffee addict” en twitter. CARTO es un poco especial, fuimos galardonados con el premio de “la empresa más disfuncional en ventas que nunca habían visto”
Si te van a meter gallina, antes de anunciar empieza a contratar gente técnica. Lo creáis o no hay gente que se mueve casi solo por dinero. Aún no estás en la fase de querer ese tipo de gente, te faltan otros 30 ó 40 empleados aún.
Aquí necesitas ya un documento y fase de onboarding, cada persona nueva tiene que aprender, así que invierte en que sepan dónde poner los pies los primeros días.
Enseña a tu equipo técnico a tener un par de bemoles. Fundamental para tratar con gente que su trabajo es convencer a otros. Importante también para saber tragarse su orgullo.
Si has hecho crecer la empresa alrededor del producto (del software vaya) prepárate porque en general la gente de ventas, marketing y demás no tienen los procesos tan claros. Y si los tienen van a ser muy diferentes a los tuyos, así que más vale aclararlos porque vas a necesitar ir bien engranaditos. La diferencia entre acabado vs cerrado muchas veces es toda esa gente. Ellos no van a querer usar los issues the github así que haz que tengan un proceso, fuera o dentro, que encaje con el tuyo.
Sabes lo que es cool y hace que un desarrollador esté contento: sentir que te ganas cada céntimo que te pagan haciendo cosas que sean útiles. Sea node o java. Las gilipolleces de la mesa de ping-pong, offsites y demás están bien pero si no hay una base profesional donde se sientan cómodos son adornos.
Gestión de la frustración. Sí, de nuevo:
Sensación de ir despacio es brutal, piensas que eres una tortuga. No lo eres pero ahora todo necesita más trabajo, aprende a lidiar con ello.
La gente se empieza a sentir sola: empieza a forzar 1 to 1. En mi caso no me gustan los 1 to 1, me gusta mucho más pillar por banda al fulano en cuestión y hablar lo que tenga en ese momento en la cabeza. Esto último es cómodo pero un error garrafal, tienes que mantener un flujo continuo donde hablas no solo del día a día si no de lo que va a venir y de lo que piensas. Esto pasa a ser crítico con más de 20 personas.
No hay tiempo para hacer las cosas bien. Nunca hay tiempo para eso, el tiempo se gana, así que “pick your battles” y luchalos a muerte. Todo no puede estar perfecto, mejor que sea así, embrace lo cutre para lo que tenga que ser cutre.
- Hay cosas que, símplemente, no se pueden hacer porque no hay tiempo. Los programadores piensan (pensamos?) que se puede hacer todo lo importante. Esto duele mucho.
Evita cualquier cosa en la que no haya un control sobre la creación. Por ejemplo, la típica de “hacemos un wiki”. Los wikis son la peste si 1) no hay un índice claro o 2) no hay alguien gestionandolos. Miles de google docs, miles de ficheros en dropbox, etc, etc, sabes de lo que hablo.
Un tema peliagudo, el firing (del hiring ya hay mucho escrito). Hay 3 clases de fires 1) la persona que no da palo, 2) la que no encaja 3) cuando no hay dinero o algo acaba. La 1 es muy raro a no ser que hayas contratado a lo bruto (como por ejemplo cuando te dan unos millones), pero tú eres listo, no vas a contratar a 10 personas en un mes. La 3 es cuando las cosas van mal, la 2 es la jodida: contratas a alguien listo, capaz, pero no sabes el porqué no funciona como debería. Todos nos las damos mucho de majetes y liberales con la mobilidad laboral, pero el despido sigue siendo de las cosas más desgradables y no deseadas, así que hazla cuanto antes y sé sincero. En esta etapa ya vas a tener (o habrás tenido) algún despido.
Este cambio pasa cuando eres más de 20, una sola persona no puede gestionar todo el equipo técnico (ni a nivel de gestión de proyectos ni al técnico) así que la cosa se complica: hay que hacer equipos y poner “jefes”. Lo camuflarás con títulos gilipollescos tipo “whatever lead”, “blabla manager” pero cuando alguien decide el sueldo de otro se acabaron las tonterías.
Ahora es el momento de contratar a los que vienen por dinero (y por el proyecto, claro), gente que sabe lo que hace, que no se anda con pijadas, que tienen hijos que mantener, que si eres gilipollas te lo plantan en la cara sin que te des cuenta. Esa gente es la que te hace crecer.
Aquí tendrás que elegir entre, generalmente, dos tipos de estructura: vertical u horizontal, esto es, por área (frontend, backend) o por unidad de trabajo o producto. Spotify tiene unos videos bastante famosos. Yo me descojono cuando los veo porque es como las películas, las partes aburridas de las vidas de los protagonistas nunca salen, son una mentira, igual que esos videos, pero para hacerte una idea vale.
En este punto los problemas técnicos principales son básicamente no técnicos:
Los problemas técnicos principales son:
La gente que se va es como los accidentes de tráfico: nunca te pasa a ti. Hasta que te pasa. Así que igual que te pones el cinturón de seguridad, compras coches seguros (esto es, no italianos) tienes que prepararte para cuando alguien se vaya. La estrategia perfecta sería tener 1 persona extra por equipo pero nunca funciona, más tienes, más haces y más tienes que mantener, así que mantén siempre a la gente con la que te gustaría trabajar cerca. Hay muchas formas de hacer esto, pero estas ya para otro post.
El punto crítico aquí es tener el músculo de la práctica bien fuerte, de esta forma las cosas, aunque parezca un caos, siempre irán razonablemente bien (teniendo en cuenta la velocidad de estas cosas). Ese músculo se empieza a trabajar cuando eres 3 pericos metidos en una habitación con mesas de ikea.
Seguro que me dejo en el tintero 200 mil cosas, lo único que puedo decir es: si estás pasando por un proceso así, ánimo.