When I was in the fifth grade, I was on the elementary intramural volleyball team. Surprising? I suppose. We did pretty well, and at the end of the season, we went on to the city-wide competition. Since I was the smartest kid in fifth grade (just ask me then!), obviously I was also the best volleyball player. As the best player, I spent a lot of my game time backing up the other players, getting behind them to make sure that when they missed the shot, I’d be there to score for us.
Imagine my shock when we were soundly defeated by the other teams all drilling the volleyball into my ‘zone.’ Obviously if these other players on my team had been better, I wouldn’t have had to spend my time in their zones and not protecting my own.
Joel On Software makes a similar point. He likens the company to a yacht, with the developers as the engine, and basically, all the developers need is a place to sit and do their pretty-code-making work. Everything else is a distraction. One minute that the developer spends thinking about, for instance, where he’s going to get his dry cleaning done, is one minute the engines aren’t running to move your company.
Google also makes this case; although a little less starkly. They provide all they can to help their workers focus on … work. And I can certainly see the advantages; in fact, most jobs should, IMHO, be like this; designer should tell the developer “I need a login form here” and the developer should be able to say “I need a header graphic here” and be able to treat each other’s job function as a black box; push the button and out comes a design.
When I was a busboy, I was the best-damn-busboy I could be. Because I focussed on doing everything for the waitstaff that distracted them from making money. Food delivery, water refills, seating, and, yes, the occassional table bussing. I worked my fanny off to ‘abstract’ the work of waiting tables. But when it came my turn to wait on customers, I wasn’t so good- I expected that same level of service from the clerks and cashiers, and I had a hard time anticipating the customers’ needs. But I was a good hardware technician; my strength lay in figuring out what the sales folk needed to help them sell hardware (and incidentally hardware installation).
I imagine that in a lot of the roles of life, this abstraction would be useful; for instance a big company where the developers just develop, the managers arrange everything for the developers, the design folk design, the design managers arrange everything for the designers, the sales guys do what ever it is sales folk do, and so on and so forth. Then the managers could get together and arrange amongst themselves how best to take care of their charges. In a bigger company, there could be a manager-manager to facilitate the care and feeding of the various yacht-parts, and to help them work together to power the yacht and direct it to parts unknown.
I have three problems with this point of view, though. First, when I’m working for myself, it’s hard to abstract the Russ-as-programmer and have the Russ-as-manager provide for all his needs. So in a very small company, this abstraction is just a Platonic ideal that we can visualize but never quite achieve.
Second, I’ve found that I work best knowing the context for my work. I tend to do strange things like listen in to other departments’ meetings, so I have an understanding of how work flows through the company. As a programmer, I need some time set aside to give me the “whys” of a project, not just the “whats.” Most often, I have to get this myself; managers don’t usually see the use of not treating me like a mushroom. With the context, I have an easier time programming for what the customer needs, as opposed to what they say they want. I don’t see an allowance for this in Joel’s model (or Google’s model).
Last, I’ve found that most manager-types don’t like to treat me like a black box. They want to know what I’m doing when I’m doing it and why I chose to do it that way. If they don’t see hard numbers (I spent 4 hours rewriting this to use a different programming technique and saved us 2 seconds off the loading time and reducing system load by 1%), they don’t see the value in you. When someone is a “black box” you have to trust them to do their job. Most managers I have worked for have a hard time trusting that I have been doing my job; I can think of two roles where my superior had that level of trust in me; the University of Oregon and Interlink.