CTO reacio a ayudarme a mí y a otros desarrolladores

Actualmente trabajo como desarrollador back-end senior en una gran empresa donde hay más de 100 desarrolladores en total. Hay varios proyectos en marcha y la carga de trabajo para los desarrolladores senior puede volverse bastante agitada. Ha habido pocas ocasiones en las que he tenido dificultades para tratar con el CTO. Ha estado involucrado en el mismo proyecto que yo un par de veces. La última vez que le pedí ayuda en un proyecto en particular, ya que estaba más familiarizado con el código base, noté algunas mejoras y necesitaba agregar un par de funciones nuevas, pero quería obtener una idea general de cómo funciona el proyecto en general. Organizó una reunión a la que no asistió, envió correos electrónicos y no obtuvo respuesta. Eventualmente terminé implementando las funciones, pero se rompieron otras partes cuando esa función se sometió a prueba. Esto podría haberse evitado fácilmente si él

Ahora entiendo que ser un CTO es un trabajo duro, pero él tiene mucho que hacer conmigo y otros desarrolladores han notado que sus compromisos a menudo resultan en fallas. Dado que no puede asignar tiempo para corregir estos errores, el trabajo a menudo se pasa a otro desarrollador para que lo haga. Esto desperdicia el tiempo de los desarrolladores, ya que tienen una gran carga de trabajo. Cuando se enfrenta a estos errores, no admite que está equivocado y culpa a la persona que limpia su desorden. Este tipo de incidente ha sucedido varias veces, ¿cuál sería la mejor manera de tratar con el CTO? No quiero perder mi trabajo o renunciar porque realmente amo la compañía y el trabajo que estoy haciendo.

¿Tiene cien desarrolladores y cree que el CTO debería hacer tiempo para corregir errores y preguntas sobre la base del código? Con ese tamaño de empresa, el CTO probablemente no debería celebrar reuniones con nadie que no tenga el título de arquitecto. ¿Por qué no le pides a otras personas que te den su opinión? ¿No tienes una jerarquía y todos solo reportan al CTO? La pregunta de por qué el CTO está enviando el código también es buena, pero probablemente esté fuera de su responsabilidad, a menos que el título que mencione no coincida con su función real.
¿Por qué diablos es un CTO que escribe código cuando tiene más de 100 desarrolladores? Algo no está bien.
Lamento decir que es su trabajo averiguar qué cambios van a romper; no es el trabajo de otra persona decírtelo, especialmente porque eres un desarrollador senior. Sí, sería genial si todas las preguntas que tuvieras pudieran ser respondidas de inmediato, pero la gente está ocupada. Es por eso que hacemos pruebas para empezar.
Ni yo ni los otros estudiantes de último año tenemos idea de por qué sigue codificando activamente cuando ya no lo necesita. De todos modos, casi nunca está disponible porque está en reuniones o simplemente muy ocupado. Tenemos un equipo de desarrolladores muy talentoso y capaz, pero sí, la jerarquía es extraña ya que el CTO es directamente responsable de todos los desarrolladores, aunque tal vez esté asignado a un proyecto y esté en contacto con el PM para ese proyecto en particular, también tendrá que informar a el CTO.

Respuestas (3)

Desafiar al CTO en esto probablemente no terminará bien para usted.

Si pudiera poner a otro gerente de alto nivel a su lado en este tema, podrían sentarse y hablar con él, pero no hay universo en el que se reúna con el Director Técnico , dígale que su código es malo, y mantener su trabajo.

En cuanto a que no se reunirá contigo... no es exactamente un compañero desarrollador del que puedas exigir actualizaciones. Incluso sugerir que te debe una actualización es probable que moleste un poco.

También mencionas que "confrontarlo con sus errores" no termina bien para ustedes. ¿Estás seguro de que esa es la mejor manera de abordar la situación?

¿No sería mejor si uno de ustedes revisara tranquilamente su código y lo arreglara sin todo el alboroto? Al final del día, él tiene la autoridad y el poder para decir que estás equivocado, y no tienes nada más que tu tribuna para apoyarte.

