Tuesday, April 21, 2009

Invert Conway's Law

...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

Or, to use active voice, since passive voice serves Satan:

Organizations which design systems can only produce designs which copy the communication structures of those organizations.

I once built a system for two groups in a corporation to automate a process. Part of the process in real life: butting heads between the two groups at every step. I could have been an idiot and designed a system which had opportunities for that legacy to persist. Instead I asked both sides to give me their point of view and created a system where both sides could get what they wanted from the other in a simple, efficient way.

The corporate politics dissipated - or I should say, those corporate politics dissipated, as the organization had plenty of similar troubles that this system didn't affect - and people found it easier to work together. People described me as a guru in the language I was using (Perl) despite the fact that I was not. Perl is a hard language to be a guru in, since in Perl, anything can mean anything. I was really only a good scripter with a strong grasp of regular expressions and a judicious sense of diplomacy. But that judicious sense of diplomacy made me a star in that company, because everybody was happy with the system.

The irony, of course, is that people gave me too much credit for my technological achievement and not enough for the diplomatic achievement. If people have come to accept that fighting with each other is as much a part of their daily life as fighting the traffic into work, making them peaceful collaborators is something to be proud of. Either way, though, if you want to see your project succeed way beyond anyone's expectations, find ways to invert Conway's Law. Think about it: what's the opposite of this statement?

Organizations which design systems can only produce designs which copy the communication structures of those organizations.

The inverse is that designing business process software gives you the ability to design business processes. If you take responsibility for that and give your users a business process which is better for everyone, people will wonder how they ever did their job without your system. That's how they're supposed to feel.

1 comment:

  1. Couldn't agree more. However, I wonder how much of the success of that project was predicated on the fact that both parties came to the table. I've been involved in projects where one or more parties didn't come to the table or didn't want/care to, and even though we did our best to build a system which enhanced the process, it ultimately failed due to lack of motivation from the parties involved.

    So, is it the contractor's job to bring people to the table, or should they already be at the table?

    Good read, thanks.


Note: Only a member of this blog may post a comment.