¿Debo mencionar que la cultura del equipo es tóxica en una retrospectiva?

Deberías abordarlo absolutamente, y no me referiría necesariamente a ella como una cultura tóxica (estoy de acuerdo con @GregoryCurrie en que solo mencionar un ambiente tóxico en un estilo retro es algo para una discusión de gerente privado). Le recomendaría discutir algunas acciones que son tóxicas y referirse a ellas como comportamientos negativos que afectan la interoperabilidad del equipo. Debería poder definirlo para el equipo e identificar por qué está causando tanto problema para usted y para el equipo. Recomendaría tener algunas ideas sobre cómo eliminarlo.

El problema de referirse a ella como toxicidad es que es un lenguaje de "culpabilización". Las personas que se comportan de manera tóxica se ofenderán y cerrarán. Al abordar los comportamientos, comienza a cambiar los hábitos del equipo. Es más fácil tener ejemplos concretos de comportamientos e instancias, y decirle a alguien que hizo algo que te afectó negativamente es mucho más fácil de digerir que las declaraciones que sugieren un estado de "siempre".

También es útil si usted mismo lo investiga como parte del problema. Las personas se sienten menos acusadas si eres capaz de denunciar el comportamiento en ti mismo. También es más probable que se unan a usted para corregir el comportamiento porque ahora tienen un socio en la solución en lugar de alguien que los juzgue.

Lo retro debe seguir siendo un lugar seguro, y eso significa no solo acusar descaradamente a las personas. Significa sacar a la gente del problema y abordarlo. La persona no es mala, el comportamiento es malo.

Joel ya escribió una respuesta bastante buena y tengo que estar de acuerdo con él sobre la dirección general y el resultado. Me gustaría darle otra razón por la que es el curso de acción correcto.

Cualquier problema en el equipo debe mencionarse en la retrospectiva. Solo si no pueden resolverse allí, el equipo debe decidir involucrar a otra persona, como un gerente.

Pero usted tiene que asegurarse de que lo que mencione sea procesable . Tu problema solo desaparece si puedes salir de la reunión con un conjunto de acciones que resuelven el problema.

"La cultura del equipo es tóxica" no es nada procesable. Es inespecífico y obstinado. Algunos dirán que sí, otros dirán que no y luego estarás de regreso en el jardín de infantes. Sin ningún cambio en el futuro o resultado positivo.

Realmente no diste ningún ejemplo, así que tendré que inventar uno: digamos que la gente de negocios te pregunta sobre el estado de tu proyecto varias veces como si no te creyeran. Tal vez porque en realidad no lo hacen.

Cuando estamos en nuestras reuniones de estado, tengo que repetirme varias veces. Siento que o ignoras lo que dije o no crees lo que dije. Me gustaría que encontráramos una manera de que solo tenga que decirlo una vez.

Ahora bien, esto no es una opinión. O tienes que repetirte o no. Cualquiera puede estar presente y ser testigo de eso. Por otro lado, la gente de negocios puede tener buenas razones para hacerle preguntas muy detalladas como "¿lo probó?", "¿lo implementó en control de calidad?", "¿impulsó sus cambios?". Probablemente porque en el pasado, simplemente creían cuando la gente decía "ya está hecho" y luego no.

Así que ahora tiene un ejemplo real y fáctico de comportamiento que le gustaría cambiar y ha preguntado cómo cambiarlo de una manera constructiva. Ahora puede continuar y discutir acciones .

Para este ejemplo inventado, la acción podría ser tener una lista de preguntas ("definición de hecho" de usted hace Scrum) que debe responderse para que cualquier elemento se considere hecho. Cuando llegue su turno para revisar el estado de un elemento, y ya está hecho, simplemente revise esta lista y confirme cada punto. "Hice la codificación, Alice hizo la revisión del código, lo implementamos en DEV y Bob lo probó. Charlie lo implementó en control de calidad hace solo una hora, puede inspeccionarlo allí si lo desea. Está listo". O tal vez encuentres otra solución.

Pero dé un paso a la vez. Escoja algo real y mejórelo con acciones . Las declaraciones grandilocuentes sin ningún contenido real, como "todo esto es tóxico", no lo llevarán a ninguna parte.

Las mejores mejoras para discutir en la retrospectiva son aquellas que son accionables

Las retrospectivas más satisfactorias son aquellas en las que el equipo decide hacer algo diferente y comienza a implementar el cambio de inmediato.

El problema de discutir cosas que son "tóxicas" es que "tóxica" es una palabra que básicamente significa "esto es algo que siento que es malo y no me gusta". Es difícil para un equipo implementar un cambio en su estado emocional, porque los estados emocionales son inherentemente subjetivos.

Es mucho más fácil implementar un cambio en el proceso que utiliza su equipo. También es más fácil hablar de cambios cuando establece el cambio en términos de lo que debe hacer su proceso; tiene la ventaja de despersonalizar mucho la discusión.

En su caso específico, le sugiero que discuta el hecho de que la gente de negocios está hablando en su reunión diaria y sugiera un cambio de proceso para evitar que eso suceda. Muchos equipos que usan Scrum no permiten que los que no son miembros del equipo hablen en stand-up, porque se interpone en el camino de lo que se supone que debe ser stand-up. Se supone que el stand up es para que el equipo se organice y resuelva sus propios problemas, no para dar informes de estado a otras personas en la organización. Tener gente de negocios participando hace que la reunión sea menos útil para el equipo.

Tenga en cuenta aquí que, cuando expongo su problema anterior en el contexto del cambio de proceso, no hago ningún comentario sobre cuán malo es el comportamiento de los invitados a la reunión. No es necesario decirlo, porque ahora estamos hablando de cambios procesables que serán un beneficio para el equipo, independientemente de cuán groseros sean los empresarios. Incluso si su rudeza surge en la discusión que se lleva a cabo (lo que probablemente sucederá si sus reuniones retrospectivas son psicológicamente seguras), aún puede tener una conversación adecuada al respecto porque siempre puede guiar a todos de regreso al cambio de proceso propuesto y alejarse. de cómo Business Bob es un gran imbécil.

Sí, este es un tema que debe abordarse. Y usted, como forastero, está en una muy buena posición para mediar aquí. Pero resolver conflictos como ese aún requiere un manejo delicado, y la reunión retrospectiva del proyecto podría no ser el lugar adecuado para ello.

Cuando crea que una persona es el problema aquí, primero debe hablar con la persona problemática en privado . Abordar sus fallas personales en público es exactamente el mismo comportamiento tóxico del que los acusa: los socava y humilla frente al equipo. Algunas personas podrían pensar que darles "una muestra de su propia medicina" podría ser bien merecido, pero es poco probable que logre mucho. La mayoría de las personas simplemente se pondrán a la defensiva o agresivas en lugar de reflexionar y cambiar su comportamiento.

Un mejor enfoque sería hablar con esa persona en privado.

• Utilice I-Statements para explicar el problema: "Tengo la impresión de que la relación entre usted y el equipo no es muy buena". "Fui testigo de situaciones como [example] que podrían dañar la moral del equipo".
• Enfócate en el beneficio para el proyecto y para la persona que quieres cambiar: “Creo que esto está haciendo más daño que bien al proyecto por [razones]”. "Creo que su trabajo podría ser más fácil si [...]"
• Brindar soluciones: "Hice la experiencia de que los técnicos toman mucho mejor las críticas cuando [se presentan así]".

En principio, tienes razón. Un retro es el lugar para discutir temas endémicos que afectan el proceso de desarrollo.

En la práctica, el comportamiento tóxico no se rectifica fácilmente. Porque si lo fuera, generalmente se autocorregiría cuando las personas chocaran entre sí en el lugar de trabajo.

No es imposible que tener una conversación en un grupo grande haga que todos vean el punto de vista del otro, pero en mi experiencia, los elementos tóxicos tienden a no ser tan abiertos de mente.
Como referencia, como consultor, he trabajado para muchos clientes que necesitaban mano de obra adicional debido a la escasez de mano de obra derivada de un lugar de trabajo tóxico (que no pudieron identificar ni abordar).

Las personas tóxicas tienden a no jugar bien con los demás, al menos con las personas con las que son tóxicas. Podría decirse que por eso son tóxicos.
En términos generales, es mejor eludir los elementos tóxicos y, en cambio, abordar esto con una parte que no sea personalmente parte de la cultura tóxica, que se vea afectada personalmente por cualquier problema que sufra el equipo de desarrollo (o al menos se preocupe por el problema) y que esté capaz de ejercer presión sobre los elementos tóxicos.

