¿Opciones para un programador principal que prefiere programar a líder? [cerrado]

A principios de este año, fui ascendido a un rol de desarrollador principal después de que el desarrollador principal de nuestro equipo se mudó a un departamento diferente. Tengo alrededor de 5 años de experiencia laboral y, debido a la disponibilidad y el rendimiento anterior, fui la principal elección de la gerencia para liderar el proyecto. Estaba un poco aprensivo, pero decidí que era una buena oportunidad para el avance profesional y la experiencia, así que acepté.

Pero mi conclusión hasta ahora es que no lo disfruto tanto como mi posición anterior de desarrollador. Aunque he dirigido con éxito un equipo de 5 desarrolladores a través de varios lanzamientos, casi nunca toco ningún código. En su lugar, realizo la planificación y el diseño y la gestión del equipo, junto con revisiones de código. La necesidad de realizar un seguimiento de muchas cosas más, y tener tareas planificadas para que puedan asignarse al equipo, literalmente me da dolores de cabeza la mayoría de los días. Aunque rara vez trabajo horas extras, me siento agotado casi todos los días cuando salgo del trabajo, y no creo que haya disfrutado tanto el tiempo fuera del trabajo como resultado.

Entonces mi pregunta: ¿cómo manejaría, o cómo manejó, tal situación? Para las personas en situaciones similares, ¿encontraste formas de administrar mejor tu equipo, tareas y tiempo que te hicieron disfrutar del trabajo? ¿O encontraste una manera de regresar a una posición más orientada al desarrollo? Sé que los puestos de desarrollador líder casi siempre pagan un salario más alto, pero puedo verme llegando a un punto en el que me preocupo menos por el dinero y las promociones que por mi disfrute de mi trabajo actual.

No he discutido esto con nadie en la gerencia, ya que pensé que debería tratar de ajustar por lo menos durante un año.

La respuesta que estoy brindando aquí es mi mejor conjetura sobre lo que podría funcionar, pero no lo he visto funcionar ya que estoy tratando de salir de una situación similar en la que te encuentras. Todo esto sigue siendo una experiencia de aprendizaje para mí, pero veo una tendencia positiva en mi equipo.

En mi empresa he sido ascendido a líder de equipo (lo llaman "líder de diseño") y debido a la escasez de personas que conocen el producto y tienen suficiente experiencia, me ofrecí como voluntario para dirigir 2 equipos diferentes. Hace unos meses "para ayudar con el cronograma", la gerencia duplicó el tamaño de estos 2 equipos.

Algo que he estado tratando de hacer ...

