Before diving into this post on mentoring, teamwork, and brainstorming, I’ll provide a brief recap of my last post. In Part 1, I introduced physical product design through the eyes of a newly graduated general engineer, art, and science enthusiast. We reviewed three basic development balancing acts that pervade the product design and engineering space: 

1. DIY vs. teamwork
2. Intuitive “Direct” modeling (aka no-history CAD) vs. “Associative” (history-based CAD)
3. Fluid, spontaneous, iterative design   vs.   Planned formal and methodic design

I shared the basic differences between CAD systems of the time and my opinions, then and now, about the benefits and challenges of their use. I left you wondering what my opinion is of Balancing Act 1 above. Before I discuss that and the roles of mentoring, teamwork, and brainstorming in physical product design, let’s go a bit deeper into details of my early career, because there’s more to design than iteration and learning to use CAD tools. 

More on working at HP

I’d worked for 5 1⁄2 years at HP. HP has solid core values and thoughtful teams. It has large company momentum. It’s steady, proper, and (at least back then) slow to market: It could take over a year to get a single project to production … or to cancellation. The folks there were humble, proud, and accountable for their work. It was good work, sometimes quite innovative. But everyone only got small pieces to work on. HP was well known for making thoughtful conservative decisions. Each project was related to the last and usually well within the scope of the division’s charter. When product or project road mapping, HP reasoned that a division may introduce a new product:

• using known technology (knowledge acquired from that division’s actual development experience) in an established marketplace (built on that division’s market experience)
• using new technology in an established market or
• using known technology in a new market

But never using new technology in a new marketplace. This product roadmap philosophy was my first (small) exposure to product development decision-making and tactics that are now a formal and powerful field:  Strategy. In those days it seemed like roadmapping was driven by the division’s marketing group and section managers. I don’t know if the strategy process has changed at HP but these days many consultancies offer strategy teams to guide clients to informed decisions.

On the ID side, there was usually tension between the division’s ID teams trying to make the project their own and corporate ID trying to enforce company-wide cohesion; cohesion that, for the most part, corporate ID set. On the ME side, Roseville Terminals Division (RTD) had a whole team of Industrial Engineers who were MEs with manufacturing, production line design, and design for manufacturing backgrounds. This was in addition to the ME’s responsible for the actual product design.

Together we not only designed monitors, terminals, and eventually PC’s, but also the production lines that built them! HP had staff dedicated to document control and took a formal approach to design, engineering, pre-production, production release documentation and process. While each participant might be adding a small portion of a product’s development at any given moment, we were at least all doing it the “right way”, the “HP Way.” The “HP way” could be tiring but we generally accepted that this was how it needed to be, at least at large companies.

As far as I know, I was the only ME at RTD, who was interested in practicing both Industrial and Mechanical design. I worked closely with an official ID person, Henry J., who was very enthused about ME CAD tools and expressed a desire to practice ME in addition to his ID responsibilities. Ultimately (at least a couple of years after I’d left) he left HP, to start his own consultancy where he did practice both. I was excited to join David Kelley Design (DKD), where I hoped I could practice ID and ME design concurrently on a wide range of leading-edge products, and contribute in a bigger way.

To be clear, before hiring me, David pointed out that DKD didn’t do ID in-house; that I was being hired as an ME (though we agreed to call me a product designer). He vaguely explained that he was working out arrangements that might make it easier for me to practice both fields in the future, and that if he could, he’d give me the chance to practice both eventually.

More on working at IDEO

DKD was infused with energy and drive. Ideation, decision-making, and the projects themselves all moved at a fast pace. These coupled with huge project variety and tight supportive collaboration between engineers and industrial designers, enhanced the feeling of team spirit.

We were a collection of mostly young, motivated mechanical engineers with a few simpatico-enthused electrical engineers. We all seemed happy, at least for now, to be there. We shared a passion for technology, engineering, and design. We were individual contributors working with world-class, outside of DKD, industrial design consultancies on super cool products that our clients wanted to be innovative and market-disruptive. Of course, they also wanted it yesterday so many of us worked unsustainably. I slept under my desk on more than a few occasions.

