¿Cómo le digo a mi jefe que hice con éxito algo que me pidió que no me molestara en intentarlo?

Estoy trabajando en un proyecto de programación en el que soy el único desarrollador, pero también trabajo en estrecha colaboración con mi jefe para diseñarlo. Hay un paso determinado en el proyecto que es un cuello de botella bastante grande, y tenía una idea de cómo eliminar el paso por completo (lo que sería una mejora significativa). La respuesta de mi jefe fue algo así como:

Lo hemos intentado varias veces en el pasado, pero no creo que el software que estamos usando nos permita hacer eso, así que no me molestaría.

Bueno, todavía tenía confianza, así que seguí adelante y lo intenté de todos modos (este es un proyecto de 3 semanas, así que solo me di 2 o más horas para intentarlo antes de darme por vencido), y logré eliminarlo con éxito. el paso.

Sin embargo, ahora estoy en un lugar extraño, donde mis opciones son dejar el paso de todos modos (lo que obviamente es un mal movimiento) o decirle a mi jefe:

Oye, sé que dijiste que no me molestara en tratar de cortar ese paso, pero lo intenté de todos modos. Aunque buenas noticias...

Esta será una pieza de código de producción bastante utilizada, por lo que eliminar los cuellos de botella sin duda será una buena noticia, pero tendría el costo de decirle a mi jefe que básicamente lo ignoré. Sé que a veces está bien que los desarrolladores rechacen las ideas, pero me imagino que, por lo general, primero tienen la conversación y luego escriben el código; no de la otra manera.

¿Hay alguna manera discreta de decirle a mi jefe sobre esto?

NOTA: Estoy seguro de que muchos de ustedes se están rompiendo los nudillos para comenzar a escribir "Es posible que no quisiera que se cortara ese paso por razones que no les dijo", y en el caso general estaría completamente de acuerdo. Sin embargo, en este caso particular, sé que eso no es cierto. Sin embargo, explicar por qué requeriría que escriba una gran cantidad de información específica de programación, y luego esta pregunta ya no sería relevante para el lugar de trabajo en general. Por lo tanto, avance bajo el supuesto de que mi jefe ha sido completamente transparente con sus razones y que entiendo las implicaciones de eliminar ese paso.

Actualización: terminé optando por la respuesta de GrayCyngus, pero también aprecio mucho el consejo de CodeSeeker de no abordar que, para empezar, podría haber pensado que no debería haber trabajado en ese paso. Es cierto que "No me molestaría" es un poco ambiguo, y sería bastante estúpido forzarlo a que se vea controvertido. Simplemente expliqué abiertamente lo que hice; mi jefe estaba complacido, pero también ofreció algunas mejoras para asegurarse de que el paso se eliminó de manera segura. En general, ¡las cosas salieron muy bien!

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
Todos hemos estado allí. A veces, lo que tu 'jefe' quiere decir es 'No podría hacer esto y no quiero que me muestres haciéndolo tú mismo'. Lo que a su vez a veces significa '¿conoces al CEO personalmente? Porque yo sí y tú no'.
Con esto has aprendido que nunca es mala idea demostrar tus competencias a tu jefe: en los malos tiempos las empresas tienden a quedarse con empleados que han demostrado ser muy capaces :-)
He tenido desarrolladores que hacen esas cosas exactamente en la misma situación. Darle una oportunidad no me molesta, incluso si se pierde algo de tiempo (a menos que estemos bajo una presión de tiempo muy seria). Si ese "intento" toma días o peor, o continúa cuando es obvio que no funcionará, entonces me molesta. Ha establecido una restricción de tiempo razonable y ha seguido adelante. Yo consideraría esa iniciativa. Además, conociendo a los desarrolladores, si realmente no quisiera que lo intentaran, como su jefe, habría sido muy explícito al respecto y habría dicho "NO intenten esto" en lugar de "No me molestaría".

Respuestas (14)

¿Hay alguna manera discreta de decirle a mi jefe sobre esto?

Creo que no habría ningún problema en que seas honesto y solo le digas que hiciste esto. Si realmente sientes que podría afectarte, puedes mencionar que fue algo que lograste hacer durante tu tiempo de descanso (aunque decir esto podría ser un movimiento deshonesto, por lo que no es muy recomendable).

Parece que tu jefe dijo "No me molestaría". Esto, sin embargo, no es lo mismo que "No lo hagas". Al decirte que no te molestes, probablemente te esté aconsejando que no te rompas la cabeza y pierdas el tiempo tratando de resolver eso, ya que los intentos de hacerlo se han llevado a cabo en el pasado sin éxito.

Actualmente estoy en una situación similar a la tuya. Soy el único desarrollador de una startup y código junto con la guía de mi jefe. En algunas ocasiones (como mi jefe no es Desarrollador), también me ha aconsejado que no pierda el tiempo haciendo ciertas posibles mejoras, pero en algunos de esos casos resultó que pude hacer lo que se creía imposible, aportando grandes beneficios para la empresa y los proyectos.

Está bien rechazar a veces esas sugerencias. Solo tenga cuidado de no hacerlo retroceder cuando su jefe realmente le está diciendo que no haga algo. Si ese es el caso, te sugiero que cortésmente tengas una conversación con él, donde puedas exponer tus ideas y planes para lograr lo impensable. Sin embargo, si insiste en no hacerlo, sería prudente no desobedecer tal orden, ya que en ese caso puedes pasar de Hero a Zero.

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .

Saldría y admitiría que trabajé en eso de todos modos. Pero lo haría como una introducción a una conversación sobre saber más sobre el programa.

Oiga, jefe, sé que me dijo que no me molestara en trabajar en este cuello de botella, pero bueno, tenía curiosidad porque pensé que el software nos permitiría sortearlo. Me puse un límite de 2 horas, así que no estaba gastando mucho tiempo en algo que dijiste que no me molestara. Y creo que encontré una solución. Quizás es algo que se ha intentado antes, y si es así, mostrarme por qué no funciona me ayudará a comprender el programa en general. Si funciona, entonces eso es aún mejor. Sé que estaba ignorando tu consejo y, especialmente si perdí una hora y media, lo siento.

Tomar la iniciativa y resolver problemas no siempre es algo malo, siempre que

  • Admítelo de inmediato.
  • No pierdas mucho tiempo cuando tengas otro trabajo que hacer.
  • No actúe en consecuencia sin hacérselo saber al jefe de inmediato.
  • (en este caso) reconozca que estaba ignorando su consejo y discúlpese.
+1 Eh, cuando lo dices de esa manera, ser honesto suena como un enfoque totalmente razonable.
Es bastante normal que los programadores y otras personas técnicas sigan pensando en un problema/idea interesante al menos en el trasfondo mental (mientras conducen, o mientras intentan conciliar el sueño o lo que sea). Si / cuando tenga una idea que podría funcionar, definitivamente querrá pasar un tiempo intentándolo. Espero que la mayoría de los jefes entiendan eso y estaría bien siempre y cuando no se pierda una fecha límite trabajando en esta idea que podría no dar resultado.
Además, al menos en los niveles más altos, esta cualidad es una que he descubierto que a los gerentes realmente les gusta . (O al menos todos los míos lo han hecho). Una vez que te gradúas por encima de "junior", un grado de autonomía y pensamiento independiente viene con la experiencia en la empresa, y siempre que hayas demostrado tu valía, esto generalmente se considera algo bueno. Sin embargo, puede salir muy mal si haces malas llamadas.
A menos que estemos hablando de un lugar draconiano donde literalmente cada minuto es rastreado y facturado, es perfectamente normal y una buena práctica experimentar con ideas prometedoras dentro de los límites del propio cubo. "Pedir permiso" incluso antes de comenzar pone un freno a probar cosas especulativas que tienen una alta probabilidad de fallar. No todo tiene que ser "gestionado por proyectos".
Omitiría la última oración: no hay nada de qué arrepentirse. Usted reserva un pequeño período de tiempo para que I+D resuelva o comprenda mejor un problema; eso es más o menos lo que todos los desarrolladores siempre hacen para estar mejor preparados para el futuro. No perdiste el tiempo.
No encontré esta respuesta útil, especialmente no tan útil como la de CodeSeeker. El único mensaje de esta respuesta es "La iniciativa es buena". No hay ninguna explicación sobre cómo explicarle a su jefe que la iniciativa es buena, y el único enfoque sugerido, "admitir una falta y disculparse", es malo .

Ni siquiera mencionaría su percepción de que le dijeron que no lo hiciera (un hecho que es discutible según su informe de lo que realmente dijo). No me disculparía a menos que me presionaran mucho (aunque si lo hiciera sinceramente por haber hecho algo dañino que no era tu intención), y definitivamente no diría que lo hice en mi tiempo libre, como si fueras un asalariado. entonces toda la energía que gastas en el trabajo pertenece a tu empresa, y si te pagan por hora, entonces era ilegal no informar las horas.

Yo lo jugaría así:

"Tenía curiosidad acerca de cómo dijo que no era posible eliminar el cuello de botella en este software. Dado que es un gran problema para nuestro negocio tener este cuello de botella, investigué un poco y parecía que podría haber una manera, y decidí para pasar un poco de tiempo comprobando si podría funcionar. Pasé solo 2 horas en esto ayer, y creo que logré eliminarlo. ¿Qué piensas? ¿Es esta una estrategia viable?"

