Tres sencillos pasos para ayudar a sus ingenieros de software a agotarse

Si es un gerente que quiere agotar a sus mejores ingenieros y destruir su confianza en su liderazgo, puedo ayudarlo.

Trabajé en dos "equipos agotados" y observé en silencio a los ingenieros inteligentes a mi alrededor abandonar el equipo o la empresa.

Soy ingeniero líder en un equipo en una pequeña startup de capital de riesgo en etapa inicial. Reporto al CEO y trabajo codo a codo con él. En el segundo equipo al que me uní, fui uno de los 11 colaboradores individuales de una empresa de tecnología grande y conocida (como Meta, Google, Apple, etc.).

Aquí está la “estrategia de agotamiento” completa para esos equipos, paso a paso.

Paso 1: no confíes en tus ingenieros

Lo primero que debe hacer es microgestionar a sus ingenieros. Los ingenieros son inteligentes, pero ¿realmente entienden cómo desea que se vea su producto? Quizás no lo entiendas del todo.

Cuando era líder de ingeniería en una startup, trabajé codo a codo con el director ejecutivo. Me llamaba todos los días durante horas, cuidando pequeños detalles que no tenían ningún impacto en la experiencia real del usuario. ¿Estás seguro de que deberíamos usar DynamoDB? ¿Por qué esta función Lambda usa Python en lugar de Node? 

Es agotador ser interrumpido por un constante ding-dong.

También me dieron una autonomía limitada dentro de los equipos de las grandes empresas de tecnología. Esto no se debió necesariamente a mi jefe, sino al sistema mismo.

Recuerdo haber trabajado en un sistema que estaba construyendo. Me dijeron con tacto: "Necesitamos hacer este proyecto de esta manera. Sé que tomará un mes más, pero necesito hacerlo de esta manera (para lucir mejor en mi paquete promocional)".

Mark Randolph es el cofundador de Netflix.

Paso 2: Introducir procesos innecesarios que hagan perder tiempo

Cuando trabajaba en una startup, un día de repente me vi obligado a escribir una extensa documentación de diseño en detalle antes de poder implementar algo. Cada pequeña creación de un punto final API debe analizarse en profundidad de antemano. De repente, el lanzamiento de una función pasa de días a semanas. Esto me frustra mucho.

¿Qué es lo peor? ¡Ni siquiera hemos lanzado nuestro producto todavía! Todos estos procesos no tienen sentido hasta que tengamos siquiera una pizca de ingresos.

Mira, Google tiene una sólida cultura de redacción y los documentos de diseño son la norma allí. Pero en una startup, no eres Google. Google necesita una cultura de escritura debido a su tamaño y a la constante rotación de personas.

Esta situación a veces puede resultar demasiado compleja. En un equipo de una gran empresa de tecnología, los procesos suelen tardar demasiado. Para obtener ciertos tipos de datos, tuve que enviar una solicitud que luego fue aprobada manualmente por otro equipo, lo cual fue frustrante durante días. Para implementar mi función, tengo que obtener la aprobación de seguridad, producto, ingeniería, asuntos legales, cumplimiento e incluso del perro del director ejecutivo.

Durante un tiempo, todo lo que hice fue editar archivos, enviar correos electrónicos, leer documentos y responder a la gente. Lo que hago no tiene ningún sentido y no es porque quiera hacerlo.

Emmitt Hill es el cofundador de Twitch.

Por supuesto, estos procesos son necesarios... pero es necesario que haya un equilibrio. No todos los proyectos en los que trabaja un ingeniero necesitan pasar por estos procesos, ni deberían hacerlo. Afortunadamente, no todos los equipos de una gran empresa de tecnología son así. De hecho, la mayoría no lo es.

Paso 3: no entregar al cliente

No hay nada peor que trabajar duro en un proyecto durante 8 meses seguidos, sólo para obtener resultados que nadie ve. Especialmente en estos 8 meses, has hecho muchas horas extras.

Lo que es peor: lo que se suponía que sería un trabajo de ocho meses se pospone a 12, 16 o incluso 20 meses. Luego, el producto se corta y el esfuerzo que usted pone nunca se entrega a nadie para que lo utilice.