At DKD the lead project engineer was also the project manager, coordinating schedules and milestones directly with the client. That same lead engineer usually met with potential clients and was involved in or sometimes solely responsible for writing the proposal to land the job. We had help and cajoling from executive leadership but we were involved early enough in the business development that by the time we landed a project we were completely accountable for the sometimes crazy schedules we’d signed up for.

Beyond the camaraderie and friendships I formed with many DKD-née-IDEO colleagues, and the wonderful range of projects I got to work on, a few of DKD’s design processes and development values really stood out. Those approaches to development permanently informed my work sensibilities. Here’s a short list of process rules I picked up at IDEO:

1. Fail often and early to avoid failing late. David (Kelley) called this “FLOSS”. I don’t remember exactly what the full acronym stands for: “F” stands for “fail”, “L” stands for “learn” and “O” probably “often”… I’m pretty sure “simple” and “stupid” are the “S”s. I must admit that I’m a much better “flosser” when it comes to product development than to personal dental hygiene.
2. Identify project risks early and figure out how to ‘proof-of-concept’ (POC) them to get risk out. POCs should be “quick and dirty” → high speed and low cost to build. POCs are not fit check models. They’re only meant to address an identified risk. Risk reduction through POCs supports the first rule: You might fail with your first POC, learn from it, and then keep producing quick, cheap POCs until you’ve validated an approach or even tweaked the solution to optimal before committing to any expensive models, hard to modify design architectures or tooling.
3. When considering solutions to a problem and before committing to a single solution, hold one or multiple brainstorms on the problem with a collection of participants with widely different points of view.
4. Always follow the rules of brainstorming (we’ll get to those shortly).
5. Always capture the results of your brainstorms in documents that non-brainstorm participants, including clients, can understand.

It seemed to me, especially in light of the pressure, budget, and deadline-driven environment — where we had to be creative and then follow through, that another rule that genuinely mattered to everyone was “ALWAYS HAVE FUN!”; a work hard, play hard culture.

My thoughts on DIY vs. teamwork, start from the community of design engineers I’d joined and their process rules above.

Mentors, design reviews, and individual contribution

It’s easy for motivated engineers to convince themselves that they’re getting things done faster by cutting corners — going straight to their first solution by themselves. Perhaps they actually are saving time right up to the moment they take a bad turn, decide to reinvent the wheel, make a bad assumption about technical feasibility, or push the design envelope a bit too hard. Looking back, I did a lot of good work alone, head down, in the zone. Given my personality and ambition, I’d started out preferring to figure stuff out, innovate, and create on my own. But my best work and the most impressive products that overcame the greatest challenges were all realized by coordinated team efforts. Looking back, I sincerely can’t call most of my work “mine” by any stretch, even when I spent hours and hours working alone on them.

Early in my career, I regularly answered and interacted with teammates, especially in my own field: peers and mentors. Then, and especially later in my career, the most stressful and least successful projects were those where I felt most on my own, misaligned with my customers (usually clients), or just technically completely out of my wheelhouse with no one to turn to for help. Mostly, I’ve been lucky to work on great teams with savvy teammates who had deep experience in a wide range of materials, fabrication & manufacturing processes. Early projects included M.E. mentors: Denny T. at HP and James Y. at DKD/IDEO. I regularly (at least weekly) checked in with them to share my progress and collect feedback. They helped me identify risk areas and kept my work balanced — meaning that they kept me considering and bringing up design details in parallel; not letting me dive too deeply into solving one problem area without at least making room in my layout for tentative solutions to other problems. They had enough previous experience to anticipate when conventional solutions could apply. They knew when to suggest a quick by-hand analysis and when I could just keep moving forward detailing with confidence. Sometimes they suggested how I might validate solutions with simple proofs of concept. They followed along more or less judging when I could find my own way and when I needed more specific coaching.

Most consultancies and corporations require design reviews before any design releases to model or tool build. I was regularly doing design reviews with Denny and Jim and others later. But design reviews aren’t the same as mentoring. Since those first 11 years of my career, I’ve missed my mentors, wishing I could run my layouts and potential solutions past them even if it meant they’d rip and reset them. Better to fail early!

Project phases and Brainstorming

Typical project cycles run in phases. In the 80’s and 90’s we categorized them as:

• Phase 0 or 1 – Concept development,
• Phase 1 or 2 – Engineering architecture and preliminary layout,
• Phase 2 or 3 – Detailed design,
• Phase 3 or 4 – Check model build, vendor liaison and validation,
• Phase 4 or 5 -Design release to pre-production, tooling vendor liaison, and tool de-bug (first article parts)
• Phase 5 or 6 – Release to production build

At HP, short of cancellation (which happened frequently), we’d work through all the phases (and beyond). As a consultant, even on successful projects, we seldom made it to 5 or 6 nor even 4 or 5; often we were hired to do only one or two phases and frequently we’d have to re-bid a follow-on phase as the project and its scope got clearer. Ideally, risk areas were identified, and proofs of concept built during phases 0 through 2. In addition to regular design reviews and well-timed proofs of concept, early effective brainstorms are often key to successful innovative projects. Most brainstorming occurred in phases 0 through 2 as well. If we got to detailed design and felt the need for a brainstorm it usually meant we were stuck. Most people accept the idea that good brainstorming can lead to great results. But they also presume to know how to carry out a good brainstorming session. Brainstorming is not pie-in-the-sky daydreaming. It’s also not reaching for the first idea that you think is going to work nor pointing out why your or someone else’s idea isn’t going to.

Good brainstorming output is the result of:

• Collecting a group of participants with great non-judgemental-in-the-moment attitudes,
• Concisely defining a single problem (or two max.), and then
• Staying on point while quickly collecting as many ideas as possible.

Once you’ve participated in a couple of well-run brainstorming sessions, you get it. They rock! And they often lead to ingenious non-obvious solutions. Throughout my career, after leaving IDEO, I’ve evangelized brainstorming and enjoyed facilitating them. The following are guidelines I share when joining a new company or when welcoming first-time brainstorming session participants. (By no means do I take credit for these rules. The art of brainstorming has been developed and refined by many great minds over the years. This is just my take on it.)

Brainstorming guidelines

TOP 3 rules for optimal brainstorming:

• DEFER JUDGMENT (Throughout a brainstorming session, don’t worry about whether your or someone else’s idea is good, bad, will or won’t work. While there’s a time to assess idea quality it’s NOT during the ideation)
• LEAPFROG! (During a brainstorming session, listen to other people’s ideas and try to build on them. You can also, of course, build off of your own idea. One thing leads to another)
• ONE CONVERSATION AT A TIME (In a brainstorming session, ideally there’s a facilitator and they and the group are listening to one person at a time. Interruptions and other conversations can’t get captured if they’re happening while someone else has the floor. If you have an idea, it’s fine to quietly sketch it while someone else is talking)

Other guidelines that really help effective brainstorms:

• It’s about QUANTITY NOT QUALITY → the goal is to collect a lot of wide-ranging ideas regardless of how good or bad they are. Typically the facilitator collects and presents after the session is over. While the group might do a communal assessment after the brainstorming session is over, (perhaps a 10-minute voting-w/post-its session), during the brainstorm it’s about effectively generating as many ideas as possible.
• DON’T GO MORE THAN AN HOUR → And watch the clock, especially if you’re breaking the session into different activities during the hour. Teams typically start losing steam after about 40 or 50 minutes. If you see that the group is slowing down (like when popcorn is ready), consider voting or maybe brainstorming on a different problem statement with the time left.
• STAY FOCUSED ON SOLUTIONS TO A SPECIFIC, CONCISE PROBLEM STATEMENT → Most of our work is complex with multiple problems on the same project. The more we can parse out and refine to single simple ones, acknowledging that there will be more brainstorms on other problems to come, the more likely that there’ll be a few great (judged at a later time of course) solutions in the pile of ideas generated.
• HAVE FUN! → (z)ANY ideas can be leapfrogged to practical ones and can be icebreakers for shy participants. Let go of your inhibitions, participate, and know that during the brainstorm there aren’t good or bad ideas… JUST LOTS OF IDEAS – FROM LOTS OF UNIQUE AND TO-BE-CELEBRATED MINDS! ;-).

We’re more likely to have fun if there are lots of pens and big blank sheets of paper scattered around the room. M&M’s or cookies help too. If you are the facilitator, be ready with these things ahead of the session.