Centrarse en quién le dijo a quién qué o que sabías que ibas en su contra no es el camino hacia el éxito. Concéntrese, en cambio, en el valor comercial proporcionado: gran cuello de botella problemático eliminado, solo 2 horas invertidas, apertura a la opinión del jefe sobre el resultado y seguir adelante.

Tu jefe es un asesor. Es una mala práctica de gestión dar este tipo de órdenes de todos modos. Te contrataron por tus conocimientos de programación y los utilizaste. Eres un empleado valioso debido a tu mente aguda . No dejes que los jefes de pelo puntiagudo se interpongan en tu camino para usarlo lo mejor que puedas.

Si su jefe le da mucha importancia a esto, entonces sabe que está en la compañía equivocada o, sin duda, bajo el jefe equivocado, y en ese caso, pronosticaría con confianza que este tipo de cosas surgirán una y otra vez con él. , y será un problema a largo plazo. Averigüe AHORA en qué tipo de empresa trabaja y decida si puede vivir con ella. También es la mejor estrategia para ayudar a su jefe a descubrir AHORA qué tipo de empleado es usted y decidir si puede vivir con eso. Si no muestra iniciativa ahora y hace todo lo que su jefe le ordena hacer, incluso cuando es estúpido obedecer, o incluso cuando es barato obtener más información, entonces su jefe esperará este tipo de cumplimiento de su parte en el futuro y estarás encerrado para siempre.

No estoy sugiriendo que te vuelvas loco y seas un vaquero del salvaje oeste, ignorando a tu jefe. Pero aquí tienes la oportunidad de crear un tipo diferente de relación en la que solo te ordena que hagas cosas de alto nivel que son realmente valiosas para la empresa y, de lo contrario, funciona como asesor y facilitador, dejando el resto de las piezas importantes. (incluyendo cómo pasa su tiempo y sus opciones de implementación) depende de usted. Si cumple con los plazos y las necesidades objetivas de la empresa, debería tener la libertad de trabajar como le plazca.

En cuanto al engaño

El engaño es un intento de hacer que alguien crea una falsedad. Tu jefe sabe lo que te dijo. Creo que es poco probable que el uso de mi enfoque sugerido resulte en que crea falsedades sobre la situación. De hecho, no sabes lo fuerte que se siente acerca de obedecer sus sugerencias como órdenes, y así es como lo descubres. Si no tiene ningún problema con lo que hiciste, lo sabrás, y si tiene un problema, también lo sabrás. Si él pasa por alto su orden aparente para ti porque tuviste éxito, esta es información valiosa.

Es más fácil obtener el perdón que el permiso. Al no pedir permiso demostraste que no necesitas que te diga qué hacer todo el tiempo. Consultar constantemente con tu jefe para pedir permiso es un metamensaje muy claro de que no confías en ti mismo para tomar tus propias decisiones. Él no te ordenó que no lo hicieras.

Si tu jefe se lo toma como algo personal

Diría algo como esto, con mucha calma y racionalidad, mirándolo directamente a los ojos (pero no de una manera desafiante), mientras proyectaba una actitud de cumplimiento de sus deseos, pero actuando como si él simplemente estuviera de acuerdo contigo, moldeando así la situación de una manera favorable a su resultado deseado:

"Joe, realmente no quise decir nada personal al seguir con esto. Vi tu consejo como si estuvieras haciendo tu trabajo: tratar de lograr la máxima utilidad para la empresa ayudándome a no perder el tiempo. Hice lo que pensé que era mi trabajo tomando una decisión calculada". riesgo y pasar una cantidad de tiempo deliberadamente corta investigándolo, y eso valió la pena. ¿Debo entender que en el futuro no quieres que tome este tipo de riesgos calculados cuando veo valor para la empresa en perseguirlos sabiamente?

Además, podría aprovechar la oportunidad para discutir el tipo de relación que usted y su jefe planean tener en el futuro:

Me gustaría que me dejara a mí lograr ese éxito. Si fracaso, entonces siempre podemos hablar de que te involucras más en la dirección de mis pasos, pero si tengo éxito (como lo hice aquí), parece que esta sería la mejor manera de obtener el máximo valor de mi trabajo".

"¿Es esta una forma de trabajar juntos con la que pueden sentirse cómodos en el futuro? ¿Podríamos probarlo durante un mes más o menos y luego volver a consultar para ver cómo cree que va? Siempre estoy abierto a sugerencias para mejorar mi actuación y el producto final de mi trabajo".

Podría seguir con esto discutiendo con él el video de Dan Pink sobre motivación: dominio, autonomía y propósito . Hable de esas cosas, luego envíele el enlace. Explíquele que tener autonomía y poder practicar su dominio son cruciales para su motivación en la empresa, y que le gustaría que él le concediera esas cosas para que pueda ser el mejor empleado posible.

