El gerente suena molesto cada vez que le informo de un obstáculo (menor)

Mi gerente parece irritado cuando pide una actualización y le informo de una barrera en la que estoy trabajando. Por ejemplo, estaba trabajando en la implementación de una llamada de subproceso, y cuando lo probé en el programa que se iniciaría, obtuve un error, pero probé con un comando simple del sistema y funcionó. Luego comencé a buscar en línea información sobre el mensaje de error.

Mi gerente entró y solicitó una actualización en el momento de la resolución de problemas. Le expliqué el comando que estaba usando para iniciar el nuevo proceso y le dije que lo hice funcionar con un ejemplo simple, pero recibí un error al iniciar el programa de destino; le mostró el mensaje de error. Le dije que estoy investigando la causa del error. Leyendo entre líneas, no estaba contento e hizo un ruido de burla y dijo: "tú eres el programador, no puedo ayudarte con esto".

Ha sido mi observación si alguna vez hablo de un "retroceso" o muestro algún signo de incertidumbre, él se disgusta. ¿Cómo debo abordar este problema o debo ignorarlo? ¿Debo siempre dejar de lado cualquier obstáculo?

El gerente es un poco técnico pero no sabe programar. Es de Rusia y creció en el ejército y está claro que proviene de una cultura diferente. No digo que crea que así es la cultura rusa, pero noto que con mi gerente piensa muy linealmente, en términos binarios (o se hizo o no, sí o no) y está muy en sintonía con la estructura. de cosas (por ejemplo, a menudo no se refiere a las personas por sus nombres sino por su posición, por ejemplo, el programador, la cuenta, etc.). Esta descripción no pretende ser fanatismo, tengo amigos que son rusos y la diferencia en la comunicación puede no ser causada por la cultura en absoluto.

EDITAR: Estoy un poco sorprendido por todas las sugerencias que dicen no dar detalles técnicos sino concentrarse en cuándo se harán las cosas. Pensé que más personas en este sitio saben que no se puede predecir con precisión cuándo se terminará un programa. Para referencia https://softwareengineering.stackexchange.com/questions/648/how-to-respond-when-you-are-asked-for-an-estimate

Me parece que acaba de descubrir un patrón en el comportamiento de su jefe. Él claramente no está interesado en escuchar sobre pequeños obstáculos como este y espera que los resuelvas por ti mismo, lo que de hecho haces. Solo ajusta tus respuestas futuras a él con eso en mente. ¿O también es así como reacciona cuando surgen problemas realmente serios que requieren una acción de su parte?
es normal que al comenzar a codificar algo se produzca un error. ¿Por qué necesita oír hablar de eso? Simplemente diga "Empecé a implementar bla, bla, espero tenerlo listo para X tiempo". Imagina que contrataste a un nuevo cocinero para tu restaurante y lo revisas. Preferiría escuchar: 1) "Estoy tratando de usar la estufa pero es diferente a lo que estoy acostumbrado. Tal vez haya una forma de encenderla con un fósforo... ¿Hay fósforos en esta cocina? Espero ¡Puedo encontrar uno en la farmacia entonces!" o 2) "Me estoy acostumbrando a usar una nueva cocina y debería estar lista para usar en un día más o menos".
@Chan-HoSuh: en ese caso específico, encender la estufa podría ser algo con lo que el dueño del restaurante pueda ayudar, en cuyo caso "Todavía no he descubierto cómo encender la estufa" no provocaría la reacción "eres la cocinera no te puedo ayudar con eso", provocaría la reacción "tenemos fósforos en el estante de arriba allá", mientras que ir a la farmacia a comprar fósforos provocaría la reacción "por qué no preguntaste alguien donde están los fósforos?" Lo importante es aprender a identificar qué problemas se beneficiarán de los aportes de la administración y cuáles no.
Me tomó un tiempo aprender a simplemente no mencionar nada como esto que tomó menos de un día completo. Después de todo, es una parte principal del trabajo. Muchos gerentes perciben mencionarlo como una solicitud de ayuda en lugar de una actualización de estado sobre lo que realmente está haciendo. "Esto es lo que he completado, esto es en lo que estoy trabajando". funciona mucho mejor y se percibe mucho mejor.
Es probable que la cultura del ejército haya dejado un mayor impacto en la personalidad de su gerente que el hecho de que sea ruso. Yo mismo no he estado en el ejército, pero las personas que conozco (que lo estuvieron) tienden a ser sensatas y cuando encuentran un problema, encuentran la manera de resolverlo con lo que tienen. Probablemente esté acostumbrado a esta actitud de "no hay problema, no puedo manejarlo". Para vincular eso con todas las otras respuestas/comentarios, él no entiende por qué le estás contando todo sobre el problema y supone que quieres que te ayude a resolverlo, lo cual no puede hacer a nivel técnico. hablemos acerca.
Tienes razón en que no puedes predecir con precisión cuándo terminarán las cosas. Sin embargo, deberías poder hacer una conjetura educada. Cuando mi gerente (no demasiado técnico) pregunta cuándo se hará algo, digo algo como "Creo que debería tomar alrededor de 3 o 4 días, pero eso suponiendo que no tenga ningún problema y probablemente correré". en enganches". Me di cuenta de que también es útil ofrecer qué tan pronto puede terminar con el siguiente paso. "Dicho esto, creo que la parte A debería estar lista para probar esta tarde..." Dar algo concreto parece ayudarlo a aceptar la incertidumbre a gran escala.

