Tecnología Informal

Nadie se estaba divirtiendo tanto como yo programándolo y nada, no podés competir con eso.

Eran todos unos cracks. Y yo decía, ¿qué es esto? No lo puedo creer. Miraba a cada uno y decía, necesito estar sentado con esta gente 24-7 aprendiendo, ¿viste? Y esa lamparita nunca se me apagó.

Como empleado, como consultor, sos un inversor de alguna manera en una startup, pero estás invirtiéndote a vos mismo entero y podés elegir una.

Yo soy muy fan del open source, pero no del comunismo.

---

Entrevista a Nicolás Bevacqua – Ramp, talento y open source

Bienvenidos a otro episodio de entrevista de Tecnología Informal. Hoy tenemos un invitado bastante especial, alguien que conozco hace ya un par de años: Nicolás Bevacqua, que trabaja en una de las empresas más importantes culturalmente en el ecosistema tech. Muy famosa en Estados Unidos, en Argentina no tiene tanta presencia, pero seguro vamos a hablar de todo eso.

Yo trabajaba en fintech y es imposible trabajar en fintech y no saber de Ramp, por la reputación que tiene. Particularmente, tiene dos grandes reputaciones: haber crecido rápido y tener el mejor talento del ecosistema. Por ahí le gana Palantir, no sé. Vamos a hablar de eso en algún momento, pero tiene mucha reputación.

Le contaba a Nicolás justo ayer cómo llegué a conocerlo. Estaba hablando en Silver.dev y dije: "No conozco en Argentina a alguien que haya llegado a ser manager desde Argentina, sin haber vivido en Estados Unidos". Y me acuerdo que haciendo sourcing veo el perfil de Nicolás y ya había hecho eso. Dije, la puta madre, me equivoqué. Digo algo y alguien ya me demuestra que estoy equivocado. Me quedó esa idea de Nicolás y, poco tiempo después, terminamos conectando y colaborando un poco. Pero yo no lo ubicaba para nada antes, no sabía quién era. Así nos conocimos y fuimos hablando cada tanto.

Así que te paso el micrófono para que te hagas tu auto-intro.

---

Carrera y primeros pasos

—Dale. Sí, soy Nico. Por dónde empezar, qué sé yo. La verdad, si me preguntás cómo arranqué, fue algo medio informal mi carrera, porque arranqué en la secundaria haciendo jueguitos y demás. Un día, me acuerdo patente, un amigo me dice: "Che, vos sabés que con C# podés trabajar, ¿no? No es solo hacer juegos open source". Y yo como que no lo podía creer.

Eventualmente entré en la Municipalidad de Morón, a trabajar en el departamento de informática. Fueron unos hermosos tres meses. De ahí me fui metiendo en consultoría y demás. Eventualmente, me cansé de lo que es el mercado argentino, la formalidad de la consultoría. A veces, el estilo de empresas que había acá era como que los managers estaban muy desconectados de la tecnología en sí. Era mucho más formalizado el rol de manager, como algo específico que no tenía nada que ver con ser un tecnólogo.

Dije, ¿para qué voy a trabajar para una consultora cuando puedo trabajar directamente para el exterior? No tenía la más pálida idea de si eso existía o no, pero renuncié y me puse a buscar startups y cosas por el estilo. Terminé encontrando algunas páginas, en ese momento era AngelList, que tenía publicaciones de startups y era bastante popular. Encontré un par de laburos de esa manera y me encantó. Nunca más quise volver a algo que no fuera de producto después de eso.

Además, era otro tipo de gente de la que podías aprender un montonazo comparado con lo que venía encontrando acá. En general, mi experiencia es bastante descontracturada, ¿viste? No me funcionó la facultad, por ejemplo, tampoco. Y bueno, fui encontrando el camino de esa manera.

---

Ramp: actualidad y management

—Vamos a hacer una cronología de tu carrera, porque tengo preguntas. Pero es importante dar el pantallazo de qué hacés ahora. En LinkedIn tenés un G2 UI/UX, es un puesto de management, nivel director. ¿Cuánta gente tenés a cargo? ¿Qué estás haciendo ahora?

—Te cuento desde el principio. Entré a Ramp, éramos 100 personas en total en la empresa hace 4 años. Ramp tiene 6 más o menos. Entré como IC (individual contributor) en el equipo de frontend y armé toda la parte del design system. Por unos meses no conseguimos a nadie, después creció mucho el equipo y terminé haciéndome manager. Yo no quería, si querés hablamos de eso también. Fue un aprendizaje definitivamente.

Ahora el equipo que tengo yo son unas 70 personas más o menos, mayoritariamente frontend y mobile, hay una partecita de backend. En algún momento manejé el equipo de talento, fue muy random, pero fueron unos meses medio caóticos. Ahora es eso: todo el frontend y un par de equipos puntuales de producto de backend.

—Grande. Mucha responsabilidad.

—Sí.

---

Patrones de carrera: sector público y juegos

—Hay un patrón interesante que tenés vos que tiene mucho que ver con nuestra generación. Hay un paso por instituciones públicas, ¿no? En LinkedIn tenés el BSRA, ¿es?

—No, estuve en la Municipalidad de Morón y en algún momento, por medio de una consultora, en el Ministerio de Hacienda de CABA. También fue una experiencia maravillosa.

—¿Por qué?

—Porque te muestra algo que no ves en ningún otro lado. Es todo lo contrario a lo que vos pensás que está bien. En términos de proceso, de burocracia, llevada a un extremo inimaginable. Uno lo imagina solo de leerlo, pero no es algo que vas a experimentar necesariamente, si tenés un poco de suerte.

—Es un patrón que veo en Argentina: mucha gente pasó por lugares públicos en algún momento. Es algo raro, que no lo puedo explicar del todo bien. Y también está el patrón de la gente que hizo juegos de algún tipo, o jugó hasta competitivamente. Damián Catanzaro estuvo en el podcast, por ejemplo. Le encantaba jugar, hacía League of Legends, hizo su propio servidor de Argentum Online. En Estados Unidos es muy común que esta es la generación del Minecraft. Es una gran señal que alguien haya hecho servidores de Minecraft a los 15 años y los haya mantenido. Y vos también, ¿no? Trabajaste con juegos.

—De hecho, en Ramp hay bastante gente que contratamos de ese mundo del Minecraft, que la verdad es impresionante. Yo, bueno, me delatan un poco los años, pero armé con unos amigos un servidor de Ultima Online, que como un predecesor del Minecraft es también un RPG. Era esto que te decía de C# open source, que podías agarrar un server que usaba el cliente oficial de Ultima Online y vos manejabas el servidor. Teníamos más o menos 150 personas online concurrentes. Era bastante lindo el server para lo que era la comunidad en ese momento. Es una nada, pero estaban los 150 en el mismo lugar muchas veces y se armaban cosas divertidas.

Eso era una experiencia interesante porque te enseñaba lo que vos quisieras meterte. Tenías la capa de paquetes de networking hasta, no sé, si querías agarrar un archivo de cómo funciona el dragón y cuántas bolas de fuego tira, lo editabas en un Notepad y te lo compilaba el CLI de RunUO. Es una forma de aprender programación que no existe porque es demasiado iterativa. Aprendés en el nivel que necesites o que estés capacitado.

Ahí terminé contribuyendo, básicamente espiando paquetes del servidor original, hice reverse engineering de cómo funcionaba un sistema nuevo y lo contribuí back a RunUO mandando un mail, obviamente. Esa fue mi iniciación en open source.

—Ese es otro patrón que uso yo de green flag cuando busco gente: la gente que hace reverse engineering tiene algo. Es gente con una curiosidad nata por lo que hace. ¿Qué estuviste haciendo? "No, reverse engineering de la API de Santander". ¿Por qué? Te tiene que gustar mucho lo que estás haciendo para hacer estas cosas.

—Sí, sí, literalmente. Hay un meme que comparten mucho en X que es "no podés competir con alguien que se está divirtiendo". Y para mí era un poco esto, ¿viste? Con el servidor de Ultima Online nadie se estaba divirtiendo tanto como yo programándolo. Y nada, no podés competir con eso.

