Laborers versus Professionals
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:
- The surprising science of motivation by Daniel Pink
- Programmer Passion: An Enterprises Most Useful Yet Repressed Advantage by Karl Seguin
- Drive: The surprising truth about what motivates us
Till next time.
5 thoughts on “Laborers versus Professionals”
It’d be nice if everybody could just trust us. But then, it’d be equally nice if we were all trustworthy. The problem is that business went down this road once where they gave IT the keys they were demanding; C-level positions, high compensation, rock-star status, big bonuses, stock options. Unfortunately, we proved that we weren’t that interested in taking messy things like business constraints and market conditions and competitive advantage into account and the dot-com era came to a messy close.
Too many developers want to force the real world into their idealized conception of what development *should* be. We want quality to be king, testing to be comprehensive, and all the resources and tools we feel we need to do the job “right”. We want perfection and we feel, deep in our hearts, that the market will reward us if we only stay pure–it was this kind of thinking that prompted people to believe that fundamental business rules were being re-written during the dot-com boom. You display that same impulse when you say “It’s inevitable that great things are bound to happen.”
Unfortunately, it *isn’t* inevitable that great things are bound to happen. It isn’t even likely, really, if you go by the average business venture. Every project, every product, every team, and every company has to make compromises between equally valid principles in order to compete in the real-world marketplace. Time to market really can trump quality of product, just as quality of product really can trump time to market. Judging when to privelege one principle over another is very hard to do–particularly when money is on the line.
If developers want to have a hand in making business descisions, then they need to become experts in business–just as some doctors have to become expert at hospital management if they want to take charge of the business aspects of medicine. If you want businesses to take our demands seriously, then we have to learn not just the language of business, we have to learn the real meanings behind the language. And we have to work to prove to management that their concerns are being taken seriously and not simply blown off as irrelevant to *true* software development. Too often, developers function as a leech on the business corpore, taking up resources and giving little of real business value in return. If you want developers to be given business resources and the power to determine their best use, then developers need to be ready to accept business responsibilities as well. We need to be consciously and energetically oriented towards providing buisness value. And not in any nebulous, true-believer, it *must* happen manner, but in real, measurable, and verifiable ways.
If we can do that, and do so in a provable and consistent way, *then* we’ll get the kind of authority you describe here. I’m all for that, but we have a long way to go, yet, I fear.
@Jacob I agree that a lot of developers out there aren’t trustworthy and don’t care about the businesses they are working for. But then again, if companies don’t want to change their hiring process so that they are able to only hire true professionals, then they get what they deserve. If professionals is what you want, then one should act in order to get those hired.
Somewhere along the post I’ve mentioned the following:
“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.”
Given these constraints, a development team should always be able to provide the best possible solution for *their* business, given that they get the freedom to work with their clients and use whatever technique/tool/technology they need to get the job done.
If you want engagement, then don’t treat developers as code-monkey’s. If you give professional developers enough freedom, then they will learn the language if the business. Heck, this is what Eric Evans has been talking about all these years now (ubiquitous language / Domain-Driven Design). But in order for that to work, development teams need self-direction and be trusted. The proof for that is out there and I have seen it work. The other option, holding development teams on a leash, forcing them into a one-way street isn’t working either.
I do agree that we have a long way ahead of us, but like the health-care industry, we’ll get there eventually.
It looks like we agree on the individual case. I don’t see it working in the general case, though. Like you, I’ve seen the individual case and the magic it can provide a company. Earned trust in software development provides enormous dividends to both the company and the developers.
I just don’t see it happening on a wide-spread basis is all. Learning the business side involves a skillset that is not merely orthoganal to software development, but in many ways antithetical to it. Developers who are capable of *and* willing to learn both are therefore rare.
It’d help if our education and training included the expectation of acquiring business skills. In this way, my favored analogy is more lawyers than doctors because lawyers have specific training on law firm structure and the role and ethics of practicing law in the business environment. If we’re to become more “professional” than “laborer” as a *profession*, we’ll need to incorporate some of that same attitude and give up seeing software development as isolated from business/market concerns.
I agree that our opinions are not far apart. I don’t see aquiring business skills besides development skills as a massive problem, more than I see it as an opportunity.
Stop the world I want to get on!
What the hell is going on in here?
Do I smell the revolting stench of self esteem?
Bloom!, where do you think you;re going, you already had your toilet break!
Im not going into the toilet, I’m going into show business.
and Mr. Marx I have news for you. I quit!
And you are right about one thing, you are a CPA – A Certified Public Asshole!
The Producers – 2005
Leave it to Mel Brooks to make comedy from reality.
More power to you Chris. I think you are awakening to the reality that I did in 2003, and although I abandoned the industry, and admire that you stuck to it. I vowed to become a simple user, and so far, I am appaled that current software and operating systeme available to the common man is absolute crap. Functional, annoying crap. It’s only getting worse, and the only remedy is to never update or upgrade..
Nice post Chris, and more power to you.
Comments are closed.