Respuestas (6)

Los técnicos quedan atrapados en este tipo de cosas todo el tiempo. Deja de incluir detalles en tu explicación. Sé que preguntó qué estaba mal, pero todo lo que escucha es "bla, bla, comando, bla, bla, objetivo, bla, bla, error". O todavía estás trabajando en ello o está completo. No importa por qué a él. Trate de incluir algún marco de tiempo cuando crea que está listo. Algunas personas preguntarán, "¿Cuál es el problema?" pero no te dejes atrapar pensando que quieren detalles. Estás recibiendo un error. Eso es todo.

Además, probablemente podría eliminar el ejemplo técnico detallado de su pregunta para practicar.

Este. Como persona técnica y gerente, cuando pregunto cuánto tiempo llevará algo, no necesito la historia de vida detrás del problema. Solo estoy interesado en cuánto tiempo va a tomar porque necesito determinar si debo decirte que dejes de trabajar en eso, ayudarte, empujar hacia atrás en el negocio, solo dejo que sigas con eso. Algunas cosas son binarias y eso está bien...
Además, cuando alguien solicita una actualización, quiere saber qué has logrado desde la última actualización. No quieren saber lo que no ha logrado durante los últimos 10 minutos, pero esperan lograrlo en los próximos 10. "Descubrir lo que significa este mensaje de error" no es un hito significativo en el progreso del proyecto, por lo que una actualización que consiste en "He llegado a empezar a entender lo que significa este mensaje de error, pero aún no lo he completado" no es una actualización significativa. Dile a tu jefe lo que has hecho.
Totalmente. Odio cuando pregunto el progreso de un artículo y recibo una diatriba técnica similar. Si no está solicitando mi ayuda técnica específicamente, entonces todo lo que quiero saber es "¿ese informe se hará hoy como usted dijo o mañana o qué? ¿Necesita algún recurso o ayuda para desbloquearlo?" No los detalles de su seguimiento de pila actual con los que está obsesionado.
@JeffO: Estabas pensando en la caricatura de Gary Larsson ( Lo que oyen los perros ) cuando escribiste eso, ¿no? ...
@Ben Cuando un gerente me pregunta "¿Cuánto tiempo tardará en resolver {problema x}?", siempre respondo: "Puedo decirle, si puede responderme 2 preguntas: primero, ¿cuánto tiempo le tomará responder mi segunda ¿pregunta?" Todos los gerentes en los últimos 30 años lo entendieron de inmediato. Cuando investigo, no puedo saber cuánto tiempo llevará resolver un problema que nunca antes habíamos visto. No puedo saber cuánto tiempo me llevará aprender lo que no sé. A veces no hay respuesta nunca. La pregunta fundamental está mal. Pregunte "¿Vale la pena continuar con la investigación?" o similar.
@mxyzplk Si los programadores supiéramos cuánto tiempo tomaría todo, estaríamos muy felices de decírtelo. No podemos saber con certeza si se va a hacer algo al final del día, y no estábamos realmente seguros de cuándo dijimos que lo haríamos al principio. Obtienes una "diatriba técnica" en parte porque estamos tratando de sacar un número de nuestro trasero y estamos tratando de darle algún tipo de razonamiento con la esperanza de que tenga alguna base en la realidad. A veces, ese rastro de pila es una montaña de la que ni siquiera podemos medir la altura. Es natural que nos tambaleemos tratando de responder una pregunta literalmente imposible.
@Ben, ¿se te ocurre que explicárselo a alguien le ayuda a ordenar todas las piezas y resolverlo por sí mismo? No tienes que entender o prestar atención a todos los pequeños detalles para que ese tipo de conversación sea útil para resolver el problema. Exigir una actualización de estado binario y una estimación de tiempo para una investigación abierta es una clara señal de mala gestión, afirmar ser técnico para que pueda descartar la realidad de que hay incógnitas desconocidas no lo hace más creíble, solo lo hace más irrazonable. .
¿Por qué supone que estamos hablando de investigaciones abiertas @James? Ha hecho una serie de suposiciones negativas sobre mi estilo de gestión; la mayoría de los cuales están equivocados. ¿Quizás es hora de dar un paso atrás y asumir lo mejor inicialmente en lugar de lo peor?
@Ben No asumí nada, respondí exactamente lo que escribiste en tu comentario "No necesito la historia de vida detrás del problema. Solo me interesa cuánto tiempo tomará", si significaba otra cosa, eso no es lo que escribiste. En cuanto a las investigaciones abiertas, cada tarea nueva comienza como una y puede convertirse en una por los obstáculos que se encuentran en el camino, eso es exactamente lo que describe el OP. El error es no reconocer que se encontrarán problemas que deben investigarse antes de poder evaluar cuánto tiempo llevará superarlos.
re usuario2338816 comentario: a veces desearía poder vincular comentarios específicos y no solo la respuesta completa.
As a technical person and a manager when I ask how long something's going to take I don't need the life story behind the issue. I'm just interested in how long it's going to takePero a menudo es imposible decirte cuánto tiempo llevará. Solucionar el problema actual podría llevar 10 minutos o podría tardar casi 2 días... Si tenemos este tipo de variación para cada tarea, ¡significaría que todo el proyecto podría tardar entre 2 semanas y 10 años! Solo podemos estimar razonablemente grandes porciones de trabajo, no cada tarea individual.
@Ben: I'm just interested in how long it's going to take.Deberíamos tener un gerente trabajando en ese tema de Cáncer . "¿Cuándo se va a curar?"
@jhocking: "a veces desearía poder vincular comentarios específicos y no solo la respuesta completa" Puede: hacer clic con el botón derecho en la hora del comentario y elegir "Copiar enlace al portapapeles". Ejemplo: lugar de trabajo.stackexchange.com/questions/52277/… (era yo haciendo clic derecho en "hace 15 horas" (mientras escribo esto) en ese comentario y copiando el enlace, luego pegándolo aquí). (No supe esto hasta que estuve contribuyendo a Stack Overflow durante> 4 años. Tal vez se agregó en algún momento allí, o tal vez siempre estuvo allí. :-))
Si ha estado haciendo cualquier trabajo durante un tiempo y le resulta completamente imposible proporcionar algún tipo de estimación razonable sobre cuánto tiempo llevará una tarea, no es muy bueno en ese trabajo.
@mxyzplk: exactamente. Por mucho que me gustaría esconderme detrás de la imposibilidad de dar una estimación de tiempo 100% segura para muchas de las cosas que hago, en la práctica puedo dar estimaciones de tiempo con una confianza razonable para la mayoría de ellas. Suplicar lo contrario no ayuda a hacer las cosas, y tampoco lo hace malinterpretar la solicitud de un gerente "¿cuánto tiempo tomará esto?" para decir "dame un tiempo 100% confiable, con una precisión de 10 minutos". Esto último es imposible, pero a excepción de los incompetentes desesperados ocasionales tampoco es lo que significa la pregunta.
Los técnicos quedan atrapados en esto todo el tiempo, probablemente porque no saben nada mejor y nunca se les enseñó lo contrario. Me hubiera encantado haber aprendido esto en una de mis clases de la universidad, en lugar de pasar años en la fuerza laboral antes de descubrir esto por mi cuenta.
@Michael Esto no es solo algo que los técnicos 'no entienden', es una situación sin salida. Cuando omites los detalles, la gente asume que les estás ocultando cosas o que las tareas eran más simples de lo que son. Si destacas que estás simplificando o resumiendo, eso parece condescendiente incluso si no lo entenderían o si sabes que en realidad no quieren saber la explicación completa. El problema es que, particularmente con retrasos o problemas en un proyecto, el problema suele estar en los detalles porque ha planeado evitar los más obvios.