Esto podría ser Recursos Humanos, si el problema es la falta de mano de obra debido a que las personas se van, o un comportamiento inaceptable como la intimidación. Esto podría ser la gestión de ventas, si la toxicidad está provocando retrasos y fallas en la entrega. Podría ser el CEO, si la toxicidad está causando problemas generales en la empresa.

Escalar, escalar, escalar. Esté preparado para que los elementos tóxicos mientan y afirmen que el problema es la otra parte. No estoy diciendo que definitivamente mentirán, estoy diciendo que estén preparados para tener una contraprueba lista para desmantelar sus afirmaciones.

Nunca menciones algo de lo que no tengas pruebas. Los elementos tóxicos que han podido salirse con la suya tienden a ser bastante hábiles para desarmar cualquier cosa que los critique y confían en obtener el beneficio de la duda; así que asegúrese de que su caso sea irrefutable e irrefutablemente probado. Es mejor presentar una queja pequeña pero infalible ahora que hacer una gran queja con algunos puntos sin fundamento o poco claros.

Si nadie que pueda ejercer presión sobre los elementos tóxicos le cree, está dispuesto o es capaz de combatir la cultura tóxica, entonces es muy poco probable que encuentre una solución aquí. Decimos "tóxico" porque puede envenenar irreparablemente el medio ambiente y, si nadie lo limpia, puede terminar en un agotamiento masivo, una baja productividad o un éxodo masivo de desarrolladores. Las empresas se han hundido por menos.

Suponiendo que la retrospectiva de la que hablas se lleve a cabo tanto con el área comercial como con el equipo de TI, mi primer paso sería hablar sobre esto con el Scrum Master o la persona que facilita esa retrospectiva. ¿Esa persona ve los mismos problemas que tú? ¿Qué ya intentaron? Incluso podría tratar de hablar con otras personas del equipo en 1 a 1, pero preferiblemente los problemas generales del equipo se discuten en retrospectivas con todo el equipo.

En el puesto de Scrum Master, me centraría en dos cosas:

1. Todos deben sentirse lo suficientemente seguros para hablar sobre el problema de manera constructiva (sin culpar a las personas, sino atreverse a decir qué comportamiento no les funciona). Puede buscar acuerdos de trabajo (específicamente para la retrospectiva, consulte también "Retrospectivas ágiles" de E. Derby y D. Larsen, página 47), o una estructura liberadora como Heard, Seen, Respected o What I Need From You .
2. Si la gente puede hablar de ello abiertamente de manera constructiva, el siguiente paso es dejar que la gente hable de ello. Si solo cree que un problema es un problema, el grupo no lo solucionará. Por supuesto, puede ayudar dejando que el grupo vea el problema, pero no puede forzarlos. Podría guiarlos dando ejemplos concretos de lo que cree que no va bien y cómo mejoraría eso, sin culpar a quien lo hizo. Para mí funciona bien empatizar con el mal comportamiento, por ejemplo, mostrando un lado vulnerable de mí mismo donde cometí el mismo tipo de errores en el pasado. Es posible que desee probar Spot the Elephant , Writing the Unspeakable o actividades retrospectivas similares.

Solo entonces deberías intentar arreglarlo. Deje que el grupo proponga soluciones adecuadas que consideren viables y valiosas, por supuesto, idealmente a través de puntos de acción concretos. Arreglar esto dentro de un sprint/retrospectiva probablemente no sea factible, así que tómate tu tiempo y deja que el equipo se tome su tiempo. Si sus observaciones son correctas, es probable que ya se hayan encontrado con este problema durante mucho tiempo, por lo que no debería importar demasiado no solucionarlo en un sprint.

Creo que te estás enfocando en el problema equivocado. Es un problema que la gente sea acosada, no hay duda al respecto. Pero las verdaderas preguntas son por qué la gente de negocios está en los diarios. Y por qué lo lideran personas ajenas al equipo.

No has mencionado qué tipo de ágil haces, si es Scrum, Kanban o algo más. Voy a asumir Scrum o Kanban.

El diario es que el equipo se reúna y sincronice esfuerzos internamente. Y plantear problemas, para obtener ayuda. Las partes son:

• El Scrum master, liderando la reunión
• Los miembros del equipo, actualizando a los otros miembros del equipo.
• El propietario del proyecto responde preguntas sobre requisitos, etc.

