Ownership: El superpoder invisible

¿Sabes qué? Esta semana he estado pensando mucho en esas frases que todos hemos escuchado (o peor, dicho) alguna vez:

• "En mi máquina funcionaba"
• "Yo solo hice lo que decía el ticket"
• "Ese no es mi problema"

Y me he dado cuenta de que todas tienen algo en común: reflejan una falta de ownership. Ese superpoder invisible que marca la diferencia entre ser un desarrollador más y ser alguien que realmente construye producto.

¿Por qué te cuento esto?

Porque el ownership es, probablemente, la habilidad que más busco cuando estoy valorando equipos. No es la más técnica, ni la más llamativa, pero sí la más importante.

Como decía Simon Sinek: "Contrata por la actitud, porque las skills se pueden enseñar". Y es completamente cierto. Puedes tener gaps técnicos, puedes no dominar ese framework de moda, pero si tienes la actitud correcta, si te importa de verdad lo que haces, el resto viene solo.

¿Qué significa realmente tener ownership?

No es hacer más trabajo. Es trabajar con más impacto. Es pasar de ser un cocinero que ejecuta recetas a ser un chef que se preocupa porque cada plato llegue perfecto al cliente.

Tres cosas que puedes hacer hoy mismo

1. Entiende el "por qué"

Antes de escribir una línea de código, pregúntate: ¿qué problema resuelve esto? ¿Para quién? ¿Cómo mediremos si funciona? Cuando entiendes el contexto, tomas mejores decisiones y hasta puedes proponer soluciones mejores.

2. Sigue tu feature hasta producción (y más allá)

No te desentiendas después del merge. Pruébalo tú mismo en producción, mira las métricas, asegúrate de que no hay errores. Sé el primero en enterarte si algo va mal.

3. Aplica la regla del Boy Scout

Deja el código mejor de como lo encontraste. Siempre. Si ves algo que puedes mejorar en 5 minutos, hazlo. El próximo desarrollador (que podrías ser tú mismo en 6 meses) te lo agradecerá.

La verdad incómoda

Si algo tarda 5 minutos en arreglarse, no digas "ese no es mi problema". Arréglalo. La mentalidad de ownership no solo te hace mejor profesional, te hace más valioso para cualquier equipo.

Y lo mejor de todo: hace tu trabajo más satisfactorio. Porque al final, lo más gratificante de nuestro oficio es ver cómo lo que creamos impacta en la vida de las personas.

¿Y tú qué opinas?

Me encantaría saber: ¿te has encontrado con situaciones donde el ownership (o la falta de él) marcó la diferencia? Compártelo en redes, me leo todos y me encanta conocer vuestras historias.

PD: He publicado en YouTube la segunda parte de esto, pero aplicado al código. Vamos a ver ejemplos concretos de cómo se nota el ownership en la práctica. No te lo pierdas.