The Crucible of Innovation

My quick survey of popular business publications seems to indicate that “innovation” may be the modern business equivalent of “abracadabra.” The short version is that with unfettered (even uninformed) imagination, absolute freedom from process, and of course a large enough supply of sticky notes, you too can hatch sufficient break-through ideas to fix nearly any business issue – especially if you can trek through the woods or scale a mountain (but make sure to bring extra sticky notes).

Forgive my facetiousness; it’s just this that kind of stuff drives me crazy! To be clear, there is no doubt that innovation is incredibly important. But there is a far more organic, seamless and effective way to cultivate creativity and collaboration in your organization. And it is likely a practice that you are already doing. It is also one that will help to create an ongoing development cadence and act as a powerful cultural transformation lever. I am talking about design reviews.

Design reviews are an oft-overlooked, even maligned opportunity for real-time innovation. But I’m not talking about what passes for design reviews in many companies. You know, the type that act as a poor cousin to a status review; “wirebrushing” people who identify issues and grilling engineers for design release-dates and tool starts. Or the pre-milestone “dog and pony show” type that serves primarily to give senior management a much desired, but usually false, sense of security. The ones where an engineer’s primary objective is to “get offstage” with minimal negative exposure and never violate the tacit agreement that if you don’t pick on mine, I won’t pick on yours. 

Design reviews can be the heartbeat of your development project and a critical part of your overall development operating system.

Design reviews can be the heartbeat of your development project and a critical part of your overall development operating system. They provide a common link for distributed teams and are a primary mechanism for learning and doing, at program speed. Generally, I think in terms of two broad categories of design reviews. The first is a cadenced review used to surface and resolve technical issues in a timely manner. It provides a consistent, recurring forum with required cross-functional participants to work on inevitable technical challenges, thus preventing the waste of engineers chasing down much-needed help. The second type is system focused and scheduled in support of key integration events. These typically involve representatives from the entire development team, who focus on interfaces and interdependencies, and are scheduled such that sufficient time is allowed for post-review work without disrupting the program.

In either case, they should be challenging, rigorous and above all, alive and energizing. They should raise performance expectations for both the product and the team with the aim of making both ever better. This is not a “check-the-box” event; far from it. It is a demanding crucible of ideas – testing, challenging and improving. An event that generates both heat and light. It’s not a PowerPoint show. Participants should bring only those materials they are already using in development such as early prototypes, test data, simulation results, or CAD with perhaps a one-page problem statement. The events themselves should be held at the gemba whenever possible – this creates powerful dynamic. And importantly, problems are not an anomaly and real time learning is why you are there.

Design reviews are a tremendous opportunity for people development and cultural change. They are an opportunity for leadership to evaluate both design solutions and the thinking behind them by asking probing questions and actively coaching in real time. More importantly they are an opportunity for leadership to demonstrate those behaviors they expect from their teams such as collaboration, experimentation, rigor, detail and ultimate ownership. The environment is not punitive, in fact there should be far more pressure on leadership. It is about stretching the team, self-pressurizing to achieve more together than they ever could separately.

Although initially uncomfortable, your team will begin to thrive on these events, relishing the opportunity to engage and grow as engineers and leaders as long as leaders remember to ask tough questions and challenge ideas, but always support their people. This is not a place for individual performance reviews or finger pointing. It is about working as a team to continually improve in order to deliver ever-greater value to your customer.

Here are a few points you may wish to consider as you think about your next design review:

1. Actively manage the agenda and scheduling. Make sure all the right people are there for the right discussions – and not present when they don’t need to be (wasteful). Also be sure to allow sufficient time for in-depth dialogue on topics. Event-driven reviews should be scheduled such that they allow time for work – but also create a cadenced (perhaps weekly) review to surface and work through breaking issues.
2. Participants, especially leaders, should be prepared. Send out critical info in advance whenever possible. Presenters should have a clear problem statement, show work to date and alternative solutions (A3s can be useful for this). This is not a place to just dump a problem.
3. Hold the review at the gemba whenever possible. Make sure actual product, critical data or CAD is available. 
4. Leaders should ask probing, meaningful questions. Not play “stump the chump” to show how smart they are or just provide answers. If you choose the former, people will shut down, if the latter you will soon find yourself owning a lot of problems.
5. Encourage robust and candid dialogue – ask the tough questions. Creative tension is an important part of creating great products. But never, ever allow attacks on people. Think about interfaces and interdependencies, and where the program is in the development process.
6. Remember to “do the experiment.” It’s not a debate club. Ask how can you effectively test a hypothesis.
7. Capture and apply knowledge. These are your learning cycles, your opportunity to enforce, update and create standards through learning. Be sure to fully leverage existing knowledge and capture new information.
8. Design reviews should be a foundational part of your overall development operating system. In larger organizations an integrated network of design reviews may be appropriate. And participation is not optional.
9. Set high expectations for both the product and the participants. But set even higher ones for yourself.

There is no potion, no incantation, not even a magic e-letter that will transform your organization into an innovation machine. It requires hard work, focus and perseverance – but that’s the point, isn’t it? Creating innovative solutions and delivering new value need to be part of who you are and built into how you do your work every day. 

Are your design reviews contributing to that goal?