My new project: Tact, a simple chat app.

Design Leads meeting

November 05, 2019

This post is part of my notes on three years of design leadership at Pipedrive. Also read the other posts in the series:

Design team leads was my most important circle, Slack channel, and weekly meeting. As a Head of Product Design, I would mostly work with design and research team leads, as well as individual roles reporting to me like Design Operations. The design leads group was the venue of organizing our daily operations and progression, which I’ll now discuss.

What’s a team?

Before getting to the mechanics of operations, I’d think about, what it really means to operate as a team and group in business context. In my head, there’s three dimensions to it - top down, bottom up, and horizontal.

Top down

We have our jobs because the company sees us as useful, and needs us to do particular things. So that we could do our work, the company supplies us with tangible and intangible materials - tools, budgets, goals, headcount, offices. In return, the company can expect good work to happen. So the “top down” aspect of operating as a team would be me as a leader representing the company and the rest of the business and other teams to my group.

Bottom up

If we were robots, we’d be done with just the above section. Things flow top down, work happens mechanically, end of story. Luckily, we’re humans. That results in both challenges and opportunities. Appropriately for design, I’d call it “creativity”. Creative, unforeseen things happen with individual humans and teams. In a well-functioning team, you have an intentional method to bubble up these individual matters, take care of any problems, and disseminate and ingest good unforeseen ideas (like using a new tool or operating in a better way somehow) through the rest of the group.

Bottom up work often happens in 1:1 context, between a person and their manager. What I found is that there are two kinds of info moving in a 1:1. There is the kind of personal stuff that really belongs in a manager relationship. And then there’s other kinds of stuff like “how do I get help with ABC”, “what does DEF mean”, “how should I think about XYZ” (asked by either my direct report, or someone on their team) where there isn’t anything necessarily sensitive or secret in nature. And chances are, if there’s one person in my group asking this, others might be (or should be) wondering about the same. So this second kind of information I’d often take out of 1:1 to my group, where the whole group could build on one another.

Horizontal

The horizontal aspect of operating as a group is a question of cultivating shared values, camaraderie, culture, community, and togetherness. It’s something that you can’t put on the agenda and explicitly discuss, but it underpins everything that you do. You can explicitly model aspects of it, like talk about values, which is a good exercise. Still, I found the most impactful expression of this aspect to be in consistent daily behavior and small acts, rather than explicitly referring to it.

The horizontal aspect of design also has stronger expression in the form of design systems, guides, components and other shared tools. When you are a small team, you don’t need this as you are implicitly sharing them in your daily work as you all sit together. When the team grows and gets more distributed, it’s necessary to support the values with more tangible system artifacts.

An additional twist on the horizontal aspect was that my design group operated across locations in the same city, several cities in the same country, and later across countries. Having a set of shared values, and tangible tools, means more efficiency and independence, while maintaining the cohesion of work and thought.

The design system part these days is well understood. The soft horizontal side of culture and values was equally important to me, if not more, than the tangible artifacts. I found it useful because it promotes the human quality of resilience – being able to predictably react to unforeseen circumstances. I wanted every member of my group to be able to make good judgements in my absence using the same shared platform of thought, so that these decisions would be predictable to both myself as well as other members of the group. We had a strong sense of bond and trust, and it would be easy for anyone to stand in for one another if needed.

Operating as a team

Enough of the philosophy. Let’s talk about what our daily operations were like.

There’s not much to it, actually. We had a Slack channel and a weekly team meeting (both having exactly the same participants: myself and my direct reports) - and that was pretty much it. The Slack channel was freeform and quite low-traffic. We’d mostly inform one another of things happening, and post links to various meeting notes. If a topic emerged through the week that needed longer discussion, we’d either schedule an ad-hoc meeting or (in most cases there was no emergency) just flag it for the next regular weekly leads meeting to discuss in person.

One thing I encouraged the leads to do, is to have regular (weekly or bi-weekly) meetings with their own teams, and post notes of those in the leads channel. Myself and the leads could then skim over the notes of other teams, and identify issues of common interest, which we could discuss further if needed.

We’d all meet once a week. Since many of us were sitting separately in different floors of the same building or in different cities/countries, this could be the only regular opportunity to see each other for quite some time, unless we had other meetings like 1:1s, lunches etc.

The Agenda

I’d prepare an agenda for each weekly meeting. It always followed a fixed structure and have the same sections. The content of each section would naturally change based on what was happening around our team and the wider company.

I found the “people / process / product” approach to be useful to generally reason about design leadership work, and structured my agenda accordingly. This is in order of my priorities and it was heavy on the first part. We often didn’t have product matters to discuss at all.

I was constantly compiling the agenda, taking notes as I went through my regular business week. As for tools, I’m low-tech, so Apple Notes worked just fine. It works nicely on all platforms, and I more than once I found myself waking up at 5 in the morning with an idea to put something on next week’s agenda, which I could do right then and there. I’d share the agenda with my team shortly before the meeting.

I considered the agenda important because it put everybody on the same page and said to everyone, “here are the facts and opinions of what’s the current state of our team and business to the best of my knowledge”. I find it a key part of a leader’s job to drive the team conversation by compiling, editing, and distributing this package.

The meeting

When I first started doing the agenda, we’d just go through it bullet by bullet. We quickly found that the meetings became mechanical and uninspired. There were no jokes or chatter, and it was boring. Nobody learned anything new.

Here’s what I then did, which seemed to work really well. I still compiled and distributed the Agenda. The meeting itself, though, was going around the table with everybody taking their turn to speak, with me as the leader being the last one so as to not bias the team and take up time that I’d rather spend hearing from team members. During their turn, each team member could ask or comment about any of the agenda items, bring up new items not in the agenda, or just pass if they had nothing to say that week. I’d be the last one to speak, and often I’d pass because we had already covered everything needed during the previous discussion.

I can’t find the exact reference, but I remember Rands somewhere calling this approach “start meetings with Any Other Business”.

I liked this format because it was both top-down and bottom-up. Top-down, I could set the tone and (literally) set the agenda, but most of the discussion was bottom-up driven and shaped by what was felt and thought by individual team members, not just the company and leader.

One concept that crystallized itself for me through the whole process was information half-life and decay. Information is like radioactivity: it decays and mutates as it goes through humans. The combined top-down/bottom-up approach let us catch and address these decays and mutations. You’d think the company had communicated something clearly, but some info was left out, or was said too long ago and someone had forgotten or misread it. This is a regular part of operating in a large human group. You’d just treat it as fact of life. Rather than trying to get everything correct upfront and making assumptions about info not mutating, you’d make sure that you have an outlet for getting clarifications and addressing any outstanding questions.