No se permite a nadie más. Y el PO ni siquiera puede hacer preguntas, está ahí para apoyar al equipo, no al revés.

Por alguna razón no se sigue esta regla básica para los diarios. Creo que al enfocarnos en cómo esto afecta al equipo, el problema desaparece cuando se siguen los diarios adecuados.

Creo que la mejor manera de tener una solución o soluciones completas es

reconocer el problema primero

. Por lo tanto, prefiero analizar la causa raíz del problema como primer paso. Porque a veces nos enfrentamos a algunos comportamientos que son el resultado de otras acciones de las que ni siquiera conocemos el origen.
Así que trate de conocer a su equipo, las partes interesadas relacionadas y otras partes para encontrar la causa raíz del problema.
Después de encontrar la causa raíz o las causas, considere el manifiesto ágil como la guía base para resolver el problema.

Creo que algunas de las respuestas anteriores tienen una visión muy optimista de una retrospectiva que es difícil de hacer bien en las mejores circunstancias, pero que en un entorno como el descrito anteriormente no puede funcionar. Si esta es la forma en que se trata a las personas, una retrospectiva no es un espacio seguro.

Los problemas con los que está lidiando son mucho más fundamentales y no se resolverán sacándolos a la luz en un entorno grupal. Es muy probable que ese enfoque explote.

Estoy de acuerdo con las otras respuestas en que está bien mencionar algunos problemas concretos en la retrospectiva y ver si se pueden abordar o solucionar. La respuesta que obtenga a esos ya será de gran ayuda para decirle si es una buena idea abordar cuestiones más fundamentales allí.

¿Qué debes hacer? Es probable que deba trabajar en su relación con el liderazgo de ambos grupos y el liderazgo común que tienen y plantearles este problema.

Dado que solo se nos cuenta un lado de la historia, y los problemas de intimidación a menudo son subjetivos (es igualmente posible que alguien realmente esté intimidando, ya que la otra persona tiene una piel delgada y necesita aprender a aceptar las críticas) , es difícil dar una respuesta imparcial a esta pregunta. Así que voy a dar 2 respuestas y puedes elegir la que más te guste:

