No pidas un “sí”; pide un “no” (2022)

• En una empresa pequeña, cuando impulsas algo dentro del alcance de tu trabajo, dar una oportunidad y un plazo para rechazarlo en vez de esperar autorización puede acelerar la ejecución.
• Una solicitud de aprobación como “¿puedo instalar la action X?” le traslada al jefe la revisión del problema, la evaluación de la solución y hasta el ajuste de prioridades, por lo que la respuesta puede demorarse.
• Decir “el lunes instalaré la action X. Si piensas distinto, avísame” muestra intención de ejecutar, pero deja espacio para que el jefe intervenga.
• Este enfoque es adecuado cuando la tarea está dentro de tu ámbito de responsabilidad, aceptas feedback, pero tienes suficiente confianza en el rumbo como para avanzar aunque no haya respuesta.
• Si además propones un plazo cercano, aumenta la probabilidad de que quien tenga algo que decir responda más rápido, y puedes mantener informadas a las partes interesadas sin detener la ejecución.

---

Dar oportunidad de rechazar en vez de esperar permiso

• Tener un sesgo hacia la acción, aunque sea para avanzar un paso muy pequeño, ayuda a romper el estancamiento.
• El hábito clave es no pedir un “sí”, sino pedir un “no”.
  • La experiencia de base proviene de empresas pequeñas, con menos de 200 empleados.
  • No está claro si el mismo enfoque funciona en empresas grandes, organizaciones sin fines de lucro u organizaciones gubernamentales.
• Cuando quieres hacer algo que sientes que está dentro del alcance de tu trabajo, pero necesitas tranquilidad o quieres informar a tu jefe, lo habitual es pedir permiso primero.
• En su lugar, le das al jefe una oportunidad de rechazarlo y, junto con eso, presentas un plazo claro para tomar esa decisión.

La diferencia vista con un ejemplo de GitHub Action

• El ejemplo es una situación en la que instalas en un repositorio una nueva GitHub Action que consideras útil para mejorar la calidad del software.
  • No es un simple capricho: ya investigaste y la probaste localmente.
  • También podrías haberle preguntado a un excompañero sobre su experiencia usando esa GitHub Action.
• Preguntar “¿puedo instalar la action X? Ayuda con el problema XYZ que estamos teniendo” hace que tu jefe tenga que hacer trabajo adicional antes de decir “sí”.
  • Debe volver a revisar el problema XYZ.
  • Debe evaluar cómo X resolvería el problema.
  • Puede tener que comparar prioridades con otras tareas, o querer que primero se comparta lo que sabe la persona responsable.
  • Para un jefe ocupado, esto puede quedar postergado, y quizá tengas que recordárselo varias veces.
• La alternativa es decir: “Voy a instalar la action X para resolver el problema XYZ. Si piensas distinto, avísame; si no, lo haré el lunes”.
  • Señala que la persona responsable se hará cargo directamente del problema.
  • El jefe puede intervenir si quiere, pero se reduce la carga de tener que responder obligatoriamente.
  • Aunque el jefe lo olvide o surja otra cosa, el avance no se detiene.
• Este enfoque puede aplicarse no solo a individuos, sino también a grupos formados por varias personas.

La presión de respuesta que crea un plazo

• El plazo es un elemento clave de este enfoque.
  • Tomando como referencia el 15 de enero, “haré la task X el 17 de enero” puede inducir una respuesta más rápida que “haré la task X”.
  • Un plazo en el futuro cercano tiene más probabilidades de generar una respuesta inmediata que uno lejano, como “haré la task X el 15 de febrero”.
• Funciona mejor cuando dejas abierta la oportunidad de dar feedback, pero tienes suficiente confianza en el rumbo como para ejecutar aunque no recibas feedback.

[GN⁺]

Opiniones de Hacker News

