- Las solicitudes ambiguas de gerentes y líderes pueden parecer preguntas pequeñas, pero pueden alterar mucho el tiempo, las prioridades y la dirección de ejecución del equipo
- Expresiones como “revísalo” o “tiene que ser moderno” pueden derivar fácilmente en respuestas excesivas, como reportes, diapositivas, trabajo de fin de semana o grandes actualizaciones
- Quien hace la solicitud debe indicar también la inversión de tiempo esperada, el impacto en las prioridades, si se trata de revisar material existente o de hacer trabajo nuevo, y para qué se usará el resultado
- Quien recibe la solicitud también debe preguntar por el nivel de esfuerzo y aclarar lo que no sepa; no debe asumir que el líder está demasiado ocupado para responder
- Ser tan específico desde el inicio que resulte un poco incómodo puede reducir mucho la confusión posterior, el trabajo equivocado y el desperdicio de costos
Cómo una solicitud pequeña se convierte en un gran trabajo
- Dentro de las organizaciones, se repite la situación en la que una solicitud breve y aparentemente ligera termina convirtiéndose en un trabajo mucho más grande de lo esperado
- Hay casos en los que un gerente pregunta “¿Puedes hacer X?”, el reporte directo dedica 10 veces más tiempo de lo esperado y el gerente responde: “No quería que le dedicaras tanto tiempo”
- Una frase breve de un ejecutivo en una reunión, como “¿puedes revisar esto?”, puede terminar en 24 personas creando 4 versiones de un deck de diapositivas y trabajando hasta el fin de semana
- Y en la reunión, el ejecutivo podría ver solo el resumen de la primera frase de la primera diapositiva y decir: “No hace falta toda la presentación”
- La frase “tiene que ser moderno, sin excusas” también puede interpretarse como una gran actualización tecnológica si no se aclara su significado
- La intención real podría ser simplemente actualizar la sintaxis de la API en una versión nueva a lo largo de varios años
- Mientras tanto, el lanzamiento de proyectos importantes puede retrasarse
Lo que quien solicita debe definir primero
- Al hacer una solicitud, el líder debe indicar directamente el límite de tiempo esperado
- Ej.: “No le dediques más de 20 minutos; trae lo que tengas después de esos 20 minutos”
- También debe aclarar qué impacto debería tener en las prioridades
- Ej.: “Estimo que tomará unas 2 semanas y no debería reducir significativamente la prioridad de otros trabajos principales”
- Debe pedir que lo contacten de inmediato si el calendario real es distinto o si entra en conflicto con otras tareas
- Debe distinguir si basta con revisar materiales existentes o si hay que analizar o crear algo nuevo
- Ej.: “Solo dime si ya tenemos algo sobre este tema. Si todavía no lo hemos pensado, con saber eso basta”
- Si se indica dónde se usará el resultado, a la otra persona le resulta más fácil ajustar el nivel de esfuerzo
- Ej.: una respuesta para enviar a un prospecto de ventas, preparación para el Q&A del próximo All Hands, temas clave de la próxima junta directiva, etc.
Lo que debe verificar quien recibe la solicitud
- Quien recibe la solicitud debe hacer preguntas de aclaración
- Debe confirmar el nivel de esfuerzo, por ejemplo: “¿Esperas un resultado muy exhaustivo que requiera varias horas, o un resumen breve?”
- Hacer preguntas no te hace ver tonto; es más riesgoso no preguntar y terminar haciendo algo completamente equivocado
- En vez de pasar tiempo interpretando los correos o mensajes del líder como si fueran reliquias antiguas, es mejor confirmarlo directamente con el líder que hizo la solicitud
- Si el líder tiene tiempo para hacer la solicitud, también tiene tiempo para aclararla
1 comentarios
Opiniones de Hacker News
Lo que más detesto es cuando un líder no técnico se salta uno o dos niveles y habla directamente con personal técnico junior, en vez de hacerlo con personal técnico senior que tiene experiencia para hacer preguntas de aclaración o definir plazos y entregables.
Es un patrón que vi con frecuencia en varias organizaciones de campañas y de tecnología política.
El personal técnico junior también entiende la cadena de mando, así que si alguien la rompe, lo haya querido o no un superior, se genera confusión y un desastre.
Quien hace el trabajo físico real suele ser un ingeniero junior, y puede responder mejor ciertas preguntas que alguien que lo ve desde un nivel más alto.
Me parece que no hace falta jugar al teléfono descompuesto.
Cuando se juntan un coordinador de proyecto de un proveedor sin experiencia, técnicos del proveedor acostumbrados a que el coordinador les resuelva las cosas, y un cliente nuevo en este mundo, puede armarse una confusión bastante grande.
Sobre frases como “si no haces preguntas y terminas haciendo algo totalmente equivocado, seguro vas a quedar como un tonto” y “nunca asumas que la otra persona está demasiado ocupada para responder preguntas de aclaración durante el trabajo”, me pregunto qué conviene hacer cuando se trabaja remoto y ni siquiera hay chat en línea.
En persona es fácil lanzar muchas preguntas pequeñas, rápidas y medio improvisadas, pero el correo se siente más formal e intrusivo, así que lleva más tiempo explicar qué es lo confuso y hasta anticipar posibles respuestas.
Las videollamadas tardan en coordinarse y tienen mucho costo adicional.
En proyectos con clientes, cada vez que surge una pregunta pequeña la agrego a un Google Doc, y de vez en cuando le aviso al cliente que revise el documento o hago que se suscriba a las notificaciones de edición.
El cliente escribe las respuestas directamente en el documento y, a medida que avanza el trabajo, repetimos el proceso.
La ventaja es que el cliente no tiene que responder todo de una sola vez, hay menos notificaciones, ambas partes pueden escribir con menos formalidad, se siente colaborativo, es fácil agregar preguntas de seguimiento junto a la parte relevante, también se pueden tener breves discusiones o asignar y dar seguimiento a pequeñas tareas mediante comentarios en el documento, y es fácil que otras personas lo lean y contribuyan.
Aquí estoy pensando en situaciones donde surgen muchas preguntas pequeñas, como trabajo por contrato con clientes no técnicos que uno no conoce bien.
Otras personas no le ponen esas restricciones al correo.
Si no se lo estás enviando al CEO, puedes escribir las preguntas a medida que se te ocurren y mandarlas de inmediato.
Tampoco hay que tener miedo de mandar enseguida un segundo correo del tipo: “Ah, también se me olvidó esta pregunta. ¡Gracias! $QUESTION”.
Si ves correos de altos ejecutivos en https://twitter.com/TechEmails, la mayoría son muy informales.
Algunos correos antiguos entre Bill Gates y ejecutivos de Microsoft no están mucho más pulidos que los mensajes de texto de un estudiante de secundaria.
No digo que le mandes emojis al jefe del jefe del jefe de tu jefe, pero un correo informal y rápido no va a acabar con tu carrera.
Entiendo que a mucha gente le parezcan más pesadas, pero no sé si en realidad son más molestas para ambas partes.
Si aclarar la pregunta requiere una conversación de ida y vuelta, entonces hay que hacerla.
El método del documento compartido también es una buena idea y tiene dos ventajas adicionales.
El acto de escribir se vuelve un paso extra que ayuda a aclarar mejor la pregunta, y las preguntas y respuestas quedan documentadas para más adelante.
Ambas son ventajas importantes frente a una conversación rápida que luego habría que volver a escribir.
Puedes trasladarle la carga cognitiva a la otra persona.
Porque es mejor interrumpir una vez que varias veces al día.
Cuando recibo un issue nuevo, primero lo reviso por encima, planifico qué voy a hacer, profundizo mentalmente en posibles problemas o conflictos y a veces armo una lista enorme de preguntas; luego separo quién es más probable que responda cada una y recién entonces inicio la conversación en línea.
Dentro de una empresa, normalmente basta con pedir una videollamada breve de 5 minutos por un mensajero interno como Slack.
Si es un colega con quien trabajo de cerca, incluso lo llamo directamente sin avisar.
Con clientes externos se puede hacer algo parecido por teléfono o videollamada si se acuerda de antemano.
Por ejemplo, en la reunión de kickoff se puede definir con qué frecuencia quiere comunicarse el cliente, qué preguntas requieren comunicación inmediata y cuáles pueden resolverse con comunicación asincrónica más lenta.
El tiempo es un pésimo indicador para representar esfuerzo, sustancia y alcance.
Por ejemplo, si ves una solicitud como “revísalo solo 20 minutos y tráeme lo que tengas después de 20 minutos”, la cantidad que cada persona logra en 20 minutos varía un poco.
Incluso si ignoramos esa diferencia, no hay garantía de que el gerente que hizo la solicitud obtenga lo que necesita de esos 20 minutos de esfuerzo.
En entornos ágiles es común ver que al trabajo de descubrimiento e investigación se le llame “spike” y se le asigne un “timebox”, pero si preguntas “¿qué pasa si no encuentras lo que querías dentro de ese tiempo?”, por lo general no hay una buena respuesta.
En la práctica, el timebox se alarga hasta que se averigua lo necesario.
Por eso el tiempo es un mal proxy para el esfuerzo, la sustancia o el alcance.
Creo que es mejor el ejemplo que aparece más adelante en el texto: “¿Esperas algo muy exhaustivo que tome varias horas, o basta con un resumen rápido?”.
Porque habla del alcance del trabajo, no del tiempo que toma.
Si se mide por tiempo, no hay garantía de obtener lo que se quiere dentro de ese tiempo, y al final se termina agregando más tiempo.
La respuesta a “¿qué pasa si no encuentras lo que querías dentro de ese tiempo?” es que descubres que no se pudo encontrar la respuesta en el tiempo esperado, y ajustas las expectativas sobre el esfuerzo necesario para esta investigación.
Como gerente, esa es precisamente una de las piezas clave de información que quieres conocer.
Por eso cualquier cosa necesita un timebox si se quiere evitar que un proyecto se descarrile y termine en la basura.
También aplica al trabajo individual o en solitario.
Como uno puede quedarse enganchado con cualquier cosa para siempre, es mucho mejor forzar un punto de parada, recibir feedback o lanzar, y luego decidir si vale la pena continuar.
El mecanismo que opera aquí es obligar a las personas a priorizar.
Si eres muy bueno juzgando prioridades, quizá necesites menos timeboxes, pero incluso en ese caso, sin un timebox puede ser difícil resistir la tentación de seguir trabajando hasta una calidad superior a la necesaria.
Este patrón de trabajo es útil cuando lo que no sabes supera por mucho lo que sabes.
El objetivo es aumentar poco a poco la proporción de “lo que sabes”, hasta poder hacer una conjetura informada y no una suposición al azar.
Por ejemplo, si hay un bug en una base de código legacy, pero el sistema de reemplazo está casi terminado y se lanzará en dos meses, ¿cómo manejarías ese bug?
Podrías ignorarlo, o decirle a alguien “arréglalo cueste lo que cueste”, pero ninguna de las dos opciones es buena.
Entonces dices: “Investiga este bug, pero no más de una hora, y dime hasta dónde llegaste”.
Al terminar, entiendes mejor la forma del problema.
Si vuelve diciendo “encontré el área del problema, pero para corregirlo necesito resolverlo con alguien que conozca bien la lógica de negocio”, puedes asignar los recursos adecuados y continuar con la corrección.
Si dice “está en esta parte del código y está bastante ordenada, pero todavía no pude rastrearlo por completo”, puedes darle más tiempo basándote en la confianza de que no será una tarea gigantesca.
En cambio, si dice “está en algún lugar de este espagueti extraño; al asomarme, el abismo me devolvió la mirada, se me heló la espalda y los cuadros de la pared lloraron sangre, así que por favor no me manden de nuevo”, queda claro que no vale la pena seguir rastreándolo y puedes soltarlo.
Te creo que hayas tenido la experiencia de no obtener lo que querías dentro del tiempo y luego agregar más tiempo, pero no es universal.
El problema está en tratar “lo que se quiere” como el objetivo final en sí.
Por eso el texto también dice “di por qué lo necesitas”.
“Nuestro mayor cliente necesita saberlo antes de renovar el contrato” vale más dinero y más horas de personal que “solo tenía curiosidad”.
A nivel de liderazgo, hay que reconocer que no se pueden perseguir todos los beneficios y concentrarse estratégicamente en lo que tenga la mejor relación costo-beneficio.
No se trata simplemente de asignar una persona a una tarea, sino también de asignar el trabajo correcto a la persona con las habilidades adecuadas.
Un CEO de una startup pidió algo, y creo que la solicitud era breve, de una o dos frases.
Como resultado, terminé haciendo un informe de 14 páginas, le dediqué varias horas y la mayor parte fue en mi tiempo personal.
Le envié el informe al CEO, pero después no hubo ninguna respuesta y no pasó nada.
A partir de entonces me hice una nueva regla.
El costo de una solicitud debe ser proporcional al costo de comunicar esa solicitud.
Ahora, cuando recibo una solicitud costosa, espero, la retraso y pido que se escale.
Quien la solicita debe hacer la debida diligencia y obtener aprobación de niveles superiores para demostrar que vale la pena pagar ese costo.
Si es una solicitud basura, no volveré a oír de ella; si es valiosa, la atenderé, y además tiene la ventaja adicional de que ese esfuerzo no se hará a escondidas sin la visibilidad adecuada.
Primero, nunca hago nada ante la primera solicitud.
Si es importante, lo volverán a pedir, y entonces lo consideraré.
Segundo, si yo tengo que trabajar horas extra, la otra persona también tiene que trabajar horas extra.
Si esa persona no quiere trabajar horas extra, entonces no era tan importante.
Tras haber pasado por varios niveles en ingeniería, desde junior hasta C-level, aprendí algunas cosas
Primero, todos deben actuar de buena fe
Vi líderes que, sin pensarlo ni 5 segundos, le pedían algo impulsivamente a un subordinado directo; y también vi lo contrario: subordinados directos que solo se mueven si se les da una sintaxis exacta, como una “línea de comandos humana”
Ninguna de las dos cosas está bien
Segundo, para un gerente o líder no existen las “solicitudes puntuales”
Cualquier solicitud pasa a tener una prioridad implícita por encima de todo lo demás
Hay que moverse dentro del sistema y el contexto completos; si no, se le está pasando esa elección al equipo
Tercero, si estás del lado que recibe la solicitud, debes ayudar a quien la hace a entender qué necesita
Hay que eliminar los supuestos implícitos, porque ahí es donde se esconden los dragones
Hay que comunicar, informar, enseñar y confirmar lo que quiere quien solicita, asegurándose de que ambas partes estén de acuerdo
Estas cosas surgen por una búsqueda de eficiencia —no querer perder tiempo si no hace falta—, pero cuando solicitante y receptor intentan ayudarse mutuamente, en general la vida se vuelve mucho más llevadera
Hay una diferencia enorme entre un líder que fuerza los límites de hasta dónde puede llegar y uno que intenta construir una relación de buena fe con el equipo
Un gerente que sigue haciendo pedidos irreflexivos terminará perdiendo de forma constante a sus mejores empleados
Por experiencia, pasado suficiente tiempo, bajo ese tipo de líder solo quedan juniors, porque la gente con experiencia evita ese equipo
Un miembro del equipo tipo “línea de comandos humana” también es un buen ejemplo de alguien que actúa de mala fe
He trabajado con personas que exigían completar algún formulario o documento que ellas mismas habían creado antes de poder empezar incluso con una solicitud mínima, y que solo después de días de discusión, críticas o circulación del tema se ponían a pensar en una tarea pequeña
Creen que se protegieron de las solicitudes pequeñas haciendo que nadie quiera tomarse el trabajo de formular la pregunta con precisión, pero con el tiempo se ganan la reputación de ser difíciles para trabajar
Otra variante es la gente que explota la ambigüedad de todas las solicitudes
Aunque en general saben qué se les pidió, entregan algo que coincide literalmente con la solicitud para “dar una lección”, pero que saben que no es lo que todos necesitaban o querían
No por casualidad, la mayoría de las personas que jugaban a esos juegos fueron despedidas en el último año
La gente puede tolerar durante un tiempo a un mal compañero que hace cierto trabajo, pero cuando hay recortes, queda al principio de la lista de candidatos a eliminar
Hace un mes me di cuenta de una falla que estaba cometiendo como líder
En apariencia, mi intención era darle ownership al equipo, y volcaba muchas cosas que había que hacer, pero en realidad le estaba trasladando al equipo el estrés de “qué hay que hacer en este momento”
Es una trampa sutil en la que es fácil pensar “¡estoy delegando muchísimo poder al equipo!”, cuando en realidad estás estresando al equipo y reduciendo su concentración
Según el OED, la nominalización empezó en el habla coloquial australiana
https://www.oed.com/search/dictionary/?q=ask
Todos sabemos que el lenguaje es un producto cognitivo biosocial en constante cambio y que no hay reglas reales, pero cuando ya existen buenos sinónimos perfectamente válidos, este uso se siente irritante, como masticar arena
No quería que esa información determinara la decisión
Pensé que debíamos hacer lo mejor para el negocio y para los usuarios finales, no lo que fuera más fácil para mí
Pero la otra persona eligió la opción más larga y difícil, y luego resultó que en realidad quería la otra, pero pensó que sería más difícil para mí
Lo mismo pasa en la vida real
Cuando estaba haciendo nuevos gabinetes de cocina, le di a mi esposa dos opciones para el riel superior de las puertas; una era más difícil, pero no se lo dije porque quería que eligiera la que más le gustara
Obviamente eligió la más difícil, y resultó que pensó que sería más fácil y que en realidad le gustaba más la otra
Por eso siempre hay que darle a la otra persona toda la información
¿Por qué no se puede decir que una pregunta planteada por la dirección no tiene sentido?
La respuesta, por supuesto, es no contradecir la jerarquía
Pero esta obediencia jerárquica en realidad no ayuda al negocio
Parece un valor que debería ser más fácil de descartar
La pregunta “¿Esperas algo muy exhaustivo o alcanza con un resumen rápido?” da risa
Si un ingeniero le dice honestamente a alguien que no es ingeniero cuánto tarda algo, esa persona se va a sorprender y va a decir que no
Pedir “no le dediques más de 20 minutos y tráeme lo que tengas después de 20 minutos” suena a locura
No hay tareas de 20 minutos
Mejor sería decir: “no mires esto; ve por un café y cuando vuelvas dame una estimación aproximada”
Hacemos trabajo complejo y necesitamos tiempo para pensar
Si no quieres que dediquemos tiempo a pensar, simplemente no preguntes
Parte del problema es que uno no quiere decirle al jefe que se vaya al diablo, ni decirle que le dedicó 6 horas a algo que el jefe cree que toma 20 minutos
Entonces, en cambio, todo lo demás se retrasa
Por eso una buena gestión de ingeniería mantiene a los ingenieros lo más lejos posible de las personas que, sin querer, les robarían tiempo a los técnicos
Una señal típica de una gestión débil es pedir un informe o asignar una tarea cuyas implicaciones completas la propia persona no entiende.
Una señal típica de una ingeniería débil es responder “sí” a esa solicitud.
Cuando un gerente débil pide algo que se sale de lo que puede manejarse como algo trivial, la persona que hace el trabajo debe hacer una de tres cosas, según el contexto técnico y social.
A) Preguntar: “¿Cómo habría que hacerlo?”
Funciona cuando el gerente es técnico y lanza una tarea ambigua para compensar su propia incompetencia técnica.
Si le devuelves la tontería tal cual, se ve obligado a enfrentar el alcance de lo que está pidiendo y la realidad de sus mecanismos.
B) Informar: “Ese trabajo requiere X recursos. ¿Cuáles son las expectativas?”
Aquí X puede ser una enorme cantidad de horas-persona, dinero, GP de RuneScape clásico o lo que sea.
Es adecuado para gerentes no técnicos y, de forma parecida a A, los obliga a enfrentar que esto es una solicitud grande que no debe aprobarse sobre la marcha, sino pasar por el proceso normal.
C) Decir “no”.
No es posible en todas las organizaciones ni en todos los contextos sociales, pero las organizaciones de alto desempeño lo hacen posible.
En un entorno de ingeniería de alto desempeño, la organización de ingeniería tiene un poder de veto fuerte contra trabajos absurdos sin sentido, y solo puede ser revertido por la alta dirección de nivel C.
Saber cuándo y cómo ejercer ese veto también es una habilidad importante que ingeniería debe desarrollar.
Así que cualquier cosa que dijeras al respecto podía terminar empujándote hacia la puerta.
Cada vez que veo usar “ask” como sustantivo, me da comezón el sentido del lenguaje, así que busqué y encontré este texto.
https://english.stackexchange.com/questions/4246/can-or-shou...
Puede ayudar a quienes les resulte igual de molesto.
Una de las mayores pérdidas de tiempo ocurre cuando a una solicitud le falta contexto.
Parece un intento de ahorrar tiempo informando solo a quienes lo necesitan, pero el “por qué” y el contexto son realmente importantes para llegar a una buena solución.
Sin eso, no se puede saber qué cosas ya consideró la otra persona.
Por ejemplo, si alguien dice: “Tenemos que bloquear las solicitudes provenientes del país X”, eso no es difícil con la mayoría de los servicios de firewall.
Pero ¿por qué hay que hacerlo?
Si lo que se busca es dar una garantía contractual de que no habrá tráfico desde cierto país, ese enfoque no sirve, porque cualquiera puede evadir la detección de código de país en 2 minutos con una VPN.
El usuario quiere hacer X pero no sabe cómo, cree que Y va a funcionar y pide ayuda con Y, mientras los demás se confunden porque Y les parece raro.
https://xyproblem.info/
Mucha gente ya murió en esa colina, y aun así se implementó.
Mejor no convertirse en otra víctima.
Al final, depende en gran medida de la cultura de la empresa y de qué tan cómodas se sientan las personas para contradecir a líderes senior.
Esa carga recae en los líderes senior, que deben hacer que la gente de abajo se sienta cómoda cuestionándolos.
Según mi experiencia, los mejores líderes son humildes y muestran disposición a escuchar.
Dicho eso, a veces hacer trabajo inútil también es parte del empleo.
Si es demasiado, claro que puedes buscar otro trabajo, pero conviene no convertirse en alguien que siempre sospecha de la dirección y la cuestiona todo el tiempo.