Rome wasn't built in a day, but it burned in one--I use this common saying when speaking to my teams about collaboration. I wonder what epic fails or team implosions were in 70 AD, especially since completing the Colosseum took about 10 years. To better build things together, I believe engineers and designers must understand and practice three primary principles: 1) Lean doesn't mean faster; 2) Sharing is caring; and 3) The closer, the better.
Lean Doesn't Mean Faster
A misconception about using lean or agile methodologies is that they expedite project completion timetables. Sometimes that's the case, but I like to explain to my clients that when we say lean, we mean smarter. It's the responsibility of both the designer and the engineer to work together to find the smartest way to deliver the desired result. Of course, that's the crux of it--figuring out how to get them working together first. "The challenges are legion," replied Dean Barker, Senior Director, Optum Technology Engineering, when I asked about his experiences managing teams.
The issue is part cultural and part process. The Agile movement offers a partial formal solution by creating shared ground rules. The Agile culture subsumes the other more functionally oriented cultures, offering a process framework that allows teams to define their work in more detail and leverage the best practices of their disciplines in a cooperative environment. Agile methods may not be 'designer-friendly' out of the box, but they can be tailored for UI design and UX practices. (Dean Barker)
Agile methods help breakdown and reframe legacy production and process habits, enabling a more open, cooperative team mentality. You need to allocate resources (usually time) for a team to get lean, work smart.
Determine your end goal. Is it get the product out with time and budget constraints? Or, is it get the product out right? The graphic below is based on Erwind Frand's popular advice, "Good, fast, cheap: pick any two."
Sharing is Caring
Recently, I read a series on Medium, "How to Work with Project Managers, Engineers, and Designers," written by Julie Zhuo. She explains that designers should take time to explain to engineers the design thinking/reasoning behind their designs. I couldn't agree more. By sharing knowledge with one another, they'll be a team capable of real innovation, not concept-only work.
Experience does not liberate designers or engineers from the sharing is caring principle. Your title does not matter. I expect steady communication and collaborative work habits (no silo-building). Form, function, process: the more each individual understands about their co-worker's process and vision, then the better everyone will be on delivering future projects.
In my 7 years with Next Jump, I've found that the best situations are created through early and often collaboration. If the engineers go off on their own and then come back to the designers asking them to 'clean it up' or 'make it better,' then things don't always turn out well--the same goes for the reverse scenario. No one wants to be a tool used to produce someone else's work; there is something to be said about the pride and ownership of something that is created together. (James Pellizzi, Senior Director of Interface Engineering)
Silo-ed teams or individuals create opportunities for damaging assumptions and missed details, and ultimately, produce a weaker product.
Have you tried thumb wrestling competitions to jump-start collaboration? When I see teams struggling, I pair up members for impromptu thumb wrestling matches and say, "The team with the most wins, wins." Then, I give them 30 seconds to wrestle before asking for their results. Five, 10, 15--usually, it's individuals, not teams, who raise a hand when I ask for win totals. I act surprised and remind them of my words again, team with the most wins. Hopefully, they get it now. To win, they must stop struggling against each other and work together, taking turns surrendering so they can rack up the wins as a team.
Here are a few other sharing is caring activities:
- A role-playing meeting where a problem is defined, everyone draws a team member's name from a hat, role plays as that member, and collaborates to solve the problem
- A problem-based innovation workshop, pairing engineers and designers, but rather than co-presenting their work, they must present each other's work
- A product envisioning activity comprised of three groups: only designers, only engineers, and designers and engineers; discuss and determine which team has the "winning" idea at the end
The Closer, The Better
Tensions between engineers and designers usually arise when collaboration is scarce. It's not a coincidence that collaboration contains the word labor. Sure, spending resources for team building sounds like a waste of time when we have client work waiting, but it's also wasteful for designers to just finish a design and pass it along for implementation. Yes, this myopic process will help you achieve project milestones, but it will not consistently produce exceptional products.
Ideally, I have a researcher and designer working side by side on each project because I truly believe that design is powered by insights gathered through research. The engineer/designer relationship should be no different than the researcher/designer relationship. To avoid snags and save time, each project member should be able to ask direct questions and provide quick, ongoing feedback. Of course, it takes practice to navigate all this directness and collaboration to successful outcomes.
On Fridays, our Motivate Design team gathers for a design and innovation discovery session. After one team member poses a problem, we spend 60-90 minutes creating a few viable solutions. This friendly, open-minded session allows designers and engineers (and everyone else) to better develop collaborative mindsets without the pressures involved with client work. They learn each other's work practices, communication styles, and more, which develops more cohesive, empathetic teams.
When these three principles are in play, you create an unstoppable, colossal force. At the micro-level, individuals become better team members. At the macro-level, having sharper, leaner teams means getting to an awesome product, not good one.