Comunicación efectiva con ingenieros de software
Introducimos 11 consejos que te permitirán tener una comunicación más fluida con tu equipo de ingeniería y diseñar mejores productos.
Si tuviera que destacar una cualidad que puede influir en el éxito o fracaso de un Product Manager, comunicarse efectivamente con tu equipo de ingeniería estaría muy alto en mi lista.
En el artículo de hoy veremos algunos consejos que he ido aprendiendo a lo largo de mi carrera y que creo que os pueden ser útiles para que esa relación sea fluida.
¿Interesados? ¡Pues vamos a ello!
Entiende tu posición
El primer paso para comunicarte efectivamente con tu equipo de ingeniería es entender tu posición como Product Manager. Los ingenieros no trabajan para ti, trabajan contigo.
Ingeniería no está ahí para ejecutar tus órdenes ciegamente. Está ahí para idear e implementar las mejores soluciones posibles a los problemas y oportunidades que les presentes.
Eres un guía, no un capataz.
Entiende su situación
Tus ingenieros tienen sus propios problemas, aspiraciones y miedos. Siéntate con ellos en conjunto e individualmente, y esfuérzate por conocerlos y crear un vínculo con ellos.
La información que saques de esa relación te ayudará muchísimo a entender el nivel de madurez del equipo, lo que en cierto modo definirá cómo debes interactuar y dónde podrás enfocar tu tiempo.
Por ejemplo, con un equipo junior, es probable que tengas que dedicar más tiempo del deseable en la parte de ejecución. En contraposición, un equipo sénior es perfectamente capaz de organizarse por sí mismo, lo que te debería liberar para centrarte en la parte más estratégica.
Empieza por el problema
Este probablemente sea el punto más importante de todo el artículo. A los equipos de ingeniería no se les presenta una solución a implementar, se les presenta un problema a resolver.
Los mejores ingenieros no van a aceptar nunca implementar una solución en la que no han participado definiéndola. Los ingenieros que lo hacen suelen estar en consultoras, no en empresas de producto. Y si les tratas como en una consultora, pronto dejarán de ser tus ingenieros.
Haz tus deberes
Tu misión como Product Manager es entender íntimamente el problema de forma que se lo puedas trasladar al equipo como si lo sufrieras tú mismo.
Haz tus deberes. Documéntate con información cualitativa y cuantitativa. Los ingenieros tienen un sexto sentido para detectar bullshit a kilómetros. Si huelen que no entiendes realmente el problema, perderás su confianza y su implicación en la iniciativa.
Explica el por qué
Carl Braun era un ingeniero que a principios del siglo 20 levantó una empresa con más de 6000 trabajadores. En un post de Farnam Street, Carl Braun on communicating like a grown-up, leemos que te podía despedir en el acto si descubría que habías dado una orden sin explicar el por qué.
Empezar por el problema no es suficiente, tu equipo también tiene que entender la razón que te lleva a querer solucionar este en concreto y no cualquier otro. Tienes que demostrarles cómo resolver este problema encaja con la visión y la estrategia de la compañía.
Tu equipo hará un mejor trabajo cuánto más crean en la misma. Asegúrate de poder argumentar tu decisión y crear una narrativa inspiradora.
Define el éxito
Tus ingenieros quieren saber si su trabajo tiene impacto en la organización. Un olor muy grande de que están trabajando en modo consultora en lugar de como ingenieros de producto es cuando no se define cómo medir el éxito de una iniciativa.
El éxito no se mide en puntos de historia que el equipo logra sacar cada sprint, ni en el número de funcionalidades que salen por la puerta. El éxito se mide en mover la aguja de las métricas que de verdad importan al negocio.
Si no comunicas obsesivamente la importancia de estas y no logras que tu equipo esté interesado por las mismas, estás perdiendo gran parte de su valor.
Involúcralos temprano
Invita a tus ingenieros a fases del discovery que les puedan ser útiles para entender el problema a resolver. Manténles al tanto de tus ideas y escucha sus opiniones al respecto.
Si la primera vez que tus ingenieros descubren una iniciativa es cuando ya está definida al 100% no estás haciendo un buen trabajo. Cuánto antes les involucres en el problema, más fácil les será después construir la mejor solución posible.
No les aisles del mundo exterior
Existe la creencia de que parte de tu trabajo como Product Manager es proteger a tu equipo de influencias exteriores. No lo es.
Facilita reuniones con los stakeholders implicados en la iniciativa para que el equipo pueda hacer el mejor trabajo posible. Evita convertirte en el cuello de botella por el que tiene que pasar todo.
Si un ingeniero necesita hablar con User Research, que lo haga. Si un miembro de la organización interesada en la iniciativa quiere hablar con un ingeniero que está trabajando en una parte del problema, que lo haga.
Si has hecho bien tu trabajo de explicar el problema y por qué es importante resolverlo, tu equipo debería ser capaz de gestionarse por sí sólo y decidir qué reuniones son importantes y cuáles no. Intervén únicamente si ellos te lo piden.
Respeta su tiempo
Al igual que tú, los ingenieros necesitan largos periodos de trabajo ininterrumpido para ser efectivos. No les interrumpas si no es estrictamente necesario.
Si trabajas en un entorno Agile lo más seguro es que cada día tengáis un daily meeting en el que os reunís y os ponéis al día. Raro será que traigas algo tan urgente que no pueda esperar al día siguiente para ser discutido.
Del mismo modo, no pongas reuniones de una hora para otra salvo que sea para atacar algún fuego. Esto es un olor fuerte de improvisación y de no saber muy bien qué estás haciendo.
Aprovecha ese tiempo para pensar si realmente tiene sentido molestar al equipo. Muchas veces este tipo de reuniones vienen porque el directivo de turno ha tenido una idea feliz y quieres ser proactivo respondiéndola. Tu trabajo no es hacer felices a los directivos, es hacer que el trabajo del equipo impacte en el negocio.
No les ocultes nada
En ocasiones los planes se tuercen y no salen como nos gustarían. Cuando eso sucede podemos tener el impulso de tratar de endulzar la situación y tratar de proteger al equipo por querer mantener la motivación alta.
Mi postura al respecto con esto es que la gente no es idiota y son perfectamente capaces de intuir cuando algo no va bien. Si tu equipo lo percibe pero tú haces como que no pasa nada, perderás su confianza.
Sé humilde
Recuerda, tus ingenieros no trabajan para ti, trabajan contigo. Escucha atentamente sus opiniones y considera su punto de vista.
Partes con la ventaja de que has podido dedicar mucho más tiempo al problema que ellos, pero eso no te da poder para descartar sus ideas automáticamente. Además, tu equipo tiene mucho más contexto de cómo funciona internamente tu aplicación y las cosas que son posibles y las que no.
Escucha, procesa la información, y argumenta por qué una idea puede o no puede funcionar. Todo el tiempo que pierdas escuchando al equipo y respondiendo sus dudas es un tiempo bien invertido.
Conclusiones
Aprender a comunicarse efectivamente con tu equipo de ingeniería es sin duda una de las habilidades a las que más provecho sacarás en tu carrera como Product Manager.
En el artículo de hoy hemos visto hasta 11 consejos distintos que puedes aplicar para engrasar esta comunicación:
Entiende tu posición
Entiende su situación
Empieza por el problema
Haz tus deberes
Explica el por qué
Define el éxito
Involúcralos temprano
No les aisles del mundo exterior
Respeta su tiempo
No les ocultes nada
Sé humilde
Y no sólo con ingenieros de software. Todos los consejos son aplicables para relacionarte con cualquier otro miembro del equipo de producto o de la organización.
A partir de aquí, en tu mano está aplicarlos para tener éxito o ignorarlos y sufrir las consecuencias. ¡Tú decides!
🙌 ¡Comparte!
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes contribuir a que esta lista llegue a más gente compartiendo directamente en Twitter o LinkedIn.
Muchísimas gracias de antemano, Simón.
Muy buen artículo Simón. Lo recomendaré a mis alumnos de los cursos Professional Scrum Product Owner.
Excelente artículo Simón, gracias por escribirlo!