Una posibilidad es que esto sea realmente intimidación. Esto no está bien. Sin embargo, como desarrollador, la "moral del equipo" no es realmente tu responsabilidad, y todo el mundo lo sabe. Si vas al otro equipo, oa su jefe, oa quien sea, y dices "a mi equipo no le gusta esto", entonces no te tomarán en serio. Tienes que ascender por tu propia cadena de mando hasta las personas de tu cadena que son responsables de ese tipo de cosas. Este probablemente será su gerente directo, o tal vez su gerente directo; no tienes que ir demasiado lejos. Si no están presentes en las reuniones donde ocurren estos problemas, hágales saber que hay inquietudes (y cuáles son esas inquietudes, puede repetir lo que escribió aquí) y pídales que estén presentes en la reunión para observar la próxima vez. Si ya están en la reunión y conocen los problemas, plantee que estos son problemas que desea manejar; podría ser que su gerente no sepa que estos comentarios son problemáticos y piensa que todo está bien, así que hágale saber que esto no está bien y que se debe hacer algo. En ese momento, si su gerente se niega a hacer algo al respecto, podría ser el momento de buscar un nuevo gerente. Seguramente, si todo el equipo de desarrollo renuncia a su tratamiento por parte de la gestión del proyecto, entonces PM se encontrará rápidamente en problemas, ya que no tienen gente para hacer las tareas; al menos ahora pueden decir que las tareas se están haciendo pero no según las especificaciones, pero si todos se dan por vencidos, ni siquiera tendrán eso. Por lo tanto, lo mejor para todos es resolver este problema sin perder a todo el equipo de desarrollo. podría ser que su gerente no sepa que estos comentarios son problemáticos y piensa que todo está bien, así que hágale saber que esto no está bien y que se debe hacer algo. En ese momento, si su gerente se niega a hacer algo al respecto, podría ser el momento de buscar un nuevo gerente. Seguramente, si todo el equipo de desarrollo renuncia a su tratamiento por parte de la gestión del proyecto, entonces PM se encontrará rápidamente en problemas, ya que no tienen gente para hacer las tareas; al menos ahora pueden decir que las tareas se están haciendo pero no según las especificaciones, pero si todos se dan por vencidos, ni siquiera tendrán eso. Por lo tanto, lo mejor para todos es resolver este problema sin perder a todo el equipo de desarrollo. podría ser que su gerente no sepa que estos comentarios son problemáticos y piensa que todo está bien, así que hágale saber que esto no está bien y que se debe hacer algo. En ese momento, si su gerente se niega a hacer algo al respecto, podría ser el momento de buscar un nuevo gerente. Seguramente, si todo el equipo de desarrollo renuncia a su tratamiento por parte de la gestión del proyecto, entonces PM se encontrará rápidamente en problemas, ya que no tienen gente para hacer las tareas; al menos ahora pueden decir que las tareas se están haciendo pero no según las especificaciones, pero si todos se dan por vencidos, ni siquiera tendrán eso. Por lo tanto, lo mejor para todos es resolver este problema sin perder a todo el equipo de desarrollo. No está bien y hay que hacer algo. En ese momento, si su gerente se niega a hacer algo al respecto, podría ser el momento de buscar un nuevo gerente. Seguramente, si todo el equipo de desarrollo renuncia a su tratamiento por parte de la gestión del proyecto, entonces PM se encontrará rápidamente en problemas, ya que no tienen gente para hacer las tareas; al menos ahora pueden decir que las tareas se están haciendo pero no según las especificaciones, pero si todos se dan por vencidos, ni siquiera tendrán eso. Por lo tanto, lo mejor para todos es resolver este problema sin perder a todo el equipo de desarrollo. No está bien y hay que hacer algo. En ese momento, si su gerente se niega a hacer algo al respecto, podría ser el momento de buscar un nuevo gerente. Seguramente, si todo el equipo de desarrollo renuncia a su tratamiento por parte de la gestión del proyecto, entonces PM se encontrará rápidamente en problemas, ya que no tienen gente para hacer las tareas; al menos ahora pueden decir que las tareas se están haciendo pero no según las especificaciones, pero si todos se dan por vencidos, ni siquiera tendrán eso. Por lo tanto, lo mejor para todos es resolver este problema sin perder a todo el equipo de desarrollo. entonces PM se encontrará rápidamente en problemas, ya que no tienen gente para hacer las tareas; al menos ahora pueden decir que las tareas se están haciendo pero no según las especificaciones, pero si todos se dan por vencidos, ni siquiera tendrán eso. Por lo tanto, lo mejor para todos es resolver este problema sin perder a todo el equipo de desarrollo. entonces PM se encontrará rápidamente en problemas, ya que no tienen gente para hacer las tareas; al menos ahora pueden decir que las tareas se están haciendo pero no según las especificaciones, pero si todos se dan por vencidos, ni siquiera tendrán eso. Por lo tanto, lo mejor para todos es resolver este problema sin perder a todo el equipo de desarrollo.

Ahora, también es posible que la premisa de la pregunta sea exagerada. No proporcionaste ningún ejemplo directo de las cosas que se dijeron, solo dijiste que algunos comentarios eran "pasivos-agresivos". También dijo que algunos de los comentarios realizados tienen mérito, que se están cometiendo errores. Ahora, ya que anteriormente defendí su posición contra el equipo de PM, ahora voy a defender al equipo de PM contra sus acusaciones, solo para ser justos. Si su trabajo no está a la altura de las expectativas, debe trabajar en eso. Asumo que esta no es la primera reunión en la que el equipo de PM presenta quejas; si tienen que acudir constantemente a usted y quejarse constantemente de lo mismo una y otra vez y nunca se soluciona, bueno, eso genera frustración. No es excusa para intimidar intencionalmente a alguien, pero a veces simplemente se dicen cosas que tal vez no deberían decirse o no deberían decirse en la forma en que se dicen. También es posible que las cosas se consideren "pasivas-agresivas" cuando en realidad no lo son, por ejemplo, si un error se señala como de alta prioridad y luego no se soluciona y luego se convierte en otro error, luego el equipo de PM podría decir "bueno, marcamos esto como alta prioridad por una razón"; para algunas personas que pueden ser "pasivos-agresivos", para otras, no. Sin embargo, es una declaración verdadera: si solucionó el primer error como de alta prioridad, entonces el error en cascada no habría ocurrido, y el equipo de PM le dijo que era de alta prioridad y dejó caer la pelota, por lo que tienen un tipo de derecho a estar molesto. En este caso, debe reconstruir la confianza entre su equipo y el equipo de PM; PM piensa que eres un incompetente, y más o menos te lo dicen en la cara. Quejarse de esto a la gerencia, si sigue el consejo anterior, no va a resolver el problema. Si lleva un problema de este tipo a la gerencia, le dirán "El equipo de PM le dice que es incompetente y, según las métricas XYZ, estamos de acuerdo con ellos, así que póngase en forma o lo despediremos", y eso es si tienes suerte y no te despiden en el acto.

