Research labs are old - really old. Edison’s Menlo park lab in the 1870s had most of the elements hi-tech R&D groups try to emulate. But that doesn’t stop every wave of innovators from starting from scratch, attacking the challenges of innovation as if they were the first to try.

In researching the myths of innovation I studied how research labs in established companies work and many miss the point.

There are many reasons for failure - foremost that creating new things is hard - but I posit that labs succeed or fail most often because of their relationships with product teams and not their technological brilliance or war chest of breakthrough ideas.

Here’s why in simple terms:

• Ideas are easy. It’s not that hard to find interesting ideas. They’re everywhere. There are many R&D groups and universities with lots of good ideas. Hell, there are many programmers or marketers with good ideas and given time and some funds they can develop them into impressive prototypes. It’s certainly hard work but it’s the easier part - it’s getting new ideas into products and out to customers that’s crazy hard.
• R&D creates culture conflict. This is the killer - the limits of sociology kills innovation more often than the limits of technology. The jargon is technology transfer, which means “how do we get ideas from R&D into products?” It’s the least sexy role in R&D and it’s never staffed with great talents for either research or product development: so guess what happens? Nothing. R&D sets goals unapproachable for product team’s 3/6/12 month horizons and wonder why they’re ignored 90% of the time, while product teams look at R&D and think they’re insane (10 year horizons? WTF). Managers love to couch this problem with jargon like “innovation pipelines” and “invention waves” but its BS - they don’t see the problem as social: R&D groups and product teams have conflicts & resentment on philosophical, goal and ego grounds and until those issues are confronted little else matters: great ideas will go nowhere.
• R&D never has a service arm. One obvious way to connect R&D to products, or to build good relationships, is to dedicate 10% of R&D as a service to Product team engineers. What problems are too big for release schedules, but too tactical for standard R&D budget? That’s the sweet spot where technology transfer starts. Any R&D manager who invests in closing the culture gap buys chips to spend when R&D has a breakthrough idea that ordinarily would scare the pants off product teams. The problem is that R&D ego would see this role as a concession to product team “superiority”, which is why to my knowledge its never been done.
• The reward models are broken. Often the conflict is created at the VP level: R&D is directed at satisfying VPs - R&D managers bet that when they deliver a great innovation the VP will ditch the old product team and start a new one - but this is radical move for any VP to make (see below) and rarely happens. In the meantime this VP-centric model encourage researchers to treat line level product managers and programmers as dead men walking, instead of as collaborators, prototype testers, or (gasp) peers in developing new ideas.
• Everyone wants to feel creative. Would you want to be told to only work on other people’s ideas? Any R&D group faces the challenge of being in the ivory tower: they’re resented as soon as they walk in the door, especially if they throw their PhD’s and research pedigrees around at engineers with different values. Innovation is a social process that smart motivated people want to participate in - if you propagate the belief that only special people in special roles can do it, something is broken.
• At the end of the day someone has to take the bet . Good R&D minimizes risk but never eliminates it. It produces explorations and potentials, but someone has to say “I’m betting my successful division on new thing X”. That’s a hard thing to say: I’ve never said it, have you? Most R&D managers despite their confidence have never said it either. In the end every failed R&D effort has a Product VP who was unwilling to take the risk, either for good reasons (the ideas were not worthy) or bad (they didn’t believe or didn’t have the the courage).

I admit this is a simplified and biased view: there are more complexities than I suggest (R&D groups have a wide range of possible goals) and I’ve worked with, but never in, R&D groups. So there, I confess, I’m a product side innovation zealot (Not really, but if you hated this post feel free to call me this especially if it’s less offensive than whatever you had in mind).

References:

• This Booz-Allen report evaluates R&D spending and supports the notion that pure R&D matters less, in a business context, than transfer.
• Mark Stefik’s book Breakthrough: Stories and Strategies of Radical Innovation was the best R&D management book I found. It’s interview centric to a fault and not the typical list of do’s and don’ts found in most management books - it attempts to provide a framework for how leaders of R&D should think about innovation with many supporting stories.
• There is a shortage of good books on managing R&D - trade secrets I guess. The closest thing to a recommended reference I found was The human side of managing technological research edited by Ralph Katz, a collection of papers that covers performance, process, invention and human nature.
• The primary reason research labs fail is that successful innovation depends on variables beyond our control - you can do everything right and still not deliver the breakthrough everyone expects - a theme explored in depth in the book.

Posted in Innovation, Management | 9 Comments »

Confession: I am in serious essay debt and I need your help to get out.

The story: I made a commitment when I quit MSFT in 2003 to publish an essay a month on the website. That’s 12 a year. Here are my stats:

2006: 5 (!)
2005: 12
2004: 10

So I owe the universe or myself (whomever cares more), 9 essays. That’s right. Not to mention the 3 so far this year that haven’t materialized yet.

I have plenty of ideas, but I’m bored with my ideas. I want yours. That way I’m guaranteed at least one person other than myself will give a shit when I post the thing.

So here’s your chance: If you could rent my brain to write something, what would the title of the essay be? What topic do you think I’m chicken to write about? What mean scary question do you want me to answer?

Lets get it on!

Posted in Uncategorized | 42 Comments »

One habits many managers have is to dump the boring, unpleasant work of their team onto contract workers. The thinking is that full timers deserve the best treatment and contractors are mercenaries: they deserve whatever they get since they won’t be around long.

It’s a mistake - good managers finds a way to treat everyone well. And there are some reasons contractors deserve special attention:

Here’s three reasons why:

1. Contracts are scouting missions. Smart companies hire interns since they know the one in five chance of finding a future employee are worth all the overhead. It costs an amazing amount of energy to hire a good employee. Any contractor you hire should be thought of as a potential full time employee - possibly not even for the skill they’re contracting for. Treat them like idiots in a box, and you’ll get idiots in a box. But give them a chance to outperform your expectations and your next star recruit might already be in your office. Sure this is rare, but it costs you nothing - tell them if they exceed your expectations you’ll consider, or refer, them for hire and see what happens.
2. Contract hires create your network. While you’re climbing the corporate ladder, every contractor has a long sequence of future companies and bosses ahead of them. What stories of you will they tell? If you ping them in 6 months about job openings on your team, will they recommend you to their peers in their new company? Contractors are true worker bees. They fly from place to place spreading reputations - will they be your ambassador or detractor?
3. They bring new ideas. Forget what job you hired them for - they bring experience your team might not have, and exposure to ideas new to you. If you constantly push their heads down into the pidgeon hole, never letting them advise or suggest based on their unique perspective, you’re cutting yourself off from potential knowledge. Give them a voice - again it costs nothing. If the three times they speak up with recommendations they sound insane, ask them to stop. But if you get some good ideas and reward them, they’ll be happy and so will you.

I can’t tell you how many smart people I’ve seen sequester away in the worst offices, never asked for an opinion and given no opportunity to shine, simply because they wore the label “contractor” - what a waste for everyone. Some contractors run circles around their FT counterparts - in fact that’s why they’re contractors: they’re good enough to make a living freelancing and taking part of the year off something many full-timers (FT) don’t have the talent, or the guts, to do.

The fear managers have is that treating contractors the same as employees raises legal issues, or threatens the full timers, but that’s nonsense - you don’t have to treat them the same in order to treat them both well. And if your team is threatened by talent, you’re in trouble for different reasons.

Posted in Management | 7 Comments »

The Myths of innovation book is wrapping up fast and it’s time to put together another crazy kick-ass no-frills book tour.

Stop 1: I’m planning to hit the bay-area for a few days in mid-May. For the last tour I spoke at Google, Yahoo, Adobe, Sun, Macromedia & Baychi. Do you have a venue and want me to come by? Now is the time to let me know.

Stop 2: I’ll also be doing local (Seattle) talks where-ever I can around the same time.

I can’t promise to stop everywhere, but if you can get a good, fun, (and hopefully book-purchasing minded) crowd together, I’ll definitely consider it.

Posted in On Tour | 3 Comments »

The fine folks at Moscow’s IT-Online have invited me to teach a one day seminar on management April 25th (registration here).

I’ve never been to Russia before and I’m looking forward to it - and I’ll be in St. Petersburg for a few days - If you have travel advice for this part of the world I’d love to hear from you.

Posted in Management, On Tour | 1 Comment »

Most people I respect have little respect for software patents - they’ve either read one, have their name on some, or have paid attention to who is most served by their creation (IBM has more patents in it’s name for each of the last 14 years). In all my research for the book I found little hope that the patent office was due for reform, especially for software, and had little hope for change.

So I was stunned when I read that the U.S. Patent office is piloting a new process for patents.

The news so far is thin and I can’t find official comments yet (couldn’t find a thing on the USPTO site):

Washington Post
ZDNET
Interview w/Jon Dudas from USPTO

(Note: Dudas’ full job title is the Under Secretary of Commerce for Intellectual Property and Director of the United States Patent and Trademark Office - his business cards must be 8×11).

Posted in Innovation, Software/Web development | No Comments »

Starting and stopping on time is easy. One person with power simply has to decide to care, the rest follows.

Having recently survived a tragicomic 8 way international conference call, an experience worthy of the 4th level of hell, I’m here to offer 5 honest tips that would have saved the day:

• If you called the meeting, do your %*?@?! job. Everyone claims they know about facilitation, but few do it. If you called the meeting, it’s your job to 1) get there on time 2) write a bullet list agenda on the wall 3) Manage the conversation so no one hogs the floor and the right people get a voice at the right time 4) make sure side issues get delegated out of the room. If you don’t do all 4, any meeting problems are your fault.
• Meetings start when royalty arrives. Watch the behavior of the senior person on a team. Most meetings won’t start until they arrive and people know it. If the VP is never late, no one else will be either. If the VP is always 10 minutes behind, everyone else will follow. If you’re a team manager, and meetings always start late, know (and blame) thyself. If you need a VP/VIP know where they’ll be before your meeting and escort them yourself.
• Someone must enforce the clock. Every meeting should start with someone assigned to watch the clock. I don’t know that you need a giant clock like Google is claimed to use, but it’s someones job to say “We’re 20 minutes in”, “we have 15 minutes left”, “we have 5 minutes, so lets wrap up”. You’d be amazed how many meetings ramble for half the allotted time on topics not central to the reason for the meeting. Three breakpoints are all you need to remind everyone to stay on track.
• Plan to end 5 minutes early. It’s insane but in all our infinite wisdom we continually plan meetings back to back with zero alloted time to get from meeting A to meeting B. Whose idea was this? If you always go to the last second, or go over, guess what you’re doing? You’re screwing over the next batch of meetings people need to get to. You’ll make unexpected friends by always ending early, which is easy if you watch the clock.
• Only have meetings that matter . If you had a meeting called “Lets discuss how awesome you are and how we can triple your salary” people will arrive right on time - the concept of a meeting isn’t bad, it’s what you fill it with that matters. If everyone is always late they’re telling you: this meeting is not important. Either learn how to make the meeting worthy of their time or don’t have the meeting. Ask for opinions at perennially late or poorly attended meetings: why does this meeting suck? How can this be more useful? Is there a better way to |insert why you think you need a meeting here|?

  Of course there are many different kinds of meetings so YMMV - But if you want more on this check out chapter 10, How not to annoy people, from of The art of project management.

Posted in Management | 28 Comments »