Sin duda, este pensamiento pasa por la mente de cada desarrollador.
Con el paso del tiempo esto es algo que de cierta forma es esperado, aunque no siempre es correcto, y hoy en día es común que las personas de edad avanzada y con experiencia lideren a las mas nuevas.

A bordo de un buque, el capitán, además de ser el líder de sus marineros, probablemente el es el más experimentado de ellos, y sabe muy bien lo que cada uno debe hacer y cómo.

He escuchado algunas historias de colegas que trabajaron con el equipo de Unix en IBM, allá existen niveles que van creciendo conforme a la experiencia de la persona. Existen también distintos niveles de liderazgo, y el líder de todos es el tipo de persona que puede hablar con usted de una secuencia de unos 10 comandos sin siquiera errar un parámetro.

¿Por qué ahora la mayoría de los líderes de TI no es así?

Hay varias razones que llevaron a esto. Hoy en día, por ejemplo, es muy común que el desarrollador sabe mucho mas de tecnología que su líder. Usted puede encontrar que esto no es correcto, pero eso es algo común, sin duda.

I. Tener un líder que no es del área de IT

La razón principal de esto es básicamente algo que por desgracia se ha vuelto más común, y es que personas que no están en el ámbito de la tecnología de la información,  asuman ese papel. La historia de que "no era eso lo que yo pedí" o "la migración no es tan simple" no siempre convence. Y eso se complica, si no es del área de exactas la persona que vino.
Note que cuando se habla de "es del área" no necesariamente tiene un diploma en IT. He tenido grandes líderes excelentes técnicamente que tenían graduación en otra área.
También tener diploma no significa ser del área, tiene que tener algo de desarrollador, de ser curioso, de adorar los desafíos, aprender cosas nuevas, estar en la sangre, y por ahí.

Cuando preguntan cómo identificar a alguien es del área,  se puede explicar haciendo una analogía, como en la película "Genio indomable": Si miro un piano, no veo nada más que un instrumento musical, tal vez imagine alguna música. Si Mozart viese un piano, él imaginaría toda una ópera. Si alguien mira un sitio de Internet, e imagina un simple medio de comunicación, estaría todo dicho no?.

II - Tener un líder que ya fué del área, pero se detuvo en el tiempo

Todos conocemos líderes que han programado en lenguaje prehistórico y no pueden usar Windows. Quizás algunas vez nos haya tocado negociar con personas que son líderes y que defienden Pascal o Cobol como el mejor lenguaje de todos los tiempos, y cuando tratamos de explicar algo más actual, como un comportamiento de una sesión web, también escucha comentarios como "hay, esas personas de Java sólo inventan!" .
Dentro de este mar de ignorancia, como hacen esos líderes para conseguir manteniendose? Charlemos un poco de eso.

Sobre la base del terrorismo

Esas famosas frases: "Si no está listo mañana, estará despedido!" O "no estoy satisfecho? Pase por Recursos Humanos" son los líderes que solo consiguen liderar en base al terrorismo. Algunas personas lo llaman falta de educación, o inseguridad. La literatura actual muestra que el método del taylorismo fue eficaz cuando el trabajador (el desarrollador) tenía menos conocimiento que el jefe. Hoy en día, la cosa es diferente, los conceptos de una tecnología después de un año pueden cambiar completamente.

OK, siendo sólo un desarrollador, ¿será un buen líder algún día?

Bueno, en primer lugar, tenemos que analizar lo que es ser un buen líder, tal vez, en su opinión sea malo, pero desde vista de la empresa es excelente.

Esto es muy subjetivo, pero creemos que para ser un buen líder, usted debe:

1. Estar actualizado con la tecnología

Un líder que puede tratar cualquier aspecto técnico es muy útil, además de eso el líder se gana el respeto del equipo. El líder no necesita saber, por ejemplo, todos los constructores de una API en Java, pero debería al menos saber lo que se puede hacer con esta API y cuáles son las ventajas de utilizarla.


2. Conocer bien el negocio

A menudo, el líder es el escudo entre los desarrolladores y los requisitos exigidos por los usuarios. Él debe saber exactamente lo que se solicita y, sobre todo, tener la capacidad de racionalizar el impacto de lo que se solicita. Exigir implementaciones imposibles, o incluso ya existentesmuestra la total alienación que un líder no puede tener.


3. Conocer los miembros de su equipo

Es importante saber que cada miembro tiene un ritmo de trabajo y una cierta facilidad para algunas funciones. Conforme la metodología
de desarrollo utilizada, cabe al líder de decidir qué es lo mejor para el proyecto. Por lo general, una conversación con el equipo ayuda en la decisión final.


4. Defienda a su equipo

Para identificar la postura de un líder, basta con reparar como él se refiere a los problemas encontrados en una implentación. Si la frase empieza con "la culpa fue de Fulanito", entonces está claro que no ve la cosa como un equipo, donde también es responsable de cualquier problema. La postura correcta sería asumir el problema como un equipo, por ejemplo: "Fue culpa nuestra, lo corregiremos tan pronto como sea posible".

¿Creé usted que esto es una exageración? Imagine entonces que usted que comprueba que un cajero de banco hace el pago de una manera equivocada y el ejecutivo de su cuenta cuenta le responde: "Oh, Yo no tengo nada que ver con eso, vaya a entenderse con él".

5. Marketing

El CP/M-DOS y MS-DOS eran prácticamente idénticos, pero uno de ellos desapareció del planeta y el otro se convertió en norma por un tiempo, haciendo millonarios a sus propietarios.
Cual de ellos era el mejor? Hoy eso no interesa, no importa, sobrevivió el de mejor marketing.
No alcanza con hacer un buen trabajo, si "los que mandan" no lo saben.

 

Estas pueden hacer algunas de las principales actitudes de un buen líder. ¿Y como conseguir todo esto?

¡No basta solo con leer, es preciso aplicarlo!

De la idea original

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw