Getting to high-performance with design teams
Let’s start with the obvious: high-performance teams require highly talented professionals.
Let’s follow with the less obvious: many failing teams are staffed with highly talented professionals. Teams that fail to perform typically lose their most talented people first. And there are few incentives better at retaining highly talented people than team performance. Everyone wants to be part of a championship-winning team, even if “championships” in the business world are more abstract than in sports.
My IBM design team in San Francisco
Approaches:
Start with a shared vision, clearly communicated.
Everyone loves to use Apple when discussing high-performance teams, but it appears they have one of the biggest team failures in modern business history in their car project. And all signs point to a lack of shared vision as the culprit - was it to be a self-driving office space? A conventional electric car? A bunch of car-related technologies? It seems that misalignment of vision resulted in a failure to launch anything, despite having 2,000 highly-paid professionals on the team.
First and foremost, have a product design strategy that everyone understands and can rally behind.
Our Design Principles for Ontada, a fantastic tool for alignment
Build a creative culture.
There are two parts to this. First, you need to provide space, support and aircover for the design team to learn & ideate on the problem space. They’re good at this, with some focus they will come back with priceless thinking. Second, you need to align the rest of the team (product, engineering, planning, program management etc.) around creatively solving problems. Design Principles work wonders in getting teams to agree on approaching problems differently (to be discussed in a later post).
Communicating mutual respect.
So many product development organizations have developed antagonistic relationships within teams. The leaders set the example - if they remember that each core function wants to create a successful product but they all define success differently, they can get their teams to work more collaboratively. Design defines success as users happily and effectively using the product, engineering defines it as reliable and efficient functionality, product as delivering against business targets. And they are all correct - miss badly on any of these aspects and there’s no point in hitting on others.
My design team at IBM created this video to share across IBM Design
Aligning people with their passion
Every designer I’ve ever worked with has unique skills and passions, beyond what was described in their job description. For IBM’s DSX, we had a designer who loved creating logos - she created a beautiful one for the product in time for launch. If we tried to use corporate marketing for the logo we never would have made it. And when the development team fell behind, we had a few designers create an introduction video for the launch event (watch it on our DSX case study page). It was so good, Gartner moved IBM up in their Magic Quadrant without having actually seen anyone use the product (“DSX is likely to be one of the most attractive platforms in the future — modern, open, flexible and suitable for a range of users, from expert data scientists to business people”¹). What was the ROI on that effort?!
Planned movement
Churn burns teams out faster than almost anything. My favorite expression when it comes to prioritization is “designers aren’t fungible”, and it goes for other product development professionals as well. How many times have managers said “I need a designer”, not recognizing that a staff designer can’t provide full value until they’ve engaged on the problem for weeks or more?
The opposite can occur as well - designers are so valuable to a team they get stuck on one problem space for years. A comfortable (probably bored) designer isn’t likely to deliver their best work. My goal was always to have ‘molasses’ team movement - continual, but very thoughtful & gradual movement among designers & problem spaces.
David leading an ideation session at Sony’s Tokyo headquarters
Sharing & understanding ideas
Ideation isn’t just for Design - in fact, it’s best done with Product & Engineering (we call this “three in a box”). At Microsoft, we ran ideation sessions with our peers on the team, and even with partners. I led working sessions with internal teams as well as Sony, HP, Acer & Asus during the ideation for Windows 8, engaging with their product planning & engineering teams. Getting peer input and demonstrating how their ideas affected our planning was critical to gaining their support for the program.
Creating a studio feeling, virtually: my Ontada Design team
Environment - physical or remote
David Townsend and I have both created multiple studio environments that supported highly successful team cultures. Building a physical studio space to create a culture of creativity is great, but what about remote teams? It takes more intentional engagements to build culture remotely:
Actively encouraging people to express themselves
Creating systems and space for the introverts to be heard
Integrating play to enable the communication environment that allows the expression of new ideas
Organizing tools and systems to share thinking (figma, structured cloud storage, design crits & scheduled working sessions etc.)
But it can be done.
Getting outside input
Teams can get stuck in a loop and require feedback from someone who is engaged but isn’t so emotionally invested. This is where we come in - having a professional who is experienced in dealing with these issues can give your team a nudge in the right direction, and get them unstuck. Your team owns their own performance, but teams don’t win championships without great coaching.
1. “Magic Quadrant for Data Science Platforms,” Gartner, Published: 14 February 2017 ID: G00301536
