Thanks to a conversation with my manager and mentor (not to mention technical genius) Neil Winton, I’ve finally truly learnt a valuable lesson. A lesson which I’ve heard people talk about at conferences and read books which espouse its fundamental importance, but until now I didn’t really get it.
The business is not my Enemy.
I work in a large company (100K+ people) and software developers are the minority by a couple of orders of magnitude. More than once I’ve muttered phrases along the lines of “it’s a miracle that anyone technically competent still works here”. I’ve seen (and had) brilliant ideas with well written implementations and great potential get killed off or completely passed by. Projects have been given to cheaper and less competent companies, only to come back buggy, untested, lacking automation and a whole host of other bad traits.
Seeing this happen repeatedly (and rapidly), the company feels more and more incompetent, ignorant of technical quality and driven purely by cost. Great strategy from the top seems to get diffused into a mist of poor implementations and wasteful deals with ill-matched vendors.
More examples soon stack up and the frustration and annoyance really kick in. Your team looks more like a beacon of hope and quality in a wasteland of poorly written projects. It becomes the fault of “the business” for pushing developers into dull management positions, forcing implementations using product X (which they recently spent millions on) and giving work to lower-quality contracts.
For me, this week the epiphany came: It’s a business– it’s function is to make money for the shareholders. Whatever helps that goal is rewarded.
This is not to say that it’s actions were always right or justified, it just means that someone rational thought it was the right thing to do– they did not understand the implications of their decisions.
If two people offer you a “Free-timed Cylomatic system”, one wants £500K and the other wants only £300K, which do you pick? With no real idea what the thing is or how it is made how do you value it? Both promise to deliver in the same amount of time but obviously the second offer is 40% cheaper! You can save the company money and helping to reach your targets- maybe you’ll be rewarded with a nice bonus! Oh yes, one SharePoint instance does sound cheaper than running all this separate wikis and intranet pages, maybe even more money can be saved there! Awesome!
In “The Passionate Programmer”, Chad Fowler gives a lot of very useful tips for a creating a successful career but the one I feel most of us (techies) overlook is the idea of grabbing an intro to business admin book and really grappling with the way our companies are run. How are we actually making money and how does my project contribute to it? Once a decent percentage of technical people can answer these questions, our profession can begin to engage with the rest of the business in far more productive way. We are in a profession which doesn’t really line up with anything that people outside of it can identify with, yet we rely on them to make decisions about it.
I’m not saying all programmers need an MBA or should become “business managers”; simply that we need to learn the language in which to talk to the people with the money and power to decide.
I’m advocating educating yourself on a minimum of business theory. Enough that you can understand the next meeting where someone shows you lots of PowerPoint slides with graphs and spending figures on without your eyes glazing over. If we want the business to stop making such terrible technical decisions we need to reach out to the people making them and help them to understand what the real repercussions are.
I know that none of this is new but I am going to try and learn a little. The master carpenter knows how to read his balance sheet, I believe the software craftsman should be no different.