• Esto es una competencia clave en las grandes empresas, donde todo el mundo está ocupado y es fácil que las cosas queden enterradas.
  Después de explicar el problema en un email, escribo: “Si no hay respuesta en [N] días, el [día N] haré XYZ”. En vez de pedir aprobación y quedarme esperando impotente o insistir, dejo una notificación de que, si nadie hace nada, XYZ seguirá adelante.
  A veces, unas semanas después aparece alguien enojado preguntando por qué lo hice sin avisar, pero cada vez puedo mostrarle el registro que se le pasó.

  • La frase “si no hay respuesta, haré XYZ” suena innecesariamente confrontativa.
    Alcanza con decir algo como: “Por estos motivos, planeo hacer XYZ y avanzaré el [fecha]. Si tienen objeciones o preocupaciones, avísenme”.
    Este enfoque te obliga a presentar fundamentos sólidos de antemano y también permite recibir feedback para evitar restricciones que no conocías o errores.
    También es raro ese comportamiento de culto de carga de seguir los principios de liderazgo de Amazon como si fueran una solución al problema. El “sesgo hacia la acción” funciona en Amazon porque quienes actuaron de forma unilateral y fallaron terminan siendo chivos expiatorios y despedidos, y esas personas no escriben en blogs sobre las virtudes del sesgo hacia la acción.
  • Me da curiosidad cómo se expresa esto en la práctica.
    ¿Algo como: “El 1 de marzo planeo desfragmentar el thingamajig. Me comunico de antemano con quienes podrían verse afectados por este trabajo. Si tienen inquietudes, avísenme. Si no hay respuesta antes del 1 de marzo, el thingamajig será desfragmentado”?
  • Esto suena un poco a fantasía, o parece posible solo cuando la regla que se está rompiendo no tiene ninguna importancia para el negocio.
    Decir “si no hay respuesta en 5 días, haré X” no sirve de defensa si hiciste algo por lo que podrían sancionarte.
    Donde podría funcionar, como mucho, es al infringir una decisión interna de diseño que no tenga relación con el negocio.
  • La parte de “a veces, semanas después, alguien se enoja porque hice XYZ sin avisar” me resulta sospechosa.
    Si alguien dice que hace esto “siempre” y escribe una frase mágica como plantilla, me pregunto si de verdad es su experiencia o si está proyectando cómo le gustaría trabajar, como en el texto principal.
    Cuando imagino la escena de ganarle a compañeros enojados mostrándoles el registro, mi detector de pavadas se va hasta rojo.
  • También me gusta porque tiene el efecto de dejar registrado quién está bloqueando o rechazando el avance.

• A esto lo llamo “no preguntes, informa”, y sirve mucho dentro y fuera de la empresa.
  Es una habilidad de comunicación básica y hace que los resultados sean concisos y decisivos.
  Tengo conversaciones así con mi esposa con frecuencia; ella suele mandar preguntas abiertas a un grupo de 8 personas, como “¿a qué hora llegan?”. Como nosotros ya sabíamos que íbamos a llegar una hora antes por el horario de cuidado de los niños, le dije que simplemente informara: “Nosotros llegamos a esta hora, y quienes quieran tomar algo antes estarán en el bar”.
  No hacía falta pedir respuestas, todos llegaron temprano y todo salió bien con una comunicación mínima.
  Tiene algo que ver con “pedir perdón en vez de permiso”, pero un lugar donde colaboran varias personas, como un repositorio de GitHub, no es el sitio adecuado para lanzar sin más un cambio grande que afecta a otros.

  • Yo también hago esto. No es solo una mejor comunicación; también es una mejor forma de vida.
    No se trata de quedar en un estado en el que solo puedes disfrutar si los demás coordinan contigo, sino de empezar a hacer lo que quieres y avisarles a otros que pueden sumarse.

• Cuando mis compañeros me preguntan cómo conseguir que aprueben sus propuestas, les doy un consejo parecido: “Haz que para la otra persona sea lo más fácil posible decir que sí”.
  No puedes tirarle a alguien 14 párrafos y esperar que se ponga al día de inmediato hasta el nivel al que tú llegaste tras meterte durante horas en el problema.
  Si tienes confianza en tu enfoque, explica de forma concisa por qué el problema y la solución encajan, y agrega un enlace a un documento para quien quiera profundizar. Conviene tener ya el acuerdo del equipo o del responsable de producto.
  Ejemplo: “Quiero resolver X con Y. Todo el equipo está de acuerdo. La propuesta detallada está en [link]. Si no hay feedback adicional que tratar, empezaré el martes”.
  Los gerentes no tienen tiempo para revisar todos los detalles, y agradecen que les dejes el trabajo ordenado —incluido el apoyo del equipo más amplio— para que solo tengan que aprobar.

  • Si un gerente trabaja así, empieza un concurso de popularidad. Ese tipo de gerente es ineficiente o inútil.
  • “Si tienes confianza” es la clave. Yo determino mi confianza no con narcisismo, sino con estadísticas objetivas e incertidumbre.
    Si la probabilidad de éxito es del 10% pero hay una razón para intentarlo, lo digo así; no lo envuelvo en una presentación absurda diciendo que estoy seguro de que va a funcionar. Si la probabilidad de éxito es del 80%, tampoco oculto el 20%; y si digo 98%, significa que realmente está cerca de eso.
    El trabajo de un gerente es manejar esas estadísticas y cubrir riesgos. Un hedge fund lo hace con dinero; un gerente lo hace con personas y recursos.
    Por desgracia, el típico gerente corporativo prefiere a alguien que dice que tendrá éxito al 100% aunque en realidad falle el 50% de las veces.