Imaginate que, otro ejemplo, hacían torneos de jugador contra jugador en el server este. Los managers del server movían a la gente a mano y hacían en papel los brackets del torneo de eliminación doble. Yo automaticé todo eso. Hice un sistema que los sábados podía salir este juego, este o aquel, un CTF, un torneo de PvP. Corría solo, no necesitaba tener al tipo moviendo de acá para allá y anotando en papel. Era muy divertido.

—Ahora me hiciste pensar, es un excelente challenge armar sistemas de torneos porque son reglas concretas y el problema es suficientemente complejo que no lo podés hacer en tu cabeza.

—Sí, fue entretenido. El algoritmo lo diseñaba en papel, me acuerdo. Es muy entretenido.

---

Consultoría, salto al exterior y open source

—Me interesó mucho que mencionaste un poco de tu historia, esto de que pasaste por unas consultoras, tipo Velocity Partners, y dijiste: "Quiero trabajar directo". Buscaste jobs, fuiste aplicando directo. Pero cuando veo el LinkedIn, no me queda claro qué encontraste. Veo una AppPress, y estuviste más o menos un año. ¿Cómo fue para vos ese proceso de que te entrevisten, de adaptarte, de trabajar directo?

—Te cuento la previa, que me parece el punto pivotal. Trabajando para Velocity, trabajamos para una empresa que se llamaba Group Commerce. Viajamos a Nueva York, conocimos a la gente que trabajaba ahí. Era un nivel al que yo no estaba acostumbrado. Estábamos en las spring plans, en las weeklies, en las stand-ups, y eran todos unos cracks. Yo decía, ¿qué es esto? No lo puedo creer. Miraba a cada uno y decía, necesito estar sentado con esta gente 24-7 aprendiendo. Y esa lamparita nunca se me apagó.

Al poco tiempo, me pusieron en otro proyecto mucho menos sofisticado y eventualmente me puse a buscar. Uno de los primeros trabajos que tuve fue este de AppPress, una startup de Indianápolis que hacían una especie de Photoshop para apps, como un WordPress de apps que compilaban a nativo. El frontend estaba en Angular.

La entrevista de eso honestamente fue: "Suena que sabés lo que hacés, vamos a probar". Era demasiado informal. Creo que hoy día cambió eso. Pero un par de los trabajos a los que entré en esa época fueron así, ni siquiera tenías una entrevista. Si tenías, era un take home para ver más o menos. A veces leían el blog y decían: "Sí, suena que sabés de lo que estás hablando, vamos a arrancar". Era mucho tirarte a la pileta en Hacker News, en publicaciones de trabajos.

Siento que es algo que pasa mucho, que la gente no se tiene confianza de decir: "No, dice New York, dice US only, no sé", y no se manda. Yo me mandaba igual, aplicaba a todo lo que podía. Algunos decían: "Sí, capaz conviene pagarle a este argentino tres lucas y media por mes". Y nada, cerrarse un montón de puertas, que pase bueno, vamos a probar. Más en una startup, que eso suma un montón.

De ahí fue una iteración constante de eso, de ir a conferencias, dar charlas, hacer consultoría por hora en trabajos de performance, cosas por el estilo. En algún momento quise hacer un producto propio. Me di cuenta que no era una persona de negocios necesariamente. Me topé con la realidad de que los clientes no es "Build it and they'll come", es un poco más sofisticado que eso. Pero la parte de "Build it" ni siquiera la hice. Hice componentes muy copados, que después hice open source y se volvieron populares. Pero el producto nunca despegó porque nunca me molesté en venderlo.

Producto de esa experiencia, las charlas y todas las cosas que había hecho open source, me contactaron para Elastic, que sí era una empresa más real de open source. Tenía unos 10 años ya y ahí sí tuve entrevistas serias. También me había entrevistado en Amazon en esa época. En Amazon me iba a ir a Canadá, pero vino Elastic y me dijo: "Te damos una mejor oferta y nos lo traemos de tu casa". Así que tuve mucha suerte por ese lado.

—Elastic también era... Fue dura la entrevista de Amazon, ¿no? Bien algorítmica.

—Sí, fueron varias, pero más que dura me pareció mucho back and forth. Leí mucho sobre cómo prepararse para una entrevista de Amazon antes de hacerlo. Una de las cosas claves que te remarcaba cualquier cosa que leas era repreguntar. Lo que buscan es eso, tener el back and forth y ver cómo pensás, más que engañarte con algún truco de cómo invertir un binary tree. Había cosas, algoritmos un poco más complejos que otros, pero nada que no puedas charlar con el entrevistador sin pedirle la solución, pero descubriendo cuáles eran los parámetros que buscaban y cómo ibas orientando los pasos.

Eso fue antes de la pandemia, así que fue yendo a entrevistarme allá en Seattle. Buenas épocas, cuando te entrevistaban en persona y te viajaban, linda época. La palabra "on-site" quería decir algo.

—Es gracioso eso, porque nosotros estamos en la industria y entendemos esto, además estamos de esa época, pero ahora tengo que explicarle a la gente que "on-site" es un legacy name, no es el nombre de verdad, ¿viste? Es como que, "¿pero cómo es on-site? ¿Voy hasta allá?" y no, ¿y por qué le dicen on-site? Y quedó, son todos en el mismo día, no. No tiene nada que ver el proceso de on-site.

Pero a su vez, me pasa algo interesante. Estaba entrevistando a una chica para trabajar con nosotros, que vive en el interior, y le digo: "Te tenés que mover a Capital y trabajar con nosotros en algún momento. Por ahí no lo hacés al principio, pero en algún momento. Igual, vení y entrevista acá en persona. Yo te pago el pasaje y te quedás acá". Y le voló la cabeza la idea de eso. Digo, es mucho más caro para mí contratar mal. Recontra vale la pena poner unos mangos. Es raro que se haya muerto eso completamente. Yo entiendo por qué el otro es más barato, pero en algún momento, pagarle 2.000 dólares a alguien es mucho más barato que 3 meses de alguien que no quiere estar acá.

—Sí, totalmente. Ya si le decís a alguien: "¿Querés viajar acá y hacer la entrevista?" y te dice que no, ya sabés que no va. Y sí, depende mucho de lo que se busque.

---

Elastic vs Ramp: culturas y modelos

—Elastic y Ramp no podrían ser dos empresas más diferentes. Elastic tenía gente en 60 países, creo. Yo tenía compañeros de trabajo en Japón, Irlanda, Seattle, Nueva York, Chicago, donde vos quieras. Muchos de España también, Grecia. Y esta era toda la gente con la que colaboraba día a día. Las stand-ups iban rotando de horario cada tres semanas, porque si no, a alguien le caían todo el tiempo a las 10 de la noche. Pero nada, los dos que estaban en Japón, por ahí era un problema.

Eso te daba, para lo que era production engineering, mucho más músculo a la noche del oeste de trabajarlo. Hacían un par de off-sites por año, generalmente una en Europa y una en Estados Unidos. Pero después ibas a una oficina, incluso durante una de esas off-sites, y estaba completamente desolada, no había nadie. Eso a mí me parecía raro.

Ramp es distinto en que la mayoría de la gente está en Estados Unidos, en Nueva York, hay una presencia en San Francisco, después tenés gente en Canadá, gente remota acá en Argentina, somos dos hoy por hoy, pero contratamos, así que si les interesa, háblenme. Cuando vas a la oficina está todo el mundo, está la gente con la que vas a juntarte de tu equipo y podés ver a todo el resto del plantel. Eso es muy interesante para mí.

—Vos entraste en pandemia a Ramp, ¿no? ¿Cómo hicieron la transición en esa época?

—Ellos creo que siempre tuvieron una política bastante anti-pandemia en ese sentido. Creo que gracias a la pandemia yo pude entrar a Ramp en primer lugar, o si no, no me hubieran ni respondido el mail. Pero a la primera que vieron un haz de luz, volvieron a la oficina todos. No es algo obligatorio ya, pero sí es más un estilo híbrido varias veces por semana y se incentivó bastante a que vayan a la oficina.

—¿Vos mandaste mail? ¿Fuiste un inbound de ellos o tenías un referido?

