Cómo dar forma y definir un rol de liderazgo técnico [cerrado]

En una serie de proyectos me encontré en un rol mal definido en la parte superior izquierda del organigrama sin nadie que me informara directamente pero con una amplia responsabilidad sobre los aspectos técnicos del proyecto. En los casos en los que tengo un equipo que gestionar, no lo he hecho muy bien, tanto en no dar una dirección de bajo nivel suficientemente clara, como en no delegar de forma eficaz y en no obligar a la gente a cumplir sus compromisos. Me siento más cómodo haciendo trabajo técnico práctico, pero encuentro que esto no se escala lo suficiente. Ahora me encuentro guiando diseños, revisando revisiones y brindando muchos consejos y apoyo para los líderes de equipo y, a menudo, para los desarrolladores más jóvenes. Esto se ha prolongado durante aproximadamente 4 años, en general tengo casi 15 años de experiencia, estoy terminando un proyecto y en las primeras etapas de un segundo, y quiero definir más claramente lo que quiero.

¿Existe un nombre para este tipo de rol (¿arquitecto técnico?) y recursos para seguir desarrollándose en él? Alternativamente, ¿es esto simplemente una señal de que debería centrarme en desarrollar mejores habilidades de liderazgo de personas o en un rol más especializado donde podría tener un mayor impacto como colaborador individual?

¿Por qué esto atrae votos negativos? Tenemos tantas respuestas que dicen "preguntar a la gerencia" y "alguien en la gerencia debería saber cómo administrar XYZ" que me resulta difícil creer que está fuera de tema que la gerencia pregunte qué roles deben manejar XYZ en el sentido general.

Respuestas (2)

De hecho, el término en desarrollo de software sería "líder técnico" o "arquitecto", tal vez "arquitecto técnico" si el proyecto tiene más variedad y tiene arquitectos de diferentes sabores. Como los títulos no están regulados, podría ser algo parecido a eso.

Descubrí que no se trata tanto de un rol de habilidades blandas como de gestión. En la gestión necesitas habilidades sociales para venderle a tu gente cosas que realmente no quieren hacer . Como arquitecto técnico es mucho más fácil porque necesitas vender cosas que deberían querer hacer. Sus sugerencias deberían facilitar su trabajo si está haciendo bien su trabajo y eso no es difícil de vender.

Entonces, sí, seguro que ayuda leer algunos libros sobre personas y gestión de proyectos, solo para saber lo que te pierdes. Sólo para saber sobre qué actúan los demás .

Personalmente, me gusta mucho Peopleware , aunque ya es bastante antiguo.

Lo que es más importante es su conocimiento técnico. Tus programadores te respetarán sobre la base de tus conocimientos técnicos. Así que necesitas mantener eso actualizado. Incluso en tecnologías que no usa, porque debe saber por qué no usa esa tecnología en su lugar.

Supongo que no necesito decirte qué hacer en ese sentido. Libros, conferencias, grupos de usuarios, proyectos de pasatiempos.

Un aspecto importante es que cuanto más asume un papel de apoyo en la enseñanza y la planificación, más pierde el contacto con las personas que hacen el trabajo real. De vez en cuando, deja todos tus libros y planes y cancela tus reuniones y ensúciate las botas. Tome un boleto e impleméntelo. Eso es importante porque experimentará los problemas de primera mano y tomará mejores decisiones para sus programadores de esa manera. He visto demasiados arquitectos de torres de marfil que insisten en hacerlo de una manera mientras que el compilador insiste en que está mal. Mantenga su contacto con las raíces y sepa de lo que está hablando en detalle. Si su gente ve que puede hacer lo que ellostiene que hacer, es mucho más fácil convencerlos de que también lo hagan. Si su solución tiene una cobertura de código del 100% y funciona muy bien, es fácil de vender. Si su solución tiene 5 años y no se puede mantener, la gente tendrá dificultades para respetar su orientación. Practique lo que predica.

Así que en resumen:

  • si se siente desafiado a vender sus ideas a los desarrolladores, obtenga ayuda técnica. Cursos, Libros, Conferencias.
  • si se siente desafiado a vender sus ideas a la gerencia, obtenga ayuda con sus habilidades interpersonales. Cursos, Libros, Coaching.

No hay un camino oficial para llegar a ese trabajo o avanzar en él. Tendrás que encontrar el equilibrio entre esos dos.

Si bien las definiciones varían según las empresas, creo que es una exageración llamar al OP "líder técnico" o "arquitecto". Un "líder técnico" sería en general la persona responsable de todos los aspectos técnicos del proyecto. Un arquitecto es responsable de la arquitectura general. Ambos roles implicarían garantizar que los aspectos bajo el dominio de la persona se realicen de acuerdo con los diseños técnicos/arquitectónicos. IOW, son dueños de esos roles y lo que va con ellos. La descripción del OP no parece que tenga ninguna de esas responsabilidades.

Muchas empresas tienen una pista técnica y una pista de gestión , y sus títulos se definen localmente. El arquitecto , el líder técnico y el desarrollador líder se utilizan para el liderazgo a lo largo de la vía técnica.

Normalmente, en el rol técnico, tiene un control cada vez mayor sobre un área técnica y las actividades diarias de los empleados en apoyo de esa tecnología. No tendría "responsabilidades de recursos humanos" o informes directos. Su equipo informa a su jefe o compañeros.

Se puede esperar que usted sea el mentor de su equipo. Se espera que los entrene, ya que el entrenamiento tiene como objetivo un objetivo de trabajo específico y la tutoría está más orientada a la carrera. Obviamente, hay muchas áreas grises, pero el tema común es que sus interacciones se basan en tener un enfoque tecnológico. (Muchas personas pueden usar los términos de coaching y mentoring de manera diferente, pero ayuda a hacer la distinción aquí. :-))

Ya sea que elija pasar a una pista de gestión o más técnica, su próximo paso sería adquirir habilidades de gestión de personas. Entonces, ¿por qué no hacer eso y decidir sobre la marcha?