Job Abstraction Layer
I usually love reading Joel Sposky’s stuff. His insights into the software business are usually right on. But I have a few problems with his recent article, The Development Abstraction Layer.
The premise of his article is that software developers create products, and it’s the job of the development management to make the developer’s lives easy so they can create good products and not worry about network connectivity or broken chairs.
But man, software developers don’t need their god complex made any worse than it already is.
Two points.
First, developers don’t make successful products, companies make successful products. In a company with more than a handful of employees, the software developers usually aren’t the creative ones, they’re just a part of the machine. They have a role to play, and it’s an important one, but I’m not convinced that it’s the most important.
A company with strong engineering but weak QA, Marketing, Sales or even Accounting, isn’t likely to succeed, especially in the face of competition.
It’s a bit like a symphony: It doesn’t matter how strong the strings are if the horns can’t keep time.
Joel’s article basically tells the strings that the job of the conductor is to make them happy. While that may be true, it’s only part of the picture. The job of the conductor is to make the people who pay his salary happy. Making the strings happy is part of that job. So is making the audience happy, which is what motivates him to do his job well.
So my first point is that we shouldn’t be putting the developers on some sort of pedestal.
Bringing me to my second point, which is that the job of management is provide that abstraction layer for every employee, not just for developers.
It doesn’t matter what you do, if you have to deal with things that other than what it is you’re supposed to be doing, you’re less productive than you could be.
Even if you work in the mail room delivering mail, if your chair is broken and you spend half the day fixing it, you’re not doing a good job of delivering mail.
Joel’s essay is saying that we should keep developers happy so they do good work. I’m saying we should keep every employee happy so they all do good work.
May 19th, 2006 at 11:03 am
This an interesting post, but I think you missed Joel’s point. Let me be fair by saying that I almost never agree with Joel, but this time I do. The manager of a team of managers is responsible for removing obstacles to his developers. Your orchestra analogy is flawed because you talk about the conductor managing the strings section. That isn’t how the real world works.
A manager of people (as opposed to a manager of managers) has one primary job: Make his people more effective at their job. Through this they will achieve the expectations of their own management. If a manager focuses on the needs of those upstream from them they will utterly fail those below them.
Now, the interesting thing about this is that the higher you get in the food chain, the more this inverts. So at the top, the CEO of a company is probably more attentive to the Board of Directors than he is to the VPs. And that is fine. But as you work your way down towards the people who do work, it is essential that their focus turn to those that they manage.
Instead of a music metaphor, consider a military one. A corporal is responsible for the safety of his fire team. He has to get his mission accomplished, yes, but if he fails to do what his people need done, they will fail him on the battlefield. At the top of the food chain, however, a senior general is responsible for fulfillling the expectations of his commander-in-chief and not so much his lower generals.
So, back to my point: There are different kinds of managers. Those that manage working stiffs need to focus on making the stiff’s life easier and more productive. Joel wasn’t specifically picking out developers as prima-donnas, he was just saying that those who manage developers should remove obstacles from developers. I don’t think he meant to say that managers should focus on developers to the exclusion of testers, PMs, graphic designers, etc.