Bienvenidos a Startup Insights Stories de Indic, un podcast donde hablamos de startups, negocio y
tecnología. El podcast de esa semana lo patrocina Factorial, centraliza la información de los
empleados y automatiza todo el proceso administrativo en un simple portal, gestiona para ti pagaciones,
el control horario, la ordenación de todos los documentos, contratos, incluyendo sus firmas
digitales, el proceso de nóminas, el control de turnos, el reclutamiento de la selección,
la evaluación del desempeño, entre muchos otros. Utiliza el código INNIC para conseguir un descuento
del 20% durante los primeros tres meses. Conectate a través de la web FactorialHR.es
Bienvenidos una semana más al podcast de INNIC, yo soy Bernat Farrero y esta semana estoy con
Pau Ramón Revilla. Pau es el CTO de Factorial, una persona clave para estos cuatro años de
Factorial para el crecimiento y para la construcción del producto, que es la parte core fundamental
de Factorial. Y Pau es el CTO, con lo cual CTO es uno de los problemas principales que tiene
todos los emprendedores que nos escuchan, o sea, encontrarlo, sobre todo encontrarlo. Desde INNIC
la petición que más recibimos es conocéis a un CTO. Si uno escucha esto cien veces o más mil
veces creo, no lo he escuchado nunca. Entonces es muy interesante para todo el mundo entender que es
un CTO, ¿no? ¿Cómo se hace? ¿Dónde están los CTOs? Y hoy me gustaría hablar un poco de eso,
de tu experiencia. No solo tú has crecido en varias compañías como CTO de developer a CTO,
sino también has conocido muy bien el entorno tecnológico tanto de España como internacional,
con lo cual creo que tu experiencia Pau es muy importante. Pero vamos al origen. Tú estudias
en multimedia, trabajas en varias agencias. ¿En qué momento empiezas a trabajar en una
compañía haciendo de developer que luego sería el sitio donde pasarías a ser CTO?
Bueno, yo creo que el rol de CTO es un rol bastante exciental, que muchos developers se
encuentran en ese rol sin peligro. En cierto modo, hay un momento donde en general el primer
ingeniero de una empresa de repente dice, hay que contratar más gente, pues venga, lo haces tú.
Y un poco de repente esa persona se encarga de empezar a formar esta organización. En mi caso,
en particular, fue un poco distinto porque yo estuve trabajando en una empresa donde había
un equipo muy senior de desarrollo que les vendió un proyecto muy grande al CEO, que harían un
proyecto en seis meses, que no sé qué. Bueno, una historia muy rocambolesca y al cabo de tres meses,
el equipo se deshació y me quedé yo solo al mando de Timón. Entonces, ahí no hubo otra opción,
que el proyecto tiene que avanzar, así que montate un equipo y tire aparentemente con el proyecto.
Entonces, ahí fue un poco un rol exciental, pero que luego, la verdad, que me ha ido bastante bien.
¿Qué compañera es esta? Production Media Networks, de Andreas, que estuvo aquí también.
Que también lo pasó. O sea, te quedaste solo en una compañía donde tuvies entrado como
developer y, entre otras cosas, porque habíais visto un equipo senior que te había gustado, ¿no?
Correcto. Y se fueron todo el mundo, pero tú no, ¿por qué no?
Correcto. Bueno, primero de todo, porque era un proyecto interesante y también porque la
oportunidad que se me daba de liderar un equipo, que en aquel entonces tampoco no era CTO,
porque yo tampoco no conocía muy bien los términos, era un chavalín. Pero bueno,
me gustaba la idea, empezar a contratar gente, intentar formarlos, pensar en arquitectura.
O sea, hay un rango de cosas que no había hecho hasta entonces, que me pareció interesante.
Cosa que no es habitual. Muchos developers no les interesa esta parte. A muchos no les
interesa. Correcto. De hecho, a la gran mayoría de developers que yo entrevisto,
les interesa más el camino técnico, el deser excedentes en tecnología, que no el de manejar
organizaciones, personas, procesos, etcétera. Pero bueno, siempre hay un subset de gente que
sí que lo encuentra como otro problema de ingeniería, donde visualizan equipos y personas
como si fueran en granajes de un problema ingenieril. Y hay gente que también va por
esa perciente. ¿Cómo fue esta experiencia? A ver, fue difícil al principio, porque no
tenía ni idea. Entonces, al final te vas metiendo muchos palos. Pero bueno, la verdad es que me ha
ayudado bastante bien, porque desde ese trabajo he ido encadenando varios trabajos con la misma
posición. En cada uno de ellos he aprendido cosas distintas. En cada uno de ellos he probado
cosas tradicionalmente diferentes. Entonces, al final, creo que tengo un mapa bastante completo
ya de todas las posibilidades que le ofrece este rol. Para repasar un poco la historia,
es que yo creo que es bastante interesante tu historia. En un momento dado, conoces a Pablo
Villalba, que ha estado en el podcast con su proyecto Teambox, en algún momento que lo
se llamó Redbooth. ¿Cómo conoces a Pablo Villalba? Bueno, conocí en un meetup tecnológico
aquí en Barcelona. Pablo siempre va muy a tope. Ya lo has visto y el tío vino muy acelerado
y me preguntó, ¿tú eres de Veloper? Sí, sí. ¿Eres la polla o no eres la polla? Yo era
muy humilde y digo, no, no, yo no soy la polla. Entonces, nada, yo no solo estoy buscando gente
que sea la polla. Acabo de tres meses, me llamaron igualmente, tenía un proyecto. A pesar de
no haberte declarado cómo ser la polla. Bueno, no encontraron a nadie que sea la polla, supongo.
Entonces, fueron a buscar la gente que era un poco menos que eso. Entonces me contactaron
para un proyecto que tenían. Entonces, accedía a colaborar con ellos. A pesar de eso, luego
me fui a Estados Unidos a buscar suerte, volví sin suerte. Y, a final, accedí a trabajar
con ellos. En aquel entonces estaba Jordi, que es ahora el CEO de Factoria, estaba Jordi
como CTO. Y, entonces, él también se marchó del proyecto. Y otra vez, pues, accidentalmente
fui CTO a Timebox, me creen, entonces. Es curioso porque Pablo Villarva, una de las
cosas que yo creo que hizo muy bien y que sigue haciendo muy bien, es atraer talento
técnico. O sea, algo tendrá, aparte de ir por ahí diciendo a la gente si es la polla,
¿no? O sea, realmente el equipo que ha montado Pablo en general ha sido un equipo técnicamente
bastante competente, ¿no? Pablo dio una técnica de convencer a gente muy potente, que es
que cuando va hablando te va haciendo así con la cabeza. Entonces tú involuntariamente
dices que es una... No sé si es el secreto, pero yo lo cuento a todo el mundo por si se
encuentra Pablo. Vigilad cuando hace... va haciendo así con la cabeza. Vale, y entonces
lo siento Pablo para descubrir tus secretos. Entonces entras en Redbooth, bueno, era Timebox,
en aquella época. Jordi era el CTO. ¿Cómo evoluciona? O sea, ¿qué cambia en aquel momento
donde ya había un equipo más grande, ¿no? Y un reto bastante importante y había Venture
Capital, había velocidad, o sea, necesidad de velocidad. ¿Cómo cambia tu rol cuando
pasa a ser el CTO? Acá cambia mucho y por varias razones, ¿no? Ahí había un proyecto
que se había hecho de forma muy orgánica. O sea, había un proyecto que era Open Source,
había entrado a mucha gente colaborando en Open Source, luego los contrataban, había
un código que era bastante legas, ¿no? O sea, que había evolucionado muy orgánicamente
y también un equipo que tampoco no estaba muy profesional, o sea, no era muy profesional
en cuanto a estructura, procesos, etcétera. Deben un poco un reflejo de la forma de trabajar
de Pablo, que era muy oportunista buscando ideas, ahora vamos a hacer esto y tal, que
es lo que he tocado en aquel momento, ¿vale? O sea, al final, tú tienes que abrirte paso
en el mercado y no se trata de tener un equipo profesional, no tienes la hora de aprovechar
las oportunidades al máximo posible. Ahora, cuando entra Capital, de repente, las cosas
cambian porque tienes que hacer evolucionar el equipo, tienes que hacerlo crecer y eso
tiene pues unos retos bastante grandes que ya no puedes hacerlo de la misma forma. Eso
es un paso que pasa en casi todas las empresas, que son una empresa de 10 ingenieros y una
de 50 ingenieros no tiene nada que ver y no puedes aplicar el mismo manual para uno
y que la otra, ¿vale? Porque, como he dicho, una tiene que ser muy ágil a la hora de
buscar oportunidades porque al principio no eres nadie, no tienes nada que perder. A
medida que te vas afianzando en el mercado tienes que, obviamente, hacer que el equipo
sea más sólido y que puedas escalarlo.
Efectivamente, esto es una cosa que luego también pasaría a factoria, ¿no? Empezaremos
con un equipo muy pequeño y muy oportunístico buscando el mercado, probando cosas y luego
cabríamos enfocándonos a un problema, ¿no? ¿Cómo se enfoca desde un punto de vista
también tecnológico cuando has desarrollado cosas que luego, al final, no son core? ¿Qué
haces? ¿Las tiras de la basura? ¿Se quedan ahí? ¿Cómo se hace esto?
Sí, al final, a mí me gusta mucho ver un equipo de producto y desarrollo que yo siempre
los pongo en el mismo saco porque creo que separarlos es un error y eso es otro tema,
pero yo siempre lo veo como un organismo o una máquina que genera ideas, genera hipótesis,
las intenta variedar o refutar y luego depende del resultado, pues, o se queda en el producto
o se va del producto.
Entonces, si tú lo visualizas de esta forma y organizas los procesos, la tecnología y
todo de una forma, que esas hipótesis sean fáciles de borrar. De hecho, es una máxima
que tenemos en Factorial, es que el código es un precio que tenemos que pagar, no es
algo que nos guste hacer. Entonces, siempre que generamos un nuevo componente o una nueva
funcionalidad o lo que sea, ya lo pensamos de cara qué pasa si el día de mañana lo
tenemos que borrar. Y lo más fácil que se debe borrarlo, más desacoplado el resto vemos
qué es.
Y, de hecho, en Factorial lo hemos hecho varias veces, algunas más frustrantes que otras,
pero muchas veces hemos tenido que coger partes muy grandes del producto directamente
de tierras a basura. Y intentar que el equipo lo celebre en lugar de decir, joder, con las
horas que he dedicado a esto, qué lástima. Porque, al final, si tú piensas que el código
es un precio a pagar y es un lastre que tienes, no es algo que tengas que estar orgulloso
de ello. Entonces, yo creo que, al final, resultaos más positivos.
Es curioso porque antiguamente se había medido la productividad del desarrollador con líneas
de código, ¿no?
Bueno, la publicidad del desarrollador es… O sea, hay infinidad de temas a hablar ahí,
pero la conclusión final o actual es que no se puede medir. Así que nosotros la medimos
en cantidad de información que recopilamos. Durante un cuéter hemos conseguido validar
hipótesis o refutarlas. O sea, hemos conseguido ganar más información sobre el mercado y
si el mercado ha respondido positivamente lo hemos podido aprovechar, hemos podido aprofundizar
en ese aprendizaje.
Una de las conclusiones de la mayoría de gente que ve la aplicación de Factorial es
que el stack, la tecnología como está hecha, es brutal. Y también el nivel de talento
que hay en Factorial, a nivel técnico, es brutal. Yo creo que hay consenso. Todo el
mundo que se ha acercado a Factorial dice esto, ¿no? ¿Qué tiene una aplicación robusta,
bien hecha, que la gente diga, hostia, qué bien hecho está esto? ¿Por qué? ¿Por qué
dicen esto?
Es muy difícil. Yo voy a divergir un poco de la respuesta que esperas, pero una cosa
que yo sí que aprendí muy bien en la antioempresa en Teambox Barra Redbus es la combinación
de producto y tecnología, que lo he mencionado antes. Normalmente son organizaciones que
trabajan de forma opuesta o separada o en tensión y en Factorial desde el primer día
intentamos que tanto César como yo, que César lidera producto y tecnología, trabajemos
como colaboradores y trabajemos de forma integrada, sin tener un pensamiento de cadena
de montaje donde tienes la persona de producto que piensa y luego tiene un artefacto que
es un diseño o lo que sea y se lo pasa al developer, el developer ejecuta, sino que
en Factorial pensamos más conjuntamente como tenemos un problema en el mercado, trabajan
los ingenieros y producto de forma conjunta y piensan de forma conjunta y ejecutan de
forma conjunta y luego entregamos esto al cliente final. Y pareciendo no entería, pero
los productos que salen de una organización donde productos de tecnología están separados
lo puedes ver y notar que no tienen el mismo nivel de robustez y de detalle. Entonces ya
no es tanto una, para mí ya no es un tema tan técnico de qué tipo de tecnología o
stack o developers, sino organizativamente, yo creo que juntar y tener al equipo de producto
y tecnología trabajando de forma colaborativa tiene un impacto mayor en la calidad del software
que no cualquier otra tecnología o cosa que puedas aplicar ahí.
Eso que es muy evidente en las compañías cuando empiezan, porque acaba en una misma
mesa y todo el mundo trabaja junto, de hecho en Factorial pues todos tenemos el mismo perfil,
con lo cual todo el mundo era producto y todo el mundo era tecnología y tal, eso a medida
que va creciendo la compañía se va complicando. Entonces ¿qué esperas tú de la relación
de producto? ¿Cómo se tangibiliza esto trabajar conjuntamente? ¿Qué significa eso en el día
a día?
Bueno, no es una cosa que sí que trabajamos mucho y es una parada continua, no es algo
que haces y que da hecho y ya está, es sobre todo en esos mecanismos que te he dicho de
la generación de una idea hasta la ejecución y la entrega al cliente final. Entonces nosotros
lo que hacemos es separar en distintos equipos y le damos al equipo toda la autonomía para
solucionar una categoría de problemas. Si tenemos un equipo que está trabajando en
Melonvento en la parte de reportes, pues ese equipo todo conjuntamente va a estar pensando
en problemas de reportes, va a estar pensando en cosas y en soluciones. Entonces constantemente
estamos trabajando ¿cómo se generan esas ideas? ¿Cómo se ordenan? ¿Cómo se hacen
las reuniones para que todo el mundo tenga voz? ¿Cómo evitamos que se creen jerarquías?
Porque igual hay perfiles que son más introvertidos y más extrovertidos. Es una parada continua
que tienes que hacer porque también hay muchos vídeos del pasado y de otras empresas, etcétera
donde sí que existe esta jerarquía y la gente tiende a ir hacia ahí, pero nosotros
luchamos constantemente para que esto no sea así y haya este espíritu de colaboración
y de una hercipa contabilití que son el valor principal del equipo de tecnología.
¿Todo el mundo tiene ideas? No, todo el mundo tiene ideas, no. Y es algo que también hay
que rebajar constantemente. Y he hecho en los One-O-One siempre lo mencionamos. ¿Cómo
has colaborado? ¿Cómo has propuesto cosas o te has limitado a ejecutar? Yo quiero que
la gente colabore. Yo quiero que la gente sienta el problema y piensa. ¿Cómo lo puedes
solucionar? Porque al final si tú llegas a la conclusión de una solución seguramente
la vas a ejecutar mucho mejor que si no alguien te dice, por cierto, esta es la solución
del problema, me la puedes ejecutar. Pero es difícil. Y sobre todo a gente que viene
de otras empresas igual en las otras empresas no ha tenido que ponerse el sombrero de pensar
y aquí de repente le estamos pidiendo o no. Te toca pensar, no solo ejecutar. Es complicado.
Yo creo que entre producto y desarrollo muchas veces se reparten el qué y el cómo. El qué
muchas veces lo piensa producto, el cómo, desarrollo. Desafortunadamente, igual desarrollo
podría pensar el qué también. Sí, o sea, tenemos esta división también porque somos
incapaces de encontrar gente que haga todo el stack. O sea, idealmente tendríamos gente
que te hace desde los píxeles hasta el deploy, al front and back en todo. Obviamente esto
no es común, los hay. De hecho, aquí tenemos varias gente que sí que es capaz de desarrollar
soluciones totalmente, gente que puede, ellos solos, desarrollar una startup o cualquier
cosa. Pero no es tan fácil. Entonces, la división que hemos hecho es, bueno, habrá
una gente que tiene un skill set que es más orientado al producto o más de diseño, porque
la gente producto en factorial también diseña y otra gente que es más de tecnología. Hemos
hecho esta división, pero idealmente en el mundo utópico tendríamos solo una función
de generalistas que pudieran solventar problemas de principio a fin. Ahora tenemos esa separación,
aún así les pedimos a todos que piensen. Pero como tú dices, casi siempre recae el
qué en producto y el cómo en producto y desarrollo.
Otro pregunta que es del por qué, que muy poca gente se hace, la razón por la que me
gustó César el primer día que lo conocí, es porque es una persona que pregunta bastante
a menudo el por qué. Y eso ya es el pensamiento estratégico, es la visión de la compañía
y la estrategia.
Sí, eso es más trabajo de management. Al final, es nosotros dando la chapa cada semana
sobre la visión, sobre dónde estamos, sobre dónde queremos estar, que también es parte
del rol de este tipo. Hablando de especialización, tú hablas de que en factora hay una posición
muy generalista. En general, la posición típica en factoria, en producto y en venta,
ahí en producto y en tecnología, es básicamente generalista. Incluso los diseñadores son
también gente de producto que diseña. ¿Qué pasa con la especialización en cuanto a las
partes del stack? ¿Cómo está estructurado el equipo en ese sentido?
Al final, en factoria, la pesar de que ya lleva cuatro años, yo creo que sigue estando
en una etapa bastante cercana a la experimentación. No somos una empresa que ya sabemos exactamente
el camino, el único que hace falta es ejecutar hacia ese camino, sino que sigamos explorando
bastante nuevo territorio. Eso significa que yo lo que necesito es mucha agilidad. El especialista
no tiene esta agilidad, porque al final el especialista puede hacer una sola cosa y la
hace muy bien, el erizo, de las dos metáforas de erizo y el zorro. Yo creo que tiene mucha
ventaja tener especialistas cuando la empresa tiene muy claro el camino que tiene que seguir
y tienes que ejecutar de forma muy agresiva y muy directa. En nuestro caso, yo creo que
seguimos estando en un sitio donde aún seguimos navegando bastante incógnitas, aún tenemos
muchas hipótesis que no tenemos respuesta de ellas. Por tanto, prefiero tener un equipo
que sea lo más flexible posible. Nosotros, cada quarter, desmontamos los equipos, os
formamos de nuevo y no tenemos ningún tipo de limitación, porque las piezas son intercambiables.
Obviamente, cada uno hay gente que sabe más de una cosa, hay gente que sabe más de otra,
pero cualquier persona en factorial puede encargarse de solucionar cualquier problema.
Entonces, ahora mismo, bueno, yo no estoy casado con decir solo fullstack y ya está,
pero creo que en el estadio que estamos ahora hay que utilizar por eso. Y también por otra
cosa que creo que es importante, ya lo mencionado antes, que es por el accountability, que para
mí es muy importante. Si tú quieres que alguien se sienta empoderado de tomar decisiones y
ejecutarlas, al final esa persona no puede formar parte de una cadena de montaje, porque
al final, si tú tienes una persona de producto, un diseñador, un back-end, un front-end y
un devops, cada uno siente solo un ership de su parte y aunque cada una de las partes
haya hecho el mejor trabajo que podía hacer, puede ser que el resultado final no sea el
correcto. Entonces, intentando limitar el número de steps y intentando paraizar al
máximo esta cadena de montaje, yo creo que consigues un producto que el cliente final
luego lo percibe como mucho más robusto y mucho mejor. Y ya el developer le motiva también.
Entonces, tú buscas perfiles full-stack principalmente, ¿no?
Sí.
Y luego los equipos van cambiando por todos lados de la aplicación, con lo cual no hay
ningún experto de ninguna parte de la aplicación.
Con el poco.
Que también es otro trade-off que tomamos. Al final, insisto que no es un manual que yo
tenga, que aplique rigorosamente, como he dicho en los rempieses he hecho otras cosas,
ahora mismo en el tacto que estamos experimentando con esta idea. Y un poco, hay varios motivos
por ello. Una de ellas es no me gusta tener especialistas sobre partes del producto, porque
cuando esa gente no está, de repente ya no puedes trabajar en esa parte del producto.
Aparte, hace que se cree mucha tradición oral. O sea, cuando hay un equipo muy fijo
que está trabajando en una parte muy específica, todo el mundo en ese equipo sabe cómo funciona
y se lo comunican de forma oralmente. Pero ese conocimiento no se persiste en ninguna
forma, cosa que con el cambio de trabajo remoto no es beneficioso.
Y aparte también, hay temas que creo que son interesantes, como evitar política, cuando
la agua se mueve no se pudre. También cuando tienes equipos que van cambiando, la gente
no tiene vendemente tiempo como para generar esa política de mi equipo, mis objetivos
y intentar luchar contra los otros. Hay bastantes ventajas. Hay desventajas, obviamente, que
es que cada cuéter hay un cambio de contexto. Entonces la gente tiene un ramp-up durante
el cuéter donde tiene que entender ese nuevo problema, tiene que conocer a esos nuevos
compañeros del equipo, tiene un cierto coste. Pero a nivel de management no se ayuda a
poder cambiar de dirección de forma más ágil. De forma similar, como he hablado antes
al generalista, seguramente, a medida que el factorio vaya madurando y tengamos más
claro el camino, seguramente esta rotación va a ir disminuiendo porque ya tenemos más
claridad, entonces podemos hacer commitments más largos. Quiero dedicar este grueso del
equipo a ir hacia esta dirección por cláteca muy clara. Ahora mismo, a verdad, es que cada
cuéter vamos ajustando bastante las prioridades del negocio.
No nos hace lentos, ¿no? El hecho de que todo el mundo tenga que aprender constantemente
cosas nuevas.
El entece un poco, pero yo creo que en el long-term la organización es más efectiva.
Es como documentar. Documentar es un coste que tú tienes, o sea, tú al final reaccionarás
es muy rápida y escribir es muy lento, pero cuando tú documentas de repente, cuando
haces un boarding de nuevos empleados, ese un boarding ya te tarda mucho menos, la gente
es productiva mucho más rápida, pero hay ciertos costes que tienes que pagar y tienes
que estar bastante, obviamente, bastante encima de que esos costes no sean demasiado altos,
pero yo creo que hay ciertos procesos que ayudan a que en el long-term tengas una organización
que sea escarable y que sea eficiente.
Oye, y estos perfiles full stack que saben hacer de todo, ¿son fáciles de encontrar?
¿Cómo los encuentras?
Ya, no son fáciles de encontrar, o sea, al final no es fácil de encontrar developers,
en general, o sea, como ya sabes, es uno de los mercados donde hay mucha menos oferta
que demanda, entonces hay muchos developers que casi todos tienen trabajo y muy pocos
que buscan trabajo, entonces es difícil ir a buscar developers.
Ahora, yo creo que con lo que nos ofrecemos de tener ownership de problemas y poder conseguir
dentro de una empresa tener un impacto que no solo es ser un enganaje dentro de un enganaje
de montaje, la gente lo gusta bastante, entonces están dispuestos a renunciar a esa especialización
para poder tener ese impacto y la gente lo ve y lo entiende.
Ahora, si siempre te encuentras developers que dicen, no, no, yo quiero ser el mejor
developer de JavaScript, yo quiero ser el mejor de tal, entonces, bueno, con ese no hay
match.
Y lo dejamos muy clavos en esa entrevista, ¿sí?
Porque tampoco no queremos que la gente venga y luego se deseducione.
Porque tú en el mercado te encuentras back-enders o front-enders, ¿no?
Pero les convences de que esto les va a interesar, les va a gustar y van a ser mejores profesionales
siendo más canalistas.
Que es una hipótesis que tengo que, a menos a mí me ha ayudado, o sea, yo conozco un
poco de todo, no sois precisamente nada, y a mí me gusta porque puedo tener una visión
más global y yo que la gente también lo valora, porque, sobre todo, si son developers
que tienen un poco de espíritu o emprendedor, que también me gusta bastante, es algo que
hago bastante, gente que tenga inquietudes, que tenga ideas, que esté todo rato consumiendo
productos y tal, etcétera, entonces ellos también les interesa porque se ven que igual
en un futuro ellos mismos también pueden ser CTOs o pueden montar su propia empresa
porque tienen una visión más holística.
Entonces, también es un traductor, al final, si eres un especialista, puedes conseguir
igual un trabajo muy bien pagado en algún sitio que buscan el mejor de tal y tal, pero
yo que soy canalista te abre otro tipo de puertas que también son buenas.
¿Cuál es el perfil que busca Factoria? Para la gente que nos escuche. Aparte, en perfil
generalista, entiendo que generalista también incluye DevOps.
Sí, aunque se encuentra menos, o sea, hay mucha menos gente que tenga desde el front
hasta sistemas, o sea, así que eso ya es un poco más, más primero.
En Factoria tenemos sistemas. Sí, o sea, hay varias gente que sí que tiene
estas kitset, pero no todos.
Pero aparte, hay alguien que se encarga solo el sistema, que da soporte también en eso.
Entonces, ¿qué tiene esta persona que busca Factoria?
Al final, para mí un tema muy importante y es algo ya no tan técnico, es actitud.
A mí me gusta gente que sea inquieta y que tenga una actitud positiva durante las cosas,
que vea problemas y no solo los mía de la cara, sino que diga, este problema me motiva
y voy a poner todo lo que tengo encima para resolver ese problema.
Hay gente que tenga este espíritu de querer solucionar problemas.
Al final, que entiendan que tecnología es un vehículo, no es la razón de ser.
Entonces, para mí es súper importante, porque al final, yo lo que no quiero hacer es dar
trabajo a la gente.
Lo que quiero es que la gente se encuentre el trabajo, que está dentro de un equipo,
con el equipo, descubran qué problemas hay, cómo solucionarlos y, entonces, ejecutar
la solución.
Al final, hay que hacerlo, obviamente.
A nivel técnico, contratamos de todo, o sea, contratamos de junior a principal y contratamos
esto de igual.
Obviamente, cada uno de los steps busco cosas distintas.
En un junior contratamos por potencial, gente que vemos que tiene mucho potencial, que sabe
suficiente de tecnología como para que no tenga una dependencia infinita con el resto
del equipo, pero que tenga mucho potencial.
Y a partir de ahí, a medida que van evolucionando, ya miramos gente que pueda avanzar más en
abstractiones.
Porque, al final, en factoría, un problema grande que tenemos es que hay que abstraer
muchas cosas, pues un producto multi-país, un producto que arregla diferentes segmentos
de empresas.
Entonces, gente que tiene que poder, pues, cogiendo varios inputs individuales, pues
a visualizar una abstracción, peso ya en niveles más avanzados.
En nivel de tecnología, ¿de qué tiene que saber?
¿Qué stack tiene que dominar?
Normalmente contratamos que tengan la mitad del stack, como mínimo.
Hay gente que, si que no se viene con todo el stack, ¿vale?
¿Cuál es el stack?
Es rubir un rails en el backend y es, ya sabes, que piden el fonten con react.
Y normalmente la gente o viene con todo stack, que no te des perfecto porque el ramp-up
es muy rápido, pero en general, normalmente vienen con una parte o con la otra.
La vienen o con rails o vienen o con react.
Y a la otra la prenden el trabajo.
Más o menos en un mes ya están más o menos productivos, dependen de la persona, obviamente.
Hay gente más ágil aprendiendo y hay gente menos ágil.
¿Aplica gente a Factorian?
Mucha.
Mucha.
Sí, sí.
¿Qué ratio de aceptación tiene?
¿Qué ratio de aceptación?
A ver, conversión.
Ya.
Entre persona que aplica o persona que entra a trabajar.
Pregunta de persona de ventas, ¿eh?
Es difícil de decir porque también hacemos bastante screening de, o sea, en el funnel,
mucha de la gente que aplica, no vamos directamente a la entrevista telefónica, depende mucho
de cómo vemos el currículum, etcétera, pero…
¿El currículum o las experiencias previas que he tenido, código?
Bueno, el proceso es muy, o sea, el Factorian es muy fácil, o sea, primero recibimos o
recibimos la candidatura, ¿no?
Y luego hacemos una reunión, más si nos gusta, hacemos una reunión donde ponemos de
encima la mesa lo que nosotros estamos buscando y lo que ellos están buscando y miramos si
hay match.
Ahí lo ponemos todo, ponemos el sueldo, ponemos las condiciones, cómo trabajamos todo, ¿vale?
Para intentar decir, si quieres ir al siguiente step, es que los dos estamos seguro que nos
cuadra, pues nos cuadra los dos.
Y luego, después de esto, hacemos una plura técnica que es bastante rápida, diferencia
de otras empresas, donde la persona trae código que tenga en casa, o sea, cualquier código
que tenga, lo trae en una entrevista técnica con el equipo de Factoria, entonces hacemos
varias preguntas, vamos rascando un poco ahí para ver a nivel técnico cuánto sabe esa
persona.
O sea, ¿no tiene que hacer un ejercicio por su cuenta?
Intentamos que no.
Hay gente que te dice que no tiene código, entonces sí que tenemos unos anunciados…
¿Qué es raro, no?
Que no tenga código.
¿Es raro que no tenga código?
No, hay gente que trabaja, o sea, que trabaja muchos años en empresas donde nos hace opensores,
o no tienen proyectos o lo que sea, es bastante más común de lo que parece.
¿Sí?
Sí, sí.
Es incluso gente muy senior, mucha gente dice, no, pues voy a hacer el anunciado porque
no tengo ningún código compartible para… pero la gente que sí lo tiene está guay,
porque así cortamos el proceso y la gente lo valora.
Al final, un developer, si está buscando trabajo o está buscando un cambio, lo que no quiere
hacer es ocho ejercicios para ocho procesos distintos que luego no se servían de nada.
Entonces, intentamos ir rápido.
¿Y cuál es el plan de carrera?
Una persona que entra en Factorial, digamos, de una posición junior, ¿hasta dónde crece
qué posición es ahí, cuánto se paga, no sé si esto se puede contar?
Sí, sí, de hecho, lo hicimos siempre en la primera entrevista para dejarlo claro.
Yo pregunto, es que evidentemente sé todas las respuestas, ¿no?
Ya, ya, ya.
Como siempre, como cualquier otra entrevista.
Bueno, es una iniciativa que empezamos el año pasado, que es intentar hacer un plan
de carrera que estuviera público, no de alguna forma, y eso es una práctica bastante común,
que se hace bastante en equipos de tecnología, sobre todo para temas de objetividad, o sea,
tú no quieres compensar a la gente, dependiendo de sus habilidades de negociación, sino
que tú quieres de alguna forma estandarizar cómo se paga en la empresa y que todo el mundo
lo sepa y así todo el mundo sabe exactamente qué es lo que se espera de cada una posición
y cuál es el sueldo en cada una posición.
Obviamente, eso intenta que sea el máximo objetivo posible, pero nunca es 100% objetivo,
porque al final alguien decide en que esté bestas del career path.
En nuestro caso tenemos juniors, que están a 35.000, y esa posición, pues como he dicho,
se contracta por potencial, es gente que sí que sepa, o sea, gente que tiene ya habilidades
para, o sea, no es gente que no tiene ni idea, sino que tienen que ser capaces de añadir
valor a factorial, pero sí que es gente que normalmente requiere mucha ayuda de los compañeros,
preguntan mucho, etcétera, entonces nosotros los queremos, pues cuando crecen, crecen dentro
de la empresa, etcétera.
Nos traemos los mid, que están a 40.000, que los mid ya es el siguiente step después
del junior, y es gente que ya es un poco más autónoma, ya no pregunta tanto, puede
sostener problemas totalmente solos o solas sin ayuda, pero es gente que aún no abstrae
mucho, es gente que no tiene capacidad de construir soluciones globales, sino que cuando
soluciona algo, soluciona ese algo, y no se pregunta él, puede evitar que eso pase
en el futuro o cosas así, ¿no?
Entonces, tenemos los seniors, que están a 50.000, pienso sí que es un peso hueso de
la pantía, de hecho casi todo el equipo en factorial está en esta categoría, que
es, bueno, de brujos que ya tienen mucha experiencia, que sí quieren capacidad tecnológica muy
alta, son capaces de cada abstracciones, gente muy, muy potente, y por último tenemos
principals, que están a 75.000, que es gente que ya no solo ayuda a nivel de individuo
o contributor, sino que también ofrecen al resto del equipo una ayuda mucho más allá
de tecnologías, sino que mentorizan, bueno, gente que es un referente, entonces la gente
dentro del equipo de factorial no me temían a los principals como un malo.
¿Cómo se cambia de una posición a otra?
¿Pasa?
Sí, bueno, en el career path tenemos establecido lo que esperamos de cada unas posiciones,
y durante los one-on-ones lo evaluamos conjuntamente, vamos mirando paso a paso y tenemos una discusión
sobre, ah, esto creo que sí, esto creo que no, etcétera, y cuando vemos más o menos
que todo bien, entonces ya planteamos la siguiente posición.
Cuando no funciona un developer, o sea, cuando decides, oye, este tío, esta tía no está
funcionando, ¿no?
Bueno, hay muchas razones por las que un developer puede no funcionar, pero para mí la bandera
más alarmante es cuando alguien no añade valor, sino que quita valor, hay developers
que tienen actitudes más negativas y no saben convertidas a que es una negativa en
propuestas.
Entonces para mí eso es una manzana podida que pueda afectar al resto y es una alarma
bastante roja.
A mí me encanta la gente que es vocal, o sea, a mí me gusta cuando la gente expresa
sus opiniones y cree que hay cosas que pueden mejorar, porque es gente que me hace challenge
y es gente que me ayuda a mejorar la organización.
Eso tiene que venir acompañado siempre de propuestas o de algún tipo de alternativa,
o sea, si algo no está bien, vamos a pensar conjuntamente de qué forma se puede mejorar.
Entonces para mí cuando solo hay la parte negativa, para mí es una bandera roja y es…
Hablas de actitud, pero no hablas de componente técnica.
Sí, porque al final, o sea, yo creo que mucha gente valora mucho el conocimiento en general,
hacer los procesos mucho pasados en algoritmos, en tecnología, pero al final el conocimiento
es bastante barato hoy en día, te puedes formar de forma muy fácil de rectificar.
Si alguien no es bueno tecnologicamente, se puede rectificar de forma un poco más
fácil.
Pero si alguien tiene una actitud mala, es mucho más difícil indicir a ese cambio.
Sí, pero luego está la competencia técnica.
O sea, parte del conocimiento, la inteligencia, no sé cómo se puede expresar para desarrollar.
Obviamente si alguien no da, tampoco da, pasa que como te he dicho, un developer puede
fallar por muchas razones distintas, pero para mí la peor es actitud, porque es mucho
más difícil de cambiar.
A mí me gustan muchas oportunidades y durante los one-on-ones siempre trabajamos mucho
las cosas que están flojas, las cosas que no salen bien, lo intentamos trabajar y en
la mayor parte de casos yo creo que hay gente que igual está ahí en el filo y se puede
rectificar y se puede salvar, pero cuando es un tema de actitud es mucho más difícil,
mucho más.
Interesante, y siguiendo hablando de la organización, ¿cómo ha evolucionado la organización
en cuanto a management, middle management, en cuanto a equipos desde el inicio que éramos
poca gente hasta ahora que igual hay unos 30 personas?
Bueno, al final, llega un punto crítico que son los 10 ingenieros donde hay que partir.
O sea, llega un momento donde ya no puedes llegar a conclusiones con toda la misma gente
en la misma sala, es mucho más difícil y también cuanto más gente tienes, más sí
duro y el ownership, o sea, tú tienes una pelota y cae entre medio de dos personas,
nadie va, ¿no?
Entonces, al final tú lo que intentas hacer es conseguir núcleos de gente, equipos en
este caso, donde sean suficientes como para que puedan tener un impacto, pero suficientemente
pocos para que el ownership lo puedan sentir todavía, ¿no?
Que no se sienten como, bueno, si no hago nada no pasa nada, ¿no?
Al final, si es un equipo 4, pues ahí sientes un cuarto de responsabilidad de ese equipo
y también donde la toma de decisiones sea un poco más efectiva.
Que eso pasa mucho.
Al final, hay ciertos debates que cuando se plantean con todo equipo de tecnología no
hay forma de solucionarlos.
Entonces, muchas veces escoger ese debate y decir, pues solo doy a un equipo y ese equipo
sí que va a tener menos gente, por lo tanto va a poder ejecutar en ese problema.
No hay un líder por equipo.
Ahora sí, este cuerdere hemos añadido esta función y sí es una función dentro de cada
equipo.
¿Vale?
Cortatoria también, por ahora.
¿Tú tienes algún tipo de middle management entre los equipos y tú?
Sí, está Uriol que es mi mano derecha con...
¿Está en un podcast también?
Sí.
Todos por aquí.
Toda la casa pasa por aquí.
Yo sí, está Uriol que me ayuda con todo el tema de organizativo.
De hecho, solo somos yo y Uriol que hacemos funciones de manager, que es una cosa que
hemos olvidado decir, que en casi todos los career paths que te encuentras en empresas
tecnologías siempre tienes un do a paz, que es el camino del ingeniero y el camino del
manager.
En nuestro caso, en el camino del manager somos yo y Uriol, y los que menos nos encargamos
de estar en todas las reuniones, ver un poco como que de mediencia se quedan entre los
equipos, contratar, echar si hay que echar a alguien, formar a la gente, o sea, todo
lo que es mantener la organización funcionando.
Lo que le damos el espacio negativo, que es tener todos los equipos, pues todo lo que
hay entre medio de eso nos encargamos yo y Uriol.
Pero no es un middle management como tal, sino que los dos ejercemos la misma función,
pero con diferentes equipos y diferentes personas.
¿Picas código?
Sí, cada día.
¿Sí?
Sí, sí.
¿Tienes tiempo?
A veces sí, a veces no.
De hecho, me sirve para ver cuándo me falta tiempo, es como un bácero.
Al final, yo por defecto, todo el mundo me pide cosas, mi calendario, ese es el calendario
de todo el mundo, entonces siempre se llena.
Entonces, cuando yo veo que en una semana no puedo picar solitamente código, ahí ya
veo que o hay algún proceso que es suficiente y pasa demasiadas cosas por mí, o igual es
hora de elegar cosas con Uriol, o igual es hora de contratar a otra persona también
para tener apoyo, pero me sirve de bácero también para medir qué capacidad tengo de
tiempo.
¿Y cómo eliges las iniciativas donde te metes a nivel del contribuidor individual?
Tengo dos tipos, hay una que hago muy poca menudo, que son iniciativas muy estratégicas,
como por ejemplo el año pasado sacamos la aplicación de mobile y ahí me involucré,
porque creía necesario que yo tuviera conocimiento de cómo se hacía, de cómo estaba, entonces
para mí era algo estratégico y quería estar involucrado, quería estar en la tranchera
para después tener una visión un poco más profunda de esa parte de tecnología que aún
no habíamos explorado, pero en general intentó coger iniciativas que no sean críticas, o
sea yo las tareas que hago, si no las hago no tendría que pasar nada, porque lo que
no puedo hacer es enfocarme solo en programar y luego descuidar el resto, entonces yo hago
tareas que sean pequeñas, tareas normalmente que son de abstracciones, de cosas que toman
un poco de todo, intentó tocar partes diferentes del código para ir viendo pues cómo está
el código, qué nivel de salud tiene, o sea así que intentó explorar como un scout,
intentar ver diferentes cosas y así también voy aprendiendo, voy viendo cómo cojamán
los developers, qué hacen, qué no hacen, intentó exponerme un poco, estar un poco expuesto
y también creo que es un poco para dar ejemplo, o sea al final la gente no quiere, sobre todo
los desarrolladores no quieren un manager puro, quieren reportar a alguien que era mi
developer.
Tú y yo nos conocimos del año, creo 2010, 2011, en aquel momento en InNIC, estábamos
oyendo hablar de Frontend un momento muy temprano y había un guru de framework del
Frontend, que era Pau, que nos viniste a dar una charla, en aquel momento era Backbone,
creo que era lo que se llevaba, pero tú ya estabas muy avanzado en el tiempo, con lo
cual ya de por sí tienes un perfil innovador de estar buscando la siguiente gran cosa,
esto sigue siendo así, tú estás buscando la siguiente gran cosa a día de hoy?
Sí, no, al final en Factorial por ejemplo hemos sido conservadores, yo intenté al principio
de Factorial hacer un cambio de stack comparado con el que había hecho en Teambox, lo pasé
que como lo empezamos programando con Jordi, el CEO, y Jordi dijo no me lies, lo vamos
a hacer con Rails, que es lo que yo conozco, entonces fuimos con eso.
Una imposición de Jordi?
Sí, una imposición, Jordi que también ha estado en el podcast, no, una imposición,
estuvimos de acuerdo, pero sí, todo el rato constantemente informándome de lo que pasa
en el mundo de tecnología, aunque si que es cierto que a medida que va pasando el tiempo
también tengo una tendencia a explorar más temas de organización, no tanto tecnológicos,
también me interesa mucho ver como las diferentes empresas diseñan organizaciones, que también
es algo que me interesa.
¿De dónde ven las ideas tecnológicas?
¿De dónde ven la innovación a Factorial?
No, una pregunta, pues puede venir de cualquier lado, al final todos, una gran parte del equipo
está constantemente, forma parte del trabajo del desarrollador que es mantenerse el día,
porque la tecnología avanza rapidísimo, todos consumimos todo tipo de publicaciones,
de podcast, de conferencias, lo que sea, entonces siempre estamos mirando afuera cosas que hay,
pero muchas cosas también vienen de dentro, y al final descubrimos que hemos llevado conclusiones
que otras empresas también han llegado, tenemos patrones por ejemplo en Factorial, que luego
hace un par de semanas el Shopify publicó algunos artículos y nos dimos cuenta, han
llegado la misma conclusión que nosotros, al final si tú miras los problemas y vas tirando
hacia atrás, hacia el raíz de los problemas, pues intentas innovar desde la raíz, pero
bueno, sí, es un mix-mix, a veces mirando afuera y a veces desde dentro pensando muy
fuertemente, pues innovamos.
¿Se prueban cosas nuevas, hay espacio para experimentar con nuevas tecnologías?
Sí, pero menos de lo que me gustaría, y es algo que estoy intentando, al equipo le
cuesta a veces dar el paso, a veces tengo que empujarlo un poco, a pesar de que no me gusta,
prefiero cuando pasa orgánicamente desde abajo, no me gusta imponer tecnología, pero
sí que a veces veo que el equipo tiene un malestar, una inquietud, o igual hay algo
que les excita mucho y tal, igual no se atreven, y a veces tengo que dar un poco el empujo para
decir, escucha pues, porque no aprovechamos esta iniciativa y vamos a probar esta cosa
nueva, y porque no aprovechamos esta oportunidad, y cual pues le damos un par de semanas más,
exploramos esta otra tecnología.
Una de las cosas que también me ha sorprendido siempre de ti es que tú te has movido mucho,
viendo otras empresas, viendo lo que están haciendo otra gente, tienes, por ejemplo,
un grupo, empezaste un grupo de WhatsApp o de Telegram, de programadores de Barcelona
en general, ¿no?
Esto sigue funcionando.
Sí.
Y de hecho estoy súper contento, es toda la gente con la que me he cruzado, que tienen
esa inquietud, es un grupo que se llama Artesans, porque nos enseñamos que no somos simplemente
developers, sino que nos gusta la artesanía, o sea que lo hacemos con amor, y es gente
que tiene este interés extra profesional, que simplemente lo programan por amor al
arte, ¿no?
Que es el que se dice.
Es un grupo que sí va creciendo, y también me hablabas de dónde sale la innovación,
pues este grupo constantemente estamos hablando y pensando en el futuro de tecnología.
Es curioso porque es que no se puede medir la productividad, yo no estoy de acuerdo
con eso, sobre todo, todo lo pasado es muy fácil de medir, tú produces una serie de
proyectos que han producido equits, output, y te han costado equits, dinero, y eso es
la medida de productividad, si pudieras estar en varios universos comparando exactamente
el mismo equit, el mismo proyecto con distintos equipos podrías compararlo, el problema es
comparar el coste o oportunidad de hacer otras cosas, o con otros equipos, como harías lo
mismo con otros equipos.
Pero sí que hay una cosa que es tu intuición, y tu intuición es bastante fuerte, o sea,
yo cuando muchas veces te pregunto, hemos sido todos los rápidos que podíamos ir,
tú tienes bastante claro que sí, ¿no?
Que estamos viendo todos los rápidos que podemos ser, tienes bastante noción.
Dudo que diga que estamos siendo todos los rápidos que podemos hacer, porque eso significaría
que no hay margen de mercura, y hay mucho margen de mercura, siempre, y constantemente
yo siempre le estoy preguntando al equipo, de hecho siempre hacemos retrospectiva, siempre
me estoy preguntando qué podría haber ido mejor, y siempre salen cosas, siempre, siempre,
así que creo que vamos a una buena velocidad, eso sí, pero podríamos ir mejor, seguro,
siempre.
¿Cuántas veces has pensado, o en factores o en proyectos anteriores, no estamos devolucionando
bien?
Sí, sí, en la mesa anterior.
¿Por qué?
Producto y tecnología.
O sea, bueno, diga, paga un poco de background, equipo de producto en San Francisco, horas
de diferencia a Vismales, equipo de tecnología en España, comunicación no solo a síncrona,
sino que se levanta la persona de producto y de repente se da cuenta que el desarrollador
no ha empezado, porque la especificación no estaba bien, cadena de montaje, o sea,
muy demasiado burocrático.
También bueno, en el equipo anterior teníamos CUAYO, en este, en Factorial he explorado
la idea de no tener CUAYO, creo que hemos podido ir más rápido.
Entonces, yo creo que sí que en otras empresas no ejecutábamos tan rápido y aquí en Factorial
yo estoy a un nivel que soy bastante contento.
Hablando de CUAYO, hay otro fenómeno que también le preocupa a la gente de negocio,
que es la calidad, la calidad del código, el ratio de packs, de problemas de performance.
Cómo se ataca ese problema, cómo se mide esto, y por qué no hay CUAYO en Factorial?
Bueno, son cosas separadas, o sea, al final, a nivel de calidad hay...
Hay dos filosofías, y ambas tienen sitio en diferentes empresas.
Hay gente que prefiere prevenir, y hay gente que prefiere reaccionar.
A ver, si tu eres una fintech y estás moviendo pasta y lo que sea, pues obviamente no quieres
ni un back que vaya a producción, vas a que prevenir es muy caro, extremamente caro,
porque se mide que tienes que entender todas las complejidades de tu producto y testear
exactamente cada una de ellas, porque cualquier cambio en cualquier parte de tu aplicación
puede ser que afecte al código de repartes.
Entonces, prevención es súper caro, y eso normalmente lo que hace es que se hagan menos
releases, que haya un equipo de CUAYO que también son muy caros, para pesar de lo que
parece, pero son muy caros, entonces es un coste muy alto y hace que ejecutes de forma
más lenta.
Obviamente, algunas industrias no pueden evitarlo, si tú vas a mandar un cohete a la luna o
algo así, obviamente no tienes opción porque no hay forma de reaccionar.
Estas empresas, por eso hoy en día sí que optan por disminuir el time to lead, que se
dice que es el cuánto tardas entre encontrar un problema y sostenerlo a producción.
Si tú eres capaz de reaccionar de forma rápida, a veces es más efectivo tener una tolerancia
a los errores, que sea un poco mayor, pero ser capaz de reaccionar de forma rápida.
Entonces, un poco de factoría ha ido más a esa dirección, hacemos continuos del Iberius,
que cada día se hacen 20, 30, 40 de ploys, o sea, no pide la cuenta, estamos constantemente
iterando, muchas cosas las hacemos sin que los clientes lo vean, lo podemos poder en
producción con clientes beta, etcétera, tenemos mecanismos que no involucran tener
un equipo de CUAYO que congele un release y que tengas ese ritmo más lento de ejecución.
A la segunda pregunta, cómo lo controlamos, es muy difícil y todas las empresas lo hacen
de forma suboptima, no sé si existe una solución correcta, que al final siempre tienes más
inputs de los clientes, más bugs, mejores, etcétera, de capacidad por hacerlos.
Y tú tienes también que balancear cuán reactivo quiere ser y cuán proactivo quiere ser, porque
por un lado dices, hay esta oportunidad en el mercado, que podemos hacer esta función
nueva o podemos explorar esta nueva mejora en el producto, o tengo este cliente que
se me está quejando de tal, tienes que intentar compensar ambos.
En nuestro caso, el mecanismo que tenemos es que alocamos un grupo fijo de gente, fijo
en el rotatorio, pero cada semana es la cantidad fija de gente que se encarga de suceder problemas
de clientes y el resto sí que trabaja más en iniciativas estratégicas.
Volviendo a la parte de más de management y de gestión, claro, tú cuando pasaste
de ser contribuidor individual a pasar a llevar a un equipo, antes era más fácil
porque dependía de ti, o entre comillas, pero pasas a no depender de ti, tienes que
conseguir objetivos, igual que antes, pero a través de otras manos y otras personas.
¿Cómo ha sido este proceso para ti? ¿Cómo has conseguido asimilar eso?
Proceso difícil, porque sí que cuando eres ingeniero, yo creo que tenemos una tendencia
a tener control, que obviamente cuando eres manager no tienes control, tienes influencia,
o sea, tú puedes apetar una palanca y esperar que eso genere el impacto que tú creas.
Ha habido mucha experimentación en cuando tocar cosas y ver un poco qué pasa, es como
tener un organismo donde tú vas cambiando parámetros y tienes que observar y ver qué
es lo que pasa en la organización.
Entonces, al final no deja de ser ir probando, ir probando, ir probando, hasta que ves que
la organización hace lo que crees que debería hacer, y eso es constantemente iterando y
pensando.
Cada corte lo pensamos, estoy a corte pasado, hicimos esta iniciativa para los bugs y al
final nos salió peor que lo que teníamos antes, tal, tal, tal, pero también lo puedes
encargar como un proyecto de tecnología, o sea, al final también lo puedes encargar
como un problema de ingeniería, y yo creo que también es el riquecedor, no sé, para
mí fue un riquecedor y a mí me gustó este cambio.
Hay algún cuatro cosas que definirás como relevantes para motivar a un developer o para
motivar a un equipo y conseguir resultados, no sé, es una pregunta un poco genética.
Ya, no sé si cuatro, pero la más importante yo creo para un developer es que siempre estén
aprendiendo, un developer tiene no todos, pero en general los que yo intento contratar
es gente que se inquieta, por tanto es gente que o se ve aprendiendo o se ve progresando
o se aburre.
Y un developer cuando se aburre, de repente abre el LinkedIn y empieza a mirar las veinte
ofertas que tiene de los requitters que están ahí esperando como wii3 para ver cuándo
se aburre ese developer, entonces para mí el punto más principal es este, a veces tienes
que tomar igual decisiones que no son óptimas, pero tienes que hacerlo para que los developers
no se aburran y es un poco, o sea, al final te parece una contradicción, pero tiene que
ser así, tienes que mantener siempre al equipo aprendiendo, siempre que se vean que están
progresando, si no se aburren y se van, es así.
Y la segunda para mí muy importante, y de hecho cuando hablo con ingenieros casi todas
empresas, yo creo que no lo hacen bien, es el tema de autonomía, todos los developers
que con los que hablen me dicen, no tengo impacto, es que me dicen lo que tengo que
hacer, yo tengo ideas, yo tengo cosas, y yo creo que el developer debe mucha importancia
a tener esa autonomía, a que alguien le diga, confío en ti, aquí tienes el problema o aquí
tienes todavía más abstracto, aquí tienes hacia dónde queremos ir, qué hacemos, yo
creo que a la gente eso le gusta mucho.
¿Hay algún proceso de la compañía para garantizar la formación, el training, o pase
de forma orgánica, porque la gente tiene espacio para formarse?
Sí, es algo que estamos trabajando y de hecho me gustaría saberlo más, sí que tenemos
un programa de body con los juniors, que es que cuando entran les asignamos una persona
que les guía durante los primeros meses, pero lo que es formación más más estricto
aún no tenemos en place, pero una cosa que sí que intentamos hacer es que el propio
equipo se forme entre ellos, organizamos unos tech lunches donde alguien del equipo
presenta cosas del stack o cosas de fuera, hay gente que dice, en el tiempo libre he
estado investigando esto y me gustaría compartirlo con todos, pero pasa de forma más orgánica,
sí que me gustaría hacerlo un poco más oficial.
Por último, ¿cómo ha cambiado el remote, el COVID y toda la historia a tu equipo?
Sí, yo era anti antes.
¿Ah sí?
Hace un año era anti y poco a poco me fui convenciendo de que o cambiábamos o me quedaba
atrás, al final yo tengo una expectativa que el ingeniero tiene cada vez más presente
y si no lo tienes encima de la mesa, se te hace más difícil contratar, entonces hace
un año empecé a contratar gente que no estuviera en Barcelona y al principio fue difícil
porque no tenía muchos mecanismos, toda la tradición oral, todo pasaba en la oficina,
era muy complicado, pero a medida que nos dolía lo hicimos más, más, más hasta que
nos dejó de doler y entonces llegó el coronavirus y forzamos a todo el mundo a ir a casa y de
repente pues nos munificíamos de haberlo hecho. Curiosamente, también durante el coronavirus
toda la gente dejó de contratar, nosotros fue cuando levantamos la ronda y conseguimos
crecer el equipo mucho porque había muchas menos empresas contrando, la gente seguía
buscando trabajo, entonces para nosotros fue muy positivo y aparte pues explicar que después
del confinamiento también seguiríamos dando el remoto.
Actualmente el equipo está distribuido, no está físicamente en la oficina, algún
developer ahí?
Sí, mucha gente en Barcelona, pero está distribuido, verdaderamente sí.
En la oficina estamos marketing y ventas precisivamente, y ha cambiado la productividad
que no se puede medir en este periodo o no?
Tu intuición.
Mi intuición.
Yo creo que a nivel individual sí, a nivel colectivo, que es una trampa, muchos developers
ciudadanos que son mucho más productivos en remoto y tienen razón porque es verdad
que el desarrollador cuando está en la oficina está con la pantalla, con los cascos y le
da un poco igual el entorno, de hecho en la oficina tenemos problemas de ahí es que
hay ruido que no se que tal, entonces cada uno se encerraba cada uno más en lo suyo.
Entonces yo creo que a nivel individual sí que siga aumentado, a nivel colectivo de cómo
funciona el equipo, yo creo que durante el confinamiento aún sufrimos un poco, pero
porque tampoco no estábamos preparados al 100%, pero yo creo que ahora estamos consiguiendo
un nivel similar o igual y aparte hemos desarrollado herramientas y artefactos que nos ayudan no
sólo al remoto, sino también a la hora de incorporarnos en ingenieros, todo el tema
de documentación, todo el tema de persistirlo todo en escritos, es un tema que ha mejorado
muchísimo.
En el futuro vamos a crecer, esto es evidente, no sé cómo va a crecer el equipo de desarrollo,
¿te asusta un equipo de 100 personas o más?
Bueno, un challenge no lo he llevado nunca, o sea yo me he enfocado siempre en este stage
entre un developer a 30, entonces esa es mi...
Ahora estás saliendo y ahora estás ya en un terreno desconocido.
Pero bueno, no sé, creo que lo puedo descubrir, de hecho hay mucha literatura, cuando mías
afuera intentas ver libros o cursos o lo que sea de gente que ha escalado equipos, casi
todo lo que encuentras es de 100 para arriba, siempre tienes la gente de Stripe, que es
el de Slack, gente que ha hecho este hiperscaling, pero la parte donde sí que no se habla tanto
y donde no hay tanto conocimiento es esta primera parte, entonces yo creo que es más
conocido...
Claro que no es fácil, vamos.
No, no, no lo fácil, pero es más conocido ese problema que el otro.
¿Algunos de estos libros lo recomendarías?
Sí, sí, el de Managing Humans de Michael Lowe, el VIP de Slack, bueno, todo lo que
escribe es muy relevante.
¿Alguna otra referencia que tengas que seguir de a menudo?
No te había avisado, es una putada.
Bueno, tiene el CTO de Slack, el CTO de Stripe tiene un libro muy bueno que se llama En
Elga en Paso, que es muy, muy bueno, mira la organización como un problema de ingeniería,
que eso puede ser bueno o malo, depende de tu metáfora preferida para una organización,
pero es muy bueno también.
Oye, pues muchísimas gracias, Pau, por tu testimonio, creo que esto es súper útil
para un montón de gente, en la mayor parte de gente no entiende este tipo de problemas
de los que hemos hablado hoy, como conseguir calidad, tengo un desarrollador, pero no me
me produce, no me sale el contrato de la gente o al revés, desarrolladores que muchas veces
no conocen por la parte de negocio, tuve estado siempre muy metido en las dos partes.
Y de hecho, desde la buena relación personal, como compañeros de piso que he tenido con
el actual CEO de la compañía, y bueno, y conmigo y con César, tenemos muy buena relación,
es bastante fácil, esta comunicación no siempre es así.
Muchas gracias y con todos los demás, hasta la semana que viene.
Somos un ecosistema de Startups Tech de Barcelona, creadores de Camalún, Kipu y Factorial,
entre otras.
Ofrecemos más de 5.000 metros cuadrados de co-working a startups y organizamos eventos
diarios para discutir negocio y tecnología hasta la saciedad.
Desde idnickfund, invertimos en equipos con capacidad de construir grandes productos
y negocios.
¡Suscríbete!