I was thinking about tech company organization the other day and I stumbled upon an interesting thought. In many ways, working in a development house is like working in a restaurant. You have customers. They look at a menu, pick what they find appetizing at that moment in time, and then place the order. The kitchen springs to life, uses the ingredients and appliances they have to create a meal, and then some one delivers it to the customer. If all goes well, the customer pays and comes back again for more. The customer really has almost no idea what goes on in the kitchen and usually doesn’t want to know for fear that they would be appalled. The customer and chefs almost never communicate with each other unless it’s through a volley of intermediate employees.
Imagine your developers are the guys in the back making the food. Imagine the development managers are taking the orders. Imagine the product people or upper management as the customers. The consumers.
It all sort of fits, doesn’t it?
Customers all want the same basic things. They want fast service. They want quality service. They want reliable service. And most important of all is that they want it cheap. It’s easy to tell when when your service is fast at a restaurant. If you don’t have your food right quick you’ll be bloody hungry! Quality and reliability are easy to measure too. If the food tastes like burnt motor oil than they’ve failed on both accounts.
For some reason the customers of the software development world have a much more difficult time of gauging the performance of their ‘kitchens’. They almost always seem to focus on speed and cheap. I don’t think they always realize that they’re getting McDonald’s though.
Fast food joints provide a ready supply of expedient food options. Through clever marketing it even seems cheap. Your typical fast food meal can cost just as much as eating out somewhere more reputable however. The real problem with fast food is that it’s completely unhealthy and has a tendency to kill you if you eat too much of it.
Your typical developer is like a fry cook. You don’t even want to know what this guy would do to your burger. You certainly wouldn’t want him to take your order cause he’d simply muck it up. He’s getting paid so little and similar jobs are so readily available that he just doesn’t care about your fries one bit. So you get soggy fries. And no matter how bad those fries are you’ll still go back to this place because it’s quite simply a quick fix.
There are nice restaurants though. There are developers out there who think just like fine chefs. They want to make something beautiful and tasty because that is their passion. They design their menu carefully and they charge a lot more so they can go buy the best steaks or wine. The wait staff is cute and attentive and will certainly know which delightful soup the chef has whipped up.
And the chef will certainly feel a little annoyed if you pour ketchup all over your dry aged filet.
You’d probably like your developers to be chefs and not fry cooks. You have to give them the leeway to do the kind of work they can be proud of. Just place your order and sit back and enjoy the appetizers while they assemble something you’ll love. If the food arrives late and cold than don’t pay!
The sad reality of this, however, is that no matter how good of a restaurant your development house turns out to be, it’s still a restaurant. Your customers are placing orders and waiting to see what will arrive at the table. It’s almost always a surprise. I think this is a terribly ineffective way of building quality software products.
Think baseball team instead. Everyone has different positions on the team but they still all work as a single unit. They’re all working for a single goal and the greater good. They’re playing to win the game. And in modern times they’re also playing to raise someones stock portfolio. You can make a lot of money while doing an excellent job and having fun.
Oh sure, every company throws out terms like ‘team building’ but they almost always mean hierarchy building. And hierarchy is exactly the root cause of the restaurant scenario. You segregate the people requesting work from the people doing the work and create tiny choke points of failure. No one ever really seems to know what anyone else wants. By putting someone over someone else you’ve almost certainly reduced the amount of two-way communication between those people. Person A might feel intimidated by Person B now. Or Person B might feel they don’t need to listen to Person A because they value their own opinions more.
I know many development companies have adopted flattened management structures. Others create things called ‘verticals’ or ‘pods’. Like communism it sounds good on paper but these types of things always seem to have fundamental flaws. My personal experiences with pods has been grueling primarily because pods don’t interact well with other pods.
The bottom line I think is that if you have a room full of smart and educated people from developers to managers and everywhere in between, why should communications be one way? How can one set of people dictating requests to another possibly use the full group’s combined potential? Bi-directional communication has to be encouraged. The most junior guy on the team might have the best solution for the project. The product manager might have thought of a simple approach to a tricky development problem but the developers might immediate dismiss it.
Avoiding conflict is not always the best solution. But the real trick here is to maximize ideas while minimizing conflict. In the end I don’t know the proper solution. And I’m certainly not saying that I work for McDonald’s. But I’m fascinated by the various attempts at company organization I’ve seen first hand. I’ve seen the ups and downs of many different kinds of structures. But what I see the most is company after company always falling back on the old standby of ridged org charts and middle management.
I think the offices of the future are going to be much different than that.