Just had lunch with Jeff Darcy who is back on the street looking for work. If you're looking for a guy who can come up with a solid software architecture (especially when it comes to storage-related architectures) he's a great choice. He made the interesting comment that when it comes to cloud-based efforts, there seem to be a lot-more cloud-startup companies on the West Coast USA, while here on the East Coast cloud innovation tends to be happening at more established companies.
He also gave me a zinger during lunch when he said "Steve, you need to post more on your blog". He didn't want to hear any of my whining about "crunch time" at work. Note to Jeff's potential employers: "He tells the truth no matter who is in the room". LOL!
I thought I would hustle back to work and try and crank out a post before Jeff got back to his RSS reader.
Blogging/Innovating During Deadlines
My argument to Jeff about letting blog posts slide as a result of engineering deadlines is a bit hypocritical. One of the efforts I've been pushing within my own team is the theory that all of us should be carving out times during our day to see the forest through the trees. EMC invites all employees to do this as part of its global Innovation Contest each year (the 2009 contest started last week by the way).
We've had some pretty big software deadlines recently. Simultaneously, we've had some requests to begin planning next-generation products. The next-generation planning process usually involves carving out some time from the key architects within the group (maybe 2-4 people), while the rest of the masses stay in the trenches debugging and adding quality to the product.
The architects are traditionally given permission to innovate during the deadlines.
This can be a bummer on several levels. Firstly, a large percent of the team don't get to do "the fun stuff". Secondly, the people in the trenches during a deadline are often at alpha and beta sites gathering key input firsthand. This type of first-hand exposure is critical in the planning of future products. And finally, the people in the trenches feel the most pain when it comes to development processes. Trench players are the perfect people to answer the question: "Is there a way to increase development speed and quality?" Process ideas are often the most powerful.
Enter Innovation By Contest
The innovation-by-contest paradigm that EMC has been espousing for the last several years is starting to occur at the individual business unit level as well. My group is currently right in the middle of its own idea contest, with a focus on ideas for the next generation product. If anyone enters an idea it becomes part of a "level playing field" of ideas.
The mechanics of this type of approach are straightforward: every idea has the same visibility, co-workers can rank and comment on the ideas (stimulating collaboration), and managers can engage their employees by officially assigning their ideas as MBOs or goals for the rest of the year.
Perhaps the most important employee opportunity is the chance for increased recognition. This morning, three of my co-workers from Russia presented further detail on their ideas to the VP of my business unit and his staff.
Innovation contests are low-touch and high-value. They are low-touch because it only takes 5 minutes to enter the idea into the system, and maybe 15 minutes to browse the ideas during the day. In the grand scheme of things this is negligible and does not affect deadlines. They are high-value because of the morale impact: management is presenting an opportunity for anyone to participate in the beginning stages of development (where innovation can often occur). And most importantly, the ideas that are coming in are really, really good. I've been seeing about a dozen new ideas per day.
This is why I believe that innovation-by-contest is a most effective organizational innovation tool. Contests, and the ideas that come with them, are refreshing.
And there's nothing wrong with a little refresher during a deadline.
Steve
http://stevetodd.typepad.com
Twitter: @SteveTodd
Comments