June
2007
A lesson from Dune0
I’ve literally read Frank Herbert’s Dune dozens of times1. Other than being a fantastic SF book it contains some pearls of wisdom that apply to many situations in our day-to-day lives.
One of the quotations I like the most is
Give as few orders as possible. Once you’ve given orders on a subject, you must always give orders on that subject. – Duke Leto Atreides, “Dune” (Frank Herbert)
When leading (ahm, and yes, managing) development efforts I’m often in a situation when a developer asks me to make a decision regarding her work. If I think however it is an issue that falls well within the territory and responsibility of the developer, I try very hard to let her decide. No, I’m not trying to avoid decision making (always a pain), I’m just trying not to “give orders” (as the Duke puts it). You see, if I make the decision I have in essence minimized the (good) responsibility areas of the developer and her ability to freely progress in the future. Now she has less space to operate in, less room to express her ideas, and she is becoming more a “doer” than a “thinker”. So overall the freedom of the team to develop as they think is right is hurt. And if that wasn’t enough, your decision on outcomes of this decision (like the evolution of that particular feature or design) will always be required, and the scalability of the team as a whole is affected.
This practice, of minimizing the decisions you make for your developers, is even harder to follow when you have a strong opinion about something one of your developer is (or is about to be) doing. For example he is about to write some fancy lock-free data-structure while you think plain old synchronized hash table will do. As long as his plans are not colliding with the overall design and the extra effort isn’t dramatic it is better to let him do what he feels is right. Above all, it is a local decision within his territory, an area which he surely knows better from anyone else. If you force him to use your solution, don’t be surprised when every little obstacle he encounter will result in him calling you to fix it for him and again you turned a thinking programmer into a robot that just follows your orders and avoids exercising his brain. A living REPL .
Indeed a mistake can be made when the decision is the wrong one. So what? Didn’t the developer and hence the team just enhanced their experience? Hey, aren’t you still making fullish mistakes? As long as the mistake is well contained within acceptable boundaries no real harm is done. It is your responsibility however as the lead to make sure such boundaries exist, so mistakes are quickly identified.
True, this practice can’t be applied with less experienced or less capable employees, but I try very hard to make sure everybody who works with me is at least capable of making smart decisions regarding her own work. Otherwise, why hire them?
1 Incidentally, I once read that the Hebrew translation of Dune exceeds the original. That’s a bold statement to make, but even if it isn’t true, the Hebrew translation is very very good.