Leyendo entre líneas, no estaba contento e hizo un ruido de burla y dijo: "tú eres el programador, no puedo ayudarte con esto".

Puede que tenga una forma muy directa de decir: "Demasiada información". La próxima vez que haga una pregunta, usted sabe mejor y solo puede dar la información relevante.

Ha sido mi observación si alguna vez hablo de un "retroceso" o muestro algún signo de incertidumbre, él se disgusta. ¿Cómo debo abordar este problema o debo ignorarlo? ¿Debo siempre dejar de lado cualquier obstáculo?

Su gerente tiene que tomar decisiones basadas en la información que obtiene de usted. Es obvio que se pone nervioso si muestras signos de incertidumbre. Si fuera un gerente y recibiera respuestas inciertas o evasivas de un subordinado, tampoco estaría satisfecho. Creo que hay dos soluciones si no estás seguro de algo sin mostrárselo directamente:

  • Dígale lo que necesita haber hecho para estar seguro (por ejemplo, más tiempo para profundizar en un tema).
  • Sea sincero acerca de la incertidumbre. Dígale de cierta manera que y por qué una situación es incierta y cuál es la mejor y la peor estimación posible.

pero noto que con mi manager piensa muy lineal, en términos binarios (o se hizo o no, si o no)

¿Te das cuenta de que, desde un punto de vista contractual, la mayoría de los proyectos son de naturaleza binaria?