• Me gusta una expresión parecida: radiar intención (radiating intent).
  Consiste en comunicar ampliamente qué quieres hacer y cuándo, dando a las partes interesadas espacio para oponerse explícitamente, pero sin ir persiguiendo consenso, alineación y aprobación una por una.
  Funciona bien en algunas situaciones y, en general, primero hace falta haberse ganado una confianza básica.
  https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...

  • Me convencen las cuatro razones para “radiar intención”. Funciona bien en organizaciones con un nivel de confianza medio o superior.
    También me gustó el matiz que agregó Eliz Ayer: “Para ser justos, con radiar intención quizá logres hacer menos cosas, porque les das una vía de entrada a quienes obstaculizan o se meten. Además, este consejo depende mucho de la situación y de la organización, así que no siempre es adecuado”

• Esta forma de comunicación parece hacer que la otra persona te vea de inmediato como una persona riesgosa.
  Por fuera parece que le ahorras tiempo, pero en realidad es una manera de decirle al gerente que, si no está siempre pendiente de lo que hace ese empleado, este podría hacer algo no deseado.
  El texto lo trata como si fuera una notificación, pero por más buena intención y comprensión que haya, las notificaciones se pierden fácilmente entre el ruido de las señales, y que no haya respuesta no significa consentimiento. También puede significar que el mensaje no se recibió.
  Si el empleado y el gerente ya discutieron el problema y ahora están en la etapa de ejecutar la solución, puede estar bien; pero cuando se plantea por primera vez un problema que la otra persona ni siquiera ha considerado, es lo peor. Es egoísta y lo opuesto al trabajo en equipo.
  También da la impresión de que alguien vio a un legendario ingeniero 10x Rockstar hacerlo y lo está imitando. Ese ingeniero siempre trabaja bien, sabe qué hay que hacer y tiene entendimiento y respeto mutuos con la gerencia, por lo que hay margen para dejarle autogestión. Parece que alguien vio eso y, sin entender por qué recibe ese trato ni cómo debería ganárselo, pensó que también se le aplicaba a él.

  • Al final, todo depende de la relación.
    Si hiciste esto tres veces seguidas y recibiste como respuesta “por favor, detente”, algo está mal. Si recibiste elogios tres veces seguidas, sigue así.
    La persona realmente riesgosa es la que, aun cuando le dicen que no, ejecuta la mayor parte de todos modos y después busca el sí. Hace lo mismo en el siguiente asunto y no responde al feedback.
    Así que lo central no es tanto el método en sí, sino la relación laboral. En un entorno con mucha confianza y donde todos están ocupados, vale la pena intentarlo.
  • Si alguien que no conozco me hiciera esto, me parecería arrogante y molesto.
    Si ya trabajé con esa persona, hay confianza y sé que lo hace para respetar mi tiempo, es una historia completamente distinta.

• La primera vez que rompes algo, esto se vuelve una receta para el desastre.
  Haber recibido un sí o un no significa que tu jefe estaba al tanto. Si algo sale mal y preguntan “¿quién lo aprobó?”, la respuesta honesta es que nadie lo aprobó.

  • Depende mucho de la cultura organizacional y de la efectividad de la gestión.
    Si en la organización no hay nadie que pueda actuar así, es señal de que el equipo de liderazgo está fallando en delegar.
  • Esto no parece algo para usar con tu jefe, sino más bien con personas de otros departamentos que deben involucrarse en el trabajo.
    Por ejemplo, cuando X del equipo Y se opone a algo.
    Si tu jefe 1) dice que hay que hacer algo y 2) no aprueba ningún plan, simplemente no lo hagas. En ese caso, la responsabilidad de dar instrucciones para que el trabajo avance es de tu jefe.
  • Si tu jefe tiene que aprobar todo lo que haces, entonces no es un jefe sino un micromanager, y ambos están haciendo las cosas mal.
  • Al menos en software, nadie debería poder hacer cualquier cosa por su cuenta.
    Decir “voy a hacer esto” está bien, pero no debería llegar a producción sin procesos como revisión y pruebas automatizadas.
    Claro que eso genera cuellos de botella. Si abres un merge request y nadie lo revisa a tiempo, no pasa nada. En estos casos, a nivel de team lead se debe acordar que se revisará y se dará feedback dentro de cierto plazo.
  • Hacerse responsable de algo incluye romperlo y arreglarlo.

