I see organizations making processes organized around "dumb people" and "smart people" all the time.

The smart people do the REALLY HARD stuff and the dumb people just make it work. A classic example of this (now fading, thank goodness) is the idea of "architects" who design the software and programmers who make it work. A newer example is web designers and programmers: the web designers/dumb programmers are expected to design the page using drag-and-drop components as well as doing simple presentation-layer programming, while the smart programmers make the components that they use.

But it doesn't work! The smart people start designing stuff in isolation, not aware of the real needs of the "dumb people," who are now their customers. They simultaneously underestimate the intelligence of their customers and overestimate their ability to consistently and mindlessly follow obscure rules. They create complicated stuff that bends over backwards to be "easy to use" and ends up being very particular about how it must be used. When something goes wrong, there's too many tricks for the "dumb people" to figure out, so they either make something that doesn't work or they put in terrible hacks to make it work.

Not only that--everyone wants to be a smart person and nobody wants to be a dumb person. If you're splitting your group into smart people and dumb people, even if you don't say so, everybody knows which side they're on. What kind of effect does that have? Perhaps the "dumb people" don't try quite as hard as they need to in order to get your super-smart stuff to work properly? Perhaps they ignore the Convenient Checklist of Three Easy Steps required to use your components?

There's no such thing as dumb people. Just different strengths. Don't teach your web designers how to be dumb programmers. Instead, expect them to be excellent web designers--and make excellent programmers available to work with them when programming and web design overlap. Don't expect your programmers to ignore design or your architects to ignore programming. Have them work together, designing and programming, and learning from each other in the process.

Everybody you hire should excel at something. Don't design your organization for dumb people.

(Only my second day on the blog and I'm already ranting. Sigh. Go to the Articles section for balanced, well-reasoned arguments.)