Si bien desde su punto de vista técnico hay muchos matices, por supuesto, en términos de un contrato, un proyecto se realiza y se puede facturar o no, en cuyo caso el proyecto puede retrasarse. Al final, a su gerente se le paga para que recopile estos datos y tome las medidas apropiadas en función de esa información.


En mi opinión honesta, toda su pregunta se lee como si se redujera a la cuestión del punto de vista (técnico frente a gestión). Tal vez en el futuro podría intentar cambiar más a menudo a la "visión de la gerencia" de una determinada situación y tratar de comprender las implicaciones de ese punto de vista. Personalmente, creo que esto podría convertirlo en un empleado mucho más valioso a largo plazo.

De acuerdo: OP es malo para administrar.
@Davor Tienes razón, a los gerentes se les paga para manejar esto para que los programadores no tengan que molestarse con eso. Pero no diría que se está "filtrando" en esta situación; preferiría decir que hay un límite de comunicación y si el OP entendiera mejor las implicaciones de ese límite, podría mejorar la comunicación con su gerente y facilitar a sus jefes y su propia vida laboral.
Parece que el gerente de OP también es malo para administrar. El problema de la comunicación existe en ambos lados.
¿Por qué debería ser bueno para "gestionar"? ¿La empresa está contratando numties como gerentes que necesitan ser portátiles? Y si hay un problema de comunicación, entonces el gerente debe informarlo, ese es su trabajo.

