If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.
– Antoine de Saint Exupéry
Another way to improve software management process is simply to create great teams. As previously mentioned, great teams are simply the key to the right results. Personally I always believed that having right people on board accounts to the whole difference between good and great. Considering that developer’s productivity varies so much so that best ones can deliver 10-15 times (Steve O’Connell) more than the worst lower end group of the scale, I prefer to work with industry stars. Having that said, I mean it deliberately attaching a controversial label to the best professionals in the industry. As a software development manager I’d always like to work with stars. I want to work with celebrities of the industry — people with lots of endorsements on their LinkedIn profile, with many spectacular (and I mean spectacular) projects under their belts.
The reason for all of that is, I never had a budget, or indeed patience, to waste on unproductive work. I’ve always managed to pull 90% (or 99% if lucky) result from my team at less than 50% of a cost that I would incur running less ambitious teams. Need is the mother of invention. Needing big results with small budgets means inventing better ways of managing the business. Having a concept of market rates means that, there’s a ceiling of what you’d pay for a small, well defined number of star software developers, as opposed to an undefined number of standard-followers. Software development mavericks are operating far beyond coding and analysis and their rates might not fit into “industry average” either.
Software stars are capable of wearing multiple hats at once, which means business reduces waste on communication between: software architects, business analysts and software developers. I personally believe that there’s no substitute for quality engineering executed by a dedicated engineer, at the same time during my career I’ve seen time and again star developers carrying all other responsibilities way better than even best managed team of mediocre engineets. Better still, I’ve seen and I’ve learned myself from them. Now at any time of my current project life-cycles I try to pass to my team the mindsets of the best developers I had pleasure working with. Mindset of not following any dogmatic theories, books or practices, where there are no “dos” and “don’ts” that apply to all situations.
The practice of working with stars has taught me that there should be no fixed set of best practices that would be applicable to any type of product or engineering pattern when dealing with a group of genuine hackers. It often takes a skill of breaking barriers. Where most of the IT management are in fact more engineers than managers they would tend to work at the detail level of each cogwheel, rather than bird’s eye view of the whole product. Engineers converted into managers would stick to purism, classic book examples, UML modelling and what have you, whereas genuine hackers would focus on “is it working or not?”, thinking: can it be copied, borrowed, re-used, twisted and mangled to make it work? Such mindset doesn’t fit into classic models of waterfall, SCRUM or what have you because there’s a lot of experimentation in hackers’ work. Instead it simply takes right amount of luck, followed with right people, (important!): lots of freedom and in the end… most often ends up with great results.
Photo credits: http://www.flickr.com/photos/zachklein/3725500/sizes/o/in/photostream/