Una llamada de atención para gerentes técnicos

El artículo más popular que he escrito se llama Por qué su programador solo quiere codificar. Hasta la fecha ha recibido más de 62,000 lecturas.

(La tercera parte de esta serie, cómo los programadores pueden cambiar su entorno, está aquí).

El artículo cuenta la historia de Jamie, un programador que se une a una nueva compañía llena de entusiasmo e ideas. Avance rápido un par de años, y Jamie es uno de esos programadores "que solo quiere codificar". Un programador que no aporta nuevas ideas, no ofrece nuevas formas de hacer las cosas y solo quiere que lo dejen solo. escribir código

Lamentablemente, casi no recibí respuesta de los gerentes o líderes sobre esta historia.

Parece que algunos de ustedes perdieron el punto, así que déjenme ser franco.

Gerentes tecnológicos, estas situaciones son tu culpa.

Debe aceptar la responsabilidad de los programadores desmotivados que "solo quieren codificar" o que parecen preocuparse solo por tecnología nueva y llamativa.

Como líder, usted es responsable de crear un entorno en el que todos puedan contribuir a resolver los problemas en cuestión.

En cambio, parece que muchos programadores son tratados como sabios idiotas; niños brillantes capaces solo de codificar.

Para. Seriamente.

La respuesta masiva a este artículo debería asustarte muchísimo. El mercado está de moda, dándoles el poder de renunciar y reemplazarlo a USTED por un mejor líder.

Tengo la sensación de que están locos como el infierno, y ya no lo soportarán más.

¿No me crees? Sigue leyendo ...

Escribí el artículo con la esperanza de que los líderes reconocieran que los programadores quieren poner todo su cerebro a trabajar, pero con demasiada frecuencia el entorno les impide hacerlo.

En cambio, recibí miles de respuestas (aplausos, comentarios o mensajes) de programadores que desean que sus gerentes presten atención. Quien desea que su cultura acoja, discuta y debata ideas.

Algunos de los comentarios que destacaron son ...

¡Omg predica! Phenomenon Este fenómeno de "negación de ideas / comentarios" es el asesino de innovación más mortal de toda la tierra, y perjudica a todos los departamentos (no solo un problema de codificador). "
“Entré a las armas de la fuerza laboral en llamas, listo para marcar la diferencia. Ahora, lucho por suprimir mis verdaderos pensamientos todos los días y solo trato de cómo están las cosas ... REALMENTE espero que los líderes comiencen a resolver esto pronto ”.
"Pasé por algo similar, incluso dejé de trabajar en mis proyectos de mascotas porque la codificación en el trabajo era una mierda y exigente, ¡me alegro de haberlos dejado después de 5 meses!"
"Es triste que en realidad la cultura de codificación en mi entorno actual sea que los programadores simplemente están interesados ​​en terminar una tarea en lugar de pensar en compartir ideas".

Hasen tiene una visión ligeramente diferente.

"Lo que necesitamos no es" aceptación "de ideas. Necesitamos ver nuestras ideas discutidas y debatidas, y luego ver que la decisión se basa en el mérito de la idea, no en nuestra posición.
Si presento una idea y se discute y luego se descarta, está bien.
Si presento una idea y me dicen que no debo hacer eso y que solo me concentro en mi tarea actual, entonces es una señal clara de que no se me permite hacer nada más que cumplir con órdenes como un gruñido.
Cuando eso suceda, básicamente estaré buscando el próximo trabajo ".

Ese último lo resume. Cree un entorno en el que sus programadores puedan contribuir completamente, o de lo contrario los mejores se irán.

Seamos realistas. Si ve este problema en su equipo, no se solucionará de la noche a la mañana. PERO, puede dar grandes pasos para revertir este problema.

Cambiemos las cosas.

Comienza a escuchar y deja de contar

Si tiene desarrolladores que solo quieren quedarse solos, hoy es un gran día para cambiar las cosas.

Comience en su próximo 1: 1 con ellos. (¿No tiene 1: 1? Utilice mi guía para comenzar hoy).

Paso 1: Sé humilde.

Tenga una conversación de reinicio con cada miembro del equipo, donde honestamente le pregunte si ha sido sordo a sus ideas, tratándolas como "recursos" y frustrando.

Independientemente de lo que digan, diles que no quieres ser ese tipo de jefe, y que lo sientes. (Sí, es bueno disculparse con las personas que puede haber herido. Sí, incluso si usted es el jefe).

Luego, diles que necesitas su ayuda. Confías en sus comentarios para mejorar. Dales permiso para detenerte la próxima vez que lo hagas y para que te den su opinión en privado sobre tu comportamiento.

Finalmente, agradézcales por estar allí y todo su arduo trabajo. Agradézcales por escuchar y ayudarlo a convertirse en el tipo de gerente que necesitan.

Paso 2: Escucha más, cuenta menos.

En todas sus interacciones con el equipo, hable la mitad. Luego, la mitad de nuevo.

Esto probablemente los pille desprevenidos, especialmente si usted ha estado "liderando desde el frente" y diciéndoles qué hacer.

En cambio, escuche cómo se hablan entre ellos. Cómo hablan de clientes, jefes u otros equipos. ¿Quién controla el flujo? ¿Quién todavía está tratando de poner ideas por ahí? ¿Quién parece completamente apagado?

Vea si puede lograr que todos participen a través de preguntas abiertas. Considere usar un "palo parlante" si algunas personas aspiran todo el aire de la habitación. Establezca suavemente las expectativas de que desea escuchar la contribución de todos para resolver problemas.

Paso 3: pregunta con más frecuencia que decir

La mayoría de los gerentes de ingeniería adoptan el enfoque predeterminado para decirles a los ingenieros cómo se debe hacer algo. Esto probablemente se deba a que solían ser ingenieros y que "ven la respuesta con claridad".

Sin embargo, contar no construye el equipo, los apaga.

Entonces, comienza a hacer más preguntas. Mucho por qué? preguntas Por supuesto, tienes que aprovechar tu curiosidad e inclinarte para escuchar la respuesta.

A decir verdad, usted depende de ellos para hacer el trabajo y depende de ellos para tomar un millón de pequeñas decisiones. Debes estar muy interesado en lo que piensan y en sacar a la luz sus ideas.

El libro Humble Inquiry de Ed Schein es un recurso maravilloso para aprender a hacer mejores preguntas.

Líderes tecnológicos, tienes trabajo que hacer. Será mejor que empieces a pasar las noches completas para arreglar las cosas antes de que sea demasiado tarde.

(¿Todavía no está convencido? Lea los cientos de comentarios de desarrolladores frustrados que desean mejores líderes, luego pregúntese: "¿Está sucediendo esto aquí?")

(¿Quieres ayuda? Respondo tus preguntas EN VIVO cada viernes a las 10 a.m. PST en UNSTUCK: The Tech Leader Q&A Show).