Hay muchas ideas en las respuestas y comentarios existentes. Algunas cosas me llamaron la atención al leer lo que escribiste.

  • Su gerente visitó en persona para una actualización. Eso es realmente una buena señal. No se esconde detrás de un correo electrónico o de una puerta cerrada. Quiere interacción cara a cara, aunque sea brevemente.

  • Parece que en realidad se quedó y escuchó mientras le mostrabas los detalles de un problema con el que no podía ayudar. Podría haberte interrumpido y marchado. Podría haberle pedido inmediatamente a otra persona que lo "ayudara" o incluso que se hiciera cargo.

  • La redacción de su respuesta parece grosera, pero la intención es alentadora. Dijo que no podía ayudarte con eso. No dijo que no le importaba, que no importaba, o que no era su problema. Hay muchas cosas genuinamente groseras con las que podría haber respondido. He visto gerentes insultar a los empleados o recurrir a ataques ad hominem en esas situaciones ("¿por qué te contraté?"). En lugar de eso, expresó su frustración por no poder ayudarte y se sintió como si estuvieras pidiendo ayuda. Es una diferencia sutil, pero que importa.

  • Probablemente esté allí para saber si necesita tomar medidas. La única acción que puede tomar es cancelar el trabajo, retrasarlo o asignarlo a otra persona. Lo que quiere de ti es la confianza de que vas a resolverlo de alguna manera, o saber si necesita asignárselo a otra persona porque no puedes hacerlo (demasiado de eso generalmente significa que una persona no está calificada ).

  • Realmente no respondiste su pregunta. Un gerente que solicita una actualización y un empleado que ingresa en detalles técnicos es equivalente a una falta de coincidencia de tipos. Hizo una pregunta booleana y usted le dio una serie de información como respuesta. Eso en realidad hace que parezca que no lo estás escuchando, lo cual puede ser frustrante.

  • Si no puede estimar en ese momento, tómese un tiempo, pero sea específico. Si son las 9 a. m., pregúntele si puede actualizarlo al mediodía, después del almuerzo o al cierre de la jornada laboral. Dale algo concreto que pueda planificar. Una respuesta dudosa le impide comunicar la información a cualquier otra persona que dependa de ella (incluido su jefe). Cuando llegue el momento señalado, dé una estimación real.

  • Obtenga ayuda de un compañero de trabajo que tenga una buena relación con su jefe. Por lo general, hay alguien con quien se llevan bien en el lugar de trabajo. Averigüe de ellos lo que hace que su comunicación con él sea exitosa.

  • Se humilde. En su próximo uno a uno, admita a su jefe que no siente que se está comunicando con éxito con él y pregúntele qué quiere saber de usted. Probablemente será una respuesta corta y simple. Escúchalo y luego haz un esfuerzo para hacerlo. Si él cree que usted quiere ayudarlo a alcanzar sus metas, es más probable que trabaje con usted (incluso si se siente frustrado).

La respuesta de los gerentes fue bastante estúpida. "Tú eres el programador, no puedo ayudarte". Por supuesto que no puedes. Si pudieras ayudarme con un problema de software, entonces no valdría mi salario. Por otro lado, si hay un problema comercial, es tu problema.

Es muy difícil proporcionar una actualización coherente cuando estás en medio de la resolución de problemas o el diseño de una solución a un problema.

Considere retrasar su respuesta hasta que tenga una idea clara del problema y uno o más planes para mitigarlo o resolverlo.

Si su gerente exige una actualización instantánea e inmediata, simplemente diga que no tiene suficiente información en este momento y que no quiere hacerle perder el tiempo con información incompleta.

Luego, tan pronto como sea razonablemente posible, redacte un correo electrónico de actualización breve y conciso que pueda seguir con una discusión en persona.