1. Deje en claro a todos (incluida la gerencia) que la posición mía y de todos los demás no es una tarea permanente. Todos son bienvenidos a dar un paso al frente, tener una visión más amplia del proyecto y participar en las decisiones de arquitectura / diseño. Tendré la última palabra (por ahora) si hay un desacuerdo sin resolución, pero hasta ahora eso nunca sucedió.
2. Concéntrese en ayudar a otras personas a desarrollarse y crecer. He tenido discusiones (casi filosóficas) con diferentes desarrolladores en diferentes momentos sobre codificación y diseño y diferentes enfoques para hacer las cosas. Algunas de esas discusiones están relacionadas con el trabajo real, otras son ejercicios de pensamiento puro. Tuve un tipo con más de 20 años de experiencia, volví a su estantería y tomé un libro de C ++ porque estaba interesado en algunas cosas de bajo nivel que hice con la meta programación de plantillas. Estas discusiones son algo infecciosas y después de que mencionas estos temas suficientes veces, las personas comienzan a pensar en estas cosas por su cuenta.
3. Delegar todo lo que pueda en otras personas. Aunque miro muchas cosas, no participo en todas las revisiones de código. En cambio, hago revisiones de código para nuestros tipos intermedios y dejo que esos tipos hagan revisiones de código para algunas de las personas más ecológicas. Veo las revisiones de código como más una herramienta de transferencia de conocimiento, en lugar de "asegurémonos de leer cada línea y encontrar cada posible error".
4. Una vez que las interfaces están definidas y el diseño básico está en su lugar, dejo que incluso los chicos más nuevos tengan tanta libertad como sea posible para codificar las partes internas de las clases. Sí, gran parte de ese código está lejos de ser perfecto, pero se prueba y funciona. Si cruza un cierto límite subjetivo en términos de "olor a código" y no lo han refactorizado, sugeriría que ciertas clases deben dividirse o reorganizarse. A veces es doloroso, pero cuando reviso unos días más tarde y obtengo una respuesta, "Odio admitirlo, pero este código se ve mucho mejor ahora", eso en realidad me da una sensación cálida y difusa.
5. Desafía a la gente. En lugar de solo asignarles funciones para que agreguen al producto, pídales que agreguen esas funciones, pero hágalo sin aumentar el número de funciones / miembros de datos en las clases existentes. Si tiene que poner algo nuevo, debe sacar algo existente y tomarse el tiempo para descubrir qué es. Todo el mundo sabe sobre la refactorización, pero sin una fuerza adicional al principio, parece que la gente necesita ayuda para dar ese salto para hacerlo realmente. Como mínimo, me propongo visitar este punto durante casi todas las revisiones de código.
6. Todo se trata de BALANCE. No puede ser la única persona mayor en el equipo que supervisa a los demás. No puede pasar toda su semana en reuniones y haciendo revisiones. No puede esperar que detecte todos los errores que cometa su equipo. Al final del día, debe asignar el tiempo para ser el líder, pero también debe asignar tiempo para ser un desarrollador. Me volvería loco si no pudiera codificar. Incluso con todo lo demás, todavía me aseguro de tener tiempo para escribir código y no solo código, sino algunas cosas realmente ingeniosas. Acabo de tener en mis manos los libros de meta programación y comencé a cavar dentro de Boost. Los chicos que inventaron esas cosas tienen que estar locos (en el buen sentido). Si su administración comienza a molestarlo sobre por qué no todo está siendo revisado o por qué un novato está revisando otro código de noobs, solo necesita explicar todo el asunto del equilibrio y que el equipo simplemente no tiene suficientes personas con experiencia y al final del día "es lo que es". Si su equipo tiene personas mayores, entonces es hora de capacitarlos y darles la libertad de hacer sus propios diseños / revisiones / ayudar a otros y no tratarlos como simples generadores de código. Con el empoderamiento viene la libertad y la gente ama la libertad. Si tienes desarrolladores que no se preocupan por la libertad / empoderamiento, está bien. Cada equipo todavía necesita codificadores puros, solo asegúrate de esforzarte por el equilibrio. s tiempo para empoderarlos y darles la libertad de hacer sus propios diseños / revisiones / ayudar a otros y no tratarlos como simples generadores de código. Con el empoderamiento viene la libertad y la gente ama la libertad. Si tienes desarrolladores que no se preocupan por la libertad / empoderamiento, está bien. Cada equipo todavía necesita codificadores puros, solo asegúrate de esforzarte por el equilibrio. s tiempo para empoderarlos y darles la libertad de hacer sus propios diseños / revisiones / ayudar a otros y no tratarlos como simples generadores de código. Con el empoderamiento viene la libertad y la gente ama la libertad. Si tienes desarrolladores que no se preocupan por la libertad / empoderamiento, está bien. Cada equipo todavía necesita codificadores puros, solo asegúrate de esforzarte por el equilibrio.
7. Tu tiempo es valioso. Por lo tanto, solicite al equipo que le envíe por correo electrónico todas las preguntas críticas que no sean de tiempo y que puedan esperar unas horas antes de obtener una respuesta. Cuando se hace la pregunta, se debe copiar a todo el equipo. Eventualmente, cuando tenga un descanso en su día, puede echar un vistazo al problema y ayudar a la persona, pero muchas veces, alguien más puede haberle dado una respuesta y no tiene que hacer nada. Obviamente, como líder, todavía estoy disponible y lo dejo en claro porque creo que uno de mis objetivos es asegurarme de que nadie en el equipo se quede atascado durante períodos prolongados sin progresar.
8. Asegúrese de que su equipo utilice tantas herramientas como sea posible para que las comunicaciones sean más efectivas. Por ejemplo, tenemos un sitio wiki y cada vez que surge el mismo problema varias veces, le pregunto al último tipo al que ayudé a crear una página wiki.

No he discutido esto con nadie en la gerencia

Creo que sabes que esto probablemente ayudaría. Comunicar su incomodidad con una posición no necesariamente especifica algo en concreto. Le permite a la gerencia saber qué tarjetas tienen, y si es una buena administración, intentarán encontrar una manera de usar su mejor potencial. No te conformes con menos.

