I think Bill shines some light on a big issue that doesn't get the due it deserves in terms of advancing the cause of more effective, more efficient product development. Process improvement is one of those necessary evils that people love to gloss over, particularly engineers who often want to cut to the chase of tinkering with and discovering new innovations without being burdened by what they see as boring, institutional boilerplate.
In reality, that mentality couldn't be more wrong. Bill lays out the very strong case for instituting processes within engineering that not only enourage and promote the exploration of advanced technologies throughout the entire engineering team, but also to do so early on in the cycle so potential problems and potential better solutions are found earlier, rather than later when it is too late and far too expensive to make changes.
Beth, thank you for your comments. You have highlighted another topic that I will be writing about soon, and that is the tendency for development teams to stick with only one design concept, which creates a ripple effect of difficulties in later stages of the project.
Bill, I hope companies will pay attention to your recommendation that engineers should be spending 2 - 3 hours a week on advanced development activities. It's absolutely essential for engineers to stay on top of the latest technology -- as much for their own good as for the good of their employers. And it's essential to do your homework before embarking on a new project. To a large extent, the success of a project is determined before the project starts. The best solution is a continuous commitment to advanced development.
Nice article. The 5% recommendation for advanced development time is reminiscent of the old (maybe it's still exists) 10% rule at 3M. As I recall, 3M actually used to allow engineers to set aside 10% of their time to work on any kind of development (advanced or otherwise). I believe that's how Post-It Notes were created.
For most companies, five percent devoted to assessment is a more manageable and realistic goal than the 20% that Google supposedly allows employs to devote to researching stuff that's not part of their job. At the same time, even 5% is a lot in the high-pressure, fast time-to-market, lower headcount world many of us work in. Let's hope they take your advice, Bill.
Oh, please! Management giving engineers or anyone 5% of their hours each week for 'non-productive' (their words) work? The chances of that in today's world? Approximately zero. Sure, there are a few companies (and high 5's to them!!) that do. And probably many more who used to. But today? Hah!
So I am a pessimist - well, I've been around for a long while so I guess I am entitled to be.
In the real world, the drive to efficiency and productivity has firmly shut the door on most (I almost said 'all' but that would be pessimistic) non-funded, tightly controlled projects. In some (most?) companies, the marketing folks have total control over the budget reins and, if a proposed project does not have a specific cost savings, it will NOT be funded. Such an environment (very oriented to immediate and short term financial results) does provide for a healthy and profitable company.
Even 20 years ago, my attempts (even as a manager) at implementing even limited opportunities for projects outside the normal marketing centric world. The answers ranged from a flat 'no' to '..you can spend as much of your time as you want' (sure, when I was already working 60+ hour weeks).
@BobGroh: You're probably right to be pessimistic about this. But if companies want engineers to focus all of their energies only on current projects, they are potentially undermining the success of these very projects. As I pointed out before, a big part of a project's success is determined before the project starts. Companies neglect these "pre-Gate Zero" activities at their own risk.
@Dave Palmer: you are totally right. But it is a very hard sell. And it doesn't stop just with 'pre-Gate zero' activities. At my last employer, they were very big on design reviews all along the design process. A very good thing.
BUT the design reviews were just a meeting in a conference room with 30 or 40 other engineers there for a couple of hours. You talked about your design, got a couple of comments and the meeting done. You then wrote everything up (comments and responses) and, bam, all done.
How much better if the design review had been a real design review where you had 3 or 4 engineers from other departments or projects who spent some real time really digging into your design. Well, I tried doing that one time and got roundly slapped down by the managers in the other department - they were not about to have their engineers taken off their present assignments to 'work' on your project. No way. Anything more than one meeting (couple of hours) - nope. Not here. Not now. Not ever.
"This approach leverages engineers' natural curiosity and their desire to learn new things, but keeps the activity aligned with organizational goals. Engineers spend this time gathering information about the technology, conducting experiments, creating concept prototypes, and identifying potential changes needed within the company -- all in an effort to learn how the technology works and how best to incorporate it into new products."
I want to go to work for you, Bill! This is a test engineer's dream. And while I agree with your ideas completely, unfortunately most companies I have observed remain short-sighted in this area. The current economy has caused many companies to run on smaller staffs and people are required to handle larger workloads, especially where down-sizing has occurred. While I absolutely advocate your ideas, I am thinking that we won't see companies operating out of fire fighting mode until the economy gets better, no matter how much sense it makes to do otherwise.
I respectfully disagree with the idea that advance development efforts can be done by the same product group spending 5% of their time on advance research.
I've spent my entire career at big companies (household names you've all heard of) and have logged years in both product development engineering and in advanced R&D roles.The best solution to keep profitshigh (meaning continual new product releases, i.e. cash flow) -- is the one that big companies do – they segregate the two roles.
For the Development Engineering Team, their job is to get the product to market.Their effort is Schedule and Cost driven (aren't they always-?) and they have aggressive milestones and timelines to meet. They cannot afford the risk of obstacles caused by various "unknown's" such as Bill is referencing.
The solution is the Advance Development Team, a separate team who works on bread-board and proto level products to test and characterizes the interaction & behaviors of the desired new feature.For example, to use Bill's example of adding a modem to a product; an embedded modem on a dual transceiver board facespower drain issues, transmit signal strength interference, and cross talk between circuits,-- just three of many problems that can happen, which the Advance Development Team must examine.
There are always solutions – sometimes even easy answers – but the Product Development Team doesn't have the time to mess around with ANY problems.They need to keep their heads down, designing with only "known's," and maintain the sprint toward the goal of the market launch.
To Bill's point of the engineers natural curiosity as the catalyst forsuccess; I do agree with that; but even AdvDev gets routine after several programs. So a good solution is to rotate your staff between the two groups to keep them always fresh.They appreciate the change of pace.
The first Tacoma Narrows Bridge was a Washington State suspension bridge that opened in 1940 and spanned the Tacoma Narrows strait of Puget Sound between Tacoma and the Kitsap Peninsula. It opened to traffic on July 1, 1940, and dramatically collapsed into Puget Sound on November 7, just four months after it opened.
Noting that we now live in an era of “confusion and ill-conceived stuff,” Ammunition design studio founder Robert Brunner, speaking at Gigaom Roadmap, said that by adding connectivity to everything and its mother, we aren't necessarily doing ourselves any favors, with many ‘things’ just fine in their unconnected state.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.