—Después de Elastic estuve haciendo consultoría on the side, cuando decidí que Elastic ya no era lo mío. Empecé a hacer consultoría en lo que sea porque estaba aburrido, francamente, y literalmente dije: "Voy a agarrar los primeros que vienen a Hacker News". Lo primero que vi en Hacker News que me contestaron fue un founder que estaba dejando de trabajar para un VC en un proyecto de un CRM. Me puse a trabajar en eso durante un año más o menos. Era un proyecto para nada copado, pero me quedé ahí porque dije: "Este tipo vale la pena y si quiere hacer un CRM integrando otros dos CRMs, yo se lo voy a dar".

Después de un año le dije: "Mirá, esto no va para ningún lado. Me parece que te estoy robando a esta altura, pero quiero irme de Elastic, ¿me ayudás a buscar algo?" Me pasó como 10 empresas de su portfolio, empecé a entrevistarme con ellos y lo cómico es que después vi un tuit sobre Ramp y le dije: "¿Conocés a alguien de Ramp? ¿Podés ponerme en contacto?" Me hizo la intro y terminé aceptando la oferta de Ramp. Y bueno, después invertí en Ramp, ese es el happy ending.

—Bien, eras un topo.

—Yo lo mismo, meto topo para que pueda ver, ui, te invierto en la empresa.

—En Argentina es muy raro hacerlo esto, pero si yo estuviese hablando con un americano que está buscando dónde entrar y que es bueno y tiene chapa y puede elegir, siempre le diría que vaya a un VC y le diga: "Dame tus 10 mejores empresas del portfolio". Te ahorrás como 50 pasos de elecciones porque te dicen la que le va bien y ya está, eso ya es un montón.

—Sí. Hay algo antiintuitivo, que es que a la empresa que le va bien, no solo paga mejor, sino además tiene mejor trabajo. No es que es elegirse la empresa que paga bien y el trabajo es malo o la que paga mal y el trabajo es bueno, no, es la que mejor paga y la que tiene mejor trabajo, las dos cosas pasan a la vez.

—Sí, también pasa por una cuestión de cuál es la calidad del riesgo que estás tomando. Como empleado, como consultor, sos un inversor de alguna manera en una startup, pero estás invirtiéndote a vos mismo entero y podés elegir una en la que te metas así tan de lleno. Por eso es una decisión muy importante, es algo que recalcamos. Hoy por ahí capaz ya no tanto, pero early on cuando era gente muchísimo más de perfiles de este estilo, estaba en medio en la disyuntiva y le decíamos: "Sí, te entiendo, mirá este fue mi proceso, le explicaba todo esto y termina acá, pero la verdad que te entiendo porque es una decisión que va con suerte a marcar los próximos 5 años de tu carrera, 2 años de tu carrera por decir, entonces tenés que tomarla convencido de que este es el lugar donde querés estar y no por decir, ah, me pagan 5K más de compensación y con eso no te vas a quedar a través de las malas".

—Es una lucha constante que tengo yo como recruiter, explicar la empresa donde el potencial es alto. Yo le tengo compasión a la gente y creo que tiene razón la gente, no nosotros cuando decimos equity es importante, cuando todas las opciones que tienen son seeds, porque las seeds las chances de liquidez son muy bajas, el pro marketing no está. Pero después viene una que es serie B y te dicen que es lo mismo la serie B que la seed y digo, no, la serie B ya, pará, acá estamos más cerca, no estamos en cualquier lado. Yo tengo en mi portafolio que le está yendo bárbaro y es tipo, me escuchan, yo digo, chicos, métanse acá y es tipo, no me creen, no conectan con la idea, es grave.

—Sí, el perfil de riesgo cambia muchísimo. Lo que es seed, series A, pre-seed ahora que está de moda, es una cosa. Y series B y series C, a menos que se haya estancado por completo y, incluso en esos casos, un exit va a tener de algún tipo, a menos que sea una estafa. En la peor de las situaciones, se va a vender a un private equity y tener algún tipo de salida.

---

Escribir contenido, libros y la industria editorial

—Me interesa todo este paso que hiciste de escribir contenido. Estamos tipo 2014, 2015, 2013, empezaste un blog, empezaste a escribir libros, empezaste a hacer conferencias. ¿Cuál era tu plan, qué era lo que querías lograr, etcétera?

—El principal objetivo que tenía en ese momento estaba haciendo consultoría con C# y un poco de frontend. En lo que es frontend siempre me parece interesante porque al que no le gusta el frontend, no le gusta el frontend para nada, y acá en las consultoras era raro encontrar gente que le gustara hacer frontend. Entonces, con tener un mínimo interés, ya era la persona que hacía las cosas de frontend y no la pasaba mal.

Por algún motivo en ese último año en Velocity dije: "Tengo que salir de mi área de confort, de este trabajo que no me está llenando tanto, ¿qué puedo hacer? Bueno, voy a hacer un blog". Primero hice un juego en XNA, para aprender una tecnología nueva, aprendí un par de cosas más de Microsoft, pero eran tecnologías muy raras. Ahí encontré Node.js, dije, Node.js está interesante.

El blog en realidad fue decir: "Voy a hacer algo real que no exista". El plan era básicamente: voy a escribir unos artículos, y ahora voy a necesitar dónde publicarlos, y para eso tengo que enseñarme a programar en Node.js, hacer el server, lanzarlo y poner los artículos ahí. Mientras tanto sigo escribiendo artículos para seguir incentivándome a hacer esto. Una vez que subo el blog, obviamente no lo veía nadie, pero eso no era lo relevante, porque era una meta personal.

Al año de escribir el blog, me pareció copada la idea de escribir un libro. Contacté a Manning, ellos te dan un editor y te pones a debatir cómo sería la tabla de contenidos, lo que querés, le vas dando forma de una manera súper iterativa. No es algo que digas desde el día uno: "Esto es una tarea colosal". Eventualmente te das cuenta de que escribir un libro es muchísimo trabajo, y si lo querés hacer por notoriedad o por plata, no da resultado. Es una experiencia enriquecedora si te gusta escribir, pero tenés que estar convencido de que querés escribir un libro porque querés escribir un libro, y no por cualquier otro motivo. Es lo que le digo siempre a todo el mundo.

Pasa mucho que te contactan, hay algunas publicaciones que ahora no me vienen al nombre, pero que te contactan para decirte: "Vimos en tu LinkedIn que dice talento, ¿querés escribir un libro de hiring?" Y capaz la gente dice: "Ah, mira, una oportunidad grandiosa, es un tren que pasa una vez en la vida". Y la realidad es que si vos querés escribir un libro de esos, vas y le escribís a un publisher que se quedan con toda la guita, y encantados te van a decir: "Sí, por aquí pasa el señor Gabriel, armen la tabla de contenidos, escriban su libro, nosotros nos quedamos con ocho de cada diez".

—¿Manning te daba 20%?

—No me acuerdo, pero era un número muy menor, más para el volumen de ventas que tiene un libro técnico.

—¿Te pagan un adelanto o algo?

—Sí, generalmente sí.

—O sea, si te pagan un adelanto, tiene que haber un proceso de selección, ¿cómo evalúan que no sos un queso?

—Teniendo un blog, supongo. Me parece que buscan gente que tenga material publicado de algún tipo, no sé, respuestas a Stack Overflow, blogs, tuits, lo que sea. Manning la verdad es que no tengo un feeling, pero O'Reilly tiene como una marca, tiene que tener algún tipo de vara.

—¿Vieron tu libro anterior y dijeron, este tipo no es un fantasma?

—Claro, sí, con O'Reilly me parece que pasó eso. Les escribí también a ellos, les llegó una propuesta de los libros que quería escribir y les gustó. Habían visto el libro anterior, el blog y demás y fuimos para adelante. Pero me parece que es distinto si ya publicaste algo, te da la credibilidad de que ya sos un autor publicado. Alguien más tuvo que haber hecho la verificación, supongo.

—También lo que más les debe pasar es que la gente no lo termina. Entonces, ya viendo a alguien que termina un libro ya es señal de que puede terminar un libro, es un montón. Terminaste uno y capaz terminás dos.

