TranscriptRodrigo: Acompáñanos en un episodio con Matías López, CTO y cofounder de Videsk, la B2B SaaS de atención al cliente por videoconferencia que está atendiendo a corporativos internacionales con un equipo pequeño.
Lo más importante que pueden aprender operadores y fundadores de esta conversación es lo siguiente:
- Es importante que tus pruebas técnicas al contratar te permitan identificar a candidatos ambiciosos y con potencial de crecimiento
- El caos es el estado natural de un producto digital, pero siempre hay que buscar el orden
- En equipos pequeños, cada acción individual tiene que representar valor para la organización
- Siempre contempla un espacio para refactorizar tu el código cuando tocas cualquier funcionalidad existente.
Esperamos que disfruten este capítulo, ¡bienvenidos!
Artemio: Hola ¿Qué tal? Bienvenidos a una edición más de su podcast Cuando El Río Suena, este espacio que está hecho para todas las personas que están allá afuera construyendo algo donde antes no había nada.
El día de hoy nos encontramos en nuestro estudio en la Colonia Roma, en Ciudad de México, codo a codo con mi socio Rodrigo Salmerón ¿Cómo estás, Ro?
Rodrigo: Muy bien, muy bien.
Artemio: Tenemos del otro lado de la llamada a Matías López, quién es el CTO y Co fundador de Videsk ¿Cómo estás, Matías?
Matías: Muy bien, muchas gracias. ¿Y ustedes cómo están?
Artemio: Bien, también acá felices de tenerte en el espacio y emocionados por todas las cosas que vamos a poder cotorrear.
Cuéntanos el pitch de elevador de Videsk
Artemio: Pero comencemos poniendo a toda la gente en la misma página respecto a qué es lo que están haciendo hoy en Videsk ¿Podrías compartirnos su pitch elevador?
Matías: Videsk hoy es una es un B2B2 SaaS enfocado en que los negocios puedan mejorar la relación con sus clientes, esto mediante una conexión cara a cara por videollamada en sus sitios. Obviamente podemos ir profundizando, ese es como la one line.
Artemio: Cuando ya traen el pitch así de ensayado, justo decimos: Bueno, imagínate que tienes diez pisos más el elevador y que nos puedes compartir tantito más ¿Qué nos dirías?
Matías: Estaba en el 3 Jajaja.
Artemio: Ándale sí, lo hiciste perfecto, pero estábamos en un skyscraper jajaj.
Matías: Okay perfecto, bueno, Videsk como les mencionaba, se enfoca en que los negocios puedan relacionarse mejor con sus clientes de una manera más humana.
Hoy, en un contexto donde se trata de automatizar muchos de los procesos, ya sea desde la venta o desde el servicio al cliente, genera ciertos roces, lo cual está bien en términos de automatización para eficientar procesos dentro de los negocios, mejorar la experiencia de todas maneras dentro de la relación con cliente, pero esto trae consecuencias del punto de vista donde muchas veces dejamos de percibir esta atención más personalizada, más humana, donde muchas veces en la parte de venta o a veces cuando el consumidor, el cliente, nosotros mismos queremos buscar una respuesta de una persona no la logramos encontrar y esto incluso a veces no significa tener que ir físicamente a una sucursal o físicamente a una oficina y esto lo queremos de cierta forma, eliminar, mejorándolo mediante nosotros nos consideramos un video contact center que esto les permite, como les digo, como consumidor desde el cine web me comunico así como hoy comunica con un chat, pero en vez de un chatbot me comunico con una persona de carne hueso directamente sobre el sitio web, aplicación móvil o kiosko interactivo y esto de cierta forma brindamos esa experiencia que cuando estamos frustrados y realmente queremos una respuesta, podemos ir a una sucursal, podemos ir a una oficina, pero en vez de ir tomamos esa experiencia, lo llevamos al mundo digital.
¿Cómo ha sido tu posición como CTO en los últimos tres meses?, ¿cómo luce el día a día en tu vida?
Rodrigo: Oye Matías ¿Cómo ha sido tu posición como CTO en los últimos 3 meses?, ¿Cómo se ve un día a día en tu vida?
Matías: De los 3 meses específicamente ha sido intenso, nuestra base o nuestra operación y misión Chile, de hecho, bueno partido en Chile con historia en México, pero hoy día nos encontramos en Estados Unidos, lo cual justo en estos últimos 3 meses ha sido una locura, voy a mantener operación en Chile y aquí también es complejo, y no solamente en Chile, sino que en Latinoamérica, en general desde mi posición, obviamente ha sido todo un reto el hecho de tener que estar a la altura, mencionando que nuestros tipos de clientes son B2B enterprise, por consecuencia de los estándares y las exigencias son muy altas, eso de todas maneras ha significado, como les digo, un tipo de challenge bien importante, pero al mismo tiempo ha sido muy enriquecedor desde el punto de vista de cómo uno puede manejar el negocio a escala y sabiendo que, independientemente de donde tú estés, se sigue un poco la filosofía del producto y se puede hacer.
Artemio: Y de hecho es raro ver que un producto que haya nacido en su ince pción en Latinoamérica después brinque a Estados Unidos porque generalmente son soluciones las que nacen de este lado del continente que están hechas para este lado del continente y luego muchas veces es como su ventaja competitiva más grande, hay pocos casos de ir hacia allá y empezar a codearte con las B2B SaaS de allá que además se multiplican a un a un ratio mucho mayor que al de acá, pero qué emocionante estar ahí compitiendo porque por el tipo de servicio que ustedes brindan, me imagino que los contratos son tanto grandes y también la necesidad allá es como muy basta, una solución como la que ustedes están ofreciendo sí, viene a cambiar mucho la experiencia del cliente al momento de pedir ayuda, ya sea como dices en ventas o en el soporte, yo creo que lo emocionante es que ustedes están allá codeándose con gente en un mercado muy competido y que justo es esta lógica de producto la que se puede seguir respetando y siempre al final del día, los fundamentos sí son como tú dices los mismos, es hablar con tus usuarios, construir producto todos los días, hacer ahí un círculo iterativo de la cosa y cada vez ofrecer más valor al mercado.
¿Cómo está estructurada su organización de desarrollo/producto y cómo ha evolucionado conforme ha pasado el tiempo?
Artemio: Venga, a ver, Matías aquí para para ya empezar a abrir un poco cómo está su cocina, qué tal está todo detrás de bambalinas ¿Cómo está estructurada su organización de desarrollo / producto? y ¿Cómo ha evolucionado conforme han ido creciendo?
Matías: Somos muy pocas personas en el equipo y de hecho nos gusta mantenerlo así, esto nos da un nivel de eficiencia y también movilidad bastante rápida, nos da agilidad básicamente.
Hoy día somos solo 5 personas en el equipo, de hecho contemplando, para que tengan conocimiento todos los que nos están viendo, somos 2 cofundadores, Andrés mi socio que es CEO, yo Matías CTO y el resto del equipo se dio un socio comercial en la parte de lo que es venta y digamos, parte de lo que tiene que ver con desarrolladores, que son 2 desarrollos los tenemos hoy en día y muchas veces se piensa que es poco equipo para operaciones, digamos justamente en Latinoamérica y lo que puede hacer en Estados Unidos, pero nos llevamos en la filosofía de ser máxima eficiencia. Nosotros hoy día llevamos una modalidad bootstrapping, lo que nos permite justamente desde el principio ser precisos en lo que realmente vamos a necesitar hacer, miramos antes de ejecutar, necesitamos entender que efectivamente vamos a crecer con nuestros clientes y vamos a crear cosas de producto para los clientes, que quieran comprarlo y realmente usarlo que le genere una solución a su problema y no solamente digamos hoy en día, a diferencia, tal vez de otras startups, digamos del ecosistema que tal vez puedan tener capital para poder experimentar para poder entrar a nuevos mercados que no están tan cimentados, no tienen tal vez tanta atracción o historial, nosotros en nuestro caso tratamos de ingresar en una industria que si bien lleva mucho tiempo, la parte de, digamos, de servicio al cliente de soporte de ventas, muchos años con muchas soluciones de por sí, tratamos de ver cómo podemos integrar nuevas tecnologías desde el punto de punto de vista siempre del Human Touch y eso es como nuestra transversalidad a nivel de filosofía en todo el negocio.
Respondiendo más directa a la pregunta, somos pocos, trabajamos eficiente y con eso, podemos decirlo como muy a grandes rasgos, no hay una operación compleja de por medio, tratamos de automatizar todo lo que se puede.
Rodrigo: Tal cual.
Artemio: Justo hablábamos en otro capítulo donde también era una startup con un equipo pequeño que cuando se empieza a estructurar una organización ya de producto, de desarrollo, sea por perfiles de usuarios o tal vez por áreas de operación, ahí cada quien se va organizando conforme lo que dice su estómago en el momento de tener que tomar estas decisiones, pero cuando eres más pequeño gozas del privilegio de que todo el equipo conozca muy bien cuál es el producto, tal vez cuál es el dolor más grande que tiene, las charlas donde se debate qué es lo que va en el backlog, todo mundo está en la misma página, no necesitan ser estos squads de producto independientes entre cada una donde, ya el producto, la organización es tan grande que necesita este tipo de orden ¿Ustedes están pasito atrás todavía no?
Matías: Sí, bueno, solo como dato, acá conocimos a personas donde tienen su startup facturando 30 millones de dólares al año y son 7 personas en el equipo y tienen casi cerca de 100 mil clientes, no siempre el número de equipo tiene que ser proporcional a la cantidad de clientes, ni facturación, y hay muchos más casos como esos.
Rodrigo: Claro, para eso hay que apuntarle muy bien a la solución ¿no?
Matías: Sí, de hecho, solo siempre decimos, hay que ver el caso de WhatsApp cuando lo compraron no eran muchas personas y mismo pasó con Instagram.
Artemio: Eran como 11, creo el equipo de personas que estaban operando Instagram cuando lo compra Facebook.
Matías: Por lo tanto vuelvo, no es necesario tener una centena de clientes, o sea de digamos, de equipo grande como para poder operar, creo que se puede a escala con un equipo pequeño.
Rodrigo: Sin duda esto es es importante para que los que nos están escuchando porque sobre todo en este ambiente de venture capital es fácil aventarle dinero y personas a los problemas.
Artemio: A los problemas particularmente.
¿Qué porcentaje de las decisiones dirías que vienen de la dirección del negocio y cuántas vienen “desde abajo”(por así decirlo)?
Rodrigo: Matías, ahora también ya nos mencionaste un poco, pero ¿Qué porcentaje de las decisiones diarias dirías que vienen de arriba hacia abajo? De la dirección del negocio y después permean en el resto de la operación ¿Y cuántas vienen más de las personas que están en el código, en el diseño, en la última línea de batalla? , ¿Qué dirías ahí que que tiene más peso sobre los productos o el producto?
Matías: Desde siempre todo fue basado en requerimientos de clientes y aquí hacer una pequeña mención cuando uno dice eso habitualmente se abstrae de decir que es una software factory o que estoy desarrollando cosas específicas para cada cliente no sino que en realidad escuchamos mucho a nuestros clientes, tenemos un marketer search muy importante dentro del negocio. Nosotros necesitamos tener un espectro completo para la toma de decisiones, por lo tanto, sí podría decir que a nivel directivo se toman decisiones muy importantes, es decir, creo que la gran mayoría de ellas sí se dan desde ese punto, pero esto tiene que ver un poco más por la cantidad de personas que somos en el equipo, por lo tanto, no hay digamos esta permeabilidad a nivel de cadena de organización, en donde se puede ver en el corporativo o en startup mucho más grandes aquí, en este caso, si bien hoy de cara a cliente tratamos de que sean específicamente 3 personas, que es digamos el director comercial, la parte como mi CEO y en mi caso yo para ver parte con cliente y me equipo dev de cierta forma decanta toda esa esos requerimientos y los ve desde un punto de vista técnico, es decir, para nosotros siempre es el más bien, no qué tecnología usar, sino que el cómo usar la tecnología para efectivamente entregar buenas soluciones y desde ese punto de vista, la primera línea es entender los problemas, hacerles ver que efectivamente a veces tienen un problema, no muchas organizaciones asumen que tienen un problema y luego de eso tratamos de pensar la mejor manera para entregarle una solución que sea flexible, digamos, a un precio atractivo y escalable.
Artemio: Oye Matías y me surgió la duda, porque justo haces la aclaración, de que el nivel de customización por cliente no es tan considerable como para justo ya transformarte en una software company más que en una empresa de producto pero de igual forma acá muchas veces hemos visto en negocios que son B2B SaaS que un deal enterprise te puede cambiar el Excel por 3x, 4x, 5x, 10x y si bajas 3 de esos en un año, olvídate, para qué quieres más, pero existe cierto grado de customización porque las necesidades de las grandes corporaciones y sus procesos están tan metidos en sus raíces que son necesarios, entonces ¿Cómo logran esto? Me imagino que es haciendo un producto muy flexible desde su incepción pero igual ajá me cuesta creer que que no existe ahí una customización severa a partir del negocio ¿No?
Matías: Mira, nosotros tratamos de seguir la filosofía de construimos cosas a medida, pero sobre el producto y siempre llevamos una modalidad silvestre, tal vez más técnico, pero los traigo de una manera de pensar a nivel lejos es todo modular y en el diseño completo, desde el principio ha sido modular y eso nos permite tomar piezas del producto y si bien hoy día somos un SaaS podemos ofrecer una modalidad PaaS que sería como platform as a service e incluso en algunas ocasiones más como IAS que es Infrastructure Accreditation Service y eso dependiendo del tipo de cliente, obviamente también cuánto quiera gastar, pero naturalmente tratamos siempre de llegar a esta modularidad y nos permite trabajar sobre nuestro propio producto, en cierta medida tratamos de mirarlo como Videsk le vende a Videsk para que le venda a sus clientes.
Rodrigo: Eso es muy interesante porque este aproach modular, o no perder nunca la visión de producto es justo lo que te marca el límite claro y no te deja convertirte en una software factory, y esto es importante para quienes nos están escuchando porque es muy fácil que se te dibuja así el dolar sign en los ojos y puedes perder fácilmente el norte e igual de todas formas, puede ser una una startup muy exitosa en ese sentido, pero puedes dejar de atender a tu nicho particular que no es solamente esa esa cuenta de enterprise sino que es un usuario que en realidad es mucho más amplio.
Matías: Sí, yo habitualmente cuando converso con otras startups y founders creo que es bastante aceptable si es que alguien quiere hacer no un pivot del negocio, sino que un pivot de su estrella norte y con eso me refiero a su esencia original del negocio no es tanto como qué tecnología o si cambiaste de mercado o sino que más bien puede ser que incluso cambiaste de mercado, puede ser otra solución completamente diferente, un cliente te demostró que había una gran necesidad, pero tu norte puede ser el mismo solo que es otro camino, en este caso nosotros creemos que nuestro norte hoy en día se alinea mucho con nuestra filosofía personal como fundadores y creemos que hay mucho espacio para mejorar en ese sentido, no solamente llevándole al servicio al cliente, creo que eso es solo una pequeña porción de lo que realmente visualizamos, pero desde el punto de vista, digamos de no perder justamente el norte, tiene que ver con cómo tú llevas eso cuando se te ponen los ojos con dólares, llega una gran cuenta que te dice “Te puedo cambiar tu facturación anual por x6, x7, pero puedes perder el foco” y eso es una decisión creo que estratégica, pero también al mismo tiempo un poco filosófica desde el punto de vista de cómo personalmente crees que se alinea con lo que tú realmente querías y por lo que empezaste a trabajar originalmente.
Artemio: 100% ahorita que mencionaban esto pensé como “Bueno es que tú tú arrancas un negocio y ves una oportunidad idealmente a partir de un problema que es lo suficientemente grande para resolverlo”, en el momento en el que llega esta oferta o esta oportunidad de enterprise cambia ese norte a ser “este problema enorme que encontré” a “este problema enorme que existe para esta empresa en particular”, no entonces quieras en ese pequeño cambio ya te moldea todo a esta gran empresa que además, si tienes suerte pues no te van a soltar nunca.
Matías: Y también hay otras posibilidades, porque no es solamente quedarse o irse por otro día, sino que pueden ser ambas, solo que conlleva más trabajo y a veces hemos visto y evaluaciones que aquí también hemos hecho dentro del negocio, generar como entre muchas comillas spin off de el producto original que de alguna manera siga teniendo alguna pequeña relación y digamos a nivel operativo para no tener que generar otra startup aparte, sino que se puedan correr al mismo.
En sus contrataciones de producto, ¿qué es lo que más buscan (que tal vez otros no) y, en general, cómo es su proceso de contratación?
Artemio: A ver Matías, tenemos una pregunta para ti respecto a su proceso de contratación, siendo tan pocos, vamos a darle una pequeña vuelta porque ahorita son 2 cofundadores y un equipo de, me vuelves a decir si me equivoco, de 7 personas.
Matías: No, no, son 2 desarrolladores y un director comercial, solo somos 5 personas.
Artemio: Son 5 en el equipo, okay, venga ahí estamos, entonces tres no son cofundadores, ni socios en estas tres personas al momento de contratar ¿Qué es lo que ustedes estaban buscando en tal vez un poco más a nivel feed, cultural? Y en general para la gente que viene ¿Cómo luce su proceso ahorita para meter a alguien más en el equipo aunque tengan esta filosofía?
Matías: Como les comenté, es una decisión propia el hecho de tener un equipo más pequeño, la verdad podríamos perfectamente emplear pero no hace sentido en este momento sería literal, tirar dinero.
En términos de contratación, voy a decirlo de una manera bien honesta, no puedo decir desde el punto de vista comercial, porque de hecho, en algún momento fuimos 12 personas, bajamos personal básicamente por un tema de rendimiento, pero eso no es mi área, así que no me convenía yo hablar sobre ese esa parte pero lo que tiene que ver con contratación dev sí, de hecho somos obviamente hoy día solo 2, pero aparte de tener un trasfondo de mantener una filosofía de eficiencia y ser pequeño también tiene un tenemos un alto estándar a nivel de lo que es selección de equipo.
Yo al menos en las entrevistas promedio de tengo que filtrar cerca de 200 a 250 personas que en los momentos en que realizamos, digamos un batch de de contratación, hay que filtrar, hay que ver y hay que hacerlo lo más eficiente posible. Yo habitualmente trato de que estos procesos no duren más allá de un mes, un mes y medio, durante este proceso tratamos de entregar feedback lo más pronto posible y tratamos, pero no siempre es así de entregar una respuesta a todos y ojalá un feedback a los que pasen a las distintas etapas. Actualmente esto se centra en 3 etapas específicamente, el primero es, digamos, la postulación, la segunda tiene que ver con preselección y esta preselección dejamos a paso de una prueba. Nosotros tenemos hoy en día nuestro github de pruebas de código abierto, los cuales se pueden hacer, obviamente previa a la contratación no los liberamos, sino que los liberamos posteriores, en esta tercera etapa es donde finalmente de los que quedan y pasan por esa prueba de preselección, en realidad son cuatro porque toman la prueba, la revisamos y la cuarta ya sería la entrevista. Nosotros intentamos primero validar un poco de no el conocimiento, no pretendemos ver que en el código sean los cracks de la programación sino que en realidad tratamos de ver la potencialidad que tiene, hemos recibido muchísimos casos de gente que es muy, muy hábil, pero no se alinea con el fit cultural ni tampoco creemos que finalmente vaya a ser moldeable ni flexible en ciertas formas de pensar, si bien mirar el código no da solamente eso, por supuesto la entrevista lo da, pero tiene que haber un fit súper importante en términos de capacidad de crecimiento y también de ambición y eso lo vemos a nivel de la entrevista y al mismo tiempo en el código y hay pequeñas cosas que, bueno lo voy a decir de todas maneras, pero en las pruebas siempre que hagamos bonus y esos bonus son habitualmente algo como “Si quieres los haces”, pero eso también demuestra que los que no lo hacen en verdad no tienen una capacidad de ambición sabiendo que pueden hacerlo ¿Por qué? Porque postulan y lo entendemos también, postulan a por mayor al volumen y no es de calidad, esas personas las que nosotros sí entendemos incluso hay veces que hemos contratado en periodos pasados devs que no sabían mucho, venían saliendo desde estos bootcamps de programación y tuvieron un crecimiento exponencial tremendo porque tenían la habilidad y las herramientas que les entregamos acá y eso es un poco el proceso de contratación, son básicamente esos cuatro pasos.
Artemio: Suena fenomenal.
Rodrigo: Y esto que mencionas sobre la potencialidad es vital porque sobre todo en equipos tan pequeños una nueva contratación tiene que llegar y como pieza de rompecabezas, calzar en el espacio que justo estaba disponible en tu equipo, porque cualquier otra forma de pieza te va a desconcentrar a todos, alguno va a empezar a jalar de donde no tiene que jalar y va a dar más o le va a faltar otra cosa o no llega a cubrir todo el espacio y entonces todo el equipo tiene que torcerse un poco para cubrir el espacio que le hacía falta este nuevo perfil y sobre todo, cuando eso pasa en materia cultural es un desastre, porque haces trizas la productividad del equipo, todo el mundo unos contra otros no, ya no llegamos ¿por qué? Ay, no sé, parece que y este pedazo ¿quién se encargaba?.
Es muy interesante también lo que mencionas de los bonus, porque nosotros tenemos un estudio de producto donde para reclutar desarrolladores y otros perfiles, pero sobre todo desarrolladores, también tenemos pruebas de código y los bonus nunca los había visto yo de esa forma, los veía como como claro, hay mucho más motivación, pero no en materia de ambición, sino sino de habilidades pero ahora que mencionas esto, por supuesto, porque ¿qué tanta entrega hay ahí? o ¿qué tanta motivación particular hay de este perfil para este puesto? y es verdad que eso puede ayudar a limpiar muchísimo a las personas que como dices están aplicando al por mayor.
Matías: Y es más, tengo caso bien práctico, donde los he recomendado cuando no han quedado porque no han hecho bien el bonus pero lo hicieron y personas que han hecho muy bien las tareas o los puntos obligatorios no hicieron los bonus, eso demuestra, digamos muchísimo desde el punto de vista de que si sabes hacerlo, hazlo, porque básicamente estás teniendo, esto tal vez no es la temática del tópico de la conversación, pero mi filosofía un poco es si vas a postular volumen, es porque no esperas algo de la empresa, sino que simplemente estás buscando un trabajo y es entendible pero eso no es lo que buscamos nosotros, buscamos esas personas que quieran crecer con nosotros.
Artemio: No y particularmente cuando estás construyendo un equipo pequeño, porque esa filosofía también la tenemos nosotros, somos mucho de decirle al equipo que tú estás entrando a un equipo de alto rendimiento, no tanto porque nos matemos trabajando de sol a sol, sino porque somos gente que todos los días busca mejorar, cuida mucho su juicio al momento de tomar decisiones, es consciente de que somos pocos, pero eso después tú puedes hacer un benchmark y ver organizaciones que sacan el mismo volumen de jale que tú y ellos son 3 veces más, 2 veces más, es lo que a nosotros nos ha visto, es vital que la gente que entra entre con pincitas porque eres muy pequeño, no te puedes dar el lujo de de fallar en esa área.
Matías: Sí, bueno, a veces no puedo decirlo con opinión fundamentada pero de cierta forma he visto desde afuera y a nosotros nos pasa desde el punto de vista con competencia.
Hoy en día, lo mismo que nosotros tenemos de producto, incluso más ha sido desarrollado con 3 desarrolladores, incluyéndome versus organizaciones que tienen 25,30 desarrolladores donde muchas veces ¿qué es lo que ocurre? se centran en tener esos cientos de miles de dólares que obtienen por desarrollo personalizado y se estancan y terminan, digamos, con una imagen por fuera de ser un SaaS, pero en realidad, desde tras bambalinas termina siendo un software factory con la cantidad de desarrolladores que tenemos.
Rodrigo: Claro y aquí, mira Matías, antes de saltarnos ya a la siguiente pregunta, porque ya nos clavó mucho, pero ahora estamos justos sabiendo de un proceso de contratación de 2 perfiles nuevos, desarrolladores que entran al estudio y estas entrevistas, las primeras el primer contacto, justo ese lo tengo yo personalmente, porque así como tú te metes a todo ese proceso, a un equipo pequeño hay que cuidarlo mucho, algo donde yo hago mucho hincapié es justo como “A ver, somos un equipo de alto rendimiento, nos contestamos así de de esta forma y le hacemos así, así colaboramos y no sé qué, ¿Te late esto?, ¿Te te llama la atención?” o en realidad me escuchas y dices “Ay, me cuesta trabajo porque si porque si me cuesta trabajo, vámonos de aquí, porque si no llegas en dos semanas ya vas para afuera” No tiene sentido, no te vas a acoplar, tú vas a ser infeliz y nosotros vamos a ser infelices, al escucharlo te tiene que emocionar, si no te emocionas ya no pasa ni ese filtro, me da gusto que hayamos podido pelotear sobre esto donde estamos tan de acuerdo.
Artemio: Jajaja.
¿Cómo se ve el stack tecnológico de sus desarrolladores?
Rodrigo: Matías, volviendo a la cocina, pero ya de la ejecución ¿Cómo se ve el stack tecnológico que usan ahí en Videsk? y esto ¿Ha cambiado a lo largo de su desarrollo? Cuéntanos un poco.
Matías: Sí, ahí hay varias cosas bien interesantes la verdad, partir por mencionar que algo que yo he tratado de involucrar dentro del negocio dentro del stack tecnológico es básicamente nos encanta el open source y contribuimos al open source, si bien nos encantaría generar código open source público en nuestro github lo hicimos y tuvimos una mala experiencia, pero dejando eso de lado hoy en día tratamos siempre de mantener stack, donde lo que se esté utilizando más allá de si es lo último que salió o lo más trend o lo que sea es cómo lo usas incluso si es lo último, de lo último, de lo último y eso es lo más relevante en el momento de stack.
A ver, hoy en sí todo es cloud, no hay digamos servidor físico ni nada similar, tratamos de llevar todo esto en capas modulares y esto se lleva a través de lectura de micro servicios se guían a través de modulación de ciertos componentes que de cierta forma tienen que hacer sentir una sinfonía completa entre cada servicio que realmente hay, evitar duplicación de servicio, evitar llevar trends, como por ejemplo llevar una infraestructura si es que funciona como monolito y efectivamente rinde ya una eficiencia concreta, no llevarlo a un no sé cabro net o llevarlo a una auto escalamiento que solo consume como si fuese diesel, no, la idea aquí esta tarde efectivamente llevarlo a un concepto en donde si se necesita escalar se escala, de lo contrario tenemos que centrarnos más bien en depurar esa funcionalidad que entregan un valor, es decir, cada minuto, cada segundo que eso esté corriendo tiene que efectivamente estar entregando un valor de lo contrario aunque sea por mil instancias, el valor va a seguir siendo, si es bajo por mil, va a seguir siendo por mil veces más bajo, siempre tratamos de llevar un poco desde ese punto de vista y bueno, digamos más, tal vez más técnicos, si es que es interesante mencionarlo, tratamos de trabajar todo con javascript, básicamente eso nos permite por un tema bastante práctico, que es trabajar en el mismo idioma, en front y en back de **una manera bastante eficiente, es decir, podemos ya sea la necesidad de traer parte del equipo para un front para ver algo en back o viceversa se puede hacer. Hoy en día no lo hacemos porque tratamos de tener expertos en las 2 áreas porque hay mucho trabajo que hacer, pero de cierta forma ese es un poco como a grandes rasgos el stack bueno, si quieren, tal vez más más profundo, hoy día utilizamos tecnología tiempo real, básicamente es todo a través de websocket, lo que nos permite trabajar como si fuese literal en tiempo real, esto tiene una complejidad a nivel de arquitectura, tratamos de siempre mantener sobre todo en el stack tecnológico, y esto es una frase que no sé si la habré creado o no, si no lo voy a tener que poner frame mark tal vez, pero es “Seguridad antes que funcionalidad” y eso es una filosofía súper importante que ha implantado dentro del negocio indistintamente del stack, que incluso si llegásemos a ocupar, no sé en 5 años más sale X, Y, Z tecnología eso tiene que pensarse siempre desde un mindset de seguridad y la ciberseguridad siempre ha sido un punto muy relevante para nosotros como en el desarrollo, siempre, siempre ha sido un punto en donde incluso puede ser que estemos muy atrasados y preferimos pedir disculpas al cliente que pedir perdón porque hubo una brecha de seguridad.
Rodrigo: Claro y no, sobre todo con clientes como los que tienen ustedes que son enterprise la seguridad es algo que nos puede dejar de lado, un saludo ahí…
Matías: Y la imagen que no se recupera.
Artemio: Claro.
Rodrigo: Un saludo ahí a Adriel y a Matías de Hackmetrics que justo se dedican a ello.
Matías: Hackmetrics, sí, claro, los conozco.
Artemio: Claro, ese par andan por todos lados, un saludo.
Rodrigo: Gracias por la visión a la a la cocina de cómo trabaja y su filosofía.
Artemio: Y también muy relevante esto con un cliente enterprise en una empresa bootstrapeada con un equipo pequeño, hace mucho sentido que tengan que tener este paso previo, porque tampoco son una empresa B2C, que puede ir, tener 80 sesiones y aprender y ahora sí ya entregar algo bueno, acá hay que llegar con las cosas mejor armadas.
Matías: E incluso hay problemas generales también, así que no es algo como decir “La imagen la puedo re hacer”
Artemio: Claro, ay, no, qué miedo, qué miedo, qué miedo.
Intermedio
Artemio: Vámonos al corte para que se me baje.
A toda la gente que está escuchando, Rodrigo y yo queremos pedirles con el corazón en mano, que si pueden ayudarnos compartiendo este espacio con cualquier fundador, operador o inversionista del sector tecnológico en Latinoamérica nos ayudarían muchísimo a llegar a la gente que estamos buscando con este espacio también nos pueden encontrar tanto en Instagram, como en LinkedIn o en nuestro canal de YouTube como acueducto.studio, y ahí todo el tiempo estamos liberando contenido dosificado de todo el valor que se concentra en este programa, así que vayan a seguirnos y sin más que agregar, vamos al intermedio.
Cuéntanos tus 3 lecciones más grandes construyendo productos digitales
Rodrigo: ¿Qué tal? Bienvenidos de vuelta a Cuando El Río Suena, con nuestro invitado de este episodio, Matías López, CTO de y cofundador de Videsk. Matías retomando la conversación y en esta dirección de destilar todo lo que tengas para entregarle a nuestra audiencia, cuéntanos tus 3 lecciones más grandes construyendo productos digitales.
Matías: Creo que esta es la más importante para mí, si volvería a empezar, lo volvería a hacer, aunque no lo recomiendan y es hacer un market research profundo, en todo aspecto sea, digamos la startup de mercado que sea, creo que eso es fundamental entender y ser experto, no por haber tenido experiencia previa en el mercado, digamos laboral, sino que en realidad saber hasta el más minúsculo grano que hay hoy día en ese mercado para entender efectivamente qué es, qué podría pasar y qué es lo que está pasando. Creo que eso es una una enseñanza muy importante, he visto y conversado con muchas startups y creo que hoy día falta eso, no por tener 3 o 4 competencias en un listado y en un deck es suficiente, creo que es muchísimo.
Creo que la segunda tiene que ver con armar un equipo a nivel con una cultura importante, es decir, fijar una filosofía aunque uno encuentre un problema gigantesco y aunque uno quisiese crear una solución de último nivel y de mejor calidad, creo que si al final no hay un fit real en el equipo siempre va a estar cojo, siempre va a haber algo que finalmente pueda gatillar en que algo no funcione, creo que eso para mí es súper importante y lo haría cada vez que inicie una nueva startup.
Creo que como tercero es poner varias más en orden creo que serían más de 3, creo que serían como 20, pero creo que la otra es cuidar la salud, tal vez no es tan común verlo desde el punto de vista de negocio, pero creo que es muy importante porque a veces uno pierde realmente harto foco en la salud y uno quiere seguir, digamos, dando todo lo que puede, pero el cuerpo tiene un límite.
Artemio: Claro.
Matías: Yo creo que eso es como relevante.
Probablemente tengo muchas más, pero podríamos estar aquí más de negocio, pero creo que para mí personalmente son las más relevantes, si la vuelvo a decir es básicamente market search, armar un buen fit cultural en la empresa y cuidar la salud en general, no solamente digamos lo digo personalmente, sino que dentro de todo el equipo.
Artemio: Claro, 100%, este primer punto que mencionas del market research hace mucho ruido, pero en el buen sentido en materia de que tú como fundador, cuando comienzas una idea, no sabes nunca enteramente bien en qué te estás metiendo, a menos que seas ya un veterano que lleva un par de negocios e incluso así nunca sabes bien a qué te estás metiendo, particularmente, las empresas de software muchas veces el mismo mercado ya te está diciendo qué es lo que va a matar a la solución que en ese momento es la que todos están utilizando, yo creo que por eso es particularmente valioso en las empresas de tecnología hacer benchmark, benchmark y más benchmark, porque así tú te puedes mismo, incluso tú puedes llegar a lo que es esta frontera de innovación, donde ya la gente está un poco así a ciegas, pero pues para llegar ahí tienes que conocer todo el abanico de soluciones.
Matías: Y eso involucra no solamente cuando digo market research, tal vez no es no es algo tal como documentado, como puede ser como lean startup o cosas similares de metodologías para desarrollo ágil, y esto tiene que ver un poco más bien con, no es tal vez tan ágil al principio cuando uno lo está haciendo, pero es muy ágil en el proceso cuando empiezas a construir y generar un producto en mercado, porque realmente sabes lo que estás haciendo y te das cuenta que, y esto le pasa al 100% de las startups, 100%, y creo que eso lo puedo decir con mucho fundamento, uno cree como cofundador que realmente está haciendo algo único y con par de búsquedas en Google te das cuenta que no, que hay 20 otras empresas que están haciendo algo muy similar, casi igual o lo mismo o mejor que tú, y creo que eso es súper importante, y eso también incluye el hecho cuando digo market research, es hablar con tu cliente, eso es parte de un market research y es entender tu potencial, tener las 2 vistas te da a entender si efectivamente el dolor que tiene cómo se podría resolver y cómo lo están resolviendo, para que efectivamente no hagas algo más y no seas otro más del mercado y que efectivamente debes tener esa vista. Particularmente, nosotros siempre hemos tenido una vista como de crecimiento a escala, siempre hemos querido tener la posibilidad de llegar a todo el mundo y eso nos dio desde la concepción de 10 y ver todas las competencias del mundo. Probablemente duramos casi un mes en eso y es harto tiempo sin tener que construir un producto, pero cuando comenzamos a construir sabíamos perfectamente qué tecnología estaban usando, por qué la estaban usando, cuánto la estaban vendiendo, cuál eran sus costos y todo eso nos permitió efectivamente ejecutar de una manera rápida para entender “Okay, yo no voy a hacer nada de lo que ellos estaban haciendo porque tengo claro lo que mi cliente y mi potencial cliente me dijo y lo voy a hacer a mí modo, no lo voy a hacer mejor, sino que lo voy a hacer diferente”.
Artemio: Me encanta, me encanta esta filosofía y creo que es algo que la gente que está escuchando se puede llevar de este capítulo.
¿Nos podrías compartir algunos rituales o tradiciones divertidas/únicas que tengan en el equipo de desarrollo o en la empresa en general?
Artemio: Matías, jalando el hilo de cómo es que operan ahí en Videsk ¿Nos podrías compartir algunos rituales o tradiciones únicas / divertidas que tengan en el equipo de desarrollo o en la empresa en general? No sé, por ejemplo, nosotros todos los jueves jugamos among us y es divertido y nos hemos conocido mucho mejor a partir de eso, no necesariamente tiene que ser eso, pero era por ilustrar el punto.
Matías: Podría usarlo, la verdad…
Artemio: Llévatela no la pasamos muy bien, neta sí.
Matías: Mira a ver, nosotros no tenemos un digamos como tal vez una un game time o algo similar siendo súper honesto, nuestra cultura se hace un poco más bien hay momentos que sí damos para poder dar crecimiento personal en el sentido de ver más de lo que el cargo en sí mismo conlleva. Pero por ejemplo, sí tenemos un ritual, tal vez de todos los lunes, obviamente yo creo que esto es súper común, poder conversar sobre lo que está sucediendo al ser un un equipo pequeño, tampoco es que necesitemos muchas reuniones, obviamente, naturalmente todos es más digamos transparente, claro, pero de todas maneras siempre está estos pequeños momentos en donde podemos conversar más que solamente del trabajo para entender que hay incluso situaciones donde hay ideas que se proponen y que ayudan muchísimo, porque nosotros, particularmente como negocio, estamos en un mundo de servicio al cliente y ventas, somos nosotros mismos los que vivimos, son experiencias que que digamos se pueden compartir y que siempre estamos constantemente buscando cómo mejorar.
En general, yo como mi cargo en la parte de tecnología, siempre intento generar sesiones para encontrar nuevas tecnologías que quieran probar, de hecho, siempre tienen la disponibilidad del equipo de usar nuestra infraestructura, nuestro budget para gastar en cosas que necesiten entender y descubrir porqué es un poco de I más d que se podría compartir en una potencialidad de producto.
Pero siendo súper honesto, como les menciono, no hay una cultura, tal vez no tratamos de llamarlo ni familia, ni tal vez algo como agregarle un aditivo que en realidad no lo es, sino que esto es, efectivamente es una empresa y una cultura de crecimiento personal, donde va a haber un feeling muy bueno donde van a haber risas, donde siempre va a haber una calidad y de confianza, una conversación de confianza, pero prontamente podría tomar eso y hacerlo, pero hoy día la verdad, como siendo súper honesto no lo tenemos y algo que me gustaría, somos una una startup de billstate, por lo tanto no tenemos todo todavía, digamos solucionado no solamente por productos, sino que también a nivel cultural, a nivel de negocio, procesos, qué sé yo, entonces, se siguen definiendo.
Artemio: Muchas cosas se siguen definiendo, y es curioso porque nosotros ni estaba en el mapa hacer una actividad así de forma interna pero haciendo una labor de hablar con cada uno de los de los miembros del equipo en qué también la estás pasando, qué cosas faltan de los pocos patrones que identificamos, porque nos fue muy bien por fortuna en esta evaluación fue que hacían falta dinámicas para que el equipo, que es remoto, se sintiera parte de algo donde tú sabes un poco más de la otra persona que está frente a la pantalla, fue que hay alguien justo dijo “Podríamos hacer lo que sea, jugar among us” y dijimos “Pues si, hagamos eso, órale sí, a ver qué tal”
Rodrigo: Pero Matías, está bien, es interesante lo que mencionas, porque dijiste la palabra aditivo, lo cual digo claro es que es como un pegamento que no tendría que ser necesario y es verdad, con un equipo de 5 personas, todos están ahí, se conocen y es mucho más importante culturalmente lo demás que mencionaste, más que el juego , que exista esta comunicación, esta relación de confianza, estos lugares de risas mencionaste, que no se hable solamente del trabajo.
Nosotros tenemos luego equipos que un equipo va en algo y otro en otra cosa, entonces sí claro, pues en 6 meses y pues nadie se habló no, entonces sí necesitamos este tipo de aditivos justo como estabas mencionando para destilar la parte más valiosa de la cultura y de una buena cultura es justo eso, una buena comunicación, que el equipo se vea en varios lugares, que nadie esté solo trabajando en su casa, reportando los miércoles, porque eso es destructivo para cualquier de salud mental, cero recomendable.
Matías: Sí, yo creo que en las reuniones, y que también tenemos pocas reuniones en general, siempre tratamos de que bueno, además, que en B2B siempre requiere muchas reuniones, las que no nos consumimos nosotros nos las consumen nuestros clientes, pero siempre es un 60/40, siempre es 60 de trabajo y 40 de poder hablar de algo, y no es digamos como estructurado, sino que es muy natural, tiene que ser algo que deben hacer y no hay que forzarlo, por lo menos en nuestro caso.
Nuevamente vuelvo a decirlo, ya que no están viendo otras personas que esto es para una pequeña escala, claramente el desafío viene cuando el equipo crezca mucho más, tal vez ahí sí tenga que agregar alguna cosa, pero naturalmente ahora no es necesario.
Artemio: De momento, así está la cosa, sí, claro.
Como líder de tecnología, ¿cómo balanceas recursos entre nuevos desarrollos y mantenimiento/bugs? ¿Tienen una regla general o sistema? O es ad-hoc y específico al equipo/contexto
Rodrigo: A ver Matías y también para la siguiente pregunta, justo es algo que nos llama mucho la atención porque son una startup, un producto que se mueve va generando deuda técnica, inevitablemente, esto es normal, es sano, está bien, si no los productos no se mueven al ritmo que se tienen que mover, pero esta deuda técnica hay que atenderla ¿Cómo balancean ahí en en Videsk entre nuevos desarrollos, incrementar nuevas funcionalidades contra el mantenimiento, los bugs que puedan quedar por ahí o atender la deuda técnica?, ¿Tienen alguna regla general para cuándo se hace alguna otra?, ¿Depende más bien del contexto? Cuéntanos un poco, cuándo hacen cuál.
Matías: Deuda técnica sí existe, eso es mentir, pero hoy en día lo controlamos, lo controlamos en el sentido de que, como les mencioné anteriormente, nuestra lógica de modularidad nos permite ir sacando piezas y volver a reemplazándolas de apoco, no necesitamos tener que hacer una refactorización completa para que todo vuelva a funcionar y el trabajo con bugs más que nada siempre tratamos de mantener un mapeo completo de el uso de la plataforma en el caso de nuestros clientes.
Sabemos perfectamente quiénes son los que están ocupando qué funcionalidad y cuando uno de ellos nos reporta algo, entendemos el nivel de gravedad de la operatividad y nosotros clasificamos la operación a nivel de si efectivamente rompe la operación de nuestro cliente, no así nuestra operación o si efectivamente rompe nuestra operación y, por consecuencia, la operación de nuestro cliente, si nuestra operación deja de operar, valga la redundancia, nuestros clientes no van a poder usar nuestra plataforma, pero eventualmente, si una función en particular tiene algún problema, la calificamos a nivel de gravedad y eso nos permite ir avanzando rápido.
Hay veces que hay bugs mínimos, que son tal vez de interfaz o que digamos no son como lo que llaman bugs no funcionales y si es funcional, efectivamente tiene una alta prioridad que por consecuencia, podría afectar la operación de nuestro cliente y eso es básicamente hoy día cómo los manejamos.
La deuda técnica naturalmente, creo que eso, como les digo, tratamos de ir sacando partes del lego en cuando tenemos el tiempo suficiente de poder ir haciéndolo y siempre tratamos de hacer un proceso eficiente cuando vemos que hay una nueva funcionalidad que pasa llevar ese módulo, tratamos de abarcar ese tiempo para volver a refactorizar, a luego volver a generar algo nuevo.
Rodrigo: Mira que esto esto último que acabas de decir, yo creo que es una estrategia vital para todos los equipos de desarrollo que se la pueden llevar fácilmente, así como de consejo de galleta.
Siempre que toques un módulo que es refactorizable, que donde tienes cosas que te están esperando es mucho más sano darle un poco más de aire para atender las cosas que tienes atrás, por más prisa que tengas, porque el tiempo que te ocupa la prisa se puede comer el tiempo de la deuda técnica por completo, pueden pasar meses y nunca tocas nada de lo que tienes ahí y pues empiezas a coleccionar bugs, tickets de soporte y clientes molestos, una gran forma de atacarlo es que pase lo que pase, tan apurado como estés siempre ves un espacio para hacer los bonus.
Artemio: Solo los que hicieron los bonus son los que se van a tomar el tiempo de dar ese pasito aquí.
¿Cómo hacen para estimar tareas, trackear progreso y saber cuándo algo se descarriló de la planeación?
Artemio: Matías ¿Cómo hacen para estimar tareas particularmente de desarrollo para trackear el progreso de lo que están haciendo y también para saber cuándo algo ya se les descarriló de la planeación o sencillamente, si tenía un deadline, ya fue ese deadline?, ¿Cómo cómo manejan un poco este este gran dolor que tienen todos los equipos de desarrollo?
Matías: Mira, yo si te soy honesto es un arte, es un arte, lo digo en el sentido que depende mucho, yo creo que siempre uno trata de mantener todo en orden, pero a veces el caos es la tranquilidad, o digamos el estado natural que en cierto se necesita para seguir avanzando y creo que esto puede ser muy ambiguo lo que digo, pero nosotros tratamos siempre particularmente en un caso mucho más práctico, nosotros utilizamos Github Project para todo lo que tiene que ver con funcionalidades que se están desarrollando o se van a desarrollar bugs que hoy día están activos y que caen dentro de una prioridad alta o de prioridad operativa y todo el seguimiento se hace siempre mediante, bueno Github para nosotros es como el centro de toda la operación dev, cada vez que hay un nuevo commit, básicamente está asociado a un nuevo issue que es, digamos, un como un ticket o un parte de nuestro del proyecto, y esto siempre se va retroalimentando, nos llegan notificaciones, siempre hacemos review, entonces estamos constantemente, digamos, haciendo una tarea asíncrona y al mismo tiempo esto se complementan al menos cada 2 o 3 días reuniones de carácter técnico para ver el nivel, máss de avance, porque eso se ve directamente en el código, siempre estamos también de documentar lo que se está haciendo. Algo también reciente no siempre se hizo y en estas reuniones se trata de ver dudas, resolver problemas, cuestiones tal vez más técnicas y entre pares, y esto se hace, ya sea entre nosotros 3, a veces solo ellos 2 o solo una persona, digamos, trata de generar un comentario dentro de un pull request o un un issue o cosa similar, básicamente tratamos de trabajar de una manera bien asíncrona, pero siempre centralizado en lo que tiene que ver con con Github Project.
Por otro lado tenemos nuestra herramienta de feedback para nuestros clientes, donde ellos nos entreguen el feedback y todos nuestros clientes ven el feedback de los otros clientes y votan entre sí, comentan entre sí también y eso nos permite perfectamente entender cuáles son las mayores prioridades a nivel de desarrollo de funcionalidades, y esto se complementa y se conecta con nuestro Github por lo tanto, nos permite ir siempre estando al tanto de lo que está sucediendo y eso nos da automatización un poco en cierta manera.
Artemio: Y jalándole tantito más Matías, cuando ustedes tienen una planeación y por X o Y, digo, no sé si trabajen por deadlines ustedes, porque sé que luego mucha gente no lo recomienda, pero luego son inevitables también.
Rodrigo: Claro, luego ya se la vendiste al cliente y entonces ahora tiene que estar listo.
Matías: Se los digo sí, hay deadline cuando hay una fecha para el cliente.
Artemio: Tal cual, tal cual.
Matías: Básicamente eso. Ahora sí, naturalmente hay un deadline…
Artemio: Como abstracto ¿no? De que algo ya está tomando más tiempo de lo que tú creías.
Matías: Sí, no hay una manera bien bien clara, sí, tal vez hoy en día yo tengo claro que estimo muy aproximadamente si esto va a durar un mes, agrego un margen y esto ya a nivel de aprendizaje, porque por supuesto si hablaban conmigo cuando recién empezábamos estimábamos un mes y nos demorábamos 3 meses, hoy en día ya calibré mi calculadora mental de la empresa, mi estimador y si yo sé que eso va a tomar un mes y estamos en la semana 2 y todavía veo que hay un avance del 20%, traxkeando directamente a través de Github, veo y estimo que es algo que puede ser riesgoso, pero hasta que eso no tenga una fecha, en realidad no se le ponen tantas fichas y tanto hora, nombre a ese desarrollo y se trata, digamos, de manejar en una manera donde podamos avanzar, luego se puede pasar a otro proyecto, pero eso queda en alta prioridad para luego volver a revisar y continuar bien, si bien voy a ser sincero, saltamos a veces en ciertos proyectos, cuando hay prioridad y o son como stopers para cerrar contrato, siempre se le dan prioridad a ese tipo de cosas, y luego volvemos nuevamente al desarrollo.
Ahora, como somos 3 personas y trabajamos de manera eficiente, casi que trabajamos como si fuésemos 20, y no lo digo yo, sino que nuestros clientes y hay muchas veces que creen antes de pasar ya a la relación más profunda, creen que somos 20 o 30 personas trabajando logramos hacer esto efectivamente distribuyendo el desarrollo de una manera más asíncrona y esta modularidad que les comentaba.
Hay muchas veces que nos ha pasado, que estamos casi en el deadline con cliente, pero una de las funcionalidades que se está desarrollando para otra cosa, es el módulo en particular, o esa característica permitía avanzar en lo otro y básicamente lo implementamos y unimos y sale un producto o digamos una funcionalidad en particular, pero con los tiempos vuelvo a insistir, como dije antes, es un poco como arte.
Artemio: Así las cosas, es loco, yo luego pienso, tal vez todo este equipo sería mucho más productivo si sencillamente no existiera este deadline y tal vez llegaría mucho antes del deadline que uno pone pero está loco.
Rodrigo: Sí, no y también hay otro eje que cruza este problema, que es el eje de la motivación o del estrés alrededor, hay uno que es motivación y otro que es estrés hacia el inminente.
Matías: Puedes estar en el día cero con fecha de deadline y ya está hecho.
Rodrigo: Y puedes tener 6 meses para entregar la funcionalidad, de todas formas ya es una locura.
Artemio: Y procrastinar 5 y sacarlo en una semana, es que es eso donde luego yo digo ¿qué es verdaderamente eficiente para un equipo así? Si se ponen estos deadlines y se procrastina después en 2 noches sacan todo el código, queda y llegan al deadline, igual y no se ponía ese deadline y quedaba en una semana, y fíjate que esto Matías, es algo que hemos platicado con ya muchísimos CTOs, ya nos dimos cuenta que nadie sabe bien ahí y todos vamos ahí con la mejor actitud y como tú dices, como siempre, procurando tener orden y cumplir.
Matías: Pero de todas maneras, lo que lo que sí les puedo decir que yo hago particularmente con mi equipo es que intento no colocar una fecha, yo sé mentalmente, como les digo, que esto puede durar por dar un ejemplo un mes, pero yo espero que en las 2 semanas avancen y luego cuando hay un progreso y sientan que realmente están avanzando, ahí sí, ya hay una fecha más o menos práctica que que ellos van a conocer, de lo contrario genero ese nivel de estrés con anticipación cuando no es necesario y efectivamente ha funcionado, a veces incluso me ha pasado como tú lo mencionaste recién, mentalmente sabía que era un mes, porque tal vez incluso había una fecha estimada para el para el cliente y lo hicieron en una semana, aunque también me ha pasado otras veces donde sí lo dejo en Github con una fecha y llegamos, incluso nos pasamos, es algo que a veces hay que hacerlo, pero otras veces no. No hay una forma bien clara, creo yo que comparto con todos los otros CTOs que van han de haber entrevistados que es como un poco arte.
Rodrigo: No, y también ahora mencionabas algo que ha tenido que ser mi labor con el equipo de desarrollo últimamente y es que cuando los veo estresados, pero apenas estamos empezando, les digo “No, a ver, la semana que entra ya vamos a ver arrancado con esta funcionalidad y vamos a llevar una semana de trabajo, ahí vamos a saber cómo estamos, ahí vamos a decir no, ahora si me preocupa, no me preocupa, ahorita la estás viendo desde afuera y no puedes evaluar absolutamente nada, hay que empaparse primero y ahora sí podemos preocuparnos o no preocuparnos o incluso ver si hay si hay algún atajo razonable” Todo eso se sabe solamente desde adentro, desde afuera solamente hay ansiedad y estrés.
Matías: Lo más complejo para mí siempre ha sido la frase que le mencioné antes, un deadline pero aplicando la frase de seguridad antes que funcionalidad y a veces es muy complejo porque la seguridad no es fácil.
Rodrigo: Claro pero sin embargo es tan delicada, no es negociable y al no serlo las conversaciones son muy fáciles y a partir de ahí, qué es lo que podemos hacer en lugar de poder pasarla por alto.
¿Qué dirías que es único o fundamental en la filosofía de su equipo de trabajo para construir producto?
Rodrigo: Matías ya llegamos, esta es la última pregunta, llegamos al final y a toda máquina todo el episodio, la verdad es que me he divertido muchísimo. La última pregunta es la siguiente, para que la contestes con el corazón en la mano ¿Qué dirías, Matías, que es único o qué es fundamental en la forma de de trabajo de Videsk es que los lleva a construir producto como lo construyen hoy en día?
Matías: Es una pregunta muy, muy interesante, creo que lo que vaya a decir hoy puede también seguir desarrollándose, por supuesto, pero creo que hoy lo más relevante es que tenemos una visión bien clara de lo que queremos lograr en términos de problema - solución, pero también en lo que tiene que ver con resiliencia y eso para nosotros ha sido como la esencia fundamental de ellos, nunca tuvimos la oportunidad y hasta la fecha se han dado sí, pero nunca hemos tenido la oportunidad de disponer de herramientas, ya sea dinero, ya sea contactos para poder funcionar, y creo que la resiliencia nos ha ayudado muchísimo, es parte de nuestro, es parte de AND y creo que el negocio siempre ha sido así y es fundamental, creo que todo el equipo hoy día lo tiene, diría que eso es lo principal.
Artemio: Ahí lo tienen. Muchísimas gracias Matías por venir acá a compartirnos de lo que están haciendo hoy en Videsk, de cuáles son sus mejores prácticas y de tu experiencia personal. Yo creo que mucho se pueden llevar las personas que están escuchando y que llegaron hasta este punto de la charla.
A ti que estás escuchando, precisamente Rodrigo y yo queremos recordarte que nos puedes encontrar en Instagram, en LinkedIn y en nuestro canal de YouTube como acueducto.studio ahí todo el tiempo estamos liberando contenido que son destilados de todo el valor que estamos captando en este espacio.
Y de igual forma, si nos puedes echar la mano compartiendo este espacio con alguien que lo necesite con cualquier fundador, operador o inversionista de una empresa de tecnología en Latinoamérica, te lo agradeceríamos muchísimo.
Muchas gracias Ro por un capítulo más, gracias Matías, gracias al equipo de producción que hace este espacio posible y nos vemos a la próxima.