De ingeniero a gerente: lo que me gusta y lo que no
(thoughtspile.github.io)- Después de trabajar 7 años como desarrollador frontend y pasar a ser líder de equipo y luego engineering manager de tiempo completo, aumentó su influencia sobre el producto y el equipo, pero la naturaleza del trabajo cambió mucho
- Un gerente puede intervenir con autoridad formal e informal en problemas que eran difíciles de cambiar como IC, como escribir pruebas, mejorar procesos o ajustar el ambiente del equipo
- En una carrera de largo plazo, obtiene mejor remuneración que los niveles comunes de ingeniería, más oportunidades que un IC staff+, y habilidades transferibles que facilitan moverse a otras áreas técnicas, gestión de proyectos, gestión de producto o emprendimiento
- Por otro lado, debe ejecutar procedimientos corporativos como evaluaciones de desempeño, fechas límite poco realistas y políticas organizacionales, y cargar directamente con conflictos, inseguridad psicológica y la presión de estar siempre disponible
- El trabajo de management rara vez muestra resultados en menos de un mes, y hasta los cambios correctos, como dividir un equipo o contratar, pueden empeorar la situación en el corto plazo, por lo que hay que soportar ciclos de feedback largos
El proceso de pasar de ingeniero a gerente
- Hace unos 2 años pasó a ser líder de equipo y, tras la expansión del equipo, se convirtió en engineering manager de tiempo completo
- Antes de eso trabajó 7 años como desarrollador frontend; al principio eligió la trayectoria de contribuidor individual (IC) senior, y luego hizo la transición a un rol de management
- El proceso de transición fue irregular, pero interesante, y en su trabajo actual hay tanto cosas que le gustan como cosas que no
Lo que me gusta del rol de gerente
-
Autoridad para cambiar el producto y el equipo
- Al convertirse en gerente, se obtiene autoridad para mejorar el estado general del producto y del equipo
- Como IC, puede ser difícil cambiar problemas como standups muy temprano, baja calidad de código o nuevas funcionalidades difíciles de entender
- Un EM puede usar autoridad formal e informal para ajustar la forma en que el equipo y él mismo trabajan, de modo que sea mejor
- La misma frase “hay que escribir pruebas” no pesa igual cuando la dice un IC que cuando la dice un EM, y lo que dice un EM puede terminar convirtiéndose en pruebas reales
-
Oportunidades de carrera más amplias
- Ser engineering manager ofrece oportunidades de carrera más amplias que la trayectoria típica de ingeniería
- Un EM suele ganar más que los niveles básicos de ingeniería dentro de un equipo, como junior, middle y senior
- También existen niveles de IC más altos, como staff y principal, con bandas de compensación iguales o superiores a las de un EM
- Sin embargo, los puestos de IC staff+ se concentran en grandes empresas tecnológicas con desafíos técnicos más difíciles, mientras que casi todos los equipos de software de cualquier empresa tienen posiciones de liderazgo
- La escalera de carrera de management continúa más arriba que la de IC
- Aunque la probabilidad de convertirse en CTO sea baja, se abren opciones que un IC puro sin experiencia de management no tiene
- La demanda de EM es más estable que la de ingenieros staff+ y ofrece más oportunidades incluso en etapas avanzadas de la carrera
-
Habilidades con las que es más fácil moverse a otras áreas
- Las habilidades de management se aprovechan de forma más amplia que las de un rol específico de ingeniería como IC
- Un ingeniero frontend con experiencia en React puede moverse a otro framework frontend, o cambiar a backend o mobile aceptando cierta pérdida de nivel
- Con experiencia como engineering manager, es más fácil hacerse cargo de equipos con focos distintos, como un equipo de desarrolladores mobile, un equipo de infraestructura o un equipo de ingenieros de ML
- Hace falta tiempo para entender las grandes dificultades técnicas del nuevo equipo, pero muchas empresas pueden aceptar este tipo de transición
- Si no se quiere seguir como EM, se queda en una buena posición para pasar a roles de gestión de proyectos o gestión de producto
- Aunque todo el mercado tecnológico se desacelere, muchas habilidades de management pueden funcionar también en otras industrias
- La experiencia de involucrarse con personas y decisiones de negocio también es útil como entrenamiento previo para emprender
-
El conocimiento envejece menos rápido
- Si seguir el ritmo de los frameworks y herramientas frontend más recientes resulta agotador, un rol de management puede reducir esa carga
- Las metodologías agile, kanban y scrum “nuevas” son conceptos de hace 20 o 30 años, y los tipos básicos de reuniones como demos, dailies y 1:1 han evolucionado durante mucho tiempo
- En el núcleo del management están el trabajo en equipo y la interacción humana, y eso no ha cambiado mucho desde los inicios de la humanidad
- Aunque hay que seguir observando los cambios tecnológicos, relativamente hay menos necesidad de profundizar con urgencia
-
Nuevos desafíos fuera de los problemas técnicos familiares
- Después de trabajar 4 o 5 años en un área técnica específica, la mayoría de los problemas prácticos ya se pueden resolver lo suficiente
- Hay límites en las formas en que un ingeniero experimentado puede buscar desafíos más grandes
- Cambiar un poco el stack, por ejemplo a un nuevo framework frontend, difícilmente mantiene el interés por mucho tiempo
- Una transición más grande, como pasar de frontend a backend, puede dar algunos años de diversión, pero puede ocurrir por casualidad o afectar la remuneración
- Inventar problemas, como reescribir todo con una nueva librería o intentar manejar 9000 RPS para el futuro, puede ser divertido, pero a menudo perjudica al equipo y al negocio
- Para un ingeniero experimentado, pasar a management ofrece la mayor cantidad de cosas nuevas que aprender sin bajar la remuneración
Lo que no me gusta del rol de gerente
-
Tener que ejecutar procedimientos corporativos
- Como ingeniero, odiaba la BS corporativa, como las evaluaciones individuales de desempeño, fechas límite inútiles y restricciones de procesos o stacks tecnológicos impuestas por la empresa
- Al convertirse en gerente, uno pasa a ser la persona que ejecuta esas prácticas, crea en ellas o no
- En una organización con calibración de desempeño, cada 6 meses el líder del equipo debe señalar a 1 persona que no trabajó lo suficientemente duro
- Si no se entrega a un miembro del equipo como sacrificio, alguien puede ser elegido al azar en una etapa posterior del proceso, así que es difícil eliminar el procedimiento
- Algunos procedimientos se pueden negociar o esquivar; por ejemplo, asignar “desempeño por debajo de lo esperado” en formato round-robin
- Desde la perspectiva del equipo, a veces el gerente puede parecer un monstruo corporativo
- Todavía no ha pasado por situaciones más difíciles como despidos, cierres o reorganizaciones
-
Tener que lidiar con tensiones entre personas
- El punto de partida para convertirse en engineering manager fue la capacidad de construir bien cosas, y esperaba apoyar decisiones técnicas, dar consejos de carrera, ajustar procesos y crear automatizaciones
- En la práctica, una gran parte del trabajo consiste en depurar tensiones sociales e inseguridad psicológica de las personas
- Ejemplo de situación:
- Un ingeniero junior comenta algunas pruebas para poder desplegar una vista previa de una funcionalidad
- La persona de QA se enfurece porque siente que el equipo no respeta el rol ni el valor de QA
- El gerente debe reconstruir la confianza
- Otro ejemplo:
- Un project manager hizo un chiste fallido y una diseñadora se sintió herida hasta ponerse a llorar
- El gerente debe lograr que el PM se disculpe
- Como no es psicólogo ni alguien especialmente bueno tratando con personas, esta parte es difícil y se parece más a un proceso de aguantar hasta acostumbrarse
-
Una estructura de trabajo que dificulta desconectarse
- La vida de un ingeniero puede ser relativamente tranquila
- Si no hay nada urgente, puede pasar medio día afuera pensando en el futuro del proyecto, y faltar de repente a algunas reuniones quizá no sea un gran problema
- Si un EM se ausenta unas horas, se acumulan problemas en el mensajero
- Un pasante olvidó cómo hacer
npm instally no puede trabajar - Un gerente senior quiere hablar sobre una funcionalidad potencial
- El release se descarrila
- Un pasante olvidó cómo hacer
- Las reuniones que uno dirige u organiza son difíciles de saltar sin preparación previa
- Esto puede mejorar si el equipo madura y los procesos mejoran, pero en general un gerente siente mucho más las horas de oficina
- El equilibrio vida-trabajo pasa a depender directamente de la propia capacidad para hacer el trabajo
-
Los ciclos de feedback son largos y no lineales
- La mayoría del trabajo de ingeniería muestra resultados relativamente rápido
- Una nueva funcionalidad da resultados en semanas o meses, y al corregir un bug se puede ver la reacción de los usuarios al día siguiente
- En una refactorización, se puede confirmar una reducción de complejidad en cuestión de horas
- Las acciones de un gerente muy rara vez producen resultados visibles en menos de un mes
- Si el equipo creció demasiado y hay que dividirlo, se deben atravesar varias etapas
- Definir la composición adecuada de ingenieros para el nuevo equipo
- Hablar con las personas involucradas sobre sus sentimientos ante el cambio
- Crear nuevas reuniones recurrentes
- Establecer procesos y comunicación
- Encargarse de tareas relacionadas con Jira
- En algunos casos, separar el codebase de un subproducto
- Si uno cree que puede terminar todo esto en una semana, está equivocado
- Incluso los cambios correctos pueden empeorar antes de mejorar
- Si falta personal y se decide contratar, en el corto plazo las entrevistas consumen mucho tiempo, y los nuevos integrantes no pueden arrancar a plena velocidad de inmediato, por lo que necesitan onboarding
- Los cambios de management se parecen más a una refactorización a gran escala que a una solución rápida de problemas, y puede ser frustrante no ver mejoras inmediatas
Para ingenieros que están pensando en la transición
- Pasar de ingeniero IC a management es una experiencia tipo montaña rusa, con lados luminosos y oscuros
- Las ventajas son tener un impacto más amplio en el producto y el equipo, mayores oportunidades y flexibilidad como trayectoria de carrera de largo plazo, y un nuevo desafío cuando el campo técnico empieza a aburrir
- Las desventajas son ejecutar políticas corporativas, manejar tensiones sociales e inseguridad psicológica, una estructura de trabajo que dificulta desconectarse, y una satisfacción muy retrasada con ciclos de feedback largos
- Si disfrutas los desafíos y la responsabilidad, y tienes la oportunidad, vale la pena intentarlo
- Management no es para todos, pero puede ser una experiencia que amplía el alcance técnico y permite ver el trabajo de ingeniería desde un ángulo nuevo
- Si definitivamente no encaja contigo, todavía hay tiempo suficiente para volver a programar
1 comentarios
Opiniones de Hacker News
Fui manager cuatro veces, incluyendo dos en FAANG, pero hay muchas partes del texto original con las que no estoy de acuerdo.
La escalera de management en realidad no está más arriba, y la mayoría de los engineering managers se concentran en el equivalente a L6/staff engineer. Los ascensos a senior manager o más arriba dependen mucho de las circunstancias y son raros, mientras que mis colegas en el track de ingeniería ascienden cuando están listos, sin tener que esperar a que se alineen los astros.
Las personas que fueron despedidas siendo engineering managers puros muchas veces siguen buscando trabajo y están cerca de rendirse, pero quienes están dispuestos a volver a roles de IC no tienen grandes problemas para conseguir empleo. La cultura de management varía muchísimo de una empresa a otra y es difícil de transferir directamente; en esta industria, creo que la habilidad más transferible es la estructura interna de Linux.
También me parece extraña la idea de que con 5 años de experiencia se puede resolver la mayoría de los problemas. Llevo 18 años trabajando y todavía hay muchas cosas que no sé y muchas en las que debo mejorar; incluso ingenieros excelentes con 40 años de experiencia siguen aprendiendo.
Lo mejor de ser manager es que pasas mucho tiempo pensando en el futuro y aumentan tus posibilidades de entrar a “esa sala” donde se habla con el C-level. Al mismo tiempo, también es lo peor, porque ves demasiado de cerca cómo se toman las decisiones.
Estoy de acuerdo con las partes que al autor original no le gustaron, pero con el tiempo mejora. Dicho eso, si eres un manager nuevo, puede que todavía no hayas vivido lo que más vas a odiar: que en muchas empresas la alta gerencia se comporta como una camarilla de secundaria, y se toleran problemas de conducta de VPs, C-level y a veces directores que, si vinieran de un empleado común, serían motivo de despido.
La mayoría de los software engineers se estancan en senior, especialmente en Google, así que concentrarse en L6 ya es un privilegio relativo. El ascenso a L6 no es extremadamente raro, pero tampoco lo recibe la mayoría, y L7 o más es difícil. Si sientes que la mayoría de tus colegas llega hasta ahí de forma natural, puede que estés dejando fuera a quienes se fueron porque no ascendieron, o que hayas tenido pocas oportunidades de acercarte a personas en niveles más bajos que el tuyo.
Estoy de acuerdo en que el camino de engineering manager no abre tantas puertas como antes se pensaba, pero no parece que las oportunidades de ascenso sean más estrechas que para un IC.
Crear algo de 0 a 1 tiene muy poca relación con la gestión de ingeniería. Lo más importante es poder escribir código rápido y hablar con comodidad con clientes potenciales, y ninguna de las dos cosas está directamente relacionada con el rol de engineering manager. Tampoco hay garantía de que llegues a contratar gente para gestionar.
Estructuralmente hay muchos menos puestos de management que de ingeniería, y como la frontera entre lead engineer y manager de primera línea es bastante difusa en ambos sentidos, el pool real de competencia tampoco se reduce tanto.
Cuando digo transferible me refiero a habilidades útiles incluso fuera de la burbuja de big tech. Puede que el dinero sea tan bueno que no quieras salir, pero conviene saber que hay cosas que puedes hacer además de hacer que las computadoras hagan bip bip.
Por ejemplo, la idea de que si un engineering manager dice “hay que hacer más pruebas” se lo toman más en serio que si lo dice un IC.
De hecho, cuando yo era un IC recién ascendido a nivel staff, sentía que me faltaba credibilidad y consideré pasarme a management porque pensé que esconderme detrás de un título ayudaría. En realidad no era necesario, y ahora, como IC en otra empresa, mis ideas y feedback se toman en serio a nivel organizacional y entre mis colegas.
Un sistema que obliga cada semestre a rankear a la gente y elegir a los de bajo desempeño está roto. Es una triste realidad que la gestión del desempeño funcione así en muchos lugares, pero no es una verdad universal de que, como manager, necesariamente tenga que ser así. Las conversaciones difíciles sobre problemas reales de desempeño son estadísticamente inevitables, pero también hay empresas donde no tienes que decir cosas como “este semestre todos tus compañeros lo hicieron mejor que tú” o “había que elegir a alguien y esta vez te tocó a ti”.
Me gusta resolver problemas y ver el panorama general, y disfruto encontrar soluciones y destrabar obstáculos. El rol que mejor me quedaba era el de “arquitecto”, aunque como título parece estar desapareciendo. Aun así, eso no cambia el hecho de que ese trabajo sigue siendo necesario.
También probé roles de líder de equipo/manager, Scrum Master y product manager, y las habilidades que necesita un buen manager son muy distintas de las de un ingeniero. La clave es tener un neuroticismo extremadamente bajo, es decir, la capacidad de tomar buenas decisiones bajo estrés prolongado y mantener una apariencia calmada y racional.
El 90% de los mandos medios no tiene esta característica y, cuando se estresa, termina dañando al equipo y a la empresa. Si quieres ser manager, debes evaluar con honestidad cómo reaccionas ante el estrés sostenido. Factores que parecen aburridos —si te desquitas con quienes te rodean, si te escondes o te paralizas y no puedes decidir, si culpas a otros para proteger tu reputación— son la diferencia real entre los managers efectivos y el resto.
Normalmente incluye trabajos poco divertidos: sacar a la luz problemas que todos evitan, dejar que la gente se queje en grupo de mis decisiones, y seguir involucrado aunque la otra persona se desconecte y te rechace.
Para mí, la gestión se sintió como algo que exige todas las cucharas que tienes y luego pide más. Dicho eso, creo que esto tiene más que ver con mi encaje personal que con la esencia de la gestión. Según encuestas de internet, mi neuroticismo es medio, pero me cuesta detenerme en “suficientemente bueno”, y siento que el alcance más amplio de responsabilidades en management genera un problema de escalabilidad emocional.
Quizá la clave para resolver el crunch y el burnout sea crear un entorno regulatorio donde todo el sustento de los trabajadores —salud, renta, pago de préstamos para universidades públicas, etc.— no dependa únicamente de conservar un empleo.
Como IC, puedes hacer crecer tu carrera aprendiendo nuevas tecnologías o dominios, pero como manager el desarrollo profesional termina dependiendo cada vez más del crecimiento personal: madurez, perspectiva, resiliencia emocional. Quizá por eso la seniority y el interés por cosas como la meditación mindfulness suelen crecer juntas.
A HN no le va a gustar, pero aunque soy soltero también me pregunto si los padres no terminan siendo mejores managers. Tal vez porque es menos probable que pierdan perspectiva y se estresen por cosas que no importan en el panorama general. Curiosamente, parece que uno gestiona mejor cuando toma cierta distancia emocional.
Resulta que soy bastante sensible por temperamento, así que personalmente me preocupa estar constitucionalmente mal adaptado para la gestión. También me cuesta ese lado a veces hipócrita de “no es controlar, es motivar”. Yo solo quiero moverme por la organización arreglando problemas, simplificando procesos y rediseñando sistemas de trabajo.
Llevo 12 años como ingeniero de software y no tengo ningún deseo de ser manager. Simplemente quiero construir cosas, no gestionarlas.
Trabajo de cerca con managers y veo en qué consiste el trabajo, pero no me resulta nada atractivo. Como ingeniero senior, lo que digo a menudo tiene influencia, pero me gusta no tener la enorme responsabilidad que viene con ser manager. No quiero sumar más estrés a mi vida.
Probablemente pase los próximos 30 años de carrera en un puesto como el actual.
Hace unos años yo estaba en una situación parecida. Mi jefe me apreciaba, tenía muchos contactos, compartía toda la información conmigo, me sentaba en espacios de toma de decisiones, me pedía opinión sobre la dirección y, si hacía falta, me respaldaba si hablaba en nombre suyo o de otros managers.
Ahora llegó una estructura de management completamente nueva, muy vertical, con mucho ego y poca disposición a aceptar feedback. Los managers de nivel inferior o ingenieros que alzaban la voz fueron marginados una y otra vez, y la autonomía y voz que yo tenía casi desaparecieron.
Incluso me quitaron muchas cosas que yo consideraba decisiones de ingeniería. Necesitaba X para un servicio que iba a construir, así que hice una solución automatizada que funcionaba bien; unos meses después me dijeron que estaba equivocado porque había otros planes para X, y me ordenaron borrar la solución totalmente automatizada y reemplazarla por un proceso empresarial manual de otro equipo. Ese trabajo se omite con frecuencia, lo que reduce la confiabilidad de mi servicio.
Me alegra no ser el manager que tiene que pelear con esa gente. Si lo fuera, probablemente ya habría perdido el empleo y me habrían reemplazado por alguno de sus amigos. Pero la influencia de un ingeniero senior puede variar muchísimo a largo plazo, incluso dentro de la misma empresa y el mismo equipo.
También existen puestos técnicos más altos con poca o ninguna responsabilidad de gestión: senior principal engineer, arquitecto, etc.; depende de cuánto valore la empresa lo que haces.
El mejor ejemplo que vi fue un ingeniero con doctorado y décadas de experiencia que trabajaba como gurú de investigación/arquitectura, usaba mucho Matlab, no tenía equipo ni reportes directos, y era “VP of technology” en una empresa de cientos de personas.
Lo difícil no es solo el aprendizaje en sí ni las personas, sino el contexto que las rodea. Adoptar una perspectiva de gestión es muy útil para entender qué se está construyendo y por qué, y por qué el trabajo parece ineficiente y roto. También te da intuición sobre las soluciones y sobre el contexto que no se está comunicando correctamente.
Actualmente soy desarrollador senior y estoy entrevistándome para una posición de líder de equipo en una startup. Creo que tengo un alto nivel técnico, pero lo que más me frustra en el día a día son los problemas relacionados con el trabajo en equipo.
Falta de confianza, compañeros que no quieren hablar entre sí, otros seniors que hacen trabajo por debajo del nivel esperado y aun así lo dejan pasar, ausencia de un objetivo claro de equipo y de visión de producto, y falta de acuerdo sobre prácticas comunes de ingeniería. Si me convierto en manager de personas, para bien o para mal, esos problemas pasan a estar dentro del alcance donde debo influir y asumir responsabilidad.
Pero cuando efectivamente me convertí en líder de equipo, descubrí que el alcance real de mi influencia era mucho más pequeño de lo que pensaba. Hay mucha gente, incluido mi jefe, que quiere operar todo directamente, y de mí solo esperan que ponga el sello.
Más bien se vuelve más incómodo, porque tengo que decir en nombre del equipo cosas que la gente teme decir. Por ejemplo: “para que una historia esté lista, la API tiene que estar definida”. Si ni siquiera sabemos qué hay que probar, ¿cómo puede QA crear pruebas automatizadas en paralelo?
Scrum Masters, Product Owners, managers y arquitectos dicen cada día lo que les conviene como si fuera una verdad evidente, y al día siguiente se quejan de por qué las pruebas van atrasadas.
Al final todo deriva en política sobre quién tiene la culpa del estado actual, y quienes eligieron esa dirección y estrategia tienen buenos contactos y también saben pasar la responsabilidad a otros.
Hace tiempo estaba en la oficina de mi entonces jefa después de que ella terminara con éxito una llamada para pedirle algo a una persona de otro departamento.
Mi jefa levantó la vista desde su escritorio, sonrió un poco y, con tono desconcertado, dijo: “No es que me haya vuelto más bonita porque mi cargo cambió de ‘Specialist’ a ‘Manager’, pero definitivamente ayuda a lograr que las cosas se hagan”. Fue un momento en el que el poder del cargo funcionó de verdad.
A un manager es fácil ignorarlo si no amenaza con consecuencias reales, y esa carta hay que usarla con moderación.
Hace unos años empecé como engineering manager siendo CTO de una startup pequeña, y mi vida cambió mucho. Siento lo mismo sobre todos los aspectos que el texto original dice amar y odiar.
Un consejo adicional es meditar de verdad. Antes de tomar decisiones importantes e influyentes que pueden perjudicar a la gente, hay que sentarse en silencio el tiempo suficiente como para que el cerebro se apague.
Al principio se vuelve una especie de relación padre-hijo con genios. Hay que aceptar a las personas y entender su manera de hacer las cosas. Cuanto más control impongas, menos control real tendrás. Intentarán esquivar y resistir la burocracia innecesaria y, francamente, yo también lo haría.
El segundo consejo es actuar siempre como alguien que se irá mañana. Eso deja preparados al equipo y a los colegas, y también mejora tu propio estilo de vida.
Crecen muy rápido, y es extrañamente tranquilizador comprobar que la organización funciona sin mí. Al mismo tiempo, como parecen crecer más rápido cuando no estoy, también me pregunto si eso será una señal de que estoy haciendo algo mal.
Algunos días siento que estoy administrando a mi familia con habilidades que aprendí en el trabajo.
Mi trasfondo es el opuesto. Soy un ingeniero de software común y corriente, pero tengo bastante buena habilidad para tratar con personas.
Tengo suficiente experiencia para saber qué cosas toman tiempo y qué partes del sistema son más importantes. Hay varios ingenieros senior a quienes escucho de verdad y a quienes les doy mucha confianza y autoridad.
Las decisiones de diseño no las tomo yo, las toman ellos, y yo aporto opiniones. Si falla, asumo la responsabilidad y aprendo; si tiene éxito, le doy el crédito al equipo. Incluso dicho con humildad, creo que el rol de manager, por encima de todo, trata sobre personas.
Hay una sola razón por la que quiero pasar de un rol de coder/IC a la ruta de gestión: las entrevistas de pizarra necesarias cada vez que cambio de trabajo.
Casi duele tener que prepararse desde cero cada vez, y aunque existen roles sin ese proceso, son muy raros. Cuando pienso en esa preparación, muchas veces termino quedándome en el mismo trabajo con un “ay, por favor, ¿otra vez?”.
Un mal engineering manager puede causar muchísimo más daño que un mal IC. Creo que esta conversación no se aborda con la frecuencia suficiente.
En una carrera larga, me encontré con 1 manager excelente, algunos managers aceptables y muchos managers pésimos. Los managers pésimos hacen que el trabajo sea mucho más difícil y a veces directamente miserable.
La combinación de un mal engineering manager con un IC junior puede ser especialmente mala. Con los años aprendí que también puedo trabajar con malos managers y mover la situación hacia un lugar mejor, o irme si siento que no hay esperanza.
Últimamente tengo más responsabilidades de gestión y me gustaría saberlo.
En una época lideré un equipo compuesto por ICs con doctorado. Tenía que encontrarles trabajo, contener a los soñadores y mantenerlos felices.
No es broma: a veces hablaba con ellos individualmente durante seis horas seguidas, actuando como orientador profesional y consolador. Nunca pensé que eso se convertiría en mi trabajo.
Uno de los miembros del equipo ayudó a cerrar dos contratos separados de 1.000 millones de dólares, así que mi tiempo quedó recompensado.