3 mentiras que tu equipo tecnológico te cuenta (y se cuentan a sí mismos)

Cada una de estas es una mentira que tu equipo tecnológico te dice—a ti y a ellos mismos. Estas ideas erróneas tan comunes surgen de un error fundamental endémico entre los ingenieros: la creencia en lo “mejor”.

Mejor no es mejor (para todos)

Dentro de una computadora, es la tierra de los unos y ceros. No hay duda ni incertidumbre sobre la aritmética y las compuertas lógicas, y salvo por algún que otro rayo cósmico, la máquina es completamente determinista, siguiendo el mismo camino una y otra vez cada vez que le das las mismas entradas. 

Incluso la aparente aleatoriedad en los juegos o simulaciones es en realidad una ilusión. Si proporcionas una “semilla seudoaleatoria” específica a, por ejemplo, Minecraft, obtendrás exactamente el mismo comportamiento en cada partida. Es útil recordar que cada miembro de tu equipo de TI eligió una profesión que involucra este nivel de certeza y previsibilidad; literalmente es imposible hacer su trabajo sin razonar de forma rigurosa desde los primeros principios.

Pero fuera de lo computacional, encontramos a seres humanos impredecibles, y todo cambia. Ningún equipo de ventas consideraría siquiera usar la misma presentación o discurso para cada cliente potencial, y cada llamada de servicio al cliente es diferente y sorprendente. Los guiones y la formación ayudan a tu personal a lograr consistencia, claro, pero es fundamental variar el enfoque según cada situación, como tantas organizaciones descubrieron cuando intentaron adoptar la holocracia o los métodos Lean para imitar el éxito de Zappos y Toyota y fracasaron estrepitosamente.

Esto es igual de cierto al construir software que en operaciones, finanzas o estrategia: no existe un único camino correcto para diseñar una pantalla de inicio de sesión, crear un informe o descubrir qué funciones están dispuestos a pagar los clientes. Por eso los ingenieros han ideado tal variedad de metodologías de software, como Scrum, Kanban, ShapeUp, el modelo de Spotify, SAfE y otros cientos, todos exitosos en ciertos casos y desastrosos en otros.

Ahora puedes ver por qué nosotros, los técnicos, caemos en la trampa del "mejorismo". A cualquiera de nosotros le resultaría atractiva la idea de creer que existe una tabla de piedra con la respuesta a nuestros problemas grabada en ella, pero la certeza es peligrosamente seductora cuando todos los días trabajas con herramientas y máquinas cuyo funcionamiento depende de la consistencia absoluta. ¿Pero cómo romper el hábito del pensamiento binario?

Primero, cuestiona sin descanso

Para tantos de nosotros, la tecnología es solo magia negra. Los ingenieros murmuran extrañas fórmulas sobre Kubernetes y zettabytes y, de la nada, aparecen sitios web, correos electrónicos y pagos con tarjeta de crédito. Así que, cuando los hechiceros nos dicen con autoridad que siguen las “mejores prácticas”, ¿quiénes somos nosotros para dudarlo?

¡La respuesta eres TÚ! Al igual que cualquier otro miembro del equipo, los desarrolladores de software necesitan retroalimentación sobre si sus planes y entregas están alineados con la estrategia de la empresa. No necesitas utilizar jerga técnica para dar tus reacciones y orientación; es su trabajo aprender lo suficiente sobre tu mercado y tus objetivos para rendirte cuentas de forma efectiva usando español estándar. No tengas miedo de preguntar cualquier cosa sobre en qué están priorizando, los motivos para elegir tal o cual tecnología, y especialmente cómo esperan que el resto del negocio se beneficie. 

Creo tan firmemente en hacer preguntas que incluso imprimí certificados lujosos con pan de oro que otorgan permiso oficial para preguntar a los ingenieros sobre cualquier tema, y los entrego cada vez que puedo. Abajo tienes un ejemplo. Si quieres uno para colgar en tu pared, mándame un correo y te enviaré uno (¡gratis!) 

Después, juega al juego del por qué

Una vez hayas superado el miedo a preguntar y aprendido más sobre el enfoque del equipo tecnológico, es momento de jugar al juego del “por qué”. Las reglas son simples y familiares para cualquier niño de cinco años: primero preguntas qué está haciendo un desarrollador, luego preguntas “por qué” repetidamente. 

“Estoy reemplazando nuestra página de pagos.”

“¿Por qué?”

"Porque es ineficiente.”

“¿Por qué es ineficiente?”

“Hacemos comprobaciones innecesarias que ralentizan nuestro tiempo de respuesta.”

“¿Por qué importa la velocidad?”

"Porque los usuarios abandonan cuando tienen que esperar demasiado para pagar.”

La señal para detenerse es cuando llegas al dinero. Una vez que escuchas: “porque aumentará las conversiones”, “porque más clientes actualizarán” o “porque reduciremos los costos de investigación”, has ganado. Si nunca llegas ahí y terminas con “No lo sé” o “porque lo dijo Jane,” tú (no el ingeniero) has perdido el juego del 'por qué'. Busca formas de conectar mucho más a tu equipo técnico con los resultados del negocio para que la próxima vez todos sean ganadores cuando jueguen nuevamente.

Después de algunas rondas de Por qués, empezarás a ver patrones y vacíos. Por ejemplo, trabajé con un equipo que estaba absolutamente enfocado en aumentar su tasa de conversión pero ignoraba totalmente los costos. No es de sorprender que se pasaran mucho del presupuesto con estrategias de anuncios sociales hiperoptimizadas que eran demasiado complejas para una sencilla campaña navideña.

Claro, sus algoritmos sofisticados eran “mejores” para conseguir pequeñas ventajas de precio en ciertas palabras clave, pero la factura de Facebook fue un baño de realidad cuando llegó (¡incluyendo cargos por llegar a tumbar algunos servidores de anuncios de facebook.com con demasiadas solicitudes!). Cuando veas estos puntos ciegos, corrige las prioridades, cancela lo innecesario y refuerza el mensaje de que la tecnología debe estar estrechamente alineada con los objetivos de negocio.

Por último, garantiza la responsabilidad

Ahora que has encontrado y eliminado las soluciones tecnológicas “mejores” que en realidad no están funcionando para ti, ofrece maneras sencillas para que los ingenieros te demuestren que siguen alineados y avanzando en la dirección correcta. Observa que no he dicho nada sobre “responsabilizar al equipo técnico”, un enfoque acusatorio que siempre me hace querer esconderme bajo el escritorio más cercano. En cambio, habilita a tus desarrolladores para que sean responsables contigo. Por ejemplo,

• Programa una demostración semanal de las mejoras en IT, donde los líderes del equipo describan los beneficios para el negocio y recojan comentarios de tu parte y de otros.
• Configura un panel que muestre métricas importantes como el tiempo en línea del sistema o llamadas respondidas, y pide a los desarrolladores que expliquen con frecuencia cómo sus acciones mejoran los resultados.
• Crea una hoja de ruta para hacer un seguimiento del avance en proyectos clave y para recuperarse rápidamente cuando se retrasen elementos importantes.

Una estrategia clara de retroalimentación frecuente y un enfoque en verdaderos beneficios tangibles para el negocio asegurarán que tu inversión en IT no se desperdicie en proyectos “mejores” ingeniosos pero inútiles. Y si tú, como la mayoría de las empresas con las que trabajo, estás gastando millones en tecnología con resultados poco claros en el mejor de los casos, ¿acaso no vale la pena medir el retorno de esa enorme inversión?

Suscríbete al boletín de The CTO Club para más consejos de nuestra comunidad.