Until recently, I insisted that brainstorms be done face to face with between 3 to 8 people in a room with plenty of whiteboard surface area (at least two walls of the room). The facilitator stands facing the group. They start by pointing out the “Top 3” main rules above which they’ve written on the whiteboard. They review the problem statement(s), also written on the board, and they go over the agenda which usually includes a short introduction to the problem, defined time periods for idea generation, and a wrap-up period where judgments are encouraged through voting.

Facilitators:

• keep the energy level high and the whole group engaged, (often using the same techniques I imagine a good improv performer might use)
• keep the group on one conversation at a time
• listen for and point out anyone making judgments, good, bad, or whatever, about any of the ideas raised during the ideation periods
• find ways to get shy folks to participate and to dampen aggressive conversation dominators without being discouraging
• keep track of the time and sincerely try to keep the group on point and schedule
• listen to, number, and quickly and concisely record ideas by writing a phrase or broken sentence or two on the whiteboard for each before asking the group for the next idea. If a sketch is needed, they should draw it super fast. Optionally they might invite the person with the idea to share it with a sketch – either on paper provided or up at the whiteboard, (this generally slows the group’s pace but also engages the participants)
• encourage leapfrogging, especially when idea generation frequency slows
• make the real-time decision to personally participate or pivot if the team is bogging down, perhaps by offering some ideas of their own. Offering up especially provocative or even ridiculous [admittedly a judgment] ideas can help the group back out of the box and stimulate more ideas. Alternatively, they might:
  • Introduce a different problem for group consideration,
  • Reword the original problem,
  • Review the ideas generated so far, looking for interesting ways to categorize them or
  • Initiate early voting where each participant gets 3 or 4 post-its. They vote for the ideas they like. If they feel strongly about an idea they can vote for one idea with up to all of their post-its. Afterward, each participant gets a chance to explain why they voted the way they did.

It can be quite challenging to host an effective brainstorm (BS). There’s usually at least one person who hasn’t bought into the ‘no judgments till later’ rule. They might be focusing on why all of the ideas just won’t work. They might think that their idea is the only obvious idea and everything else, including this BS, is a just waste of time (and money by the way; the more participants the higher the burn rate for the client). The facilitator works to quickly and diplomatically contain the argumentative folks all while keeping it light and keeping it from becoming an ego competition. A well-facilitated brainstorm can easily generate 40 ideas in 50 minutes. I’ve seen groups approach 80 unique ideas from time to time. After facilitating a productive BS, I’m usually exhilarated and exhausted. Usually, I’ve formed a strong opinion about obvious opportunities for success and I’m ready to go back to my cube to detail away in CAD… But it is super important to remember process rule number 5 above: “Always capture the results of your brainstorms in documents that non-brainstorm-participants, including clients, can understand.”

The after brainstorm work

It’s natural to want to “get back to work,” moving to next steps after a brainstorm. At a truly solo startup or for a completely DIY project where you wear all hats and no one will ever care about your thinking, that might be fine. But in our real world of reporting, regulatory, development teams, and collaborative dependencies, the first thing the facilitator does before walking out of the conference room is to take pictures (panoramic or tiled) of all the ideas listed on the whiteboards. (Usually, but especially during a prolific BS, I’ve had to pause to take pics before erasing the boards and continuing with ideation). Then they gather up all the loose sketches participants made during the session, confirming that the idea number on the sketch matches the idea number on the whiteboard. It can easily take hours to go through ideas, throw out the repeats and create a summary document. This includes sketching for each idea to further refine or at least clarify it. The sooner you do it, the more likely you’ll do it well. By the way, video recording the brainstorm, (a great idea) is not a valid substitute for these post-brainstorm steps: Participants’ ideas deserve thoughtful archiving, bringing out the brilliance of ideas that otherwise might be interpreted as vague, ambiguous or fantastic. BS facilitators get the last licks. They are usually the final filter before the client reviews and decides if the whole BS was worthwhile.

A note about modern and virtual brainstorming