Se dice que trabajar en proyectos que nunca funcionan es una de las mayores causas de agotamiento.

El envío es el latido de tu empresa (2013)

En la startup en la que trabajaba, trabajamos duro en un producto durante más de un año pero nunca lo enviamos a los clientes. Cada vez que pensábamos que el producto estaba listo para enviarse, nuestro director ejecutivo pedía "sólo algunas funciones más". Después de un tiempo, el equipo pierde confianza en la capacidad de ejecución del director ejecutivo. Solo recibimos comentarios de lo que piensa el CEO, no de los usuarios reales, lo que hace que sea difícil preocuparse profundamente por el asunto.

El producto debe estar libre de errores cuando se entregue y tener una buena experiencia de usuario. Sin embargo, no es necesario que sean perfectos. Si él siempre busca la perfección, vamos a pasar momentos realmente malos. Especialmente porque todavía no hemos logrado adaptar el producto al mercado.

El perfeccionismo es a menudo una excusa para procrastinar.
Mirando hacia atrás, creo que nuestro director ejecutivo simplemente estaba retrasando la venta del producto y la recepción de comentarios críticos.

En los grandes equipos de tecnología en los que trabajo, a menudo nos reorganizamos a medida que los ejecutivos y vicepresidentes cambian en todos los niveles. Cada reorganización trae consigo nuevos ejecutivos con una nueva visión de la organización. Esto significó que los requisitos siguieron cambiando, muchos proyectos en los que trabajamos durante meses o incluso años fueron abandonados y nunca vimos el impacto de nuestros proyectos en el mundo real.

La falta de concentración conduce al fracaso en la entrega a los clientes. Cuando un producto no tiene una visión de liderazgo sólida, está condenado al fracaso.

https://twitter.com/JonErlichman/status/1404479095472373761

Paso adicional: prometer demasiado y cumplir poco

Este paso es la culminación de todos los pasos anteriores. Piénselo, por así decirlo, como el último clavo en el ataúd, la gota que colmó el vaso.

A la mayoría de los ingenieros de estos equipos se les prometieron beneficios excesivos que nunca se materializaron.

Durante mi año de inicio, estábamos creando un producto que nunca llegó al mercado mientras el director ejecutivo dedicaba su tiempo a recaudar dinero. Si bien inicialmente tenía una participación considerable en la empresa, comenzar a recaudar dinero antes de que el producto se adaptara al mercado significó que mi capital se estaba diluyendo. Muy diluido. De repente, el incentivo financiero para iniciar un negocio desapareció. Incluso si la startup saliera por mil millones de dólares, yo habría ganado la misma cantidad de dinero trabajando en una gran empresa de tecnología durante diez años. Más allá de eso, la compensación en las grandes empresas tecnológicas es totalmente líquida y está garantizada, y las salidas de mil millones de dólares son cada vez más raras en el entorno actual.

En las grandes empresas tecnológicas, todo ingeniero que se marcha se incorpora por alguno de los siguientes motivos:

  • Visión del producto: Les apasiona el producto y el problema que resuelve.

  • Espacio para el desarrollo/visibilidad futura: Sienten que tendrán más espacio para el desarrollo y, por lo tanto, más oportunidades de crecimiento.

  • Mejores oportunidades de promoción: mayor espacio de desarrollo y visibilidad → Promoción

Desafortunadamente, cada año todos los ingenieros pierden un poco de esperanza en lograr sus objetivos.

La desesperación acelera la aparición del agotamiento.

Sus razones para unirse a la empresa simplemente no se materializaron. Cuando sus esperanzas llegan a un punto bajo, se van.

Al final, no pude escapar del dolor del agotamiento. Entonces, elegí irme.

Extracto de: Códice del ingeniero

https://engineercodex.substack.com/p/how-to-burnout-a-software-engineer

 

Supongo que te gusta

Origin www.oschina.net/news/262153/how-to-burnout-a-software-engineer
Recomendado
Clasificación