Bueno, ahora que ya finalmente chapé Ser data-driven no es de guapas para la Bilbostack 2024, me he tomao algunos findes de no escribir.

De no escribir “ocio”, porque bien que le he tirao al currito*. Es que si no, no hay manera de pensar. Como dicen en 📖 Peopleware 3rd Edition:

Transclude of 📖-Peopleware-3rd-Edition#^faf0b2

Y aunque me han metido en otro marrón, la J On the Beach

…afortunadamente aquí vamos apoquinando y solo hablo 10 minutiques. Me puedo permitir la Patchwork.

Esta patchwork, más que una patchwork es una reflexión.

Lo sabe el Señor, que una de las cosas que más negro me pueden poner en este mundo, es el tener disfunciones dolorosas en el seno de una compañía y no hacer nada con ellas “por defecto”. Es decir, que no es que se haya dicho en algún momento: “sí, esto no nos está yendo bien pero, por el motivo X, lo dejamos estar”. Me pone negro sobre todo porque esto suele pasar por tres motivos:

Esto último es algo que hubiera sumado a esa naturaleza humana que nos hace la puñeta de la que hablaba en Ser data-driven no es de guapas: no tomamos decisiones porque no aceptamos la finitud de la vida. Tomar decisiones es aceptar la mayoría de veces que cualquier alternativa es un compromiso, con unas ventajas, y unos inconvenientes. Es curioso porque no tomar ninguna decisión (cuando esto no es una decisión tomada conscientemente… porque paradójicamente se puede decidir no tomar una decisión), tiene normalmente muchos más inconvenientes… pero no te enfrentas a la pregunta de qué es importante para ti.

No nos gusta responder a esa pregunta porque enseguida nos damos cuenta de que se pueden hacer bastante menos cosas que las se quieren. Como explica Oliver Burkeman en 📖 Four Thousand Weeks:

Everything is important:

Link to original

Perhaps you’re familiar with the extraordinarily irritating parable of the rocks in the jar, which was first inflicted upon the world in Stephen Covey’s 1994 book, First Things First (…) The real problem of time management today, though, isn’t that we’re bad at prioritizing the big rocks. It’s that there are too many rocks—and most of them are never making it anywhere near that jar (p. 49).

Link to original

¿Qué puede hacer uno cuando está en to mitad de uno de esos flujos rotos? Hacer el curro de:

  • Poner sobre la mesa el problema, por qué hay que solucionarlo ahora, las alternativas que hay con PROs y CONs, y proponer cuál es el curso correcto de acción (esto a mi gente le sonará muchísimo, porque cada documento que pido tiene alguna variación de esto. Por ejemplo, las RFCs).
  • Pedirle a quien le corresponda decidir que, por favor, decida. Insistentemente.

El primer punto es bastante sencillo**, pero el segundo requiere…

  • toda la asertividad del planeta Tierra.
  • buena reputación (dentro de la empresa y… si la cosa se tuerce, fuera). Porque lo malo de las decisiones de este tipo es que no suelen gustar a todo el mundo. De nuevo, de 📖 Extreme Programming Explained:

    The Theory of Constraints shares with other theories of organizational change the assumption that the whole organization is focused on overall throughput, not on micro-optimization. If everyone is trying to make sure his function is not seen as the constraint, no change will happen…

    Link to original

Pero salvo que quieras vivir en un entorno con resultados mediocres (y la vida es muy corta pa eso), esto son lentejas. Hay que hacerlo.


* Esto está fatal hecho, la verdad. No lo hagáis. Abajo el capitalismo.

** Por desgracia, parece que no es sencillo, porque se escribe poco. Y se escribe poco en general porque se percibe poco valor. Y se percibe poco valor porque LaGente™️ tiene, en general, una capacidad muy (MUY) baja para estructurar el pensamiento y por ende también para expresarse correctamente por escrito (son una misma cosa: Writing is thinking) y en ese caso escribir (y leer) no aporta. Y vuelta a empezar. Esto lo toqué un poco en ✍️ Extreme Programming for writers.

Related: Stop buying handhelds and play some games!