A Voluntarily Loosely Organized Organization

Why a loosely organized project team is more efficient than a heavily organized one

could have been another title for this note.

During this last year, my way of thinking management has definitively changed. The more I apply these concepts of unorganization, the more we progress and are efficient (and the more I experience difficulties with some of my colleagues of the management staff who consider the more organized is a team, the more efficient it is).

Let define what I mean by loosely organized organization:

First, our company claims to be proficient in J2EE web applications and Eclipse applications solutions. This implies strong skills, improved everyday, and that a pool of experienced software engineers are accustomed to digging around for new technologies, evaluate them and choose using them or not. In other words, our engineers are autonomous - this is a strong criteria for hiring here.

The "revolutionary" idea (I don't feel it so revolutionary but natural to me actually) is that the same way guys are able to choose a technology, they are able to choose the tools they want to work with (machines, software, frameworks, etc.), the right methods, the place/role they can take in a project, the people they have to communicate with, the tasks they have to plan. And if they experience difficulty to do it, the manager (well, me) is here to help everyone who asks.

The historical way of managing technical people that was applied to our engineers in a first step - my observation applies to French big companies and IT companies - can be roughly summed up into:

• defining methods (telling guys how to do things)
• defining roles (telling guys what is their place, and stay in their shoes)
  
• defining tasks (granularity depending on experience, but project leader defining more precise tasks for less experienced guys)
• defining tools and services developers need
  
• defining people developers will communicate with (either clients or people of our company like experts)

If this model perfectly fits corporate developers needs, providing them an reassuring environment, it also totally prevents them from any creativity and natural talent expression. Not completely saying that some companies/people found any interest in maintaining people creativity under control, I only notice that this way of management is the most current.

As we hire guys for their proficiency, their talent, their autonomy, their creativity and their accomplishment potential, I've made the bet to manage projects in such an unorganized way.


To sum up, every developer has to:

• find their natural place in the project, which may change during the project (or ask for some help)
  
• know what to do (or ask for some help)
  
• choose the right tools (or ask for some help)
  
• use the right methodology (or ask for some help)
  
• know time constraints and other constraints (or ask for some help; I use to remind everybody constraints periodically)
• help others folks

And my job is mainly to provide help in these domains, and take care of more long-term goals and constraints. Note that in our organization, any guy saying "I dont know what to do" without having asked any help before, has a problem. In a more conventional organization, it would denote a lack of management.

To conclude, I admit this model works because guys are autonomous, talented and motivated. As a result, everybody stay motivated and is free to organize his work, and find his place in the project. And everybody improve very fast (including me! ).

Ho, and yes, we are hiring ! (Java, Java, Java, XML, and web applications/semantic web/distributed computing/rule engines appreciated - based in Toulouse, France)