Cuando finalice su proyecto, busque una posición más orientada al programador en su empresa o fuera de ella.

Discuta con la gerencia que le gustaría tener menos gerencia y más "manos" técnicas en habilidades.

Parece que estás en una posición de PM frente a un desarrollador principal. Consideraría que un desarrollador principal está codificando más.

Perspectiva de los empleadores :

Si disfrutas del trabajo actual y tienes una buena historia allí, me gustaría mantenerte y encontrar un lugar para ti, así que no me preocuparía demasiado por hablar con ellos.

Un gran desarrollador es algo valioso, pero debe venderles que vale la pena hacer más codificación y tal vez diseñar que el acto de malabarismo.

Bríndeles un camino para respaldarlo estableciendo un plan de sucesión. Básicamente, encuentra a alguien en el equipo actual que está interesado en hacer las cosas que le causan dolor de cabeza, durante los próximos 6 a 9 meses los capacita y les asigna sus tareas de una en una.

Elija algo fácil primero, como actualizaciones de estado semanales:

• Siéntelos a su lado cuando realice una actualización de estado.
• Siéntate junto a ellos mientras hacen la próxima actualización de estado.
• Permítales hacerlo por su cuenta y revíselo antes de que salga para la final.

Luego, dele progresivamente las tareas adicionales hasta que haya entregado la mayor parte de sus responsabilidades adicionales.

La razón por la que estos trabajos menos deseables se pagan más es porque si no los hubiera nadie los haría, no necesariamente porque requieren un mayor nivel de habilidad ... oferta y demanda.

Sin embargo, para que pagues más alto ... Si fuera yo, me gustaría saber que te quedarás, ayudarás a esta persona cuando sea necesario, serás un mentor para los chicos más nuevos, será el diseñador / cerebro clave / experto en el dominio en lugar de líder del proyecto. Básicamente, esta es una posición valiosa, alguien más puede hacer el acto de correr y hacer malabares (obviamente, para obtener más paga).

Creo que si presentaras a tu empleador un plan de 6-9 meses que decía

• Una buena explicación de por qué cree que es mejor en general volver a centrarse en la codificación de las otras responsabilidades.
• En quién sustituirme ... o tienen que encontrar a alguien ... creo que este será un factor decisivo.
• Cada mes durante 6 meses, qué responsabilidades le entregarías a la nueva persona
• Qué responsabilidades mantendría cargadas (como el diseño, tal vez sentado en las revisiones de código, etc.).
• Una idea de la disminución de los salarios que estaría dispuesto a aceptar (en algún lugar entre el original y el actual) aunque permita que lo mencionen.

Si lo reúne como un plan para mí, como empleador, estaría más que feliz de trabajar con usted para que eso suceda.

Buena suerte.

He estado exactamente en tu situación. la respuesta se reduce a la relación que tiene con su gerente. En mi caso fue muy bueno, así que un día lo llevé a un lado y le dije que no estaba disfrutando del trabajo, me sentía demasiado estresado y quería volver a la codificación. Estaba mucho más feliz de escuchar eso que hacerme entrar y renunciar. Así que elaboramos un plan para que otra persona asumiera el cargo de Líder del equipo y yo para volver a la codificación.

2 preguntas que no son obvias en tu publicación:

• ¿Estás en una empresa que gana dinero directamente con el software que escribes (como Google, Microsoft o Fog Creek) o estás en una función subsidiaria (como en un banco o una empresa de alimentos)?

• ¿Es el CEO un tecnólogo o alguien que se levantó a través de roles comerciales?

Si eres una empresa de software con un tecnólogo CEO, no te preocupes. El liderazgo corporativo sabrá quiénes son los desarrolladores valiosos y hará lo que sea necesario para mantenerlos. Si todos los ejecutivos son personas a las que les pusieron el distintivo de "administrar personas" o "administrar presupuestos", preocúpense. Preocúpese doblemente si está en un departamento interno de TI. Si este es el caso, debe aceptar que un buen equilibrio entre la vida laboral y personal es la recompensa por seguir siendo desarrollador.

Un último punto: haz lo que te haga feliz. El consejo de todos los demás sobre opciones de carrera como esta es sobre lo que los haría felices, y esto se trata de usted.