Blog

Playing Nice: The Power of an Integrated ID and Engineering Team

Fall is not pumpkin spice latte time, it’s college football season with its wonderful rivalries.  As much as Buckeyes despise Wolverines, we have to admit the game would not be as rich without worthy adversaries.  Great design teams have rivalries too, although they have a lot more mutual respect and less overt contempt.  We think great design teams need a little rivalry to function best.  Not all industrial design firms have in-house engineering.  At Juggernaut, we have talented teams of both industrial designers and mechanical engineers.  We believe that this ‘rivalry’ is an asset that creates better outcomes. 

Arguing Right

I’ve met people trained in both engineering and industrial design.  While it may be possible for some people to develop both skills, I think two people working together can do a better job.  It’s important to the design process to have healthy arguments.  It’s easier to argue with team members than it is to truly argue with yourself.  Considering both sides of a problem is not the same as arguing about it.  In the design process, the industrial designer is an advocate fighting for user experience and visual design language.  The engineering team advocates for function, reliability, cost targets, manufacturability and risk reduction.  It actually helps a product to have these independent functions argue and advocate for the aspects of the design that are their responsibility.  BUT – as you can imagine, this process absolutely relies on the ability of each function to argue effectively and to concede when it’s right for the design.  The same advice I give recent grads looking for their first job applies here too: “One @$$^*&% can ruin everything”.  In other words, team health is paramount.  We work on this at Juggernaut, reminding each other that team health is not about avoiding conflict, but rather arguing well and at the end of the day earning each other’s respect and abiding the end result.  In Gino Wickman’s book Traction, he writes:

If an issue is starting to hit home and the solution causes you discomfort, you must try not to push the solution in a direction that’s more favorable to you or your team.  If you do, you aren’t fighting for the greater good of the company; you’re just protecting your turf.  You should have healthy conflict and let the best solution come to light, even if it causes you some pain.

Wickman’s EOS system has a structured implementation of this process called Identify, Discuss, Solve (IDS) that our teams practice every week.  It has helped our team argue for design solutions in a healthy manner that is best for the product.

Preventing Blue-Sky Paradox

A team that dreams too big can really hurt a project.  It’s important to manage the stakeholder’s expectations of what can feasibly be delivered in the real world with budget constraints, manufacturing, durability, technology etc.  I first heard this idea named in a Harvard Business Review article “They Bought In. Now They Want to Bail Out.” by Eric J. McNulty

I think you are in part a victim of what I call the blue-sky paradox. You have to get people to dream big dreams in order to sell the project. But by doing that, you also set them up to be disappointed. Eventually, they have to come to terms with what’s really achievable and how much it’s going to cost and how long it’s going to take, and they lose faith.

Knowing that this occurs, we can internally dream big but then dial it back just a little when presenting ideas to all the stakeholders.  It’s important not to present concepts that will never have a reasonable chance at execution.  Integrated ID and engineering teams act as a reality check for each other in this regard.  When reviewing ideas internally, we will consider not just technical feasibility, but other idea killers like cost, time and risk.  Of course, we present concepts to the team that stretch what’s possible, but there’s no reason to get everyone salivating over something that’s just never gonna be possible.

Who Takes the Lead?

Most projects start with the industrial design team taking the lead on design concepts.  As an integrated team though, we recognize that certain projects are going to come conceptually from engineering.  We’ve done a great deal of work on adjustable mounts for flat panel TVs.  In the early days of flat panel technology, TV’s were several times heavier than now.  That meant that a new design was initially an engineering problem, answering the question: how can we support the weight safely, cost-effectively and get the range of motion we need?  A well-integrated ID and engineering team can swap these lead roles when it makes sense without causing a rift.

Reduce Risk but Keep an Open Mind

We rarely work on projects for companies that don’t have internal engineering teams.  Client’s engineers who don’t regularly work alongside industrial designers can be skeptical and guarded.  This is natural.  They are usually left to “clean up the mess” when eager visionary stakeholders like CEO’s and Marketing execs in their company over promise.  Having our engineers working closely with our designers gives the client engineering team the confidence to see that they won’t have to be the lone voice of dissent.  It’s demoralizing for client engineers to be perceived by their company visionaries as the one who is always crushing dreams.  Our engineering presence alongside ID provides a voice of reason and allows them to be a little more open to new ideas knowing they won’t be the sole voice of dissent if the idea ends up being infeasible.  Product cost can also make client engineers unpopular.  Some design teams ignore cost until late in the game.  Unfortunately, that pushes the ugly task of saying NO down to the client engineering team.  It can also lead to a lot of wasted effort and disappointment.  Our integrated ID/engineering approach uses the concept bill of materials to combat this problem.  By keeping costs in mind at every stage, we can reduce the risk of late-stage surprises.

Trust the Implementers

A designer is free to explore more concepts when they trust there is a good team to execute the engineering.  A simple yet powerful example of this is CAD models.  When we build CAD models for the purpose of industrial design, they are meant to communicate a vision.  When we build CAD models for engineering, they are meant to communicate dimensions precisely.  Therefore we almost always rebuild those models when moving from ID to engineering.  This allows the designer to move quickly with the CAD modeling process knowing that tiny mathematical imperfections like draft angles and clearances will be worked out by engineering.  Trying to do it all at once would hamper creativity.  It would be penny wise and pound foolish.

Engineers Should Not Play Designer

One of my mentors, Roy Fischer, taught me what he called the “student factor”.  It was when seemingly small details were overlooked.  Details like flat surfaces (that should be crowned) on molded parts that we know would look wavy when mass produced, or parting line details without a small reveal that would line up poorly.  The same sort of thing happens when we see work where an engineer obviously decided to play designer.  We see bad proportions, poor ergonomic balance, overuse of large radii, ridiculous branding to name a few.  There are times when an honest engineering detail like a heat sink can be a thing of beauty and be incorporated into a design, but it’s almost never done well with an engineer acting alone.

These are just a few examples of how an integrated team of both designers and engineers can add real value to the product development process.  Collaboration with honest discourse from all perspectives can drive more valuable and successful results.

Comments are closed, but trackbacks and pingbacks are open.