A recent 37signals blog post, “Making shit work is everyone’s job”, captures the essence of the spaces in which I like to work (and currently do). The post has also ruffled a few feathers, at least in the comment thread, of those who focus not on the concept but on the literal practicality of it.
Before going any further, it’s important to note that the emphasis in the title should be on the word work, not the word shit—the latter implies a bunch of pointy-haired bosses doling out tasks from the Big Bucket of Scutwork you just know they keep under their desks. Instead, DHH’s point in the post is that when you hear an employee say “Oh, that’s not my job,” you have some managerial work to do.
Departmental hedges grow fast and tall if not trimmed with vigor. It’s the natural path unless you take steps to fight it.
Taking steps to eliminate the “that’s not my job” attitude is crucial; no one should ever consider themselves too good to do any job that makes the company go.
At one of my previous jobs, at which I led 4 different teams, there was a natural split between the people who do technical development work and the people who handle large amounts of paper (which end up as electronic documents)—I managed both groups. Both groups are important to the forward progress of the company, but there are skillsets among both groups that do not overlap. To me, people in each group were not inherently better than people in the other, but of course the efficiency and quality of the work would differ depending on who did it—case in point, I can create web apps in my sleep, but if you ask me to work a scanner of any sort, I will stare at it for an inordinate amount of time trying to figure out which way to put the paper in (and don’t ever ask me to print on letterhead, because it’ll never work). But we know we have the right people because if shit had to get done, people would try to find a way to do it.
Sure, there might be fallout, but I’d rather deal with the fallout of monkeypatched code and its ilk than deal with the ongoing management problem of people with delusions of grandeur (ed. note: turns out I eventually had to deal with both, but that’s a story for another day, and not for the public).
To my mind, there’s also a related issue of the very real need to ensure that the people who are doing particular tasks are free to do those tasks. It’s not building hedges (or silos) to have people dedicated to tasks such as systems administration and engineering so that developers are free to, well, develop. I would argue that filling gaps with people possessing the right skillsets to ensure continual forward momentum (smoothly) is actually an ongoing hedge-trimming activity.