Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
tal vez mencionando Juan que hay Tech Lead en...
bastantes disciplinas de lo que tiene que ver con tecnología.
Incluso dentro del desarrollo puedes tener un tech lead en la parte de front end, tech lead en la parte de backend, tech lead en la parte de base de datos, también tenés tech lead en la parte de sistemas o en la parte de operaciones
Entonces, si tenés hardware físico, tenés tus propios data centers, puedes que tengas un tech lead de la parte networking y un tech lead de la parte de hardware. O sea, en las diferentes disciplinas que hay en una empresa, en las disciplinas de IT, en todas ellas puedes tener uno o más tech leads.
Juan (00:44)
Muy bienvenidos sean todos a una edición más de Dev&Ops podcast, el podcast de tecnología donde hablamos de todo lo que está en la industria el día de hoy, cómo afrontar las carreras que cada vez están más exigentes y.
de todo lo que es nuestra vida, nuestra experiencia aquí con lo que hemos afrontado nosotros. Mi nombre es Juan y me acompaña mi buen amigo Douglas, quien siempre, cada vez que nos encontramos, me habla de muchos otros temas que cuando ya empezamos a grabar se nos ocurre, ok, hubiéramos grabado desde antes, porque siempre tenemos pláticas muy interesantes. Douglas, ¿cómo has estado? Ya tengo tiempo de no escuchar de vos.
Douglas (01:26)
Juan, ¿qué tal? No, bien, Yo creo que siempre lo menciono cuando empezamos cada episodio, me encuentro con alegría y emoción de una plática más, ¿verdad? Ya lo dijiste vos, estas conversaciones que tenemos nos resultan entretenidas y encima de ello lo que buscamos realmente es proveerle valor a las personas que nos ven y nos escuchan. Así que esperamos que en esta ocasión no sea la excepción.
Juan (01:56)
Correcto, la verdad es que nuestra intención siempre es que encuentren un tema, un tip, un consejo o alguna anécdota que nos haya ocurrido a nosotros que pueda ayudarles a ustedes a no cometer los mismos errores. Douglas, estamos en tiempos de fiestas aquí entre nosotros y creo que qué mejor ocasión para hablar sobre lo que es un Tech Lead.
No tiene que ver una cosa con la otra, quiero mencionarlos. Claro, Que es un tech lead y también me gustaría que habláramos sobre cómo llegar a ser un tech lead. Y te comento y también le comento a nuestra audiencia rápidamente.
Douglas (02:26)
Interesante transición ahí,
Juan (02:41)
que este es uno de los temas que aún hoy en día para mí siguen siendo un poco difíciles de explicar, un poco difíciles a veces de entender porque dependiendo de la empresa pueden tener diferentes ocupaciones. Así que por eso se me ha ocurrido hacerte muchas preguntas Douglas ya que en esta cosa más específicamente en estos puestos vos tenés mucha más experiencia tanto
llevando esos puestos como también formándolos creando las organizaciones que se van a llevar a cabo en la empresa así que de eso va tratar el día de hoy para los que nos están escuchando vamos a hacerle muchas preguntas a Douglas ¿Cómo te sentís con eso Douglas? ¿Estás preparado?
Douglas (03:30)
No, mira, me siento
bien, me está causando cierta premoniciones de lo que creo yo que va a ocurrir en los comentarios, ya sea del episodio completo o de los clips, los shorts que siempre subimos a redes sociales, porque siempre subimos shorts de los episodios y muchas personas con poco contexto creen que tenemos una idea errónea o creen que ya saben, ¿no? Los comentarios en redes sociales aguanta con lo que se les ponga.
Y lo que ocurre Juan con los títulos en los puestos técnicos es que toda empresa se vuelve una empresa de tecnología porque necesita adaptar cierto tipo de software, aplicación ya sea interna para manejo interno o externa que sea cara hacia sus clientes. Entonces toda empresa necesita transicionarse y volverse una empresa técnica. Esa sido la realidad por los últimos 15 años tal vez.
12 años, algo así, las empresas se han visto forzadas a ello y han adoptado puestos de trabajo y han decidido ponerle el nombre que han querido ponerle, verdad, aquí ya hemos hablado antes en el pasado de venir y decir no nos estracemos con el nombre que nos dieron a nuestra empresa, enfoquémonos más en la función que tenemos, verdad, entonces como hay mucha empresa que ha decidido ponerle el nombre que ha querido ponerle a su puesto de trabajo, a su plaza disponible, ya miro
gente en los comentarios cuando intentemos aclarar cosas en base a nuestras experiencias diciendo eso no es así, esta persona no sabe lo que habla, la empresa donde yo estoy, el que se llama IT manager y hace todo, o sea, ya miro ese tipo de cosas. Al final, lo que queremos hablar aquí, Juan, es como que el estándar que definen los grandes de la industria, verdad, y tratar de seguirlo de una manera ordenada, de una manera
estandarizada entre estas empresas que definen el camino de la industria, que lo que tiene que ver en mi área como DevOps Engineer, que es lo que es un puesto incorrecto, pero lo que la gente reconoce, ¿verdad?
o más apropiadamente como SRE, Google define la mayoría de esos estándares, eso es una realidad, las personas que están en la industria lo saben. Pero vamos a hablarlo desde esa perspectiva, las personas que ven y escuchan el episodio completo, de antemano les pedimos esa aclaración, esto va difícilmente va a llegar a las personas que nos ven en un short únicamente, pero...
Juan (05:48)
jajaja
cierto.
Douglas (06:06)
Si las personas que ven el episodio completo se toman con un short de nosotros cuando lo compartan con sus amistades, con conocidos, denle un poquito de contexto y ahí nos ayudamos todos a transmitir valor. Pero bueno, al final es el tema que queremos hablar.
Juan (06:24)
correcto, correcto. Me gustó algo que mencionabas y de hecho antes de entrar al tema de Yenon, me gustaría hacerte una consulta y te lo hago porque sé que estás un poco más en contacto con la industria a nivel estandarizado. Donde yo trabajo creo que tenemos una forma de trabajar mucho más relajada, voy a decir, en cuanto a puesto de trabajo y ese tipo de cosas.
Hace unos años atrás recuerdo que todo lo que hacían las Fang se le llamaba, no sé si aún se les dice así, Facebook, no recuerdo cuáles son las siglas exactamente, Meta, por ahí está. Todo lo que ellos hacían las demás empresas trataban de replicarlo sí o sí, independientemente de si aplicaba para ellos o no.
¿Te parece que sigue eso siendo de esa manera? Basándome en lo que veo en redes sociales, quiero creer que ya no están así. ¿O ⁓ te parece que sigue estando igual?
Douglas (07:30)
Mira, sí en gran manera sigue siendo así y eso genera, como te digo, genera el apurarse a querer entrar a una tendencia, genera que empresas que quieren seguir eso...
habrán puesto de trabajo con nombres extraños ¿verdad? ¿Por qué yo creo que sigue siendo esa la realidad Juan? Seguimos seguimos, seguimos viendo a los grandes en aspectos técnicos porque son los que definen los nuevos estándares en la industria y seguimos viéndolos a ellos en cuestión de organización.
Juan (08:03)
Claro.
Douglas (08:08)
Queremos usar las tecnologías que está usando Netflix, está usando Meta, está usando Google, Microsoft. Queremos usar también parte de esas tecnologías. Queremos entonces traer a nuestros departamentos o equipos o empresas la cultura o el flujo de trabajo de ellos. sigue siendo así y se vuelve como una cadena. Yo trabajo en una agencia digital.
Juan (08:25)
No,
Douglas (08:34)
Entonces, muchas veces en mi investigación para proponer cosas internas, miro qué hacen los grandes y luego otras agencias digitales que están haciendo y trata de combinarlo con las necesidades que tiene tu equipo.
Juan (08:45)
Correcto.
Douglas (08:49)
Y lo mismo ocurría en esta empresa donde vos y yo nos conocimos, siempre que yo hacía algo miraba qué hacían los grandes, qué hacían otras empresas relacionadas con turismo, porque la empresa en la que estábamos, que vos y yo trabajamos juntos es relacionada al turismo, y lo traía a las necesidades del equipo, pero sigue siendo así, por lo que yo logro ver la industria sigue movida por lo que los grandes introducen, ¿no? Y vemos incluso empresas como Nvidia, que es una empresa de
Juan (08:49)
Sí.
Sí.
Douglas (09:19)
queriendo entrar en establecer tendencias de lo que tiene que ver con software, con flujo de trabajo muy inteligente, donde corren los modelos de inteligencia artificial en las tarjetas gráficas que ellos crean y si te creo la necesidad de que tenés esta herramienta y si lo corres con modelos locales
Juan (09:32)
jajaja
Douglas (09:43)
vas a hacer un trabajo grande todas las empresas hacen eso, no, aquí no es una crítica contra Nvidia, pero te digo incluso hasta Nvidia que es una empresa de hardware está saliendo a tratar de implementar ese tipo de horizonte para las demás empresas al cual podamos ver seguir y repetir
Juan (09:43)
Sí.
jajaja
es que nunca queremos quedarnos atrás, no queremos sentir que todos están llegando hacia ese lado y por qué ellos no pero bueno, está interesante
Douglas (10:13)
Y juan
y perdón y ahí lo puedes ver en puestos nuevos, verdad, yo sé que el tema central es tech lead pero lo puedes ver en puestos nuevos que están saliendo alrededor de Inteligencia Artificial, no? Empresas grandes tienen sus flujos de operaciones basados con cierto uso de Inteligencia Artificial y entra a LinkedIn, entra a cualquiera de estas plataformas de trabajo en línea y vas a ver LLM Operator no sé qué, verdad, vas a ver
DevOps AI, Engineer, tal vez DevOps AI es una práctica que alguien trató de implementar y entonces ya salió una empresa, hey, esto me gustó, mira, estamos haciendo esto, busquemos un DevOps AI, Engineer. Entonces, lo vemos, ¿no? Lo vemos. De nuevo, acá, si en la empresa donde están, lo voy a aclarar una vez más, se llama, como se llama el puesto de trabajo, o lo que vamos a aclarar que es un Teclit, es diferente, ¿verdad? Se respeta, por supuesto.
Juan (10:43)
Sí, sí, sí.
Sí.
Douglas (11:13)
Lo único que queremos hacer es aclarar un poco nuestro entendimiento de lo que el estándar en la industria está buscando establecer y estas empresas grandes que tratan de... ¿Qué tratamos de seguir? Tal vez ellas van a buscar guiar a la industria porque les conviene, pero al final también nosotros buscamos seguirlas. Entonces, es una comunicación de dos lados.
Juan (11:27)
Sí.
Juan (11:37)
Bien Douglas, gustaría entonces, ¿qué te parece si avanzamos con el tema? Y me gustaría...
simplemente como para dejar un poco claro los estándares y todo y como para que vayamos viendo cómo puede ir cambiando dependiendo de las empresas dependiendo de lo que vayamos hablando. Tengo por aquí anotado una pequeña definición que encontré por ahí en Indeed.com. Esta es una página estoy seguro que muchos la conocen es para encontrar trabajo, buscar y encontrar trabajo y etcétera.
tienen un artículo al respecto y ellos definen Techlead como un profesional que ve por el equipo y el personal técnico del mismo. Ellos se preocupan por la tecnología de la compañía y usualmente lideran el desarrollo de software o los equipos de ingeniería de software y ayudan a encontrar troubleshoot
buscar los problemas técnicos que están habiendo en la empresa que tienen que ver con el desarrollo de software. El desarrollo de software, tareas de ingeniería y releases lanzadas a producción de productos.
Bueno, ya de aquí vemos que de entrada ellos están hablando, bueno, una persona que se encarga de el personal técnico.
de la empresa y que tiene que ver más que todo con el desarrollo de software o los equipos de ingeniería de software. Así que este es algo que vamos a ir hablando más adelante estoy seguro que nos vas a ir aclarando algunas cositas, dublas, de entrada eso lo que podemos ver respecto a los tech leads o líderes de tecnología es que su
su envolvimiento y su mundo tiene que ver bastante con siempre con la empresa pero con el aspecto más técnico de la empresa. Hasta el momento ese es como mi entendimiento más simple Douglas de lo que es un tech lead.
alguien que lidera, valga la redundancia, al equipo de trabajo en cuanto a las operaciones de desarrollo de software, específicamente. Pero estoy seguro que también tendría que ver con aspectos de, como ya mencionaba el artículo, ingeniería. Tendría que ver, llame a ingeniería pues, no sé si tendría que ver con las redes o tal vez cómo se intercomunican los diferentes servicios y productos.
pero bueno, por ahí está mi entendimiento hasta el momento. Me gustaría que tal vez nos expandieras un poco más esta terminología o bueno, tal vez cómo lo sentís vos que tiene que ser un Techlead o cómo lo has visto en diferentes empresas en las que has estado.
Douglas (14:48)
Si, no, yo creo que la definición que está ahí está muy buena, muy buena obviamente en la práctica, yo encuentro mayor inclinación hacia ciertos lados de lo que la definición en Indeed menciona, obviamente en la práctica de mi experiencia, volviendo a aclarar eso. Quiero comenzar tal vez mencionando Juan que hay Tech Lead en...
Juan (14:59)
Ok.
Douglas (15:13)
bastantes disciplinas de lo que tiene que ver con tecnología. Está el Teclid en la parte de desarrollo.
Incluso dentro del desarrollo puedes tener un tech lead en la parte de front end, tech lead en la parte de backend, tech lead en la parte de base de datos, también tenés tech lead en la parte de sistemas o en la parte de operaciones o puedes tener si tenés por separado un equipo de nube o infraestructura, puedes tener un tech lead de infraestructura y también tenés una disciplina de SRE que solo está en la, cómo se llama, el reliability, en la disponibilidad de los sitios.
y
eso, puedes tener un tech lead en esa área. Entonces, si tenés hardware físico, tenés tus propios data centers, puedes que tengas un tech lead de la parte networking y un tech lead de la parte de hardware. O sea, en las diferentes disciplinas que hay en una empresa, en las disciplinas de IT, en todas ellas puedes tener uno o más tech leads. La palabra.
Juan (16:14)
Suena caro,
pensando como el dueño de la empresa o como alguien que tiene que ver con pagar el salario de estas personas. Creo que estoy seguro que muchos tienen esta primera impresión de que puede ser, es que voy a pagar más dinero y va a ser más caro. Tal vez por eso prefieren no implementarlo.
Douglas (16:34)
Me gusta ese comentario que hiciste, porque sonaste
a gerente administrativo. Suena caro. No, está listo. No, pero me gusta la pregunta porque entonces podemos aprovechar a aclarar por qué es todo lo contrario. ¿Verdad? Porque más bien es todo lo contrario. Entonces me gusta que tengamos esa perspectiva en mente. ¿Verdad? Entonces primero aclarar esa parte. Segundo, cuando dice que maneja el personal técnico.
Juan (16:38)
Ya estoy listo.
Douglas (17:00)
Yo lo he visto mayormente, esta es mi experiencia, y entre tratar de indagar de nuevo en lo que hacen empresas grandes, estas empresas grandes recordemos cómo investigo estas cosas como paréntesis.
estas empresas grandes sueltan blog posts donde comparten experiencias positivas y negativas como llegaron a cierto nivel. Aprendí mucho, me acuerdo yo hace como 10 años más, sí como 10 años, de Walmart, por ejemplo. Walmart soltaba bastante información respecto a su cultura y respecto a tecnologías. Yo aprendí mucho de Walmart que no era tan común aprender de Walmart en ese tiempo, aunque se hizo su nombre. Pero ellos sueltan
en este tipo, ya sea en blog posts, en papers, en investigaciones internas, en post mortem, en reportes, ellos van sortando todo este tipo de información y así es como uno sabe.
que están haciéndolo grandes, lo que ellos deciden compartirlo, estoy seguro que tienen cositas internas que no las dicen porque nadie va a soltar el secreto de cómo realmente volverse millonario. Pero en fin, esa es la manera en que él se hace, ¿por qué yo me he empapado de eso? Pues uno ha estado en diferentes situaciones de dar la estructura a departamentos técnicos y también yo mismo busco crecer en mi propia carrera técnica, entonces ese es el paréntesis de
porque yo he buscado empaparme de eso, ¿verdad? Pero entonces, volviendo a la pregunta Juan, mayormente yo le he visto que el Teclid está encargado o es jefe de la parte tecnológica, la parte técnica como tal, por ende, vuelve indirectamente
líder o jefe de los ingenieros técnicos, pero de qué manera? El Teclid es el que define los estándares técnicos, si van a usar que lenguaje de programación para, si digamos que es un Teclid de front-end, ¿verdad? Que framework van a usar para aplicaciones de cierto tipo, ¿verdad? ¿Cómo se van a hacer el CSS y las clases y todo para cierto, para situaciones
para el landing pages. Entonces, él viene y define ese stack de que se va a trabajar, cómo se va trabajar, qué tecnología, qué versiones.
¿Verdad? Él define el flujo de trabajo. Él dice, vamos a crear un branch del main branch y vamos a hacer feature branch y vamos a hacer esto. Él define ese flujo de trabajo. Él viene y qué, cómo se llama, con qué frecuencia se va a estar publicando en base a muchas otras cosas que le vamos a ir discutiendo. No, él define esas cosas y entonces luego viene.
y entre documentaciones y charlas y correos y memorandums, la manera que sea necesaria, distribuye eso a los ingenieros de Frontend.
Entonces ellos tienen que aplicar lo que el Tech Lead definió. El Tech Lead está ahí disponible para ayudar con implementaciones, con preguntas para resolver el problema que se volvieron más críticos, que requerían de mayor planeamiento. Pero los ingenieros están obligados a cumplir con ese stack técnico que el Tech Lead definió o ayudó a definir. Porque hay puestos más arriba que podemos medio mencionarlos más adelante, Juan, para aclarar la visión.
Entonces de cierta manera, hay un ingeniero que no lo está cumpliendo, el técnico puede llamar la atención porque se cumple el estatus técnico. No necesariamente que sea él el encargado administrativamente de llevar a este ingeniero. No es necesariamente él que le va a probar días de vacaciones o que le va probar horas extras o que le va a probar la cena, etcétera. No necesariamente es así. Aunque empresas nuevas
he visto que si el TechLit de paso es el jefe de las personas, en lo personal yo a mí me gusta más cuando el TechLit es únicamente líder de la parte del stack técnico.
y no del ingeniero como tal porque son habilidades distintas que no todos tenemos. Alguien puede ser muy bueno en la parte técnica y muy bueno en documentarse y muy bueno en enseñarla, eso te ayuda a convertirte en Techlet y podemos ir adelantando esa parte ahí para cuando lleguemos a ese tema, más no necesariamente bueno en saber cuando probar vacaciones, bueno en saber cuando es bueno que tengamos horas extra porque ya es una habilidad administrativa, entonces por eso a mí en lo personal me gusta más ese concepto de
Juan (21:39)
sí
Douglas (21:48)
cuando el teclit solo es responsable del stack técnico y por ende, por ende de cierta manera le da instrucciones a los ingenieros por medio del stack técnico. Creo que me expliqué Juan.
Juan (22:04)
La verdad es que sí, a mi me queda mucho más claro y me gusta esa diferenciación porque se enfoca mucho más en la parte técnica y no tienen que estar pensando en...
le apruebo las vacaciones a Fulanita o no porque voy a tener un déficit de personal y son cosas que estoy seguro que muchos de los que nos están escuchando no quieren lidiar con eso estoy seguro que la gran mayoría de los ingenieros, personas de IT en general preferimos más tener que ver con la parte técnica que con el manejo de personal
Douglas (22:30)
Mm-hmm. ⁓
Juan (22:45)
generalizando más que todo entonces sí suena un puesto de trabajo bastante apetecible creo que sí a todos nos gustaría trabajar de esa manera así que eso está interesante ahora bueno mencionaste tienen que generar estándares
tienen que hacer que se cumplan estos estándares. ahí vi Douglas en algún lado que también a veces los tech leads son los encargados de la contratación de nuevo personal.
a mi ver suena muy... tiene sentido, ¿no? porque ya hemos visto muchas ofertas de trabajo donde te piden un montón de cosas que cuando lo leemos decimos esto no tiene sentido me están pidiendo que tenga experiencia en el kernel de Linux pero para ser un desarrollador junior y es como que está raro, ¿no? entonces un tech lead que se encargue de la contratación como que tiene un poco más de sentido
¿Lo has visto así o cómo ves? ¿Qué te parece esa forma de... o esa tarea para los tech leads?
Douglas (23:56)
Mira.
Aquí eso depende. Creo que el Techlit está capacitado para contratar en su mayoría para identificar a alguien que técnicamente es apto para tu equipo. Más no necesariamente va a estar capacitado para ver si los demás aspectos de un profesional encajan en tu equipo. A veces la cultura del profesional, la parte psicológica, cómo se
Juan (24:08)
Claro.
Douglas (24:27)
se desenvuelve ante la presión, ante los errores, acepta sus errores, no necesariamente aquellos que somos técnicos, tenemos esa capacidad de identificar en un profesional, en un ingeniero, ese tipo de cualidades. Entonces somos buenos identificando lo técnico y terminamos contratando personas que luego es difícil de trabajar con ellas, no por su aspecto técnico. Entonces yo creo que...
Juan (24:42)
Sí, sí, sí, sí.
Yo tenía una... Perdón
que te interrumpa Douglas, pero eso que estás mencionando me recuerda a una gran jefa que tenía antes yo y recuerdo una anécdota que nos contaba exactamente de eso. Estaban buscando otro programador.
Douglas (24:57)
No, claro.
Juan (25:11)
y pues llegaron los candidatos y yo no estaba involucrado en ningún nada que tenga que ver con el proceso, ¿no? Pero luego nos contaban, sí encontramos a este que era bueno pero tal cosa. Y este otro era bueno pero no sabe tal cosa. Y había uno, recuerdo, que era muy bueno y nos decía a ella, esta persona es muy buena, realmente es lo que andamos buscando pero tiene esto, esto y esto que si yo lo traigo en cuanto a su personalidad.
que si yo lo traigo al equipo que tenemos ya aquí va a perturbar todo el ambiente que ya tenemos creado entonces no me conviene
Y me pareció muy interesante esa forma de poder ver otras cosas más allá de lo técnico. Imagínate yo, peor aún, que estaba totalmente verde, estaba empezando yo en esta carrera tan bonita de tecnología. Así que no conocía muchas cosas y escuchar que tu contratación dependía no solo de lo técnico.
sino también de tu personalidad, de tus aspectos, habilidades blandas que se les dice hoy en Pues para mí fue una gran novedad y como bien decís, esa es una habilidad diferente, el saber identificar esas cosas. No todos tenemos esa forma de ver.
Douglas (26:30)
Sí, sí, es una habilidad diferente y eso es algo que no es discriminatorio, realmente que cuando... durante el proceso de contratación Juan se quiere lo mejor para todos. Entonces no es justo traer un profesional a un equipo donde sabemos que él no se va encajar, él o ella no se va a encajar o no la va pasar bien. Queremos que la persona venga, se una y sienta que es un fit, un encaje perfecto para ellos o casi perfecto, no, perfección no existe.
Juan (26:36)
Claro, claro.
Douglas (27:00)
pero casi perfecto que sientan, aquí me desenvuelvo, aquí hago, verdad, y que también el equipo sienta, hey, esta persona que se añadió, nos ayuda con esto, nos trae esta nuevo, que nos ayuda a verlo de una perspectiva diferente o hacerlo mejor, o sea, que todos ganemos. traer un profesional.
Cuando no es tiempo, porque a veces no es tiempo para contratar a alguien, aunque creamos que sí, o cuando no encaja en todo sentido, no es justo para todas las partes. esa es una habilidad diferente, por eso normalmente el Teclid, en sus inicios, lo que hace es aprobar el aspecto técnico del profesional.
Juan (27:30)
Sí, sí, sí.
Douglas (27:43)
y alguien más se encarga de los otros aspectos y ahí se toma la decisión eso es lo más común ahora
mencionando que es una habilidad diferente identificar lo que conlleva fuera de lo técnico. También que el TechLit contrate, ahí un depende. Hay empresas y no sé si luego de esto entramos, Juan, a aclarar las diferencias entre los puestos, ¿verdad? Pero hay empresas que tienen un manager de la parte de sistema, puede ser un director, un IT director, ¿verdad? Que esté sobre encima de todo o un manager de ciertas
que lleva la parte administrativa o también está el Staff Engineer.
que eso es otro puesto que tal vez puede que sea esta la persona que termine definiendo a quien se contrata. Tal vez el Staff Engineer por su experiencia ya ha aprendido a identificar más las de otras cualidades de los profesionales y no solo la parte técnica. Entonces, también están estas cosas que podemos ahondar en ellas si te parece para responder a tu pregunta. No siempre son el que contratan.
Juan (28:29)
ok ok
Douglas (28:58)
no siempre es el más indicado para todos los aspectos de quien contratar, sin embargo, en mi opinión, siempre se le debe consultar en la parte técnica del profesional que se quiere contratar.
Juan (29:11)
Sí, Zapatero a su zapato, como dicen. Y sí, la verdad es que me gustaría hablar de las diferencias con estos otros puestos de trabajo que...
Douglas (29:14)
Exacto.
Juan (29:23)
La verdad, no sé en qué momento se empezó a popularizar más estos puestos de trabajo, pero antes era, lo que yo recuerdo, lo que yo tenía exposición, era pasar de junior, senior y luego aspirar a ser manager. Pero hoy en día hay mucha más división o mucho más puestos de trabajo donde podemos encajar dependiendo de nuestras habilidades.
Y creo que muchas personas, por eso mismo, tal vez por el desconocimiento, porque no estamos expuestos a diferentes formas de organizar la empresa, nos pasa que confundimos estos puestos de trabajo. Y pues entonces sí me gustaría que nos aclararas un poco eso Douglas, diferentes, bueno, las diferencias que tiene un Tech Lead con estos otros puestos de trabajo que son más...
administrativos tal vez podríamos decirlo.
Douglas (30:22)
Sí, fíjate que sí, es bueno que entremos a eso y me gusta lo que decís porque antes en efecto pasaba de puesto técnico, técnico, técnico, técnico a un puesto gerencial donde terminaba siendo más administrativo que otra cosa y no estábamos preparados y es ahí donde entonces contrataban a alguien más enfocado en administración que en lo técnico, entonces se acababa nuestro path de crecimiento una vez que llegamos al nivel senior. Esto ya tiene, no sé, tal vez 15, 20 años en la industria que existen
en estos puestos, tal vez no con el nombre que están hoy, pero que se identificó que salía bien tener un pad de liderazgo técnico.
un camino de liderazgo técnico y un camino de liderazgo administrativo para en conjunto encontrar la mejor forma de administrar un departamento. Entonces mira, yo creo que las partes que hay que aclarar, mi opinión, son una de las diferencias con el engineering manager.
Juan (31:24)
ok
Douglas (31:25)
de cualquier departamento de ingeniería o de nuevo ahí puede entrar, según la empresa, entrar un IT director, un IT manager, dependiendo la empresa, no, pero la diferencia con el manager es que él sí lleva más la parte administrativa, él sí normalmente es el jefe directo de los ingenieros.
E incluso a veces puede ser o jefe directo del lead, del tech lead, ¿verdad? O están al mismo nivel con el tech lead y se reportan a un director o a otro manager, ¿verdad? Pero el engineering manager, el IT manager, IT director o cualquiera que lo desempeñe en tu empresa, lleva la parte administrativa, permisos, lleva la parte del presupuesto, es quien lleva mayormente el presupuesto, usualmente lo hacen conjunto.
Juan (31:54)
jeje
Douglas (32:18)
con el lead o con el staff engineer que ya lo voy a mencionar, pero creo que la manera más fácil de resumirlo y sin entrar a profundidad es la parte administrativa. Fulano tiene tanto tiempo de horas extras, verdad, y hay que calcularle las horas extras, vamos a manejar una guardia, un on-call rotation y este va a ser el horario, verdad, o sea, lo administrativo.
Juan (32:28)
Ok, sí.
que hubieron pleitos entre
compañeros de trabajo, se pelearon.
Douglas (32:50)
Exacto,
si o que alguien viene tarde, viene tarde o se conecta tarde si trabaja remoto o dijo algo inapropiado, ese tipo de cosas. El administrativo es el engineering manager en conjunto, ojo, va en conjunto con la meta técnica del departamento.
en conjunto de lo que quiere el cliente, lo que ocupa el departamento y qué decisión se toma, qué equipo se toma, en conjunto con eso. No estamos diciendo que no sabe nada técnico, pero su enfoque es lo administrativo dentro del departamento técnico. Ahora, el staff engineer.
es un puesto que algunas empresas pequeñas o que no pequeñas tal vez que no son enormes los departamentos o tienen solo un tech lead o solo un staff engineer pero la estructura el puesto de staff engineer está por encima del tech lead pero normalmente tenés solo un staff engineer por disciplina y puedes tener varios tech leads
Juan (33:50)
ok
Douglas (33:53)
por equipos, entonces supongamos que tenés un equipo que maneja los microservicios de la plataforma de ventas y lo que tiene que ver con cliente inventario, pero tenés otro equipo que maneja backend de los sitios web, por decir algo, entonces puedes tener un tech lead para los del todo el sistema interno.
Juan (34:12)
Ajá, ajá.
Douglas (34:20)
y los microservicios y otro tech lead para quien lleva el backend y eso de los sitios informativos, ¿verdad? O tal vez sean aplicaciones web, es más, y también si tenés un móvil, puedes tener un tech lead de la parte de móvil porque está por equipo. Pero todo lo que es backend va a tener un staff engineer, que ese es encarga de que exista.
Juan (34:28)
ok ok
Douglas (34:45)
armonía entre todos, le voy a dar autonomía a cada teclis que decida que lenguaje, que método, que flujo, verdad, pero que exista cierta armonía para que se trabaje con lo mismo, si sale un back-end engineer diciendo vamos a trabajar con Pearl, ahí donde el staff engineer va a decir no, verdad, sea, está bien, tenés experiencia con Pearl y está bien, va a hacer trabajos y es así, pero ya se nos debía, los demás están trabajando con Pearl.
⁓ están trabajando con Go, están trabajando con Java, están trabajando con C++, entonces hay que mantenernos en esa esa categoría. El Staff Engineer tenés uno por disciplina, TechList tenés uno por equipo.
Hay empresas que tienen un tech lead y un staff engineer arriba. Hay empresas donde el tech lead es suficiente o no tienen tech lead y el staff engineer hace las dos. Entonces el staff engineer está más arriba, el staff engineer se encarga del research más profundo de nuevas aplicaciones, el staff engineer está más casi más en lo técnico pero también con cliente, también con los managers, qué necesidades hay.
Juan (35:37)
Ok.
Douglas (36:03)
los managas se ocupa tal cosa, vamos a implementar AI, qué herramientas de AI, él empieza a hacer eso y delega a los tech leads los diferentes aspectos, mirad tu equipo le va tocar implementar AI, digamos el tech lead de SRE, tu equipo le va a tocar implementar AI en los tests, verdad, he estado viendo más o menos estas herramientas y le delega el tech lead que vaya definiendo, el tech lead es por equipo, qué tan grande es la empresa, ahí va a depender qué tantos tech leads
dentro de la misma disciplina porque ya aclaré antes, tener teclit en backend, frontend, en base de datos, etc. Pero cuántos teclits en frontend o cuántos teclits en backend va a depender de cuántos equipos tenés. Entonces por ahí son las diferencias y por eso te decía que muchas veces, de hecho el staff engineer cuando tenemos esa estructura, staff engineer, teclits y luego ingenieros senior y juniors, cuando tenés esa estructura el staff engineer es quien más decide
en conjunto con el teclit del equipo al que el nuevo profesional va a ir. Entonces, de nuevo, creo que esas son las mayores confusiones y creo que son los puestos que vale la pena aclarar para que no exista confusión.
Juan (37:15)
Sí.
Sí, está interesante, verdad es que, bueno, ya cuando las empresas empiezan a escalar y a expandirse, pues sí es necesario tener una estructura que también escale junto con ella, ¿no? Porque, bueno, lo que se estaba pensando mientras hablabas es que, pues hablabas, un staff engineer. Sí, staff engineer o staff manager, dijiste. Staff engineer. Gracias.
Douglas (37:45)
Staff Engineer.
Juan (37:47)
para múltiples tech leads. Ya de ahí, pues día de entrada, estoy pensando en una empresa mediana grande. Creo que sería contraproducente tener este tipo de estructuras en una empresa que tengan que cinco developers en general, ya sería como contraproducente, O no sé, no sé, tal vez sí,
Douglas (37:57)
Sí.
Bueno, pero mira, me gusta que
hagas ese comentario y aprovechemos a aclarar lo que dijiste al principio que suena caro, Una empresa con cinco developers ocupan o un Tech Lead o un Staff Engineer. Yo pensaría. Yo no haría Tech Lead más Staff Engineer. Lo veo innecesario.
Juan (38:19)
Claro.
Douglas (38:30)
Pero ocupas a alguien, que se tome el tiempo de probar las herramientas técnicas, las metodologías de flujo de trabajo, encontrar el mejor horario para despliegue. Necesitas a alguien que haga esto para que ahorre problemas. Y si tenés solo ingenieros haciéndolo, ya vimos que el manager no tiene normalmente, o no tiene la capacidad técnica profunda para hacerlo,
Juan (38:49)
Ok.
Douglas (39:00)
tiene el tiempo porque está con cosas administrativas. el manager...
Juan (39:04)
Normalmente lo segundo.
Douglas (39:05)
Sí, sí, normalmente es lo segundo, no tiene el tiempo, pero nos hemos, ya hemos hablado antes, a veces el manager no tiene idea de tecnología y es una realidad y pues se ocupa lo administrativo, se ocupa que el departamento genere ganancias. Ahora, ocupas a alguien que defina eso, si lo dejas a cada ingeniero, entonces imaginate que me tenés a mí en un departamento de SRI o un departamento de operaciones, me tenés a mí trabajando con Kubernetes, instalando
que prefiero trabajar en AWS, instalando Ingress y todo relacionado a Kubernetes. Y luego tenés a otro que prefiere trabajar en Docker Swarm. Y aunque sea complejo, él busca hacer trabajar Docker Swarm ahí. Luego tenés a otro ingeniero que no usa contenedores, prefiere máquinas virtuales de manera directa. Entonces, empezás con ese caos y cada quien tiene su flujo y por proyecto o por aplicación o por microservicio.
dependiendo la granularidad de tu empresa y departamento, te encontrás con maneras diferentes. Y no se logra poner de acuerdo porque yo te digo, Juan, no, mira, usa Kubernetes. Kubernetes es mejor. Y vos vas a decir, no, mira, es que con la VM hacemos esto. Y como estamos al mismo nivel, no nos vamos a poner de acuerdo. Y se lo vamos a llevar al manager.
Juan (40:18)
Ok, sí.
Douglas (40:22)
que está más enfocado al administrativo y él va a tomar una decisión un poco a la ligera o aunque le quiera dedicar tiempo no le va a poner el tiempo que él quiere y va a haber inconformidad interna. Y entonces tal vez yo soy el de, estoy invirtiendo papeles para que me sigan en el ejemplo. Entonces yo soy el que trabaja con VMs y el manager dijo que voy a trabajar con Kubernetes porque Juan trabaja con Kubernetes. Entonces Juan, ¿cómo trabajas con Kubernetes? Y me lo explicás a la carrera, a medias, porque puede ser que sí querrás compartir.
informas tu conocimiento de información pero no tenés el tiempo porque tenés tus propios tickets o puede ser que no quieras compartir información pero estoy obligado ahora a usar Kubernetes porque dijo el manager pero no tengo todo el conocimiento entonces está viendo el caos que se generan entonces si le pago más a un tech lead en un departamento de cinco ingenieros ya sea front end, sea backend, ya sea sistemas, lo que sea
Juan (41:06)
Sí.
Douglas (41:17)
esta persona va a definir ese flujo y va a ver armonía. Y entonces cuando el ingeniero que no sabe Kubernetes va a estar en Kubernetes, el Teclit es el que hizo la documentación, es el que hizo los diagramas de flujo, es el a quien vas a llamar cuando tengas problemas. Fíjate que hice este deployment, ¿verdad? Y no me genera lo que quería y te va a ayudar a trouble churing y te va a ayudar a ver las cosas más grandes.
y va a empezar a ver armonía y va a empezar a sacar features más seguidos, despliegue más continuos, menos fricción y empieza a fluir y ahí te das cuenta que la inversión que hiciste en alguien con mayor conocimiento y con cualidades para Teclit
Juan (41:49)
Sí.
Douglas (42:01)
te están pagando con creces, intereses en ganancia, verdad, porque te quitas esa fricción y ahora los ingenieros ya no tienen excusa con quién decidir, el manager no tiene que cargar con eso, el manager administrativo, sino que está a este puesto que está encargado de definir esos estándares técnicos, entonces esa es la razón por la cual no es un gasto, obviamente, obviamente si tenés un equipo de cinco, como vos dijiste, si tenés tres ingenieros, un tech lead y un staff engineer, creo que lo estaría gastando.
Juan (42:04)
Ok. ⁓
Douglas (42:31)
Pero en equipos más grandes, entre más tenés, más puestos de tech lead y más puestos de staff engineer vas a ir necesitando.
Juan (42:41)
Sí, ya en empresas grandes es inherente, ya se espera que exista todo esto. Qué interesante, la verdad me gusta cómo lo planteas, verdad es que incluso si de entrada pareciera que hay un incremento en la planilla, pues a la larga vas a recibir todos los beneficios en esto.
Douglas (42:47)
Sí.
No, incluso para terminar la idea, si de esos cinco ingenieros que dijiste uno es teclit, esos cuatro que quedan van a poder hacer el trabajo de 8 o 10 que no tuvieran un teclit porque no va a haber fricción, no va a haber fricción, va a haber un flujo y hay una persona encargada para eso. al final hasta vas te aseguro por experiencia que hasta vas a necesitar menos personas, menos ingenieros para hacer más trabajo.
Juan (43:15)
Ok. Sí.
vas a hacer más con menos. Ok, me gustaría entonces Douglas, ya lo hemos ido mencionando durante la charla, pero tal vez mencionar un poco más conciso lo que, qué habilidades necesitaría yo desarrollar o pulir vamos a decir, para que me consideren como un tech lead. Porque está claro que bueno, de entrada necesito
Douglas (43:32)
con menos, correcto.
Juan (43:59)
saber mucho sobre lo que es tecnología en general. Pero qué consejo darías para alguien que está aspirando a alcanzar ese puesto de trabajo? tal vez está... Podemos verlo desde muchos aspectos Douglas, porque ¿cuál sería tu consejo para alguien que aún es junior y para alguien que ya es senior?
Douglas (44:23)
Si, no, mira, me gusta, yo creo que es la mejor manera de cerrar con el tema realmente esas habilidades. Yo creo que es bien similar el consejo para el junior y el senior, cualquiera que tenga esa aspiración, porque pues el junior, estos consejos que vamos a dar, lo va ayudar a llegar a ser un senior primero y le va aplicar ahí. Cada una de estas habilidades se van exponenciando a medida vamos creciendo y así funciona la tecnología, Me voy a enfocar poco.
con lo técnico pero lo voy a mencionar verdad porque es evidente vos lo dijiste hay que saber
hay que ser muy bueno en la disciplina técnica en la que están buscando ser TECLID. Si sos programador, si sos front and back, si sos full stack, porque también hay algunas empresas que son full stack en el departamento, y entonces el staff engineer es de full stack. Si sos de sistemas, si sos de SRE, si sos de DevOps engineer, como sea que lo llamen. Entonces tienes que saber mucho de la tecnología, la disciplina en la cual quieres ser TECLID. Tenés que conocer...
Juan (45:11)
ok
Douglas (45:26)
decentemente bien la capa de arriba y la capa de abajo. No puede ser un programador de backend, un tech lead en backend, en microservicios.
que desarrolle una estrategia que vaya a sobrecargar la base de datos o que vaya a sobrecargar los servidores o que no sepa que estás corriendo en contenedores y no lo tome en cuenta o que no sepa que estás corriendo en máquinas virtuales y no lo tome en cuenta. tenés que tener ese entendimiento, no experto, pero entendimiento para que cuando hablés con él, cuando el teclid, hablé con el teclid de, perdón, de backend, hablé con el teclid de sistemas.
entiendan el lenguaje y cuando el teclit de Backend hable con el teclit de Frontend entiendan el lenguaje, conocer el flujo de una aplicación desde desde el Edge desde el request por el DNS y por donde pase y cómo llega a base de datos y casi entender eso, no importa el teclit de qué vas a hacer, tenés que entender eso, en lo técnico, experto en tu área conocer decentemente bien todo el flujo, verdad, porque vas a estar, vas a ser
ese puesto que va a definir los estándares técnicos y el stack técnico de toda una disciplina o de todo un equipo, mayormente en la disciplina.
Juan (46:43)
sí creo que a eso
no recuerdo el nombre pero recuerdo la figura que hablan de una T donde si pones las diferentes habilidades en una línea pues las que no pertenecen a tu habilidad principal o a tu enfoque principal se quedan bien generalizadas pero en la que sí es donde vas a profundizar y pues ahí se forma como una especie de T
Douglas (47:09)
Mm-hmm,
¿ay sí?
Juan (47:09)
generalista en lo demás
y muy profundo conocimiento profundo en el tuyo.
Douglas (47:14)
Sí, creo que lo pusiste muy bien ahí. Me gusta esa ejemplificación. Ahora, en cuestiones de habilidades, yo resaltaría, Juan, muy bueno en investigación o en research. Hay que ser muy bueno en eso porque vas a estar probando cosas nuevas para implementar. Entonces, quiero mencionar, en mi opinión, es muy importante, muy bueno en research, muy bueno en prueba, en hacer tu propio lab local o en montar tu ambiente de sandbox y en probar tecnologías. Entonces, muy bueno en research.
Juan (47:44)
Research no es solamente Google Earth, por cierto.
Douglas (47:47)
Claro, no, no, no, yo creo que, y me gusta que lo digas, no, por eso estamos diciendo muy bueno en research, es ver y yo mencioné un poco al principio y lo voy a resumir acá, no es ver qué hacen los grandes, qué hacen otras empresas en tu rubro, qué necesidades tienen en tu departamento y triangular eso a encontrar si eso te conviene o no o cómo adaptar esa práctica, esa tecnología, ese framework a tú.
Juan (47:52)
Exacto.
Douglas (48:12)
aplicación, tu equipo, tu flujo, etcétera. Entonces eso es bueno en research, ¿verdad? Se llama, como se llama, research and development, ¿no? Que es como investigación y desarrollo. Sería en español la traducción más apropiada, creo. Si existe otra, hay que nos corrijan.
Juan (48:21)
sí
Sí, sí me parece bien.
Douglas (48:37)
Ok, bueno, resource, obviamente Juan, aquí vienen cosas que no nos gustan a las personas técnicas, entender el negocio. Hay que entender el negocio porque si estamos haciendo un, otra vez, otra vez.
Juan (48:49)
otra vez decía eso, no puedo programar y no entender el negocio
simplemente.
Douglas (48:55)
¿Cómo puedo programar sin entender el negocio?
Pues si cuesta programar sin entender el negocio, a menos que un tech lead ya me de todo masticado.
Como tech lead es bien difícil, no lo vas a lograr, o sea, ¿cómo definiste el estándar de qué framework vas a usar en el front-end si no sabes el producto, quién va dirigido, quién no son los usuarios? Tus usuarios van a ser niños, porque plataformas que son para niños hoy en día, y de hecho generan mucho dinero el contenido para niños, porque un niño te puede ver lo mismo 60 veces en un día y no se aburre, ¿verdad?
Juan (49:34)
Sí, sí, sí.
Douglas (49:34)
y obdu
tu plataforma o aplicación va dirigida a personas de la tercera edad, va dirigida a jóvenes, sea, todo eso, tu cliente, es con cliente, ¿no? Tu cliente es un editorial, tu cliente es un banco, tu cliente es una agencia, todo eso va a cambiar, entender el negocio para poder que nuestras soluciones encajen con lo que vamos a hacer. Otra habilidad, Juan, que quiero mencionar que yo creo que es de las grandes es tenés que dejar de ser...
Ese ingeniero experto a quien todos llaman para solucionar, que es ser buenísimo en encontrar problemas y solucionarlos y pasar a ser alguien que documenta cómo solucionar ese tipo de problemas y cómo evitarlos. Ya no vas a ser solo aquel que dice que Juan es el que sabe resolver esto, decile.
Identificaste que este problema pasa relativamente seguido o pasa de vez en cuando cada vez que hay tal cosa, resolves el problema, lo documentas, haces los diagramas, haces la documentación necesaria, haces ejemplos una vez que lo tengas, hablas con el manager, estamos diciendo a alguien que todavía no esté GLEAP.
para que llegue ser ahí, hablar con el tech lead, venís y decís, hey, mira, que encontré esto, lo documenté, de esta manera esto pasa siempre cada vez que cuando. Y buscas organizar una reunión o al final del stand up, se quedan 5 o 10 minutos más y decís, hey, miren, este error que ocurrió la vez pasada, ocurre cada vez que tanto, aquí puse el documento, ¿verdad? O sos el que ahora cree estas alertas para evitar que esto pase, cuando la alerta caiga y esto, aquí está el round book, haces un round book de pasos de cómo hacer el troubleshooting.
Juan (50:55)
Sí.
Ok.
Douglas (51:25)
cree este dashboard para monitorear cuando vean esto se van al dashboard o sea
ya te convertís en alguien no sólo bueno para solventar sino que documentó, alertas, hizo dashboards, informó a la gente, entrenó a la gente, dio accesos, hey, miren, va, tenés que meterte a Garfana, cuando esto pase, si alguien no tiene acceso a Garfana, mándenle un mensaje que yo le creo al usuario, o sea, pasás de ser el experto en solventar a ser alguien que aparte de ser experto en solventar,
documenta y prepara para que todos puedan repetir lo que vos hiciste porque recordemos este va a ser un puesto que va a encargarse de dirigir el stack técnico de un equipo de trabajo y esta persona tiene que ser la primera en saberlo enseñar en saberlo explicar y saberle dar soporte entonces cada vez que hay un problema se dice si alguien se vuelve a atrapar con este problema escríbame verdad que yo les ayudo entonces
Juan (51:59)
mmm
Douglas (52:23)
Yo pensaría Juan que de manera general, de nuevo aquí hay más detalles y van a cosas que se van a cambiar por empresa, por departamento, por equipo, de manera general son las que yo destacaría, ¿verdad?
Juan (52:25)
interesante.
Douglas (52:38)
aparte de lo técnico y que en lo técnico ese alguien que está constantemente yendo más allá y documentar lo que hizo, explicarlo, alguien que está preguntando cuando van cuando el teclit viene y dice vamos a usar este stack el que hace las preguntas correctas no es decir, ahora que vamos a usar este stack, cómo va afectar
esta otra cosa que hacíamos pero no es una pregunta general sino que una pregunta conectada, digamos que estabas trabajando con VMs y entonces ahora el tech lead dice que vamos a trabajar con Kubernetes, entonces alguien que diga, antes ¿cómo va afectar eso? porque antes hacíamos un build y se mandaba un artifact a hacer deployment, ahora cómo vamos a hacer los builds de los contenedores, sea cosas que tengan sentido, que tengan coherencia, eso es lo
Juan (53:28)
Claro.
Douglas (53:31)
que hace ver que estás viendo más allá de la tarea que tenés en frente y que podés ser alguien que va a llegar a dirigir el stack técnico de un equipo. Vos dijiste Juan al principio que suena como un trabajo entretenido, como algo que nos llamaría la atención hacerlo.
Pero no olvidemos que no solo es que voy a tener la oportunidad de investigar tecnologías nuevas y de probar las tecnologías nuevas y de decir vamos a usar React en el front-end ¿Verdad? ¿La nueva ya? qué más hizo? No.
Juan (54:04)
Si, la nueva versión de tal cosa.
Douglas (54:09)
Ahí apenas comenzó tu trabajo. Ahora vas a ir a explicarlo, a enseñarlo, a evangelizar, como se dice, ¿no? Ese es el término que se usa en ese sentido, con esa tecnología, porque de manera directa en la mayoría de empresas no sos jefe de ninguno de los ingenieros, sos jefe del stack. Y más allá de buscar, forzar las cosas, es explicar y enseñar primero, como cualquier padre, ¿no? Que a nuestros hijos primero hay que explicarles las cosas.
y llevarlos de la mano y enseñarle antes de querer recurrir a otro tipo de disciplina. eso es lo que yo más resaltaría Juan para alguien que quiera llegar a ser un puesto de Teclit que si tiene esas cualidades de hecho les recomiendo que lo busquen activamente.
Juan (54:56)
Excelente, verdad es que me gusta mucho este enfoque que nos estás dando porque, como mencionábamos, tech lead suena a que alguien que solo va a estar en tecnología y estándares, etcétera, pero pues aún así necesitamos mejorar muchas habilidades blandas que por ejemplo documentar eso creo que a nadie le gusta o no estamos acostumbrados vamos a decir, no estamos acostumbrados.
Así que hay que mejorar esas cosas y buscar siempre, en general, yo diría Douglas que siempre hay que buscar mejorar porque sí, pero bueno, si en tu empresa te permiten, está definido esto en el career path, pues mucho mejor, mucho mejor aspirar a este tipo de cosas.
Douglas la verdad es que me ha gustado mucho la plática estoy seguro que si alguien pues tiene alguna duda nos puede comentar en los vídeos le vamos a tratar de contestar yo le puedo preguntar a Douglas para que nos ayude a contestar igual yo también puedo aportar en lo que pueda
Así que si alguien llegó hasta este punto, no me queda más que agradecerles mucho. Por favor regálenos un comentario, un like, compartir, todas esas cosas que ayudan al algoritmo para seguir creciendo y llegando a más personas para que esta comunidad bonita siga creciendo. ¿Verdad Douglas?
Douglas (56:23)
esto.
Juan (56:24)
Y bien, sin más que agregar, no sé Douglas si te gustaría algunas palabras antes de despedirnos de esta bonita audiencia que hemos tenido hoy.
Douglas (56:34)
aparte de agradecer por la atención, animar de nuevo una vez más a las personas que sientan que optar a un puesto como este en el futuro o crecer en su carrera en los diferentes puestos técnicos, lo tomen con frialdad, que seamos de mente abierta y aprovechemos las oportunidades que se nos brindan enfrente.
Juan (57:01)
correcto es correcto. bien muchas gracias a todos y nos vemos a la próxima.
Douglas (57:09)
Bye.