Yo trabajé en la industria de las publicaciones. Escribir era eso. Llegué a entender bastante de cómo se hacían los libros, cuántos se quedaban. Es una industria con un problema de estructura de mercado. Tiene un problema de estructura de mercado y no lo sabe resolver porque además los jugadores están peleados entre sí. Está como Amazon contra todos y todos los otros tienen la... si son buenos en elegir libros. Amazon no es bueno en elegir qué libro va a tener éxito, al menos no lo ha demostrado a lo largo del tiempo. Entonces, tenés el publicador tradicional que es bueno en elegir y crear las marcas, que se queda con muchas marcas, que no se las quiere vender a Amazon. Y Amazon que es más, publica lo que vos quieras, qué sé yo, y te doy más margen. Entonces, están como repeleados y no se desbloquea.

Y es un problema porque Scribd nunca salió de la trampa esa. Porque, de hecho, ya pasaron 10 años y me estoy quejando de ellos que no me pagaron el equity todavía, a pesar de que la empresa les fue bien. Así que esto les estoy cobrando. El problema general es que tienen un deal con las publishers y que todo el negocio está contingente a que no hables con Amazon. Entonces, es como que si nos lo hicieron a nosotros, se lo hicieron a todos. Por lo tanto, el mercado no tiene una estructura donde el tipo que tiene plata no puede operar porque está peleado con los otros publishers. Y a su vez, los otros publishers tienen como un modelo mental medio arcaico. Es como pasa con Spotify y los registros. Spotify hizo algo que no se pudo hacer con libros, que es esto de pagar por cuánto la gente lee. Y todo eso no te lo aceptan con los libros porque la gente no lo lee.

Y después hay el mismo problema de distribución. Porque al fin y al cabo, lo único que saca el autor de un publisher reconocido es la distribución y el logo de decir, publiqué en O'Reilly. Pero si vos ya tenés una marca, es lo mismo con los medios, de founders que van direct y hablan en un podcast durante tres horas y no necesitan pasar por MSNBC porque no les suma nada. Es un poco lo mismo. Si vos ves, no sé, Stripe Press, es como un toque de midas. Lo que tocan se convierte en oro. Y ahí está un poco más alineado, por lo menos.

—¿Cuántas ventas de libros tenés entre todos los tres libros que publicaste?

—No tengo idea.

—¿Orden de magnitud? ¿1.000? ¿10.000?

—Fue más de 20.000 entre los tres.

—Un montón.

—Sí, no está mal. No son Harry Potter.

---

Open source, producto y modelos de negocio

—Me interesa, vos sabés que lo menciono bastante y tengo mucha gente que viene al podcast que trabaja o en DevTooling o en open source, Elastic es un caso de eso, y yo tengo, me quedó esta deuda en mi carrera como programador, que yo tengo un perfil muy orientado a producto y siempre tuve como una barrera en hacer open source. Porque te juro cuando voy, yo voy a Next.js, hice un par de PRs peor. Voy a Next.js y no entiendo el código, siento que es otra cosa al código que yo conozco. Y siento que en general, como una dinámica de trabajar en Elastic, todo tu trabajo es público, ¿no? Entonces como que no hay, poner el trabajo de producto tiene alguna neblina de cuál es el impacto de lo que vas a hacer, porque por ahí es un feature corto, qué sé yo, pero el trabajo no pasa nada. Siento que es tan distinto, es cómo se evalúa, cómo se piensa, cómo es la dinámica. ¿No tenés alguna opinión de lo que es trabajar en Elastic o Ramp en este aspecto?

—Primero, en Elastic yo trabajaba en realidad en una parte de closed source, que era la parte de cloud, que era como un competidor de AWS para el hosting de Elasticsearch, Kibana, Logstash y demás.

Open source es complicado. Depende por dónde lo mires. Como dinámica de trabajo está buena, te enseña muchísimas buenas prácticas que no siempre necesariamente se aplican en otros lugares, en términos de documentar las decisiones que uno toma y tomar decisiones que sean escalables y no tomar ciertos atajos que te pueden perjudicar a la larga.

Yo creo que lo veo como un espectro entre open source y producto, porque si estás demasiado del lado de open source, te terminás volviendo muy idealista y después te la das contra una pared. Cuando te pasa esto que te digo yo, quise arrancar un producto y me puse a hacer componentes como si eso fuese hacer lo que alguien quería comprar. Y claramente no iba a reemplazar Jira por haber hecho un textarea más sofisticado. Ese me parece que es el problema que tiene y se extiende a las empresas.

Porque si ves, capaz no es el caso de Vercel. Me parece que Vercel es muy único en ese sentido. Una empresa que encontró cómo hilvanar open source y un modelo de negocios que funciona muy bien. En el caso de Elastic, era mucho más complejo porque su claim to fame era Elasticsearch, que era open source, y después hicieron una licencia un poco más híbrida que parte era open source, pero parte no. Y en realidad no está aceptada por OSI y demás. Se metieron en todo un tema así que un montón de la gente que trabajaba por Elastic decía, sí, sí, let's drink the Kool-Aid, pero en realidad no sé si todos estaban de acuerdo con esa modalidad.

Me parece que eso se vuelve muy complicado. Cuando querés hacer un negocio sobre open source, te lo resumiría como: yo no volvería a apostar por una empresa que esté basada en open source. Porque es muy difícil de armar el negocio. Y tiene ese componente cultural del idealismo que es inextricable para mí del open source, que si ese es tu core, es imposible de iterar rápidamente, de romper barreras, de bajar procesos, de iterar rápido. Todo esto que conocés del lado del producto, es una lucha cuesta arriba.

—En el podcast estuvo Dax Raad, y él dice que las empresas que tienen productos open source, y todo lo que es DevTooling tiene que ser open source, o sea, realmente es como que no se puede, no se acepta lo otro ya. Dice que hay que hacer dos productos directamente. Hacés uno open source y después el producto con el que hacés plata. Pero no es que es uno y lo podés, no se pasa nada con eso. Tenés que construir la distribución y después tenés que construir el producto con el de la distribución.

—Claro, Elastic lo que hacía, y ese era el problema de Elastic para justificar su toma de decisiones, porque ellos tenían Elasticsearch, y después ciertas funcionalidades de Elasticsearch ya eran pagas, eran premium. Entonces, la parte de security, de tener role-based access authorization, control, era pago. Esto es algo completamente básico. Si tengo un clúster de Elasticsearch y no soy una persona que quiere ser atacado, lo necesito. Entonces, ¿cómo defendés esa decisión? ¿Cuál es la métrica? Es difícil de explicar. Y te terminás metiendo en un montón de distracciones, lo resumiría así, de este estilo que no son: "¿Con qué más vamos a hacer plata?" sino "No, bueno, esto en realidad tiene sentido hacer plata con esto porque..." y no, no creces mucho así.

—¿Y cómo ves vos OpenSearch en esa pelea con Elastic? Porque en Amazon les quedó mucho más claro, hacen plata con el hosting y después ya está.

—Mirá, yo soy muy fan del open source, pero no del comunismo. Así que si vos estás diciendo que tu plataforma es open source y alguien la agarra y dice: "¿Qué se puede hacer con esto? Forkearlo y hacer mi propia distribución". Bueno, vos dijiste que se podía hacer eso, si no, ¿por qué estás diciendo que es open source? Es literalmente la definición de open source. Alguien lo puede agarrar y modificar y distribuir sus modificaciones.

Ahí es donde me parece que empezaron a perder mi estima y el hilo porque no es justificable decir: "No, bueno, porque en realidad entiendo que tu decisión fundacional fue contraproducente, pero eso no quiere decir que Amazon, jugando con las reglas que vos instauraste, esté en falta". Yo lo veo un poco así. Me parece un no-brainer de ellos. Probablemente en un fin de semana hicieran la primera iteración de ese producto y con la distribución que tienen, te destruyeron. Así es el juego.

—Es difícil alinear los intereses a veces. Y yo creo que eso que mencionás de Elastic, que empieza de una manera y después lo hace, le pasa a todos. Me pasa a mí, por ejemplo. Yo tengo una agencia, una empresa de servicios, y cuando recién empecé en mi negocio, no tenía clientes y me metí a comer barro. Entonces viene el cliente y me dice: "Te pago 10%". Yo le digo, bueno, no tengo otra cosa. Y después pasa un año, tengo una cartera grande y el cliente de 10% y ahora le digo, yo no te quiero atender más. Es muy difícil hacer esa conversión. Y decir que yo no tengo tanto problema, porque yo siempre puedo decir, se acabó y no pasa nada, pero cuando vos recién empezaste, tenés que prometer mucho. Y de repente cuando te va bien, decís, prometí cosas que me están mordiendo. Y como que no hay un mecanismo para alinear esas cosas bien, pero a su vez es lo que te trajo hasta donde estás. Entonces es difícil.

