This post is the twenty-second part of a ramble-rant about the software business. The current posts in this series are:
This post is about organic software management.
Organic Software Management
The beauty of organic software management is the software and teams perform as they should. Can you force a management style onto a team? Yes. Does it produce? Sometimes, but rarely as good or as much as organic management. Why? Because people self-organize. And they do so instinctively; organically even.
Geeks are people too. Whenever I think about how geeks socialize I am reminded of a quote from the movie I, Robot (not sure if it was in the book, and I find the robot series from Asimov very inspiring): "Why is it that when robots are stored in an empty space, they will group together, rather than stand alone?"
Many of you know this already: Our family raises chickens on our small farm in Farmville Virginia (I am not making up the name of the town, I promise). These are egg birds, not for meat. We also have a small garden. We derive immense satisfaction from growing our own food. It's amazing how versatile nature really is. If you get a few things right, you can do almost anything you want to a garden and still get vegetables and fruit. If you don't do those few things right - and all of them, mind you - you will get little if anything from your garden.
The first key is creating the right conditions. The second key is planting the right stuff at the right time. The third key is taking care of the garden. Our garden is my model for using the word "organic."
So how does organic software management apply to teams?
Are the conditions conducive to produce the desired outcome?
Are you introducing the right stuff at the right time?
Are you taking care of the team / project?
1. Conducive Conditions
When you think of the conditions required to produce quality software, what do you think of? I think of a comfortable and quiet workspace, modern equipment, and reasonable management.
Some folks can code away in a noisy, busy environment - some have to. Others cannot. I'm one who needs quiet. If I'm not in a quiet environment, I create a controlled noisy environment through the magic of my Zune. Nothing breaks my heart more than seeing developers tasked with creating tomorrow's applications on yesterday's equipment and software development platforms. The people who hired those developers must think they're super-awesome-coders... I bet they're paying them as if they're super-awesome... Probably not. Probably someone is "saving money". My favorite anecdote about saving money involves toilet paper - it keeps the crowd on the edge of their seats. I'll blog about saving money later.
2. Stuff and Timing
This is a broad topic. When it comes to managing a team of developers it involves lots of communication. Good people will draw more work. This will start a cycle that ends with intervention from management or the good developer. Usually the good developer manages it by quitting, so it behooves the manager to get involved before this happens.
Good developers need breaks. Most (but not all) good developers love learning new stuff. Training is a win-win for these folks. They get a break, and learn something new that can help the team and organization.
Also, developer teams require steering. It's not suicide knob steering here; think tiller on a large boat. Gentle guidance, not wild thrashing. And definitely not too much - over-steering can get you into trouble faster than anything else (especially if you're on a slippery surface). Leadership is the answer and I prefer the follow-me style of leadership. A lot of this overlaps with...
3. Taking Care of the Team
In our garden, we do things to keep stuff we don't want out. We weed, we apply as little pseticide as we can (erring on the side of losing plants rather than over-treating), and we shoot at the neighbors we catch stealing stuff. Ok, I made that last part up. Our neighbors are welcome to anything they want from our garden. We only shoot at people we don't know (or readily recognize) - and even then we fire a warning shot first.
Everyone is not a good fit for every team. Taking care of the team sometimes means letting good people leave simply because they're not a good fit for the curent operation. It's weeding. Other times people outgrow the team and there's no place inside the organization for them. Occasionally folks blossom and take root in other sections of the organization. That's transplanting.
I'm sure the organic analogy breaks down at some point. I see these patterns all over organizations. Fighting them seems counter-productive.