Puede pedirle que vea Greatness del capitán de barco David Marquet o una versión más larga (también hay otras versiones, mire los videos relacionados). Incluso puede hacer que vea Los grandes líderes sirven a los demás .

No es suficiente sentarse y dejar que su jefe lo maneje a su antojo, como quiera. Para tener éxito, también tienes que manejarlo. Ayúdelo a aprender cómo proporcionar lo que necesita para que sea más fácil hacer un trabajo de primer nivel.

+1 (¿puedo +100 esto?). Cuando dices "oye, investigué y creo que encontré una manera" no significa "eres un estúpido y lo hice cuando pensabas que no podía" y al mencionar cuánto aclara el cuello de botella en una parte del código de uso intensivo significa más dinero para la empresa, lo que hace feliz a todos. : Mi jefe ahora valora mi aporte porque he mostrado iniciativa y cómo poner el negocio primero.
@IDrinkandIKnowThings He actualizado mi respuesta.
Sí, lo hiciste... y lo sacaste de los aros de gol de campo.
Aquí hay una trampa escondida. Si "Lo hemos intentado varias veces en el pasado..." ha llevado a descartar este curso de acción debido a los efectos secundarios conocidos por quienes lo intentaron en el pasado pero desconocidos para el OP (por ejemplo, dependencias mal documentadas de terceros cosas de fiesta aguas abajo), entonces pareces una herramienta para volverte vaquero. Si bien esta situación resultó bien, la próxima vez preguntar por qué y cómo fallaron los intentos anteriores es una práctica mucho mejor al hacer sus riesgos calculados.
@Myles Es por eso que aconsejé adoptar el enfoque de “Pasé solo 2 horas; ¿qué opinas?" Esta actitud de dejar la última palabra al jefe a pesar de haber tomado sus propias decisiones es clave, y es precisamente lo que la hace no personal. Sí, tener más información es mejor, pero tener un sesgo por la acción es un rasgo deseable. No tengamos tanto miedo a los errores que no podamos tomar riesgos calculados a pesar de carecer de información perfecta. El jefe debe saber mejor que dar órdenes en lugar de proporcionar información crucial como la que imaginas.
@Myles ¿El jefe quiere ser un cerebro dirigiendo toda su organización, o quiere que 100 cerebros la dirijan? Un buen jefe consideraría valioso incluso cometer errores absolutos debido a la experiencia y el aprendizaje que se produce en sus empleados inteligentes, dedicados y ambiciosos. Mire el video del capitán del barco que publiqué para obtener más información sobre esto.
Realmente me gusta esto, porque si hay un problema con la persona que lo hace en contra del consejo de los jefes, generalmente se trata de ego, percepción y apariencia. Al minimizar o pretender que nunca hubo una conversación en la que el consejo fuera no hacerlo (a diferencia de los obstáculos), elimina ese factor del ego. De hecho, esto hace que parezca que la conversación desempeñó un papel en la orientación de la solución. Una respuesta muy bien elaborada.
Buena referencia de dilbert tiene un voto a favor :)
@CodeSeeker Ninguno de los videos tiene el capitán del barco en su descripción o en el título del video. Su solicitud no está clara y no estoy interesado en ver a un grupo de oradores motivadores para seguir su línea de razonamiento de por qué proceder sin siquiera mirar los errores del pasado sería ventajoso. Como otra cara de la moneda de "No tengamos tanto miedo a los errores que no podamos tomar riesgos calculados a pesar de carecer de información perfecta". "No tengamos tanto miedo a la inacción que no podamos tomarnos un momento para detenernos y hacer algunas preguntas". La mejor de las suertes en tu carrera.
@Myles Pasó 2 horas. Eso es un riesgo bastante bajo, ¿verdad? Además, pareces bastante ofendido. Eso es lamentable. No estoy seguro de por qué, porque de hecho estuve de acuerdo contigo en que más información es mejor que muy poca. Pero una cosa que no sabes sobre mí es que he sido durante mucho tiempo una persona que quiere información exhaustivamente completa antes de actuar, como sugieres que es lo mejor. Así que créeme, lo entiendo. Pero a medida que aprendo y crezco, he ido descubriendo que necesito un mayor sesgo para la acción. Tal vez tú también aprendas eso algún día. Arreglaré el título del enlace para agregar el capitán del barco.
@Myles Una cosa adicional en la que pensé fue la reversibilidad de las acciones o decisiones. Cuando una decisión o una acción es de bajo costo (ya sea porque es fácilmente reversible o porque no cuesta mucho explorarla), es valioso actuar aunque falte toda la información. Cuando una decisión o acción es de alto costo, o difícil/costosa/toma tiempo de revertir, entonces es mejor tener más información y es mejor ser más deliberado. En este caso, lo que estaba señalando es que 2 horas es muy poco, considerando todas las cosas. Y presumiblemente, el OP tiene control de fuente y puede revertirse fácilmente.
@CodeSeeker I mi opinión sobre esto puede estar determinada por la industria en la que estoy. En el procesamiento petroquímico, las personas que hacen "conjeturas informadas" sin hacer un esfuerzo total para educarse pueden llevarlos a un verdadero problema. Hace un par de años, un técnico que no estaba seguro de cómo hacer un trabajo hizo su mejor suposición en lugar de volver a la oficina para verificar los procedimientos. El sistema de control perdió contacto con una válvula de control crítica y detuvo toda la planta. En ese momento, nuestra planta ganaba 1 millón de dólares al día y nos costaba medio día de producción. Proceder en contra de las instrucciones es una mala práctica.
@Myles, nunca recomendaría ir en contra de los procedimientos establecidos ni entrometerme con el equipo que uno no comprende completamente. ¡Soy más consciente que casi nadie! Sin embargo, en el caso del OP, está trabajando con software. Los cambios son baratos y fáciles de deshacer. El cambio que hizo se puede revisar y probar antes de pasar a producción. Repito que el riesgo de lo que hizo es muy bajo: perder 2 horas de trabajo de una persona. El trabajo de cuello blanco se rige por reglas diferentes a las del trabajo de cuello azul. Ser asalariado es un gran indicio de que uno es contratado para lograr un resultado, no para seguir un procedimiento.
@Myles (Aunque se deben seguir los procedimientos que existen hasta que se logre la comprensión y luego los cambios se realicen solo juiciosamente).