—Sí, es un problema de toda la industria, de hecho, porque a Redis le pasó lo mismo. Tuvo un proceso muy similar donde hicieron también una licencia más bespoke, que era anti Amazon básicamente, para que no puedan hostear su servicio y cobrar un proporcional. Sin ir más lejos, con empresas como Amazon, que yo me entrevisté y quedé en el proceso, te pasaba que vos decías: "Che, todo el trabajo open source que hice, todos los artículos, ¿puedo seguir haciendo esto? ¿Está bien?" Y ellos te decían: "Sí, en tu tiempo libre podés hacer lo que quieras". Y en una empresa como Elastic te decían: "Sí, obvio, seguí haciéndolo. Podés ir a conferencias, hacer lo que vos quieras". Y como que lo usaban como parte de su plataforma. Y nada, tenés esa disyuntiva de: "Che, te encontramos por esto, pero ahora no queremos que lo hagas tanto en realidad, porque una vez que entraste acá, ya está, es producir para nosotros".

---

Ramp: producto, hiring y cultura

—¿Trabajás en una empresa que está buscando talento? Recomendanos. Nosotros trabajamos con algunas de las mejores empresas del mundo y les filtramos y les buscamos talento para que puedan armar el mejor equipo posible. Si en tu empresa están contratando, mencionanos.

Hablemos un rato de Ramp, finalmente. Llegamos a Ramp, podés hacer toda la propaganda. Yo voy a hablar un poco de cómo yo hablo de Ramp. Cuento un poco mi historia, que una de las ofertas que rechacé gravemente, en realidad no fue una oferta, pero yo creo que lo hubiese conseguido, fue para trabajar en Brex cuando era seed. Porque ellos me dijeron: "Che, estamos buscando a alguien que haga backend en Elixir". Y yo soy tipo frontend, qué sé yo, y les dije: "Chicos, ¿qué están haciendo? No quiero trabajar en Elixir". A los dos meses soltaron Elixir y eran todos JavaScript, o sea que grave lo que pasó.

Me acuerdo que Brex había sido una de las empresas que más rápido creció en su momento, fue 2017, creció un montón, y de repente apareció Ramp, que era como una versión costa-este de Brex. Encontraron, digamos, como origin story, las dos ofrecen como el servicio de tarjeta de crédito para startups, reverse chance, un broad market fit violento. Pero me sorprendió mucho que Ramp, primero, creció más rápido que Brex, en un espacio mucho más corto. Y lo otro que pasó, y yo lo viví con Brex, porque llegué a hacer los procesos de entrevistas con ellos tres veces. Y me pareció una entrevista re fácil. Yo dije, el talento acá no puede ser muy bueno, me acuerdo sentir eso, ¿viste? Y Ramp rápidamente era, bueno, tenía algunos cracks, tipo estaba el de programación competitiva, ese Neil Wu, el que después se fue a hacer Cognition Labs. Como que armó una reputación de talento duro, ¿no? Y lo armó en Estados Unidos, y yo llegué a trabajar con Ramp a través de un partner que me pasó como una lista de requerimientos, si era que tenían que tener, o libros escritos, o programación competitiva, o tipo una lista de 10 que decía, esto es imposible. Y pasan los años, y yo, por ejemplo, cuando en una plataforma, hay una plataforma que se llama Paraform, que te dice qué tipo de empresas les gusta a los founders, digamos, de dónde picar talento, ¿no? Y Ramp está siempre. O sea, Ramp está siempre. Y yo le digo, no van a agarrar de ahí, ¿viste? Pero, tipo, está siempre. Entonces, la reputación de talento que tiene es muy importante, ¿no? Entonces, o es una de las empresas con más crecimiento, más rápido crecimiento, debe estar con Deel, digamos, abajo de ChatGPT, porque ese partió todo, pero es medio raro, porque tiene 7 años, ¿viste? No sé. Pero estamos en top 10, seguro, top 10 de velocidad. Mejor reputación de talento. ¿Cómo llegamos acá? Hacé tu pitch de Ramp, explicale a Ramp a la gente, y ¿cómo llegamos acá?

—Ramp es una plataforma de automatización financiera. Básicamente, si tenés una empresa como Silver, te dan el sistema para que le puedas dar una tarjeta a cada uno de tus empleados, y cuando tienen un viaje a costa de la empresa, puedan pedirte los fondos, rendirlos en la plataforma, subir los recibos, y no tener que estar una mañana entera, en el mejor de los casos, rindiendo gastos, subiendo recibos, sacándole fotos a cada cosa, sino que pueden hacerlo on the fly, y no necesitan hacer tanto trabajo manual.

Eso es como con lo que empezó, que es la tarjeta. Después agregamos la parte de reembolso, la parte de pagos de cuentas por transferencias, por ACH, y demás. El producto se fue expandiendo, tienen la parte de accounting, travel para hacer tus bookings. Tiene una parte de tesorería ahora, que es como una cuenta que te da un yield bastante importante de los fondos que tenés en la cuenta.

Estamos trabajando fuertemente en lo que es intakes, que es básicamente: "Necesito un servicio o un producto, puedo preguntarle a Ramp con plain text qué es lo que necesito", y Ramp me orienta en el workflow de procurement de la empresa. Esto ya es para empresas más grandes y sofisticadas, que si querés contratar LogRocket y tenés un gasto anual de un millón de dólares, probablemente no sea tarjetearlo y listo, sino que tenés que ir a compras y lidiar con el proceso de ellos. Nosotros tratamos de reducir la carga manual que tiene todo ese proceso.

Después tenés toda la parte de rendición de gastos. Obviamente la empresa tiene una política de gastos, qué se puede gastar y qué no. Podés comprar un kilo de yerba cada tanto, pero no te podés comprar una computadora por día. Lo que hacemos ahora es automatizar mucho de eso, dar recomendaciones a los managers de: "Che, esto me parece que está fuera de la política o no", basado en lo que dice el documento. Capaz hay una recomendación, si decís que sí está dentro de la política, de actualizar la documentación para que quede evergreen.

Eso es a lo que se está atendiendo mucho a través de todo el producto, de cómo podemos meter agentes o casos aplicados de inteligencia artificial donde se elimina el primer 80% del trabajo, por ejemplo en esto del policy agent, de decir: "Mirá, nuestra primera impresión es esto. ¿Qué te parece?" Por ejemplo, tenés dos expenses de café de 5 dólares cada uno, esto nos parece que están todos bien, lo podés aprobar con un clic. Son 50. Y después capaz tenés un par de cosas un poco más outliers que te decimos: "Che, mirá esto, dale una miradita", pero pasás de tener que mirar 60 cosas a mirar 10 con distintos ratings.

—Dentro de lo que es como producto o servicio fintech, ¿el caballito de batalla es expense management? ¿Esa es la parte que ustedes hacen excepcionalmente bien?

—Yo diría que Ramp hoy por hoy tiene muchas curvas de crecimiento que se van stackeando. La primera es esa que se hace demasiado bien, que obviamente seguimos invirtiendo en automatización especialmente. Después lo siguiente que se agregó fue la parte de bill payments, de poder hacer pagos a gran escala. Y eso también viene creciendo muy fuertemente, pero es un área de producto muchísimo más compleja. Entonces hay 3 millones de necesidades que tienen las grandes empresas, que es lo que se va cerrando. Sí, esas serían como las dos grandes cosas.

—Este producto o este servicio de productos, y pasa en fintech, que yo trabajé un poquito, así que hablo con un poquito de experiencia, no mucha, pero un poquito. Es como fintech siempre tiene que, hay muchos jugadores que tratan de atacar estos problemas. Por ejemplo, yo uso Mercury para mi banca personal, es mucho más orientada a ser banco, no a hacer todas estas otras cosas. Pero es un producto que anda muy bien. Está Brex que compite de otra cosa, geolocalización, pero hace cosas y hay como servicios que atacan acá. ¿Cómo logró Ramp volverse un líder en este mercado? ¿Fue por ejecución, fue porque entiende mejor el producto, fue por un go to market mejor porque están en Nueva York y es más finanzas? ¿Cómo lo ves?