Facilitators and participants often do their real judging and sometimes add new insight after the brainstorm. Perhaps these ideas will be captured in the summary, or perhaps not. Be sure to share a link to the summary with all of your participants. Also, give them a space to add refining ideas, links to references or new thoughts. It’s especially easy to do today with applications like Miro, Slack, Google Docs, and Sheets. In the last 3 years, all of the brainstorms I’ve attended or facilitated, have included a virtual component. Miro can be used instead of whiteboards for 100% virtual brainstorming. Generally the problem today is choosing which apps to use and learning how to use them effectively. Finding apps that include natural, fast sketching interfaces is also challenging. Even as I attempt to transition to tablet-based drawing and journal keeping, I continue to put a Pilot Razor Point or two in my pocket and carry blank numbered physical personal and work journals with me at all times!

In the end, regarding brainstorming and documenting designs, design thinking, and decisions, it comes down to personal attitude, discipline, and consistency. If you get hit by the proverbial bus or you just move on, the rest of the world may thank you for your attention to these.

Work After IDEO 

DKD, ID2, and Matrix successfully merged to become IDEO in the first quarter of 1991. By that summer, while our director of ID (I’m not sure if this was his official title) was on vacation, David gave me the chance to work both ID and ME concurrently. I was assigned phase one of a personal dream project – cycling computer architectures and concepts for Specialized. Specialized was trying to decide whether to make their own from scratch or whether to OEM (Original Equipment Manufacturer) it. We hoped they’d hire us for a design-from-scratch approach. The Palo Alto studio lead industrial designer, Paul B. was asked to mentor me. We started the project together with me doing concept ideation, and working on the ID, ME, ME architecture, and POC’s concurrently. The first two weeks went swimmingly well from my point of view. I preferred to sketch in pencil and mixed media rather than the traditional marker pens, and I was doing non-aesthetic computer architecture and mounting POC’s right out of the gate. My foam and physical modeling skills weren’t honed, but I worked with others who were fluent and world-class. Two weeks into the phase, our ID director returned from break.

I don’t know the details, if any, of discussions prior to my having taken these roles. I also don’t know what was discussed after the ID director returned. But he and others at IDEO were very concerned and shared a number of admittedly valid reasons why I should not be practicing both ID and ME for IDEO in general. He and David agreed that I could finish out the phase. He proposed that if I wanted to apply to work as an industrial designer at IDEO, I could submit a portfolio and interview for the job. We finished phase one two weeks later. As far as I could tell, Specialized was happy, but ultimately they chose to oversee an OEM approach to cycling computers. Specialized did continue to call on IDEO to help with other interesting challenging projects. I worked closely with ID teammates at IDEO on a number of cool projects after that, but I was strictly and officially an ME. In the early spring of ‘94, I left IDEO to join a startup, Creative Insights (CI), as head of ID and ME.

I hope to share takeaways from CI, Moto Development, BlackTop Design, Speck Design, Speck Products, Speck China, Made Products, TouchFire and EchoNous in future posts. I left IDEO so I could practice ID too. I started my own gigs or joined startups so that I could do bigger and bigger pieces of the design and see it all the way through. But I wonder how it would have worked out if I’d stayed. IDEO was so impactful that I periodically have “returning to IDEO” dreams much as many of us have 1st-day-of-school-naked-and-can’t-find-your-locker-etc. dreams (I have those too)!

It’s been nerve-racking from time to time and project to project, but I really enjoy product design and engineering. In my career, I’ve progressed from an obsessive with a solo focus to more and more appreciatively collaborative. I love working in the concept phase, sketching out architectures and possible solutions, reviewing and drinking the Kool-Aid of inspired Strategy and ID teams’ visions. Of course, I always hope to be involved with them as early and as meaningfully as practical. But, oh my: I had no idea how much fun I’d have identifying the challenging bits, the significant risks and BRAINSTORMING! I also keep discovering that things go better when others are involved. No matter how brilliant anyone seems to be, they just can’t do it all by themself. They can’t hope to be there on time, with optimal solutions if they’re truly working alone; at least that’s how it seems to me. When it comes to balancing act #1: DIY vs. Teamwork, it truly is a balancing act. We can’t get great work done without doing a lot of the work solo with determined focus nor without involving colleagues of differing points of view and skills. A well-run project needs at least your immersed pair of eyes with multiple other pairs checking in from start to finish. In a word, my final answer to DIY vs. Teamwork is emphatically, “YES.”