We understand: Drupal is made out of code, so it makes sense to put the master of code in charge of the site, managing all the other lesser coders. Don't do it! For one, it dumps a whole lot of non-coding responsibility on them, and you get a lot of value having them do what they do best. But perhaps more importantly, it puts responsibility for making sure the site works for everybody on the shoulders of somebody who doesn't really think like the rest of the people in the company. When they look at a site, they see the variables and functions and APIs and other components, but that's not what other people see! And one more thing: some day they will leave, and odds are pretty good the site will still be needed after they're gone -- you want to make sure they're not the only person who understands how everything fits together. You'll need to keep things running with whoever is left, so make sure there isn't anything that only one person understands.
Also, you want to minimize the pieces in your site that can only be worked on by one person. Don't just throw them at the guru, find a way to make them less complicated and more accessible. (Maybe document them better?)
Now to be clear, you do want whoever is in charge to be a top person -- somebody who understands the business, who know how to communicate with all the stakeholders, and who thoroughly understands the technology in your site. It's *possible* that person is also the top coder -- but it probably isn't.
#drupal #webdevelopment #31daysofsimplifyingdrupal