En otras palabras, mejor sufrir en silencio. Siga haciendo su trabajo, y simplemente acepte cualquier error de su parte como una realidad de empleo allí.

Es solo una de esas situaciones en las que la persona que habla no está haciendo amigos.

Podría ser hora de que los desarrolladores maniobren al CTO para que deje de escribir código. "oiga, jefe, déjeme manejar eso por usted". El truco es ayudarlo a superar el obstáculo "No soy técnico si no codifico".
Un punto importante aquí es que la empresa podría perder algo de credibilidad (y por lo tanto dinero/contratos/clientes/etc.) si el CTO rompe los sistemas de producción de forma regular con sus compromisos. Ahora bien, esto no es un argumento en contra de nada de lo que dijo, es solo un factor que puede volverse muy relevante (especialmente después de docenas de oops, I broke the site, sorry).
@RaduMurzea si le está costando mucho a la empresa, uno podría abordarlo de una manera que no señale con el dedo. Por ejemplo, señale el problema general de las confirmaciones que rompen el sistema (no se mencionan los nombres), el daño que está causando y proponga un nuevo modelo de confirmación para los cambios, más pruebas o alguna otra solución.
Ha llegado a un punto en el que no solo me ha pasado a mí, sino que varios desarrolladores se han quejado. Toma un ticket abierto, ya sea una característica o una solución, crea una rama, escribe un código, lo fusiona para desarrollarlo. En un caso, se tuvo que eliminar una característica clave de un sprint ya que el CTO comprometió un código que rompía la funcionalidad existente, lo que resultó en un cliente descontento y la gerencia se desquitó con ese desarrollador senior cuando el CTO era claramente el culpable.
"Revisa tranquilamente su código y arréglalo sin tanto alboroto". Mejor aún, esté atento a las cosas que hacen sus ejecutivos para modificar su trabajo o presentaciones y cuando las anomalías se manifiesten inevitablemente, reúna a todos en silencio para controlar los daños. En mi experiencia, todo lo que puede hacer cuando los ejecutivos meten las manos en el tarro de las galletas es mantenerse dos pasos por delante.

Le sugiero que en este caso deje en paz a su CTO, incluso si eso significa volver atrás para corregir los errores.

El verdadero problema que veo (o podría preguntar) es ¿por qué siente la necesidad de codificar si tiene 100 desarrolladores en plantilla? La respuesta es probablemente algo así como "esto debe solucionarse ahora mismo , y mis desarrolladores están demasiado ocupados para hacerlo".

¿Tal vez podrías ofrecerte para ser su hombre de referencia en las cosas que siente que deben abordarse de inmediato ? Ofrécele que te das cuenta de que está demasiado ocupado para hacer este trabajo y pídele que venga directamente a ti, y atenderás sus necesidades de inmediato.

Idealmente, lo que necesitamos es que alguien, ya sea otro desarrollador o un administrador de proyectos, le diga que ya tenemos procesos implementados para problemas que necesitan priorización y suficientes desarrolladores para hacer el trabajo necesario. Pero la gente tiene miedo a la confrontación. Otros desarrolladores y yo hemos ofrecido varias veces nombrar un líder de desarrollo que se encargue de esto para que pueda estar libre de codificación ya que de todos modos apenas tiene tiempo para ello.

Debe comprender el papel del CTO en su empresa.

En algunas empresas, los CTO son "superdesarrolladores". Se espera que participen y trabajen con los desarrolladores a menudo y, a veces, incluso hagan algo de diseño o codificación.

En otras empresas, los CTO trabajan a un nivel diferente y nunca se involucran con los desarrolladores.

Debe averiguar cómo y si el CTO debe participar en su trabajo.

Hable con su jefe sobre los problemas que tiene y pregúntele cómo puede obtener ayuda si no puede manejarlo usted mismo. No insinúe que esta asistencia debe provenir del CTO.

CTO reacio a ayudarme a mí y a otros desarrolladores
RespuestasAquíPolítica de privacidad1y, 0v