Miguel.Simoni

A continuación, la traducción al español del artículo original escrito por Marcus Blankenship:

Cuando entrevisté a Jamie para un puesto en ZenTech, parecía un ingeniero entusiasta. Con sólidas habilidades tecnológicas, ideas para la mejora de procesos y productos, y una gran actitud de equipo, fue la elección obvia.

Pero, dos años después, Jamie era “ese tipo”. Ya sabes, el que quiere codificar sin ser molestado.

Debí haber notado las señales. No habló en retrospectivas, no contribuyó ideas para procesos o productos como yo esperaba y sus interacciones “amigables para el equipo” fueron generalmente sarcásticas. A menudo hablaba de deuda técnica, nuestra falta de innovación y las decisiones “estúpidas” que nos detenían. Un irritante sentimiento de “te lo dije” plagó sus comentarios y retroalimentación.

Jamie puede haber pensado en dejar la empresa. No podría decirlo si lo hizo. Aunque, ciertamente desearía que lo hubiera hecho. Pero estábamos escasos de personal y necesitaba toda la ayuda que podía obtener.

¿El resultado?

Otro programador cliché que solo quería codificar y quedarse solo.

La gente está formada por el medio ambiente

Demasiados gerentes creen que el problema radica en Jamie. Si fuera un mejor empleado, un trabajador dedicado o al menos se preocupara más, entonces esto no sucedería. ¿Verdad?

Lamentablemente no.

La transición del programador entusiasta al programador polarizado no ocurre de la noche a la mañana. Pero comienza antes de lo que piensas.

Las primeras sugerencias importan mucho

La forma como manejas las ideas de los nuevos programadores envía una señal importante. Buena o mala, prepara el escenario para lo que esperan. Esto determina si comparten más ideas en el futuro… o si mantienen la boca cerrada.

Claro, algunas ideas pueden no ser factibles en su entorno. Algunos podrían quedar en segundo plano para ser discutidos “cuando no estamos ocupados”. Algunas ideas parecen grandiosas, pero se topan con normas culturales no expresadas.

No importa cuál sea la razón, descartar o devaluar las ideas de su programador, especialmente en los primeros meses, es una mala jugada.

Dañado por todas las negativas, intentará algunas veces más presentar sus ideas de manera diferente, buscando un resultado exitoso. Si continúa sintiéndose castigado, se dará cuenta de que la única forma de ganar es no jugar.

Que es exactamente lo que no quieres que tus programadores aprendan.

Dejará de presentar ideas, solicitar reunirse con clientes y tratar de entender genuinamente el negocio.

En definitiva, es perder perder.

Cuanto mayor es la idea, mayor es el riesgo

Recuerda que tu programador se arriesga cuando ofrece una nueva idea. Cuanto mayor es la idea, mayor es el riesgo.

¿Por qué es un riesgo? Porque nuestras ideas nos reflejan a nosotros mismos, nuestros puntos de vista y nuestras pasiones. No promocionamos ideas que no nos interesan o que creemos que no funcionarán. Presentamos nuestras mejores ideas con la esperanza de que sean recibidas.

Esto requiere vulnerabilidad, lo cual solo ocurre si estamos bastante seguros de que no seremos humillados. Si creemos que nuestras ideas no serán aceptadas, dejamos de ofrecerlas.

Los comentarios sobre las ideas moldean el comportamiento

Es natural entonces, que tu programador se reduzca a hacer solo lo que le da el éxito: la codificación.

Su entusiasmo por la creación, la innovación y el desarrollo, por desgracia, están perdidos.

Tal vez se conviertan en ideas poco realistas sobre calidad o métricas del código.

Su preocupación por la cuota de mercado y la salud empresarial se reemplaza con una preocupación por los títulos y las escalas salariales. Se preocupa más por cuánto gana, cuál es su cargo y cómo se ve en LinkedIn.

Su entusiasmo por cambiar el mundo es reemplazado por el proceso de desarrollo.

Peor aún, sin embargo, su preocupación de que “No estamos construyendo lo correcto” será reemplazada por “No estamos construyéndolo correctamente”.

Aprendió a no aportar ideas sobre lo que se construye, por lo que se obsesiona con la forma en que está construido.

Tu cultura, para él, se ha convertido en la supervivencia del más apto.

¿Cuál es tu enseñanza?

Si bien nunca dirías esto directamente, tu cultura puede estar enseñando:

“A nuestra empresa no le gustan las grandes ideas de personas pequeñas”.
“Solo te enfocas en construir cosas”. Entendemos lo que el cliente necesita".
“Eres solo un mono de código”.
“Hmm … ¿por qué estás haciendo tantas preguntas? ¿No tienes código para hacer?”

¿Cuál es tu verdadera cultura?

La cultura no es el eslogan en tu pared, ni cómo describes tu misión durante una entrevista. La cultura es la forma en que las personas realmente actúan y lo que realmente les importa.

Ifte Choudhury, Profesor de Texas A&M University, declara,

“Una cultura es una forma de vida de un grupo de personas: los comportamientos, las creencias, los valores y los símbolos que aceptan, generalmente sin pensar en ellos y que se transmiten a través de la comunicación y la imitación de una generación a otra”.