Too Many Cooks in the Kitchen?
This post is a follow-up to my last one about hosting your own applications versus outsourcing them to third parties. One of the problems I see pretty often on sites is that many key components are each served by a different company. You have one provider for customer reviews, another vendor for videos, a third company for your analytics package, etc. Check that post to read about the things you should consider before integrating third-party solutions with your website. Here, I want to talk about a similar challenge that exists not for multiple software packages working together, but with multiple developers working together.
Many smaller companies don’t have a dedicated web development team that handles everything in house. They may have one or two web managers who oversee the site, but who outsource the actual work to one or more actual developers. Or it may be a case where it’s just the business owner juggling all of his responsibilities with managing a set of developers. The more coders you put on a team, the bigger chance you create of having too many cooks in the kitchen.
I first ran into this years ago on a site that sold personalized greeting cards. Originally, I was contracted to build out the ecommerce store, and to work together with the one developer who had built the original store, but whose expertise was really in HTML and JavaScript, and who also had experience working with the image processing company they were using. That worked really well. The other developer was in Chicago, and I was in Florida, so we had only an hour’s difference in our times and it was easy to communicate via phone and instant messenger to get things working.
Then came the redesign – insert web designer from California. He had a day job so we couldn’t contact him during business hours, so there was usually a 12-24 hour delay in emailed communications back and forth.
Then he added a desktop publishing company in India. While California is still only a 2- or 3-hour difference from Florida and Chicago, we now had a company who kept opposite hours from the rest of the team. And of course there were some communication problems due to the language barriers.
But all of these issues can be mitigated. It slows down development, but if time is not critical then it can cost less money for the business owner. Unless the owner is too busy to facilitate communication among the multiple developers, and unable to understand what’s happening due to a lack of technical understanding. This varied team needed the business owner to act as project manager, but he didn’t have time, so it devolved into a lot of excuses and finger-pointing. That was when we made our exit.
I recently started seeing something similar on a current project. The main difference is this: we report to the marketing manager, who:
- actively manages tasks among developers
- does his best to make sure we’re not stepping on each others’ toes
- understands that one developer may make a change that breaks something another developer works on
- prioritizes tasks and handles other project management needs
Again, we have lots of cooks in the kitchen – but is it too many? In an actual restaurant kitchen, there’s a pecking order. The owner doesn’t throw a bunch of cooks into a room and let them battle it out. He hires a kitchen manager to oversee what happens, a sous chef to manage the actual operations. The pastry chef doesn’t make soups. The soup chef doesn’t wash dishes. Etc.
My point is that there are good ways and bad ways to put many parties on a project at one time. Before you begin hiring, take time to figure out who’s going to own what happens to the site. Not who’s going to make or lose profit, but who is ultimately responsible for whether the site is operational or not. If it’s you, do you have time to make this a priority? Or would it be better to hire an employee to oversee this part of your business? Or do you want to outsource the site management as well as the actual development. All are valid choices – the only wrong choice is to not make one at all.