Da un paso atrás y piensa en la situación de manera lógica: si te alejas de la situación inmediata de estar en un equipo y sesgas tu opinión hacia tu "grupo interno", ¿crees que es más probable que el equipo de PM esté actuando de manera beligerante para no hay razón, o cree que su equipo está dejando caer la pelota repetidamente y le da al equipo de PM una razón para estar enojado con usted? Tómese un minuto, reflexione sobre esa pregunta y deje que guíe sus próximos pasos.

Voy a adivinar que el trasfondo de esta situación es algo como esto:

• Su empresa vende un producto físico, como maquinaria, que no tiene nada que ver con el desarrollo de software.
• En algún momento se dieron cuenta de que necesitaban entrar en el desarrollo de software para capturar más del mercado, por lo que contrataron a algunas personas para crear un departamento de TI y crear software para ellos.
• Debido a que la empresa no tenía experiencia en software y/o porque trató de contratar a los desarrolladores más baratos, los desarrolladores que contrataron eran de baja calidad y/o casuales.
• Debido a que la empresa no comprende el desarrollo de software, se permitió que los departamentos que necesitaban software dirigieran y controlaran el proceso de desarrollo en lugar de TI; estos departamentos proporcionaron especificaciones detalladas deficientes o inexistentes mientras establecían y hacían cumplir plazos de entrega arbitrarios
• Esto dio como resultado que el departamento de TI entregara software de baja calidad, lo que resultó en el incumplimiento de los plazos, lo que hizo que los departamentos que requerían dicho software no estuvieran contentos, lo que provocó que perdieran la confianza en el departamento de TI.
• Por el contrario, el departamento de TI se volvió menos confiado en los otros departamentos porque TI carecía de autonomía y esos departamentos estaban felices de culpar a TI por todos los problemas de software, incluso si esos problemas se derivaban de que esos departamentos no hacían su parte al producir especificaciones, etc.
• Debido a que los problemas anteriores nunca se abordaron, la calidad del software siguió siendo deficiente, lo que siguió erosionando la confianza entre TI y los otros departamentos, lo que culminó en lo que ve hoy: a otros departamentos se les permite microgestionar TI a un nivel ridículo. grado, en un intento de producir software que sea de calidad aceptable

Esto no es reparable.

La razón es que su empresa, como tantas otras, no entiende lo que es. Ya no es una empresa que vende productos físicos; es una empresa que produce software que le permite vender productos físicos. En otras palabras, TI no es auxiliar para su empresa, sino su núcleo. Pero la dirección no entiende o no está dispuesta a admitir esto. Y mientras esto sea cierto, TI continuará siendo tratado como el hijastro pelirrojo y la relación entre ese departamento y los otros departamentos nunca podrá recuperarse.

Incluso si la gerencia tuviera una epifanía, probablemente nada cambiaría. Cuando los niveles de confianza son tan bajos, se necesita un gran esfuerzo para reconstruirlos; es decir, las personas equivocadas deben ser trasladadas a diferentes roles o despedidas, y las personas adecuadas deben ser contratadas, recibir el mandato de sacudir las cosas para solucionar el problema y, de hecho, empoderarse para hacer cumplir ese mandato. Para la mayoría de las empresas, este es un puente demasiado lejano.

Entonces, en cuanto a su pregunta, no : nada de lo que pueda decir o hacer afectará materialmente la forma en que se estructura la empresa y, por lo tanto, cómo se trata la TI. Es probable que solo lo muestre como una amapola alta para que la gerencia la corte en caso de que no se ajuste a la dinámica disfuncional de la empresa. Si no te gusta, tu única opción es buscar otro trabajo.