How we wrote our Design team’s charter, together

Our Design team grew three-fold last year, from four to twelve, including our first dedicated UX Researcher. This year, the plan is to expand the team further across the EU and the US. 📈

When you’re dealing with this kind of growth, it’s essential to scale not only your team structure and processes but also your culture. Really, culture should be scaled first — because if you get the culture right, everything else will follow. Culture beats process. In fact, culture eats process for breakfast.

Brian Chesky’s post from 2014 about the importance of culture at Airbnb is a powerful reminder. Their early investors advised them, put bluntly, not to f*** up the culture. Brian explains that when your culture is strong, you can trust everyone to do the right thing. There’s less need for rigid processes — and you don’t want rigid processes in rapidly changing organizations.

So, back in late 2020, we organized a Design (and Research!) Team Away Day to get to know each other better. One of the activities was a 90-minute mini-workshop to define the foundations of our team’s charter.

Defining our team charter from the bottom up

We started by unpacking what a team charter is and what it’s good for. I’m a fan of the definition given in the book Liftoff! It’s a bit meta but nicely framed. See for yourself:

“A team charter is a living document that helps a team understand its understanding of itself.”

— Chris Avore; Russ Unger. Liftoff! Rosenfeld Media, 2020.

Team charters can be comprehensive documents, but we wanted to start small, in a highly focused way (Pareto Principle 💪). We chose to define and document two main areas:

• Team purpose
• How we work together

Starting with team purpose, we asked all team members to break out and independently ideate three statements that encapsulate what we stand for as a design team and how we bring value to the organization. Each person then picked their best statement and shared it with the group. We reviewed the statements and voted on those that resonated the most (we had three votes each).

Next, we defined the principles of how we want to work together. We asked everyone to ideate what’s important to them and list the attributes of a productive, inclusive, and healthy team culture. We then clustered the attributes and labeled the emerging themes.

There was no voting at this point. It was just to get us primed for the next activity — the creation of collaboration principles and norms. For this, we reflected on the following questions to get us in the right frame of mind:

• What are our expectations of each other?
• How do we support each other?
• How do we address conflict with each other?
• How do we provide updates to each other?
• How do we create a safe space to work together?

Then it was time for us to work individually again. We asked everyone to draft six collaboration principles and then shortlist the best three, which they then shared with the group. We clustered the principles into groups and discussed what they meant to us.

Discussion is important to tease out colorful and nuanced perspectives, which are most useful. But it also ensures that the outputs are inclusive and everyone feels like they had a say. A charter is a document that people should feel comfortable adopting and living, after all.

Finally, we gave everyone six votes to highlight the principles they’d like to see documented in the charter.

Translating our workshop materials into the first version

And that was it. We had enough material and could continue with the rest of our Away Day agenda. (Yes, there was a craft beer sampling lecture at the end — delivered remotely, of course.)

A few days later, I sat down to review the workshop outputs. I noticed some strong themes emerging for both the ‘Team purpose’ and ‘How we work together’ sections of the charter. After writing it up, we reviewed version 0.9 as a team, made some refinements, and the following week signed version 1.0 during our weekly DesignOps sync.

We literally signed it in Figma, using the Pen tool. It was deeply ceremonious, heh heh. Kris even used a gradient color for his signature! He’s always got a couple of creative ideas up his sleeve. 🙌

How we plan to use the team charter

And here it is — the Productboard Design team charter, shown proudly on our team’s page. (Hint: scroll down a bit, there’s a link to it about halfway down the page)

Here’s where our team charter will come in handy:

• When onboarding new joiners, so that we have a shared frame of reference from the beginning
• When defining and updating our team ceremonies and cross-functional ways of working
• When hiring — transparency is one of our core values, so we want to share the charter with the world so that people interested in working with us get insight into our culture
• During design critiques within the team and reviews with other stakeholders

I’m happy to say that the word is spreading throughout Productboard. Some product teams have already reached out, and they’d like to create their own charters too.

Where next?

Team charters are meant to be living documents, so we plan to revisit ours every now and then. But for now, we’ve got a great set of aspirational statements, definitions of mutual commitments, norms, and collaboration principles that we can point to during discussions, remind ourselves of, and live every day.