A while ago, my good friend Michel Grootjans tweeted the following:
Are developers (a) laborers or (b) professionals? If (a) don't expect them to think. If (b) don't expect them to execute without question.
Personally, these few sentences struck a nerve or two. Read it a couple of times and think about this statement for a while. Try to picture your own work environment and how this relates. Go ahead! I can wait.
OK then, let’s move on.
I’ve been working for an enterprise corporation for 5+ years now. One of the things I’ve seen and learned there over this period of time is that laborers are more valued by management than professionals. Let me elaborate on this.
One of the biggest issues in a typical enterprise corporation is trust, specifically the lack thereof. The direct consequence of this lack of trust are massive amounts of constraints, regulatory processes and fear-driven development. This is the natural habitat of laborer developers, a nice and cozy place where they can spend their hibernation until retirement. This is where the term ‘code monkey’ originates from. Nine to five, no thinking, narrow focus, like soldiers in the military obeying orders to make a big mess. But sometimes, amongst these massive cohorts of laborers, there are small islands that exist of one or more professional developers. These are the kind of people that are very passionate about their craft, that want drive innovation and also want to continuously learn and improve. If you’re a developer and you’re reading this blog post, you probably fall into this category of developers.
But professional developers always have one part of the establishment going against them. It’s not the laborers. They don’t care. It’s an instrument better known as management. A large part of the IT industry, especially corporate IT shops, are being run by giant flocks of managers. Some of these managers started out as software developers and some of them are just born that way. But there’s something that they all have in common: they don’t write code as part of their day job. Although they don’t get their hands dirty with writing software, most managers do feel compelled to impose all kinds of political decisions regarding business requirements, software architecture/design, tools and technologies to the development teams they are ‘managing’. I for one want to make it clear that this has to stop. In order to lift this industry to the next level, we as software professionals need to free ourselves from the leash that is currently being held by management.
Professional developers working in these kinds of corporate environments are generally considered as troublemakers, if not by their direct bosses then certainly by other parts of management. The general attitude towards professionals is slamming them with more procedures, so called ‘company standards’ and ‘default architectures’. This ends up with a lot of frustration, a feeling of burn-out or even worse, suffocation as it may seem that the walls are closing in. Professional developers generally have a hard time placing this attitude towards them. They just want to do the right thing and provide the best possible solution they’re able to come up with. If managers don’t trust their development teams to make the right decisions, then why did they got hired in the first place?
I for one am pleading to get past this all this. Any business that wants to survive in this hard world economy and even wants to get ahead of its competition has to free its professional developers from management. It’s that simple. Management is great for enforcing compliance, but if engagement is what you want (and is definitely needed for bringing innovation), self-direction is essential. I already wrote a blog post about self-organizing teams a couple of years ago. Today, I’m even more convinced that self-direction is one of the major key enablers for innovation in the IT industry of the 21th century. Anyway, someone who isn’t coding at least 50% of his day job shouldn’t be allowed to interfere with any kind technical decision making. Period!
I’m not saying that development teams should get a signed blank check. On the contrary. Financial and business constraints should still be taken into account. But when it comes to creativity, methodologies, technologies and tools, management shouldn’t get in the way. Development teams should be able to take responsibility for their own actions. Managers should know their place by making sure that their development teams can operate as optimal and efficient as possible by removing as many impediments as possible.
Let me show you a couple of examples where this principle of autonomy has immensely paid of so that you’re able to judge for yourself.
I personally find health care a fascinating craft. I find it fascinating simply because there are so many parallels than can be drawn between software engineering and the state of health care roughly 200 years ago :-). Lets take about modern hospitals for example. Medical facilities are generally being run by senior medical staff and not by managers! Senior medical staff are people that have a high degree of mastery in what they do and still perform their craft every single day. Maybe they’re not doing it full time so that they’re able to fulfill their ‘path-finding’ responsibilities, but still, they are still fixing their patients. Hospitals do have managers however, but they are there simply for enabling the medical staff to not worry about anything else besides saving lives. Can you picture lying in an operating room when a manager in a suit bursts through the door, yelling at the surgeon that he’s not allowed to use technique xyz to save your live? Preposterous you say? Not so with the current state of affairs in IT departments of the enterprise corporations.
There are a couple of concrete examples in the IT industry as well. Remember when Google announced that their engineers get to spend 20 percent of their time to work on something of their own interest? This resulted in massive improvements for products like GMail, Google Maps, Google Docs, etc … and directly contributed to Google’s success and current market share. Other companies like Atlassian and Facebook are enabling innovation in basically the same way.
Yet another example is Pixar. If you haven’t seen or listened to this interview with Ed Catmull, the president of Pixar, stop reading this blog post and let it inspire you now! Somewhere along this awesome interview he mentions the following:
Part of the behavior is I don’t know the answers. And at first that seems a little bit glib. But after awhile people get that I really don’t know the answer to a lot of these things. So we set it up so that the management really doesn’t tell people what to do.
Think about how amazing it would be like to work in an environment like that. It’s inevitable that great things are bound to happen.
There are plenty of other examples out there, like open-source software, Wikipedia, etc. … . They all prove that self-management results in engagement and that this is going to be a major differentiator in tomorrow’s economy.
Make sure to check out the following resources as well:
Till next time.
