Soon after I started managing managers, I promoted a few designers to a Design Director role, meaning they went from designing to managing designers. I had a few conversations with some who were very eager to get started and “make their mark”. One particular high achiever wanted to “do” something in their first few weeks as a manager and asked for my advice. I thought for a moment and said:
“I wouldn’t _do_ anything.”
Focus on being a human first. Build real relationships. Listen. Look for patterns. Be yourself instead of an exact replica your boss or someone you think is super awesome. After all, you were promoted because of your unique qualities. (And if you don’t know why you were promoted, ask!) If you focus first on forming a genuine working relationship with each of your direct reports, trust will form. Then your real work can begin.
When I took on a new role, it was in addition to running a product design team. In order to do both jobs well, I decided to take a good look at what I was currently doing on my product design team. Turns out, there were things that had crept into my routine that were not truly necessary.
While being in a managerial role comes with some admin and process-related tasks, I’ve seen it overtake people’s job to the point where they start think and then act as if its their primary job. And this can leak through to the team. Process becomes the proxy for productivity.
I decided I needed to be pretty ruthless with how I approached my days in order to carve out the space to do my new job really well. So, if it didn’t directly effect the quality of my designer’s output, I cut it out of my job description. Some things I delegated the things that still needed to get done to the Design Directors below me, and others I stopped doing all together.
I sort of came to the realization that: at the end of the day, the final output is all our customers sees; they aren’t there for the planning, the research, the iterations; they only see and use what we ship. While everything leading up to it is imperative and directly effects the final output, I didn’t want the process of it to become my main focus. I hired and built an awesome team, so I trust my design directors and designers (along with their project teams) to do that! I decided to focus in on the design output and giving feedback on each design iteration until it was something I knew we would be proud to ship to our customers.
I did trimming down and refocusing exercise because of a major change and role shift, but I think I would benefit from doing this more regularly, even without such a big event. Things creep in and can really add up over time if you don’t take the time to look and reassess.
I said yes to a big job opportunity this week without asking a single question. I had plenty of them, I just knew my own answer regardless. I also believe that when someone asks you to step into a new leadership role, there is going to be some ambiguity and part of your job will be to create clarity.
I said yes to something I was working towards professionally, even though it presented itself much sooner than I thought. I said yes to stepping into a lot of unknowns and the opportunity to make things better. I said yes to something I know I’m capable of. I said yes to trying out a new job alongside a great group of people.
I said yes to being an interim head of design for Automattic. And I’m really excited about it!
Recently, the design team I lead was going through a period of low morale. I noticed this through conversations in 1-1s, our team Slack channel, and most notably in our team meetings. The designers were all working on some very big product problems and while the work was really challenging, the rewarding aspect seemed to be replaced by a feeling of frustration.
Instead of trying to jump in and fix the actual issues, I tried a different approach. Jay, one of the designers on the team, had been referring to some topics and discussions as “spicy”. It became sort of a fun word that the team started using. On the next team meeting agenda, I added an item called “Spicy topics” and asked if anyone had anything on their minds that they’d like to talk about with the whole team. By this point, everyone knew that “spicy” meant something along the lines of: seemingly unsolvable, slightly controversial, generally frustrating, somewhat confusing, or any combination.
Here’s how it works: Someone on the team will describe the issue, topic, or ask a burning question. As a team, we discuss it for a while until we’ve reached some sort of conclusion. Depending on the topic, this could mean: it just needed to be discussed as a group, we’ve identified a problem that needs further action, or we were able to bring some clarification to something that was once confusing. As the lead, I tend to listen and only jump in when I think I am the best person to provide clarity or perspective on a topic.
We’ve been doing this consistently for a couple months now and I’ve seen a notable difference in the team. The benefits:
Creates a space to bring up challenging product, business, and organizational problems.
Diffuses issues that could become distracting, discouraging, harmful, or even toxic if left unaddressed. (Things that people initially thought were Extra Spicy ended up being not so hot once they said it out loud and talked it through.)
Surfaces things you might miss as the lead who operates at a higher level and is more removed from project work. (For example, I was able to identify and prioritize an entire project that I otherwise wouldn’t have.)
Adding 🌶 Spicy Topics 🌶 to a meeting agenda creates a space to bring up challenging problems and diffuse issues before they boil over. The reason this works so well on our team is because we are a very close knit group and have built up a sense of trust. (One person even described Spicy Topics as group therapy.) I personally love it because it means we can all be open with one another and help each other out. Just because I’m “the boss” doesn’t mean I need to or should seek to fix everything. What I can do in this particular scenario is create the space and empower others.
At the end of every week, my boss asks us to write down a lesson we learned. Mine are usually due to a slip up I made. Here’s how it goes: I make a mistake, apologize to the person, and end up saying something along the lines of: “I should have done x, lesson learned for next time.”
Because we work remotely, this apology is often over text. I did a quick search and found out I make a lot of mistakes learn a lot of lessons.
I don’t think we talk openly enough about the mistakes we make, especially as people in leadership positions. Maybe it’s because we are afraid to let people know we don’t actually have everything together or because being vulnerable feels not great. I just think it makes us more human. With that, I want to share a few of the mistakes I’ve made recently and the lessons that came out of them.
I needed to make a big change that involved a number of people. I assumed one of the people involved was already aware but it turns out, they were not. Lesson: Talk to every party that is involved in the change.
One of my weekly one-on-one meeting with a direct report got canceled. I was going to bring something up that had the potential to get misinterpreted. I didn’t want to wait until a whole week so I decided to send it to them in a text format. It didn’t go well. Lesson: Have difficult conversations in person or on the phone.
I was working a three day week but didn’t adjust my to-do list accordingly. I ended up having to ask someone on my team to take over one of my bigger items without much notice. Lesson: Delegate early and often.
We had a team meeting that overlapped with a monthly company wide meeting. A couple people were excited to have our team meeting and wanted to watch the other one later (it was recorded). I decided to leave it up to everyone to decide what they wanted to do. This caused confusion, especially with new folks on the team. Lessons: Set expectations and communicate them clearly.Cancel team meetings ahead of time when they overlap with townhalls.
I came back from a three month sabbatical and felt extremely frustrated with myself that I wasn’t fully up and running by the second week back. I beat myself up for being so off my game and letting routine things fall through the cracks. Lesson: Transitions take time. Give yourself the time and space to make it happen.
While sharing lessons I’ve learned is great, it really only tells half of the story. I’ve found that being open with people about the situation that lead to the lesson can be very freeing. Being so open also has the added benefit of creating a sense of trust, deeper relationships, and invites others to feel okay making and sharing mistakes of their own.
I learned how to change the oil in my car before I could drive. Twenty years later, I still change it myself. Sure, I could have someone else do it in the same amount of time for the same amount of money, but I think its important to get under the hood yourself.
I feel the same way in my career. As I grew into various leadership positions, I stopped designing things in order to focus on my new job of growing and leading a team. This transition was really hard at first because my progress could no longer be measured by the amount of stuff I designed. Instead, I began delegating projects and tasks to the right people so I can focus on more strategic work.
Delegating is a major part of leadership, but I’ve found that doing a small amount of contributor work has huge benefits, even if it only adds up to a week out of the year. For these five reasons:
Empathy. For the team, especially new folks joining.
Humility. No one is too important to pick up trash, change a light bulb, or lend a hand.
Context. Puts your high level decisions in context of implementation.
Support. Volunteering to help out shows support, to the people under you and the team itself.
Perspective. Getting closer to the ground means seeing new things and how everything fits together.
For me, it acts as a refresher for how things work. As a lead, it’s vital for me to know the how so I can properly prioritize and speak the same language as designers, developers, and business folks. Same with my car – getting under the hood for the little stuff helps me know how everything works so that when I do need to bring it into the shop, I have a grasp on the problem and can speak to the mechanic in their language.
As the Design Director for WooCommerce at Automattic, I manage a large team of designers. Automattic is distributed company and everyone works from home (or wherever they happen to be). Our team is spread out across Europe, the US, and Australia.
The WooCommerce design team has grown and changed over time. As new people join, we try new things and the things that work, stick. One of those things that has organically evolved over time has been our twice-weekly team meetings.
Why meetings? Why two a week?
We are a team of designers. A designer’s job primarily is to identify and solve problems. But the end result is making a thing. Whether it’s a design, landing page, flow, or insights from research, we are all making something. And great design needs a short feedback loop. Since we are all remote, we have to be more intentional about meeting than we would if we were all together in an office.
The purpose of our meetings:
To form a tight feedback loop so our product is consistent and the best it can be.
To get to know each other, bond as a team, build trust. In a remote setting, virtual face-to-face time is key.
To discuss thoughts, ideas, and changes to make as a team.
How we run them: logistics and tools
Our team chats are very casual, but over time a general flow and process has evolved. I’ll walk you through how a typical meeting goes, including the tools we use.
Reminding and alerting An hour before the call, a recurring slackbot reminder that I set up goes out. (“Team X” is the name of our team.)
Agenda The link leads you to the running meeting agenda in Google Docs. For efficiency, we keep the same doc for every meeting. It contains the following information:
The header, which stays on top of the agenda, has the title of the doc with everyone’s name.
Below that is the note taker and call leader, the blog post title with date, and a list of who was present/not the previous meeting.
Before the meeting
Whoever is the first person to click on the link that day is the one who updates the agenda. To update the agenda, you simply copy and pasting the portion below the line. Then change the date to today’s date, update the leader and note taker (we go in order of colored names up top) so its all ready to go for the meeting.
If you have work in progress to share, you add it to that section. If you have something else to discuss, you make a new section and add it below.
When the meeting starts, I drop the Zoom link in our public Slack channel (it’s also in the channel description) and everyone starts filtering in. We chit-chat and say hi until everyone joins.
When everyone is on, I usually announce who is the call leader and who is taking notes. The call leader takes over and runs the meeting. Running the meeting involves two things: reading through the agenda topics, facilitating discussion, and making sure we are good on time. This will vary from person to person, depending on their style and personality. Taking notes involves writing down what is discussed and posting the meeting notes to our team’s p2, a private WordPress blog only accessible to people within the company. (The Google doc is formatted in a way where it’s pretty much just a simple copy & paste.)
What we do
The short answer is: Anything anyone wants as it relates back to the purposes of our meetings. The only real rule we’ve made is no status updates. This came about from a quarterly retrospective; someone expressed that our team had a bad case of Status Update Overload. We all agreed they weren’t a productive use of time and wanted to fix it. We all agreed to focus our meetings on three things: Question of the day, show and tell, and topical discussion.
Question of the day
This idea came up after a recent company-wide survey, where we scored low on “Feeling Part of a Team”. Someone on the team suggested we try a Question of the day at the beginning of every Tuesday meeting. It was around the time when three new people joined the team and it was a great way to get to know everyone.
Questions are asked in the beginning of the meeting as an ice breaker and usually take around 20 minutes. Past examples include:
What time of day are you naturally most productive? When are you least productive?
What else is on your desk besides a computer? (Bonus: Stop, take a picture and share on Slack)
If all the computers, electronic gadgets and software on earth disappeared tomorrow, what would you do with your time?
A note: We don’t do these every week anymore as we all feel part of a team now. Instead we do them ad-hoc as questions come up. For example, today we spent our whole meeting on this one question: “What is something you are actively working to improve upon?” This was asked for a variety of reasons, but essentially it was to make a space for people to be vulnerable, share their work struggles openly, and for everyone to see that they aren’t alone. It was sort of like group therapy so we decided to not take notes and keep it in a safe space.
Show and tell
For those who went to design school, you may know this as a Design Critique. Every meeting (give or take), someone from each squad will add an in-progress design they are working on to the agenda. The process varies from here depending on what the design is. If its a:
Idea We try and stick to only sharing designs, even if they are super rough sketches. This way, we’re all seeing the same thing. When you are sharing ideas about a design instead of an actual design, everyone will have a different picture in their head and it can be difficult to get on the same page. That said, it does happen and we’ll listen to the idea(s) and offer feedback on if and how to move forward, usually by asking to see a design 🙂
Sketch/Figma file or other static design
If there’s a piece of UI, a logo, or a landing page that a designer is iterating on, they will share their screen, describe the problem, and show the various solutions they have come up with. They’ll ask for feedback and anyone on the team can comment. The notetaker is responsible for capturing the feedback.
Prototype or flow
If the designer wants to share a prototype or flow, they’ll first set the stage by explaining the scenario, much like they would if they were testing the flow with a real user. They’ll then ask for a volunteer to run through the flow. The volunteer will then share their screen and run through the prototype, talking out loud as they go. The notetaker takes notes and the rest of the team gives their feedback as well.
Giving and receiving feedback We’ve never set any rules for this, but follow this basic guideline: Focus on the work, not the person. It’s up to receiver to decide which feedback to implement and return with an updated design next meeting, post it to p2 for a wider audience, or start prepping for a usability test.
Topical discussion
Whatever topics people want to discuss with the team, they can add them to the agenda. This can be big initiatives in WooCommerce product, the Design org, Automattic, or in the outside world. In the past, examples of this have been:
Research: Demos, tips, tricks, updates to process
Brand strategy: Explanation, thoughts, next steps
Figma: It seems to solve a problem we have with Sketch not being collaborative. Should we investigate further?
Who attends
The whole design team. On Tuesdays, we invite guests from other teams within the company to learn and share.
When they take place
We meet twice a week at two different times to be inclusive of timezones and not to be too US centric. Tuesdays are at 3pm UTC and Thursdays are at 5pm UTC.
Routines. I develop one for a period of time and then realize I’m in one and feel the urge to shake it up a little. This week, I’m in between trips and noticed that I’d develop a daily pattern of sorts. I woke up and decided to do something different. Different for this week meant something outside of reading, writing, house projects, or snowboarding. Denver Botanical Gardens: a place I would not normally choose to go, which meant it was the perfect choice to break up the week.
Stepping into the bio-dome-like greenhouse was like going to a different country. From snow, dry, below-freezing to green, humid, and warm. My mind wandered. There were plants that looked like the patterns on them were computer generated. And colors that would never be described as “natural” or “earthy” were everywhere. I thought about a podcast I just listened to where a guy made an app that sent him a random Facebook event every day, just so he would be guaranteed to not be stuck in a routine. In the orchid room, I thought of Georgia O’Keeffe and how I want to paint again.
It had a similar effect to traveling. Seeing something new and different inspires me, gets me excited, and also has me looking forward to get back home. Back to my routine.
I love old signs. I also love road trips. On every long drive, I’m bound to pass at least one old sign. I think, “I should stop, that would be cool picture.” But I don’t, I keep on driving. And then I feel a tiny bit of regret.
Today, while driving across Wyoming, I decided to listen to myself. I stopped at every cool sign I passed along the way. No regrets!
I was having a conversation with someone about the book I was reading. I had mentioned that before I had borrowed the book from the library and started reading it on my Kindle, I had no idea it was over 900 pages! They proceeded to start talking about why they preferred to read actual books. I was about to convince them of why Kindles were actually better, but stopped.
I was reminded of something that happens in my work bubble. As a designer, there’s a lot of software and tools out there. Every day, something new comes out and someone is convincing you to switch. Sketch is better than Photoshop! Figma is better than Sketch! I think that we forget that everyone has different needs. And other people aren’t you, even ones that share the same profession.
When my needs aren’t being met by a certain tool, software, or thing, then I look for something else. For example, before going on a trip, I didn’t get my act together in time to find a book. Kindle allowed me to borrow books from the library as I was packing, without going anywhere. This works for me and while I may share my story with someone, I don’t feel the need to convince, especially if something else is already working great for them.