En mi experiencia, los gerentes que exigen con frecuencia actualizaciones de estado/línea de tiempo generalmente necesitan pasárselas a otra persona, y decirles "No puedo decirlo" solo generará más demandas de su mejor estimación. Tienes que decir algo para sacártelos de encima y, dado que lo que digas nunca será exacto en este punto, aprende a darles una estimación que funcione a tu favor .
@Air Lo que, por supuesto, conduce a estimaciones infladas y, finalmente, no cumple con los plazos de todos modos. Pero el punto clave es que esa es la decisión de los gerentes: si quiere un desarrollo ágil, tendrá que ser lo suficientemente flexible para adaptarse a que lo que debería haber tomado una hora tome diez horas (ya sea dándote el tiempo, o cambiando las especificaciones), y debe dar sus mejores estimaciones. Si quiere un número concreto, dale tu 90 %, incluso si eso significa decir diez horas por algo que probablemente solo te lleve una hora.
@Air estuvo de acuerdo, pero a veces solo se necesitan unos minutos para despejar la cabeza y dar una respuesta coherente. Si puede decir algo como "Estaré en su oficina en 15 minutos con una actualización", eso al menos gana algo de tiempo. Si el gerente constantemente quiere actualizaciones AHORA MISMO, bueno, ese es un problema que se resuelve mejor con un cambio de escenario.
Sí, en esta situación, donde realmente no sé ahorita si este problema se va a arreglar, o cuándo, digo, te daré una respuesta a eso el martes a las 12 am. Así que tengo una fecha límite para mí, si no puedo resolverlo antes del martes a las 11 a. m., no lo voy a terminar y necesito mucha más ayuda, o un contratista especialista o lo que sea.

Cuando le informas a tu jefe de un obstáculo, ¿también vienes con una solución? Me doy cuenta de que el tiempo no siempre permite esto (como en su ejemplo cuando él se acercó como lo identificó). Los gerentes (deberían) querer que los miembros de su equipo sean solucionadores de problemas, no reporteros de problemas.

A menos que la solución sea realmente algo que usted necesita que el jefe haga personalmente, ¿qué espera que haga su jefe con la información? No necesariamente tiene que saber que su solución funcionará, pero debe tener algún plan. "Hola jefe, acabo de encontrarme con este problema, y ​​esto es lo que voy a intentar hacer para resolverlo". Si tienen una idea mejor, pueden darle algunas ideas o comentarios.

Si no viene con ningún plan propuesto, parece que solo les está pidiendo que resuelvan su problema. Creo que esta es probablemente la razón por la que dijo "tú eres el programador, no puedo ayudarte con esto". Mencionaste que él es algo técnico, pero no un programador. ¿Qué cree que puede hacer con su informe de problema y sin idea de una solución?

"¿Qué crees que él (s) puede hacer con el informe de su problema y no tiene idea de una solución?" No espero que haga nada, pero él parece pensar que lo hago. ¿Hay alguna manera de que pueda expresarlo de otra manera? Vino a mí preguntándome qué estaba haciendo, no fui a decirle sobre el problema.
Entiendo que esta vez llegó en medio del problema, pero el título de su pregunta dice "siempre". Si esto sucedió solo, olvídalo. Si sucedió más a menudo (como sugiere la pregunta), entonces parte del tiempo vas a él. En esos casos, tenga un plan. Es posible que no esperes que haga nada, pero si acudes a él sin un plan, es probable que así lo vea. Si tienes un plan sabe que no le estás pidiendo que haga nada
A tu jefe, "¿qué estás haciendo?" no es "Estoy solucionando una implementación incorrecta del patrón Observer", sino "He solucionado todos los problemas prioritarios y he superado 10 de 30 problemas no prioritarios, el proyecto debería estar listo el próximo lunes".

Diferentes estilos para diferentes personas.

Su gerente ya ha indicado lo que quería de usted. No quiere los detalles porque no era lo suyo.

¿Qué hay para mi ahí dentro? es una pregunta que debe responder cada vez que hable con alguien, ya sea un gerente o su subordinado. Sus antecedentes pueden tener algo que ver con su respuesta, pero primero debe responder la pregunta en función de lo que necesita saber.

Toma a los seres humanos como seres humanos. Suspenda su juicio sobre su raza o creencias y podrá ver las cosas claramente desde donde se encuentran.