Trust and Location

The problem of deciding where the operational processes of any production model should happen is a classical one. From guilds to mass production, the analysis has been deeply studied for physical processes for decades but, for information society, specially about information technologies, we must admit that we have not yet reached the same level of science maturity.

Why am I stating this? The process of software development not only has exposed this situation, but it is continuously experiencing the most intense effects of the same problem. As long as the development process does not require to be located in the same location as the physical resources used, the developers might fulfil their tasks at any place.

But this is only one side of the coin: the specific characteristic of the task is that it is a highly intellectual activity. As such, it is very difficult to subject it to procedures and operational rules. And consequently, it is incredibly hard to manage this sort of development, not to mention managing a whole bunch of developers trying to work together.

All of these thoughts came to my mind while reading "Remote", the book from Jason Fried and David Heinemeier Hansson, founders of 37signals. In their book, they review the culture and disciplines which have allowed them to deal with a wildly distributed workforce all over the globe to develop their products.

While I was reading it, another book plenty of savoir faire about software development came to my mind: "Peopleware", from Tom DeMarco and Timothy Lister. A timeless classic indeed that I revisited time to time.

Both writings agree on the key of software management: trust. Without trust, there will not be empowered teams, nor outstanding performance, nor amazing agility to face the unexpected. And, of course, neither effective nor efficient distributed teams management, either.

Another common point they both discussed, with its own perspective each of them, its the environment where work takes place. In the case of "Peopleware", they analyzed how layout, furniture, open space and natural light impact on the performance and motivation of people. In "Remote", the analysis brings in the pros and cons of working at home.

But I think there might be a intense debate between the authors of both books about a very specific point: the social nature of software development activity. DeMarco and Lister remark this factor all over the text, although not expressing it directly. In the case of Fried and Heinemeier, they don't reject such important characteristic but, as they deal with it in a very distributed, very-low-frequency personal contact scenario, they use other type of mechanisms to keep the team together.

My 5 cents: to be effective and efficient, a setting as described by "Remote" require a minimum level of maturity from all members, both at professional and at personal level. Maybe you have hired young and talented people to boast your projects but, if they are highly physically distributed, much will relay on their personal traits and goodwill to keep rowing in the same direction, dealing with conflicts and stress under a continuous lack of reinforcing communication.

In a scenario which combines very different kinds of people (age, gender, education, experience, personalities... maturity), a physically closer setting, with much less dispersion, would be very helpful to any manager. And the more roomy, lit, free-configured the layout, the better.

I had once a team leader working in a very complex project, with a tight schedule (kind of perfect storm), but counting on a bunch of incredibly talented, very young people. It was the case that this leader was a serial smoker, and he needed to go out of the building frequently to indulge himself. He took advantage of this short periods of time to have casual chats with different members of his team undergoing through tough obstacles. He even used this informal meetings to deal with harsh conflicts between people. And much was obtained through these off-line chats than with dozens of formal reviews or follow-up meetings. Nothing similar might have happened in the case of highly distributed people working together.

Transform and Transcend, by Johan Galtung, and conflict resolution in the intranet arena

Everytime I was taugh or I read about negotiation and conflict resolution, I felt that something was missing. If everybody already knew the same preparation tasks, the same tactics, the same technics to evaluate inputs and outputs, that would mean that the result of the process would always depend on other factors, just precisely what training programs, books and methodologies were not able to teach. This feeling was even more intense when I studied game theory, the branch of mathematics regarding these kind of problems: although highly useful, I though that the most intense and hard conflicts couldn't depend on maximin-minimax tables or Nash equilibria to be resolved.

And here it comes: by pure serendipity (a visit to the Peace Nobel Price Museum in Oslo) I found this book, written by an infatigable conflict fighter who have been involved in many of the most difficult conflicts in the recent history: John Galtung. I was completely attracted by the starting point of the book: there are conflicts that can't be solved. Here you go. Several hundred pages from this point disgressing about conflicts. Wow. What could follow next? What was the whole book about, then?

Here's the catch: there are always conflicts that can't be solved in their own terms, in the terms that the contends have used to set them up at least. These settings have to be transformed in their terms, and transcend in their objectives. Otherwise, you are bound to reach a draw, no matter how hard you try. And a draw is not an option in the most severe cases, wiht human lives at stake.

And if this is not an interesting enough starting point, Galtung take us on a journey in which we are going to see how these kind of conflicts appear in every scale of life: from marriage life, to clash of civilizations. And in every case, independtly of complexity or amount of resources involved, there is only one path to take: transform the conflict. And once transformed, transcend it, because a new range of previously not seen possibilities have been opened to everyone involved.

It's easy to make jokes about some of the examples, taking into account that several of them are very close to my circumstances. The "bullfighter" parabola to describe how Spanish people, mainly Castillian and Basque, behave in conflict situations, are, at some point, hilarious. But, as I can consider myself part of the "problem", maybe I am not entitled to ponder this point without bias.

The applicability of this methodology in innovation processes in organizations is direct and clear. We face position-based negotiations everyday, and people and departments which are to be transformed, commonly reluctant to change, have a huge amount of *arguments* against the need to evolve. The lesson learned here is that, unless your transform the terms of the conflict, and transced it, you will lost the opprotunity to change your organization crushed under a heap of common-sense day-to-day business-as-usual reasons. And how do you transform it? Although you can use the technics described in this book, the solution is always case-specific.

For example: in our project, we have been facing a lot of pressure from Internal Communications department to increase the size of the widget devoted to corporate news, although it implies that our desktop concept would be distorted to a unrecognisable point. What was the true reason to press for this? Fight for pixels? Hunger for protagonism? In fact, there was a completely understandble requirement: as long as its mandate is to reach employees to get them know about corporate news, the only way they have found to improve the hit-ratio was the common practice in traditional webs: more page space to attract more clicks on news!

Once we really got to the root of the problem, we were ready to transform the conflict and transcend, because this offered us new possibilities. For example, we got rid of tabs inside the desktops, using web browser ones instead. And if this was not enough to give them more page space to news, we proposed them to give a bigger protagonism to image and lesser to text, which provokes a more intense call-to-action effect.

Coming back to the book, I have to admit that I've enjoyed this reading a lot and it was a really useful lesson in a very special period of my life... and a lifelong lesson indeed, professional and personally speaking.