—Hay muchas respuestas para dar, pero para mí la realidad es que todo parte del talento que tenés. Si mirás este tema del compound interest, básicamente todo se compone del talento que tenés y de ahí podés seguir agregando cosas que funcionen bien o mal, pero el motor del crecimiento siempre va a ser qué tan visionario es el founder, qué tan bueno es el talento y qué tan bueno es el producto desde el que empezaron en un inicio y después todo eso para arriba.

Si en alguna de esas cosas no tenés el motor de ideas de los founders, te va a costar seguir creciendo, seguir creando curvas de crecimiento a través del tiempo. Si no tenés el talento, eventualmente vas a ahogarte en la complejidad del producto y si el producto ya es complejo por sí, o lo vas a tener que reescribir de nuevo o vas a tener que arrastrar toda esa deuda de alguna manera o ir pagándola porque no es sostenible.

Por eso me parece la parte de hiring crucialmente importante y es esto que decís. Bueno, capaz Brex no ha crecido tanto, ahora creo que está creciendo más, pero tuvo un montón de rondas de layoffs, Ramp nunca tuvo y Ramp siempre tuvo una vara mucho más alta. Me parece que hay mucho de eso.

---

Hiring, entrevistas y cultura de talento

—¿Cómo se llega a tener ese employer branding? O sea, hablemos de talento. Vos ya eras el número 100, o sea que ya había una visión de management de talento de barra alta, ¿no? ¿Cómo lo viste vos y cómo se mantiene en el tiempo? Hablemos un poquito de toda esa parte.

—Cuando me entrevistó, como te decía, me había entrevistado en 10 otras empresas, en realidad estaba buscando algo más tipo Series A, más que una pre-IPO, que en unos años haga IPO. Pero Ramp ya valía 1.6 billones de dólares, ese fue el artículo que había visto, entonces decía, bueno, ¿qué tanto más puede crecer? Pero la verdad, el proceso de entrevistas y la gente que conocí en el proceso me sorprendió. Para una empresa que tenía dos años, ya valía 1.6 billones de dólares, que también podés decir tanto bueno como malo de eso. Podés decir, che, ¿cómo vale 1.6 en dos años? ¿En tres cuánto va a valer? ¿Cero o diez? No sé, porque es una cosa muy rara. No, no pasa. Pero sí se veía que un montón de fondos de inversión grosos le estaban tirando guita a lo loco. Levantó 1.400 millones de dólares en los seis años que tiene. Es una bestialidad.

En cuanto a la vara de talento, mi experiencia fue buena en las entrevistas. Se hace mucho hincapié todavía en lo que es la experiencia del candidato, que cuando te estás entrevistando sientas que no te vas a enterar nunca, salvo intrínsecamente, qué tan bien o mal te fue en base a la lectura de los entrevistadores. Pero eso me parece importante, porque si te está yendo mal en la entrevista no es que te van a empezar a buchear.

En los ejercicios tratamos de enfocar cada una de las distintas evaluaciones en distintas señales. En una primera entrevista medimos qué tan flexible sos a tener una serie de requerimientos muy complejos y cómo priorizás tu tiempo en una entrevista que claramente es bastante compleja. Es un ejercicio bastante amplio y te decimos ciertas cosas específicas que generalmente te importan y no nos importan en esta entrevista. ¿Podés manejar eso? Y hay gente que dice: "No, esto es importante, yo lo voy a hacer". Y en el ejercicio está clarísimo, esto no importa. Bueno, mucha gente cae en eso.

—Te estilan cuando le decís, no quiero estilos. El clásico.

—Exactamente. Y esa es una de las entrevistas, ese es el gran filtro que tenemos en lo que es frontend por lo menos, pero tenemos una similar en mobile también. Y una vez que pasás eso hay bastante buenas chances de que pases el on-site, que son otras cuatro entrevistas. La filosofía ahí es un poco: no queremos guardar ni nuestro tiempo ni tu tiempo en traerte al on-site, hacerte cuatro horas de entrevistas más y que no tengas buenas chances de quedar. Por eso ponemos toda la carne al asador al principio y después validamos otras cosas.

En la on-site ahora tenemos una entrevista que mide básicamente si podés razonar bien en algoritmos. Es decir, si tenés un problema que es de algoritmo completamente resolvible, pero que claramente no es algo tan sencillo como mostrar una lista de datos en una UI, sino que hay que pensar un poco. Y mide específicamente eso la entrevista.

Otra entrevista que estamos terminando de ultimar para este fin de mes es una evaluación de qué tan bien usás herramientas de AI. No quiere decir que también implementás un chatbot, pero si tenés una implementación larga y te decimos: "Usá toda la AI que puedas para llegar lo más lejos posible", cómo te perfilás. Y eso es algo que se está empezando a usar en toda la industria de evaluar cómo te adaptaste a este cambio de ahora hay que usar AI porque si no te quedaste atrás.

Después tenés la entrevista de arquitectura y diseño que es bastante clásica. Es charlar de cómo ves trade-offs entre diferentes tecnologías, contar algún proyecto que hiciste que te parezca complejo, qué fue lo complejo, cuáles fueron los challenges, cómo los atravesaste, qué aprendizaje tuviste. Y después hay una de leadership que básicamente es una cuestión de team fit, de cultura y de cómo te posicionás frente a una empresa. Esas son las entrevistas principales. Después hay algún filtro más de algún code challenge, pero básicamente eso.

—Me interesaría hablar un poquito de la entrevista de AI porque es algo que desde mi lado, que tengo 50 empresas clientes, empiezan a surgir estos temas de cómo evaluar adopción de AI, pero no saben cómo hacerlo. No he visto challenges que me hayan satisfecho del todo. Entonces contame un poco, en este ejercicio, qué es lo que querés evaluar. ¿Qué le evalúan? ¿Los prompts? Vos podés tirar un prompt que te tire tres cuartos de la solución y podés tener mala suerte y que te tire cualquier cosa y que no ande y te meta en un laberinto. Ese es el gran riesgo.

—Mirá, yo lo veo de esta manera. Si te estás entrevistando en una empresa, lo que está clarísimo es que te están evaluando a vos. Entonces, si agarrás y decís: "Mi contribución a esta entrevista va a ser copiar y pegar el prompt en un chatbot de ChatGPT y ver qué me dice y copiar y pegarlo en el editor y ver si compila", no contribuiste demasiado, así funcione flawless. No me mostraste nada de cómo funciona tu cerebro.

En la entrevista lo que quiero saber es cómo pensás. Ni siquiera me interesa tanto que el ejercicio ande a todas luces y que le pegues a todos los requerimientos, tanto como entender cómo pensás, cómo pensaste los trade-offs, cómo llegaste a la solución a la que llegaste y cómo puedo extrapolar de ese rendimiento tu rendimiento en uno o dos años de empleo. Que es una cosa, si te pones a pensar, es una locura. Yo veo a una persona una hora, entre todos la vemos seis, siete horas, con mucho, y ahí decidimos, sí, esta es una persona que puede trabajar para nosotros por dos años. Es difícil. Es como casarte. Tomamos un café y de acá decidimos si nos casamos o no casamos.

Me parece el principio fundamental es ese. Partiendo de esa base, lo que a mí me interesa evaluar con una entrevista de AI es cómo razonás lo que le vas a preguntar a la AI. Es lo mismo que en las otras entrevistas te dejamos googlear, por ejemplo. ¿Qué es lo que googleás? O cuando te encontrás con un error de la aplicación, es normal, ¿cómo lo debugueás eso? ¿Le preguntás al entrevistador que te ayude o empezás a tirar hilos de alguna manera? Lo que se evalúa es eso, básicamente, cómo razona la persona en el contexto de un problema que se puede ver a diario, como es resolver un algoritmo que no conoce, resolver algo con ayuda de inteligencia artificial, resolver algo que lo obligue a priorizar de formas que capaz no son las ideales en condiciones normales de presión y temperatura y demás. Pasa un poco por ahí.

