The Evolution of Working Practices a.k.a Managing Without Managers

Twelve or so years of formal project management have taken their toll! Before joining Osmosoft, I was mainly familiar with standard leadership protocol. Tasks and objectives were mapped out in detail and, if things weren't going well, they were micro-managed to completion.

Which is why some of the new ideas I'm being exposed to while here at Osmosoft are so refreshing. JP (my bosses' boss) talks about managing commitments rather than micro-managing people. Thanks to Jon Lister, I've read the fascinating and controversial paper by Ricardo Semlar, whose company in Brazil is managed from the bottom up. There's the Wisdom of Crowds, where we learn about how information at the coal face is best processed and reacted to at the coal face (rather than by an executive 15 levels up the management chain). And now we're observing how innovation can happen in the open source space. A lot of food for thought.

Also relevant is the feeling of antipathy that exists towards project managers (all managers?) here at BigCo. I've worked closely and successfully - often pleasurably! - with developers for many years, so it was a surprise to find that (project) managers here are viewed with, at best, suspicion, and occasionally with vitriol. Not all that surprising, though, when I hear the stories about how project managers have occasionally behaved here in the past. Less said, best left.

Anyway, I don't want to be a project manager here. What I've been charged with is the experimental creation of an environment where projects practically run themselves. Where coordination and cooperation occur with the minimum of effort on management's part. Where conditions lend themselves to innovation and inspiration.

While enjoying the benefits that such a system could bring, it's worth touching on the luxuries we don't have. We don't have the luxury of writing poor code. Independent open sourcerers can and do write poor code sometimes, and it just gets ignored. We don't have the luxury of writing our code in a vacuum (which would defeat the object of our existence), we need to collaborate with the open source community. One of our mantras is "adoption through reuse", with everything that comes with it. We also don't have the luxury of not making or keeping commitments, whether internal or external. So how do we create an environment where this "just happens"?

Part of the answer is a change from tracking tasks to tracking commitments. Built into these commitments will be language pointing at quality controls and liaison with the community. Prioritisation will take place between people affected by incoming commitments. The main input from the team's leader will be to provide mentoring and guidance on prioritisation where needed. Team members are at liberty to not make commitments, although expectations about their other output will go up rapidly as a result.

My hope is that our experimental system will take a lot of the stress out of my job. And will have the added bonus of providing team members with the protection and space needed to get on and do their jobs (pushing back on making new commitments when they already have a full plate). Let's see!

(Photo taken by aussiegall)