Es conocida la frase con la que a Michael Jordan le gustaba resumir la importancia de jugar en equipo.
Talent wins games, but teamwork and intelligence wins championships.
Trabajar en equipo forma parte de la mayoría de nuestras actividades. Y conseguir hacerlo bien es una tarea en sí misma. Algunos oficios, como el baloncesto de Jordan, han incorporado el problema desde hace mucho tiempo y, por lo tanto, lo tratan como un aspecto más que tienen que desarrollar y mejorar. Es fácil echar un vistazo a otros muchos oficios, profesiones e industrias -construcción, hostelería, cine, etc.- y reconocer en ellos patrones específicos para resolver el problema.
Es algo, además, histórico. Como en casi todo, no hemos inventado nada al respecto: hemos continuado toda una serie de esfuerzos cuyo origen es nuestro mismo origen como especie. Hace unos meses, Richard Barber publicó un precioso libro, The Prince in Splendour: Court Festivals of Medieval Europe, explicándonos toda la complejidad y el trabajo en equipo que se requerían para celebrar un festejo en la edad media. En un ejercicio anacrónico pero fértil, nos pide imaginar los retos a los que se enfrentaban entonces.
Imagine that you are a master chef, working for a celebrity who wants to throw a wedding dinner for their daughter, with 200–300 guests. Next imagine that you have no electricity — no refrigerators, no freezers, no light — and no gas. Your suppliers have to get everything to you fresh, and you don’t want to use salted meat for this important occasion. You are not sure exactly how much of any ingredient you will need until very close to the day. What’s more, the guests may stay on for several days. Among them there will be vegetarians or people needing special diets. To top this all off, the only transport available is horse and cart, so nothing can be brought at the last minute.
Desde un punto de vista formal, abstracto, cualquier tarea en equipo puede entenderse como el conjunto de reglas que organizan las relaciones entre distintos elementos para obtener un resultado. En 1967, Melvin Conway publicó un artículo, How Do Committees Invent?, que recogía esa propuesta formal, formulando como tesis principal la correspondencia entre ese resultado, el conjunto, y sus partes, los elementos.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Como cuenta el propio Conway, esa idea quedó posteriormente recogida en la obra clásica de Fred Brooks, The Mythical Man-Month, en lo que desde entonces se conoce como la Ley de Conway. Todo suena mejora aderezado como una ley. Brooks llamaba la atención sobre la necesidad de mantener en la organización de los equipos la misma flexibilidad que el propio sistema tenía en la organización de sus partes.
Conway goes on to point out that the organization chart will initially reflect the first system design, which is almost surely not the right one. If the system design is to be free to change, the organization must be prepared to change.
Conway, en su artículo, señalaba el mismo problema relacionado con la flexibilidad en términos de comunicación, y apuntaba a una regla de magnitud.
To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces. The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon.
Construyendo producto digital he oído con frecuencia expresiones del tipo es una empresa sin alma, el producto está bien, pero le falta alma, y cosas similares. La aportación de Conway ofrece contexto y un significado preciso para entender ese tipo de expresiones. Siguiendo el principio de homomorfismo de su ley, se puede llegar a conclusiones simples pero muy potentes, y que identifican fallos con los que solemos vivir.
1. Si la construcción del producto está dividida o fragmentada, el producto también lo estará.
2. Si la construcción del producto se hace siguiendo reglas de organización interna, el producto ofrecerá una experiencia de lo que es la organización interna, no de lo que el producto debería ser.
3. Si la construcción del producto se hace con una comunicación hacia dentro, el producto se comunicará con la gente a través de una comunicación que no puede llegar a entender bien.
Aunque son conclusiones aparentemente evidentes, vivimos constantemente en entornos donde o bien la organización de los elementos es nula, o bien responde a criterios que no están conectados con el resultado. Solemos vivir en silos de frontend y backend, de diseño y marketing, de datos y ventas. Y nuestros productos irremediablemente transmiten esa experiencia de cuevas ciegas.
Sin duda, merece la pena prestar atención a todos los aspectos que están relacionados con la organización y la comunicación del trabajo en equipo. Y considerarlos como parte fundamental del propio desarrollo del producto digital.