—Necesito insistir en este tema de evaluación. Vos podés tener un developer que en su workflow tiene muy buena adopción de AI y usa Cloud Code. Y Cloud Code ya por ahí le tirás una tarea que tarda 5 minutos, no podés hacer eso en una entrevista. Entonces ya más para atrás tenés que hacer prompts cortos, con problemas muy definidos, tenés que hacer un prompt muy orientado a esta entrevista. Y además lo que te tira, hay que leerlo. Entonces ahora tenés que leer un pedazo de código que te tira, y que es como que si te tiró un desastre y no te das cuenta, porque leerlo es mucho más difícil que escribirlo. Para entender algo, es mucho más difícil leerlo que escribirlo. Y como que siento que agrega mucha variabilidad. ¿Vos ves como que este problema en este formato de entrevista?

—Hay que ver qué es lo que hizo, por qué, y tratar de darte cuenta cuáles partes podés rescatar, cuáles no, y qué se puede hacer. Va un poco por ahí la cuestión, me parece. Para mí todos los mejores casos de AI, de uso, son tratar de remover el 80% de los pasos que hay. Desde que decís, me parece que es por acá, hasta que llegaste acá.

Un ejemplo que no tiene nada que ver, pero te lo tiro de Ramp, es: hicimos internamente una extensión de Chrome, que podés ir a cualquier property de Ramp, como un empleado, hacer un highlight de alguna parte de la página y decir: "Esto me parece que hay que cambiarlo por esta otra cosa". Te abre una ventanita de chat, te editás con un bot y te abre un PR. Vas al PR y podés conseguir un review de algún frontend o pasárselo a alguien más que lo lleve a finish line. Todo eso, hasta que se abre el PR, antes era un proceso manual. Venía el chabón, te publicaba una screenshot en Slack, alguien de frontend venía, hacía todo el PR. Y ahora, capaz, un diseñador de punta a punta lo puede hacer con un rubber stamp. Es eso, es cómo llego de la idea a lo más cerca posible de resolver la ejecución.

—Solo quiero mencionarte que al principio de la entrevista dijiste hace 10 años que estabas escapando de hacer CMS, y me acabás de hablar de un CMS con extra steps.

—Bueno, qué sé yo. Volvemos a las bases, es todo CRUD y CMS.

---

Management, equipo de talento y cultura de hiring

—Como último tema, mencionaste que en un momento tuviste que tomar el equipo de talento. ¿Qué hiciste ahí? ¿Qué pasó?

—Early on en Ramp, en ingeniería éramos 30, en frontend éramos 4. Estuvimos 6 meses más o menos que no encontrábamos otros frontend que nos convencieran. Y después conseguimos otros 8 de la noche a la mañana. Fue un cambio interesante. Después de eso, empecé a hacer management. Como te había dicho, era algo que ya me daba reluctancia, por una cuestión de esto que te decía antes, de que no me gustaba el management tradicional de estar en el micro de cada persona, qué es lo que tiene que hacer para su día a día y qué sé yo. Pero acá es un modelo mucho más de player coaching, de decir: "Mirá, me parece que esto lo podés mejorar, que esto tendrías que publicitarlo más, por ejemplo. O acá me parece que estuviste mal en ir por este lado, en dar feedback de esta manera, lo que sea, y cosas para corregir". Entonces más ayudar, orientar a la persona, más que hacer su trabajo por ellos. Es la forma que lo definiría.

En la parte de talento, en algún momento salió la persona que era el head of talent y realmente no teníamos una alternativa en ese momento. Teníamos a un chico, Jacob, que es el VP de People, que en ese momento había pasado a Risk Operations a ser el jefe de People y como que no se sentía del todo listo para afrontar el equipo de talento, entonces dijo: "Bueno, vos te interesa mucho el tema de contratar gente muy capacitada y demás, te lo damos a vos el equipo por unos meses y vamos viendo". Y básicamente hicimos eso, creo que fueron dos o tres meses o un poco más, unos seis, de manejar el equipo de talento, que era muy interesante porque es un equipo que no tiene nada que ver con ingeniería, pero ahí sí capaz fue más de una especie de micromanagement de decir: "Che, a nosotros lo que nos interesa es esto, es aquello". Ir debugueando en el panel de recruiting, que era lo que estaba faltando en algún momento, eran las entrevistas, había alguna que era muy fácil, alguna que era demasiado difícil, algún entrevistador que le decía que no a todo el mundo, algunos entrevistadores que le decían que sí a todo el mundo.

Mi rol hoy por hoy, sigo revisando los scorecards de los paneles, de prácticamente todos los candidatos a los que terminamos haciendo la oferta, y muchas veces pasa que leés un scorecard que tiene una conclusión, pero leés el texto y la conclusión es otra, completamente distinta. Y nada, remarcar eso a la gente y entrenarlos a decir: "No, pará, acá estás diciendo que sí porque es una mentira cómoda, no porque es lo que vos creés realmente".

Algo que aprendí del CTO de Ramp, Karim, es un poco eso, de confrontar a la gente no porque creas que están equivocados necesariamente, sino por el simple hecho de confrontarlos y ver qué hacen. Insisten en su posición, entonces están más convencidos de lo que vos creías, o no insisten en su posición, entonces realmente es como que dijeran: "Pongo esto, pero no tenían una posición tan formada". Eso me parece súper interesante.

—A mí me pasa, en la empresa, que ahora cuando contratamos para Silver, todo el equipo entrevista primero, yo estoy involucrado, hago una, qué sé yo, pero después viene como la debrief. Y la debrief es un momento donde lo que ellos piensan es una cosa, y cuando lo dicen en público, como en el debrief, es distinto. Como que no machean las cosas, ¿no? Porque yo tengo la decisión final si se contrata o no, lógico, pero obviamente me tiene que gustar mucho una persona si ellos dicen todos no y yo digo que sí, tengo que estar muy jugado para hacer algo como eso. Pero hay veces que están hablando así y dicen, nosotros hablamos y tenemos una idea, ¿viste? Tres yes y un no. Es bastante positivo, ¿qué pasó? Y después le digo, bueno, cuénteme cada uno, y todos van hablando y es tipo, soft yes, soft yes, soft yes, no. Y yo le digo, chicos, ¿tengo que hacer algo acá? Yo no tengo que hacer nada, ya sabemos lo que está pasando.

Nosotros hacemos eso, revisamos todos los reclutas, revisan todos los feedbacks, y a veces un recluta técnico dice sí y no, y decimos, igual no nos alcanzó, no nos gustó. Hay algo que no cierra de los detalles. Toma tiempo hacer esto, ¿eh?

—La política que tiene un poco Karim es buscar spikes en un candidato, buscar cosas en las que sean muy proficientes por más que tengan algunas partes más ásperas. Entonces, capaz es más interesante un candidato que alguien vio algo, un destello de brillantez, pero otra persona dijo no o no me convence del todo, que un candidato que pasó raspando en todas las entrevistas.

—Y ahora, en este proceso que vos te tocó manejar un poquito el equipo de talento, y después habrán conseguido otro Head of Talent que volvió a tomar las riendas, ¿no viste valor en seguir haciendo parte de ese trabajo desde la vista de ingeniero? Cada tanto ir con el equipo a decir, bueno, calibremos estas cosas que no están funcionando del todo bien, eso lo seguís haciendo.

—Sí, ese partnership lo sigo haciendo, como te digo, revisar todos los scores todo el tiempo. Después de una on-site, básicamente el panel interno de la on-site decide si es un go o no go. Ahí pasa a mí y a un par de ingenieros más que revisamos y capaz les hacemos un pushback. De ahí lo revisan el CTO, el CEO y el COO, y de ahí finalmente vamos a una oferta. Pero sí, es un proceso bastante adversarial, porque es lo que nos hace mantener una vara bien alta.

—Ese review del CTO o del CEO para una empresa que ya tiene Ramp, ¿cuántos programadores tiene Ramp? ¿200?

—No, somos unos 350 o 400 a esta altura.

—Llega un momento donde para 350, hagamos este ejercicio, los próximos 350, el CTO tiene que ver 350 perfiles y firmar con gente que no va a poder hablarle. Nosotros tuvimos un intercambio en Twitter sobre esto, yo soy un poquito escéptico de que eso tiene mucho valor. No sé cómo lo ves vos, el tema de que el CTO firme, que pueda rechazar gente que no conoció, no sé cómo lo ves vos.