La forma más discreta es presentar esto como algo en su tiempo libre y que no afectó en absoluto su trabajo de producción asignado. Preséntelo de una manera en que lo hizo para tratar de 1) mejorar la empresa y el equipo en general y 2) mejorar el producto/su propia experiencia.

Probablemente en la línea de

Hola jefe, durante mi tiempo libre probé este código que pensé que sería muy útil para nosotros como organización. Quería ver si podía hacerlo yo mismo. Me tomó más de 1,5 horas y no interfirió en mi trabajo en absoluto. Aquí están los resultados y creo que puede ser un valor para nuestro equipo para propósitos de XYZ. ¿Pensamientos?

De esta manera, puede presentarse como 1) no sobrepasar sus límites 2) no menospreciar sus esfuerzos en el pasado 3) tiene una excelente habilidad que puede compartir con su equipo.

La forma en que presentas esto es tan importante como el trabajo que hiciste.

Esto solo funciona si realmente lo hiciste en tu tiempo libre . No mientas si pasaste tiempo de la empresa en esto.
Como mencionó OP, "Bueno, todavía tenía confianza, así que seguí adelante y lo intenté de todos modos (este es un proyecto de 3 semanas, así que solo me di 2 o más horas para probarlo antes de rendirme)" -- esto es tiempo libre. Si tiene 2 horas para trabajar además de su proyecto principal / crucial, tiene tiempo libre.
Nada en la pregunta sugiere que lo estaba haciendo en 2 horas que tenía para el trabajo que no sea su proyecto principal. Parece bastante claro que estaba haciendo esto como un proyecto de trabajo.
+1, pero si haces esto, deberías trabajar suficientes horas esa semana para asegurarte de que realmente era tu "tiempo libre".
@Erik: tiene razón, nada en su publicación sugiere que tenía otros proyectos en los que trabajar, pero es una suposición segura. La suposición de que no tiene otros proyectos asignados y tropezó con este problema de 'cuello de botella' y decidió trabajar en él (durante 2 horas y tuvo éxito) es plausible pero muy poco probable. Si eso es realmente cierto, entonces OP puede presentarlo como "Mi agenda es bastante abierta y aproveché esta oportunidad para intentar abordar este problema de 'cuello de botella'. Estos son mis resultados".
@DavidK No, es tiempo libre si no lo necesita para otros proyectos, es decir, pudo dedicar tiempo.

Creo que ser honesto está bien. Yo iría a lo largo de las líneas de:

"Estaba bastante seguro de que el software lo permitía por razones X, Y, Z, así que, entre otras tareas, lo investigué y {haciendo magia} pude hacer que funcionara. También creo que podré aprovechar un plan para {otra situación aplicable}".

Lo más importante aquí es que no invirtió mucho tiempo en ello y que lo informa más temprano que tarde, ya que esto puede afectar otras partes del diseño (la eliminación de cuellos de botella aquí puede significar que no necesita otros cuellos de botella para cumplir con las especificaciones).

