7 tips to create high functioning design teams (Part 2)
Welcome back for part two! If you’ve not read part one, and the first three awesome tips, you can find them here.
4. Codify design
Pain is temporary, suck is forever.
Jason Deamer, Pixar
This quote signifies how the short-term pain of getting negative feedback about your work is easily outweighed by the prospect of releasing to the world something that is subpar.
At a micro level, we created design sparring — how we give and receive design feedback at Atlassian. The format varies slightly between teams, but the essence of the sessions are the same. It’s a structured, regular, and inclusive design critique, which helps teams make better design decisions. Read more about design sparring at Atlassian.
At a macro level, we codified our design process and shared it company-wide. Design at Atlassian is an inclusive process with our triad partners in Product Management and Engineering. Quite often, non-design disciplines see the design process as this kind of blackbox. So by codifying our process and sharing it, we wanted to debunk that blackbox myth. Essentially, we wanted to show teams where they were going, before we took them there. This gets people much more comfortable contributing to the creative process.
In codifying our design process, we stipulated specific activities that every project team must undertake. These provide the foundations for successful projects and incorporate activities like the experience canvas and the health monitor. Outside of these foundations, teams are free to hack the process within their project team to make it work for them. This ensures that the team can add creativity when is needed on a project by project basis.
All of these activities are wrapped up into an internal “playbook” as individual “plays.” This playbook provides simple guides and step-by-step processes into how to run workshops and meetings. It means that anyone, regardless of their discipline, can understand how to run a creative workshop session. It makes our design process inclusive.
This codification of how we do design at Atlassian gives us a baseline that we are constantly evolving. It ensures that our design teams and other disciplines understand how they can contribute to the product development process. Most important as a manager, it gives my team the foundational tools they need to be successful in their roles.
5. Give candid feedback to your teams
I have several times made a poor choice, by avoiding a necessary confrontation.
John Cleese
Avoiding confrontation is the easy path; it’s the route many people take. But confrontation can be valuable when it comes to career development. It’s good to have tough and open conversations, because they can help build trust with your teams.
Sheryl Sandberg of Facebook has this really nice framework called “Radical candour.” Radical candour ensures that you create an environment where teams are happy to give and receive open and honest feedback. Giving candid feedback shows your team that you care about their career development and growth. If you are not open with them, how will they learn and develop?
We practise this candid approach to career development using a skills matrix that every designer in the team fills out. Our skills matrix is broken down into three themes:
- Craft
- Get shit done
- Leadership
In total, we have about 20 core competencies among which designers will assess themselves using a scale of 1–5 (1 being novice, 5 being a practice leader). The manager will also, separately, complete the matrix. This often provides open and honest conversations if the ratings differ wildly. But that is exactly what we want to encourage, because it provides an opportunity for open discussion and allows a career plan to form.
The skills matrix has been a wonderful tool to help us build trust with our teams. It helps individuals take control of their career development because they understand the areas they need to focus on. And, it lets them be proactive in managing their own destiny within the company.
6. Shuhari
If you think about the last job you started, you were probably given a laptop, asked to fill out a few payroll forms, shown where the shared folder was, and then basically asked to get to work. But becoming a master of something involves a learning curve. As a novice, knowing where you are on that curve helps you push forward in a rewarding way.
Design is a broad discipline when considered holistically, and to gain mastery of it in even one area requires dedication and a few good teachers.
Aikido gives us Shuhari: a system to bring you from novice to master, and it’s broadly broken down as follows.
Shu: To Learn
Ha: To practice
Ri: To master
Within our design teams, we help take new starters on this journey by giving them 90-day plans. These plans are extremely detailed, and as managers we spend a lot of time creating them. We break a new starter’s time down in 3 distinct phases.
Day 0–30. Understanding and learning.
Day 30–60. Starting to practice.
Day 60–90. Becoming a master in a specific area.
It’s a simple yet powerful framework, which is loosely modelled on the book “Your First 90 days,” first published in the 1980s. Our 90-day plans have detailed links about company history, team makeup, team resources, people to meet and greet, and clear tasks and outcomes we want the new employee to achieve at each phase of their learning. Recruiting top talent is hard and expensive, so spending the time to set new starters up for success is extremely worthwhile.
7. Responsibility and Accountability
At some point your team will ask you what design owns, and you need to have a better answer than the user experience.
Alastair Simpson
One of the often overlooked things when setting up a great team is ensuring that they understand what they’re responsible and accountable for. This can be challenging in large, multi-faceted teams and is often changing as the makeup of teams evolves. As design has evolved, we often say we’re accountable for the “user experience” — But what does that mean? Performance affects the user experience, and we certainly don’t own that…
At Atlassian, we work as triad groups of Design, Product Management, and Engineering. The entire triad group is responsible and accountable for two key lagging indicators, Monthly Active Users (MAU) and Net Promoter Score (NPS) within their product. They are also responsible and accountable for other, more direct leading indicators, things like; conversion, feature usage, customer sentiment using the HEART framework and many more depending on what is being built. We recognise both the benefits and limitations of a metric like NPS, but over time it provides a well known barometer that the triad use as a guide. The triad need to balance decisions around design, functionality, and code to ensure all of these leading and lagging indicators move in the right direction.
We then go a step further and break down our NPS feedback into categories that map to our disciplines, this is called RUF.
R = Reliability (Engineering)
U = Usability (Design)
F = Functionality (Product Management)
We have a clear lagging metric for each discipline to track to. As a triad, each part needs to balance what they work on to ensure the overall product experience, and leading and lagging metrics move in the right direction. But more importantly, as a team and as individual disciplines, it’s very clear what we’re responsible and accountable for, both as a group and individually.
I am constantly picking up and learning new ways to interact and collaborate with my team. It is always important to be responsive to the needs of different teams that you manage. Rituals that work for one team, may not work for another. As an example, I recently switched from managing a team in a single location, to one across three separate time zones. I am a firm believer in face to face design sparring at a physical wall, but this was now no longer an option. So I listened to my new team, who had been successfully using “virtual walls” in our internal confluence instance to get feedback on design work, rather than physically or via video conference. Flexibility here had to be the right approach to move forward.
This is one of the keys for me: include the team in the process of creating, owning and iterating on team rituals and processes. Again, it may sound simple, but people like to be included in crafting their own destiny and way of working. Whilst some things may be non-negotiable, as a manager you need to understand when to be flexible with your team, versus when to hold fast onto your trusted beliefs. For me this includes a foundation of best practises that I believe any team needs in order to be successful. I then dip in and out of the playbook of ideas I have built up over the years and see what works for the situation I am in. If this sounds familiar, it should. Any designer in today’s industry should have a set of their own foundations, which they then apply the right design techniques to, depending on the situation they are faced with. Some of the foundations I strongly believe in were born from spectacular failures, both my own and other managers I have worked for.
This collection of tips can sometimes be hard to implement as the grind of day-to-day work sets in. Make sure you take the time to set up your teams for success. When you get it right, you’ll be working with an awesome, high-functioning team that just gets shit done together.
Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.