• Este enfoque parece funcionar solo con jefes de empresas estadounidenses o acostumbrados a la cultura de negocios estadounidense.
  Si a tu jefe no le gusta, puede salir muy contraproducente. En una evaluación de desempeño, es fácil que el jefe lo etiquete como insubordinación, y sería como entregarle en bandeja la evidencia que necesita.
  A veces, incluso en Estados Unidos, pedir permiso es realmente lo mejor, y más todavía si se trata de recursos.

  • Insubordinación es una palabra que corresponde al ejército. La idea de que una persona adulta pueda “insubordinarse” es ridícula.
  • También hay formas de trabajo no estadounidenses muy diversas.
    Por ejemplo, en las culturas escandinavas, la gestión suele ser bastante hands-off, y a menudo se espera que los empleados tomen muchas decisiones de manera independiente o consultándose entre ellos.
  • De los jefes que he tenido, casi ninguno habría detestado este método. Claro, suponiendo que lo que se pretende hacer no sea una estupidez.
    Pero todos esos jefes estaban profundamente impregnados de cultura estadounidense.
  • Si la toma de decisiones independiente se considera insubordinación, me pregunto cómo delega ese gerente y cómo funciona el trabajo en la sociedad en general.
    Incluso la toma de decisiones militar efectiva depende en gran medida de que las unidades en el terreno puedan adaptarse sin llamar al cuartel general cada vez.
  • En una empresa no estadounidense donde el jefe de verdad tiene vida y no trabaja los fines de semana, o incluso se toma días o semanas libres, este método podría no funcionar.

• A esto lo llamo crear valores predeterminados razonables.
  En lugar de exigir que la gente tome decisiones sobre cada detalle, consiste en definir un conjunto de valores predeterminados razonables que demuestren que entiendes la situación y avisar que avanzarás con ellos.
  Así se construye confianza, y cuando realmente se necesita atención, la gente presta más atención, porque sabe que normalmente no le haces perder el tiempo.

  • Me gusta el encuadre de “valores predeterminados”. Deja espacio para propuestas y cambios.

• Esta forma de comunicación es buena, pero no me convence la parte de la fecha límite.
  Si un subordinado está haciendo algo sobre lo que yo podría ejercer veto, basta con que me avise. Puede que yo tenga más contexto y juzgue que eso es una pérdida de tiempo o que no es una prioridad.
  Ponerle una fecha límite al gerente es raro y suena como una amenaza sutilmente irritante.
  Me gustaría pensar que, para algo menor como un GitHub Action, le di al miembro del equipo suficiente autonomía como para decidirlo por su cuenta.

  • Una forma de pedir el no como “avísame si no debería avanzar” es realmente buena.
    Pero agregar “lo haré en esta fecha, salvo que digas lo contrario” se siente un poco agresivo.
    Incluso si solo se menciona el momento del trabajo y se deja en algo como “creo que lo terminaré para entonces”, se puede dar margen a que la otra persona considere que es mejor no avanzar.
    Aun así, desde hace tiempo el objetivo era ser más firme. Encogerse no alcanza.
  • Si no dices cuándo vas a hacer el trabajo, ¿cómo sabe la otra persona si dijo que no o no?
    Si crees que un día es suficiente y avanzas, pero la otra persona responde dos días después, ya habrás hecho algo en contra de sus instrucciones.
    Incluir una fecha evita eso: “El miércoles (26) migraré el sistema de build. Si hay alguna preocupación, avísenme”.
  • Fue un error que el texto lo llamara fecha límite.
    Lo entendí recién después de leer los ejemplos; en realidad no es una fecha límite, sino más bien una fecha prevista de trabajo.
  • Una fecha límite para la propia acción también puede ser una cortesía.
    Porque le informa a la otra persona el periodo de aviso y permite que alguien que lea un correo antiguo más tarde juzgue si todavía es relevante.
  • Ponerle una fecha límite a algo que todavía es solo una idea es raro y agresivo.
    Normalmente, una fecha límite significa “ya se decidió hacerlo y ya se recibió aprobación o acuerdo, así que ahora se informa la ejecución”.

• Parte del truco de “haré esto a menos que me digan lo contrario” está en no formularlo como pregunta, para reducir el costo de comunicación.
  Así, la persona que lo recibe no necesita responder, y ni yo ni las personas en copia tenemos que leer correos adicionales.
  En ese sentido, me gusta la función de poder poner un pulgar arriba para indicar que lo leíste y estás de acuerdo, como las reacciones con emojis en GitHub o Google Docs. Curiosamente, en algunas partes de HN no es muy popular, pero es una forma ligera de comunicarse que evita tener que pasar por el trámite de escribir un comentario como “¡me parece bien, tiene sentido!” cada vez. Es similar a un upvote.