Usar la inspiración como excusa puede ser útil.

Si bien estoy de acuerdo con otras respuestas en el sentido de que un jefe cuerdo solo estaría preocupado de que usted no cumpla con los plazos establecidos, algunos otros jefes pueden tener problemas con usted para desobedecerlo y, además de eso, tener éxito.

Entonces, tal vez podría decirlo como "Tuve una idea loca que creo que no era lo suficientemente prometedora como para informarle, pero quería intentarlo de todos modos; y con este enfoque fue más fácil de lo que esperaba. ¡Qué suerte tuve! " si cree que su jefe podría estar más enojado porque desobedeció que más feliz porque el problema se resolvió.

Esta respuesta puede funcionar para usted. Pero, ¿por qué el OP debería pensar que funcionaría para ellos? Creo que la respuesta a esa pregunta falta en la respuesta.
@IDrinkandIKnowThings No entiendo lo que quieres decir; Señalé que esta respuesta es una respuesta protectora en el caso de que su jefe piense que desobedecerlo es peor que hacer el trabajo. Tenía la intención de que el OP (o todos los que vean esto) usen su juicio sobre el carácter de su jefe, ya que no sabemos nada; No sé si esperas que te diga cómo detectar a esos jefes.
Entonces creo que dejar más claro que esta respuesta solo aborda eso sería bueno. Leí la respuesta de que está defendiendo esta respuesta en todos los casos.

Muéstralo y pregúntales

Estuve en esa situación hace años. El proyecto que estábamos haciendo requería una visualización de estructura alámbrica de un dibujo CAD, junto con una representación del usuario colocado en el dibujo capturado desde un dispositivo de seguimiento de la cabeza. El gerente del equipo y el líder general del proyecto dijeron: "Aquí, use esta diapositiva transparente con el marco de alambre impreso en ella... péguela en la pantalla de la computadora y simplemente dibuje al usuario en la pantalla".

Estaba horrorizado. Esto era tan de baja tecnología y poco elegante que me resistí a la idea. Para agravar este sentimiento, el objetivo general del proyecto era, específicamente, crear una solución técnica de vanguardia para el problema general. Que una parte de esta solución, la parte tangiblemente visible, sea tan fantásticamente fea, y pedirme que afecte esa parte, bueno, simplemente hirió al ingeniero en ciernes que hay en mí.

Pero insistieron, así que lo intenté. Para mi alegría descubrí que la solución que proponían no podía funcionar . Así que me arremangué, realicé la ingeniería inversa de los archivos CAD y elaboré en casa un renderizador de estructura de alambre 3D en C++ durante la noche.

Llegó la mañana, simplemente les mostré y pregunté: "¿Es esto lo suficientemente bueno? ¿Cumple con nuestros requisitos?".

Levantaron las cejas y dijeron "Oh... bueno... ¡sí, sí! ¡Eso es bueno!".

Hacer lo mismo. Simplemente muéstrele al jefe cómo funciona su solución y luego pregúntele "¿Qué piensa usted? ¿Es esto algo que podamos usar?".

Sí, tienes que ser honesto. No tiene sentido hacer el trabajo y luego no usarlo; eso sería realmente un desperdicio de los recursos de la empresa. Concéntrese en los beneficios como la razón por la que pasó un poco del tiempo de la empresa.

"Sé que dijiste que no me molestara, pero parecía que realmente lo querías si era posible, y sé que me ahorraría mucho tiempo en el futuro manteniendo el código, así que hice un pase rápido en el enfoque X y parece estar funcionando bien. ¿Puedes echar un vistazo y ver lo que piensas?"

Pedirle a su gerente que lo revise y lo apruebe o lo desapruebe en este punto es un reconocimiento de su autoridad y deja en claro que no lo estaba ignorando. Además, si hay otras consecuencias o inconvenientes de los que no está al tanto, tendrán la oportunidad de mencionarlos.

En primer lugar... muchas empresas tienen un poco de margen en los cronogramas para permitir la experimentación. Es casi seguro que no utilizan 8 horas al día para la planificación de la capacidad. (No voy a especular sobre cuántas horas al día le cobran ) De todos modos, si el suyo no tiene eso, entonces solo para despejar las cubiertas, aproveche esas dos horas "perdidas", comiendo en el almuerzo o quedándose un un poco tarde por unos días. No menciones esto a menos que te lo pidan específicamente.

Luego, acérquese a la unidad de su jefe y dígale que el problema del cuello de botella seguía molestándolo, por lo que ha hecho una prueba de concepto que le gustaría analizar con él.

