A while ago, I published a piece titled "Beyond Innovation: Adding Adoption To Your Business Objectives," which started with the observation that we're damn lucky in the technology business. Innovation, particularly on the software side, moves faster than in other industries because of fewer physical constraints. Oh, sure, a few hard realities apply, such as the speed of light, or the amount of heat your overclocked gaming PC generates. Those constraints are trivial, compared to the limits of physics and chemistry that innovaters in other industries face.

As good as rapid, unconstrained innovation can be, it's not without its problems. Technology companies want to give the human source of these innovations, whom we'll call The Smartest Person In The Room, enough latitude to put their talent and creativity to work. And heck, since they're smart, why not put them in charge of things needed to bring their innovative ideas to market, such as the development team? Unfortunately, there is such a thing as giving highly intelligent people too much latitude.

Around the Valley, the Smartest Person In The Room (SPITR) often holds a title like CTO, Chief Architect, or Development Manager. The stereotypical SPITR is thirty-something, graduated from a school like Cal Tech or RPI, wears slacks with tennis shoes, and talks at a pace that's sometimes hard to follow. The SPITR has profound technical skills, and a creative mind that operates much like a pinball machine, lights flash and sirens sound when the SPITR hits a new idea, and it won't be long until the SPITR bounces to to the next possible innovation.

Obviously, every company needs to hire people like the SPITR and find the right role for that person. You'd be stupid to waste someone that valuable. However, even the smartest people aren't smart about everything. For example, Napoleon may have conquered continental Europe, but he didn't have the political acumen to know how to hold on to what he won. Symptomatically, he had a bad habit of putting his less-than-capable relatives and cronies on the thrones of defeated countries, with predictable results.

The same rule applies: SPITRs are good at many aspects of product or service development, but not everything. For example, just because a SPITR is smart doesn't mean that person will make a good development manager. Every team lucky enough to have a SPITR needs to be realistic about filling out the other roles with people that have complementary skills. The SPITR also needs a counterbalance, since not every idea from any human being is going to be a good one.

Unfortunately, some technology companies give too much unchecked power to the SPITR. You know you're working in one of those companies if...

• The feature list for the next release is completely under control of the SPITR.
• The SPITR has a secret feature list.
• The development team looks to the SPITR for guidance more than 80% of the time, and to the customers and partners 20% or less. (We might want to set the bar lower, but you get the idea.)
• The SPITR takes risks, such as last-minute check-ins of unreviewed code, granted to no one else on the team.
• The SPITR has a product vision that no one else on the team fully understands.
• The SPITR's projects are surrounded with so much mystery that no one in upper management feels competent to judge how well these projects are going.
• The SPITR does not have time to mentor other team members.
• If in a managerial position, the SPITR is not devoting sufficient time to management tasks.

Dealing with an unchecked SPITR is not easy. Companies fear that, by doing so, they'll squelch the SPITR's innovations, or drive the SPITR to look for a job in another company. But those are just excuses for bad management. If Eisenhower could make good use of Patton, a CEO or EVP in a software company can figure out how to harness the talent of a good SPITR who's responsible for too many things.