—En la práctica es más un sistema de checks and balances que de otra cosa. Yo estoy en un montón de los paneles de entrevistas, entonces tengo una línea bastante directa de lo que se ve en los candidatos. Obviamente el CTO no va a estar en todas esas entrevistas, si va a una entrevista, honestamente, es para cerrar al candidato, no para ver si es bueno o no. El rol del CTO en ese caso, por ejemplo, es validar que los razonamientos que usó la gente que llevó a la decisión del hire están bien fundados y no es por una cuestión de inercia, básicamente. Pasa más por ese lado.

—Yo pienso que hay que estar muy deliberate en hiring, pero llega un volumen que ya no sé cómo funciona. Somos ocho, somos diez. Yo lo que siempre dije en esta empresa, desde que entré, es que me preocupa que a medida que la empresa crezca, que salga a la bolsa, que vaya bajando la vara. Y llega un momento que dejas de crecer porque el crecimiento es una función de la calidad del talento que tenés, en buena medida. Y por suerte Karim era bastante receptivo de esta idea, entonces siempre nos tomamos muy en serio el tema de no bajar la vara. Y es difícil porque a medida que vas creciendo como empresa, obviamente terminás contratando gente muy buena y otra gente que está mucho más cerca de la vara. Y hay gente que obviamente te va a decir, che, esta persona está más o menos parecida a esta otra. Y yo lo que siempre digo es, en un long enough timeline, esa función de decir, che, Jorge es más o menos parecido a este candidato, podemos contratar al candidato. Y después decís, che, el candidato este es parecido al candidato que acabamos de contratar hace seis meses. Y terminan llegando a esos McDonald's. Entonces es un rol súper antagonista porque terminás confrontando a gente que le decís, che, mira, la vara hay que dibujarla en algún lado y no moverse de ahí porque termina mal.

Otro ejemplo reciente que tuvimos fue algo que yo creo que es muy importante, es no permitir que los equipos controlen su funnel de recruiting de punta a punta. Si vas a reclutar backend engineers para travel, por decir, no puede pasar que los entrevistadores sean todo el equipo de travel. ¿Por qué? Porque si hacés eso a través de todo el equipo, pasás de tener un único funnel a tener muchos silos y capaz en alguno es mucho más ancho el tubo que en otras partes de la empresa. Entonces capaz el equipo de travel tiene una vara más alta y no pasa nadie. Y capaz el equipo de financial products tiene una vara mucho más baja y pasa todo el mundo. Y después este problema de, che, Jorgito, se acentuó un montón porque la gente dice, che, el equipo de financial products tiene un montón de gente que nada peor y funciona, están ahí.

—¿Sos un plomero? ¿Esto es plomería? ¿Estás tratando de tapar los agujeros para...?

—Sí, sí. Ingeniería es eso al cabo, ¿no? Ver cuáles son los cuellos de botella, cuáles son los caños más grandes y más tapados y ver cómo destaparlos. Te puede pasar tanto en esto como en, nada, tenemos un bottleneck de reclutar diseñadores y en este momento el output que podemos tener en el producto es tanto porque tenemos un diseñador para 15 ingenieros y bueno, hay que rebuscársela. Después de unos meses te pasa esto de frontend. Esto es literalmente lo que pasó cuando yo entré. Había muy pocos diseñadores, contrataron diseñadores y frontend por seis, ocho meses de una empresa de tres años. No contratamos ni a uno y teníamos que contratar un montón. Y bueno, tenés que ir ajustando eso y decir, nosotros podemos, no por esto vamos a contratar a cualquiera que se nos cruce por la puerta porque morimos. Y esa fue una decisión que costó mucho sostener a través de los meses, pero bueno, pagó.

—Yo hago esta mención para la audiencia. Yo estaba haciendo recruiting freelance en esa época cuando me crucé con Ramp a través de un partner y fue 2021-2022, pero particularmente 2021 fue. Que fue el pico donde se bajó la vara en todas las empresas. O sea, que Ramp haya mantenido la vara o hasta la haya subido fue súper contratendencial, completamente contratendencial. Yo me acuerdo que tenía un cliente, justo el que mencioné, que le está yendo bárbaro. Me acuerdo que le estaba buscando dos perfiles y vino uno y dijo, no, es que yo tengo una oferta de 6.000 dólares allá. Yo le digo, no, Pertin, es justo Pertin. Paletti ofrece 7, tenés que ir y hacer las entrevistas, que te vaya bien. El tipo dijo, no, no, tiene que ser 7.000 y sin entrevistas. Y yo me doy vuelta, yo como recruiter externo que cobro por metidos, me doy vuelta y le digo, volalo a la mierda. ¿Qué es esto? Encima sin entrevistar. Y claro, porque al otro le habían ofertado sin entrevistar.

—A mí me parece una locura total por una cuestión de, vos, ¿qué es lo que estás buscando con un trabajo? ¿Estás buscando estar rodeado de gente que tenga tu capacidad o más y de la que puedas aprender? ¿O un sueldo? Eso me parece que es la diferencia. Si estás buscando un sueldo, bueno, y no querés intimidarte, está bien. Ser programador puede darte ciertos lujos. Pero a mí me parece como, en función del crecimiento personal, de querer estar rodeado de gente de la que puedas aprender. En el día a día, es una parte importantísima de tu vida estar con gente que está capacitada y de la que vayas a aprender. Tenés que evaluar como candidato cuáles son las medidas que toman para mantener afuera a gente que no está a tu altura. Y bueno, buscar un poco el mercado, ¿no? ¿Qué es la vara más baja o más alta a la que podés llegar?

—Yo siempre digo, tenés que entrar a la empresa que tiene el proceso de entrevistas más difícil que puedas pasar.

—¿Y cuál es la que paga más? Primero empecé por acá.

—Yo creo que es un problema general en Argentina. Yo lo veo como recruiter. Argentina no es un país pobre. Uno no habla mucho de la situación socioeconómica de los candidatos, porque se supone que uno tiene que ser ciego, esas cosas. Pero está la pirámide de demás lados, ¿no? Está la pirámide y está el tipo que es clase media, clase media baja, está buscando sobrevivir primero, y tiene una mentalidad muy orientada a eso primero. Percibe toda seguridad. Entonces, igual le decís, el proceso de entrevistas es difícil, es peor para ellos. O sea, lo ven como es un riesgo a mi seguridad. Entonces, es como que hay un candidato que no le podés hablar así. O sea, el trabajo no lo tenés todavía.

Hoy leía un post en r/devsarg que decía: "Fui a una entrevista de trabajo y sentí que me estaban interrogando". Le habían hecho preguntas como decirte: "Dibujá una casa con un perro y agregale una hamaca". Y el tipo estaba completamente superado por eso. No entiendo, ¿qué esperás de una entrevista? ¿La buscaste en el diccionario la palabra entrevista?

—Seguridad. Esperan seguridad. En serio, no lo digo en joda. Esperan seguridad. Y cuando le decís que es un lugar exigente, que es intelectual, que se trabaja bien, que hay metas ambiciosas, todo eso lo perciben negativo. Lo perciben negativo porque dicen, es un lugar donde me puede salir mal. Mi objetivo es supervivencia. Es muy distinto. Para mí no es tan equivocado. Simplemente que necesitan un pase interín de seguridad.

—Sí, sí. Es un paradigma completamente diferente.

—Lo importante es eso. El crecimiento que puedas tener porque si no, terminás completamente aburrido por más éxito que tengas monetariamente.

---

Cierre

Bueno, espectacular la charla. Nos excedimos un montón. Así que te quiero liberar, tenés 70 muñecos que tenés que manejar ahí. Te van a estar matando en el Slack. Realmente un placer enorme haber conectado. Y bueno, obviamente, mándenle en LinkedIn un mensajito si quieren aplicar a Ramp. Vuelvanlo locos. 100 millones de mensajes, mándenle.

—Más que bienvenido. nbevacqua@ramp.com

Listo. Bueno, un gusto.

---

Si les gustó el podcast, denle follow para saber de los nuevos episodios y síganme en Twitter en @Conanbatt.