Hagamos una pausa aquí y mencionemos que un buen jefe estará encantado en este punto . Debería estar orgulloso de ti por tener iniciativa y por hacer algo bueno, incluso si no funciona del todo. Si este no es el caso, puede haber algo roto en su cultura corporativa.

Bien, volvamos al jefe. Analice su enfoque con él y demuestre cómo y por qué funciona. Pídele que te ayude a hacer agujeros en tu idea. Haces esto porque (a) lo involucra y tiende a convertirlo en un aliado en esta cuestión; (b) está familiarizado con enfoques fallidos anteriores y puede conocer trampas de las que usted no es consciente; (c) su propia experiencia técnica puede ayudar a corregir cualquier brecha en su solución o ayudar a mejorarla aún más. Concluya con un resumen de los beneficios que ofrece su solución.

Suponiendo que su demostración vaya bien y pueda mitigar cualquier falla en su solución... Pregúntele: "¿Deberíamos impulsar esto?" ¡Buena suerte!

Otra nota al margen ... ¡Soy un gerente y regaño a mis muchachos si no vienen a mí con propuestas no solicitadas! Ahora, los desarrolladores son desarrolladores, uno de ellos me preguntó: "Técnicamente, si lo esperabas, ¿realmente no lo solicitaste?". ¡Dios, amo a la gente del software! ;D

Como desarrollador y administrador de desarrolladores, este es el enfoque que recomendaría. "Examiné un poco este problema y creo que tengo una solución. ¿Podemos revisarlo y verificar que funciona y que no me perdí nada?"

Tu jefe dice: "Dos personas lo intentaron antes que tú y no lograron hacerte, así que no te molestes". Lo miras durante dos horas y descubres cómo hacerlo. Está bien. Tu jefe está feliz. El producto se mejora. Todos están felices.

Tu jefe dice: "Dos personas lo intentaron antes que tú y no lograron hacerte, así que no te molestes". Lo miras durante tres semanas y no sabes cómo hacerlo. Eso es malo. Tu jefe está muy descontento de que hayas perdido el tiempo, y con razón.

Tu jefe dice: "Dos personas lo intentaron antes que tú y no lograron hacerte, así que no te molestes". Lo miras durante tres semanas y descubres cómo hacerlo. Tomaste un gran riesgo. Y su jefe aún puede estar descontento porque trabajó en un problema que no era la máxima prioridad.

Ningún jefe razonable tendrá un problema si le tomó dos horas resolver un problema que le dijo que no se molestara porque asumió que la solución sería imposible o tomaría mucho más tiempo.

Me concentraría en el hecho de que resolvió un problema que se le asignó resolver, y no mencionaría el hecho de que eliminó el cuello de botella que se le dijo que no intentara solucionar.

Su gerente le indicó que no hiciera algo y lo hizo de todos modos. Eso es a primera vista insubordinación. Si le dice a su gerente que hizo esto, literalmente le está echando en cara su insubordinación y esperando que el fin justifique los medios. Es posible que su gerente no tome medidas al respecto, pero es muy posible que pueda afectar su evaluación de su trabajo en el futuro. No hay ningún escenario en el que su gerente lo celebre por hacerlo.

Por otro lado, te asignó la tarea de hacer que algo funcione. Hizo que algo funcionara y, como subproducto de esa solución, eliminó un área problemática. Ese es un buen trabajo. Celebra el cumplimiento de tu tarea, ignora el biproducto. Si su jefe nota que eliminó el cuello de botella en el proceso, alégrese pero no se jacte. Si te señala que hiciste lo que te dijo que no hicieras, hazte el tonto y pregúntale si le gustaría retroceder y encontrar otra forma de resolver la tarea original. Reconozca que tiene razón y que cuando lo hizo solo estaba tratando de resolver la tarea original y no consideró esa parte.

Sí, es una mentira, pero está jugando el juego de una manera que le permite a su gerente salvar las apariencias. Te arriesgaste y valió la pena, pero si hubiera roto todo, ¿querrías que tu gerente te arrojara en la cara cómo te equivocaste? Dele a su gerente el mismo respeto que le gustaría que le diera a usted.

Buenos puntos, pero diría que el gerente en realidad dice que no hagas esto ... parece que el gerente solo sugirió al OP que tenga cuidado de no perder el tiempo tratando de hacer eso.
@GrayCygnus - Tal vez ... pero ¿te gusta que te digan que te equivocaste? Dudo que su gerente lo haga. Y su gerente es el que va a hacer su revisión anual que determina su aumento, y posiblemente si debe obtener la promoción que desea...
Depende de como lo tomes creo. Puedes pensarlo como "Ves que estabas equivocado, yo tenía razón", o desde el punto de vista del gerente, una forma más madura de verlo sería "Genial, parece que estaba equivocado. Es genial que uno nunca deje de aprender".
@GrayCygnus: son palabras clave que no son tan diferentes de "Seamos solo amigos"
No estoy seguro de por qué esto consiguió votos ... SMH
@MisterSortofPositive: porque esta pregunta realmente es "¿Cómo le digo a mi jefe que te lo dije?" sin parecer un idiota para todos excepto para mi jefe.

Proporcionar información donde los desarrolladores hayan realizado dichos cambios es muy importante. Entre otras cosas, a los superiores les gusta estar informados de todo, ya que les gusta tenerlo todo bajo control.

Estuve involucrado en la misma situación en la que me salté un paso antes de realizar el pago, ya que no era necesario en absoluto y habría sido una frustración para los usuarios finales. Olvidé informar sobre lo mismo a mis superiores y tuve que responder a muchos sobre por qué no había informado, por qué cambié el flujo, etc. por qué había puesto el escalón allí en primer lugar. Por último, me preguntó si quería agregar eso en el flujo nuevamente, cuántas horas puede tomar y le dije que no mucho, pero 2 horas como máximo.

Entonces, dile algo al jefe como...

Hola Boss Name , según nuestra última conversación, he completado la tarea junto con eso, me he saltado el paso que discutimos para ayudar aún más a mejorar y suavizar la experiencia del usuario final. El flujo funciona bien. Lo comprobé y se eliminó el cuello de botella. Me gustaría tener sus aportes para lo mismo, también si desea mantener el flujo anterior, mantuve una copia separada para eso.

  1. Dile que lo resolviste, y qué tan rápido.
  2. Dile que te limitaste a "2 horas más o menos" para encontrar una solución.
  3. Si parece molesto por 1. o 2., discúlpate y dile que estás dispuesto a comerte el tiempo si no está contento con eso. (En otras palabras, prepárate para trabajar 2 horas extra). Espere trabajar horas extras ese día. Si puede, elija un día (pronto) para mencionarlo en el que trabajar horas extras no afecte su horario personal; pero no le pidas que lo postergue si quiere que recuperes el tiempo ese día.

Esto evita la deshonestidad y muestra que todavía estás comprometido con la relación: estarías dispuesto a aceptar las repercusiones de ignorar la opinión de tu jefe.

En el futuro, podría ser mejor aclararlo con él por adelantado: "Creo que puedo resolver X, ¿está bien si dedico una tarde a eso y luego me comunico contigo?" o algo.

Nota

En este caso, dijo, "no me molestaría"; no "No puedes". Y, él no te pidió que le dieras tu palabra, entonces parece que cumpliste tu palabra (silencio). Si le habías dicho explícitamente que no trabajarías en él, primero debes disculparte por romper tu palabra.


Estás en una situación delicada (en general). Dado que su jefe no es técnico, a veces tiene que tratarlo como un cliente que tiene metas, pero no entiende la mejor manera de realizarlas. Si cumples sus objetivos y, al mismo tiempo, respetas la relación, con el tiempo debería llegar a confiar en tu juicio.

Pero debe tener cuidado de no estirar esa confianza demasiado rápido. Él podría confiar más en ti por hacer lo que parecía imposible; o menos, por ignorar su entrada. Cuando aceptas hacer (o no hacer) algo, él necesita saber que cumplirás tu palabra. Tener un desarrollador confiable es mucho más importante para él que tener un software confiable, ya que nunca puede confiar directamente en el software: no tiene experiencia con el software, pero tiene mucha experiencia con las personas.

Mire su cultura, las respuestas difieren.

En los ambientes académicos se suele respetar la iniciativa realizada fuera del horario normal de trabajo. Estos entornos dependen tan seriamente de la novedad que si hay resultados, siempre serán revisados ​​profesionalmente. La verdad primero, las ambiciones a un lado. De la misma manera, si la empresa es un spin-off reciente de la universidad, o su supervisor directo tiene un doctorado, o el director ejecutivo es un ex profesor universitario, puede esperar una respuesta generalmente positiva, incluso si la idea se considera cuestionable.

Sin embargo, si la empresa tiene más orígenes corporativos, es antigua y grande, puede ser mucho menos capaz de aceptar un trabajo paralelo de este tipo. Es posible que su supervisor directo se preocupe más de que usted no se haga cargo de su trabajo, el supervisor superior puede creer que las ideas deben provenir de la fuente correcta, el supervisor superior puede estar fuera del alcance razonable e ir allí para discutir ideas no aceptadas puede enojar al supervisor directo. Este puede no ser un enfoque muy óptimo y puede llevar a toda la empresa al final si sucede en exceso, pero así son las cosas.

Esta no es una respuesta a otra pregunta si es apropiado probar ideas personales durante las horas de trabajo remuneradas.