I recently joined a team of designers to lead. One of the patterns I noticed was a lack of ownership over the product areas some of the designers were working in. This came about in a few ways, but the biggest and most common sign was how someone approached a problem. Some designers propose a solution and others ask how something should be solved.
“Should the settings be in a modal or the sidebar?”
“Where should I show the error message?”
When I see a question like this being asked without an accompanying design, I reach out to the designer to learn more. I go about it differently depending on the person, but overall I remind them that this is their project. They are the lead designer on it and they were put on it for a reason! I ask them to use their experience to first ask the question to themselves and start exploring possible solutions. Then, when they had a good grasp and handle on the problem and many designs that solve it, to propose the best solution (or two) instead of asking others how to.
This is a small shift but I’ve seen it have a big impact over time on my previous teams. It leads to more thought out designs, fruitful collaborations, and a sense of pride and ownership over the final design that gets shipped and used by millions of people.
The projects the designers on my team are working on are ones that don’t have a person whose full time job it is to Project Manage. This means that the job falls to different people. In the past, this job has fallen onto a designer, often as a second full time job. Over time, I’ve taken steps to make sure that doesn’t happen. After all, designers still need to design. Here’s the current way I’m approaching it.
Starting a project when you don’t have a full time Project Manager:
When a project gets identified as a priority, the designer assigned to it spends some time understanding the problem and fully wrapping their head around it through exploration, research, etc.
The designer writes out a list of user flows: all the things the user will be able to do when the first version of the project ships.
The designer shares this list with the devs and they both iterate on it until everyone is in agreement and feels a shared sense of ownership over the project.
The list then gets posted where everyone can see it and Github issues are made for each item in the flow, along with any corresponding dev tasks that are needed to support the flow. This provides a solid baseline and can help when issues “pop up” in the middle of design and dev cycles. The designers and devs can work together to decide if each one is worth adding to this release or the punting to the next.
Designs get added to issues, are iterated on with dev feedback, PRs are made, and as the product area comes to life, it can be tested. (The original list of user stories also makes for a great test plan.) Repeat a few times and ship it!
I recently had a conversation with a design manager that started something like this:
“I want to start having my team to do daily standups.” “Why?” “Just so I can easily see what everyone is doing.”
This sort of scenario is pretty common and I’ve actually done this myself in the past. (Standups on their own aren’t the issue here, its any task managers ask their team to do that is strictly for the manager’s benefit only.) I now question every non core-work related task I add on to my team’s workload. Otherwise, it will quickly add up and a designer will spend more time not-designing than designing. It will also send the wrong signal: that I care more about the meta work than the core work.
Back to the original example: If you have trouble seeing what everyone is working on, I bet there’s another problem. Focus on that instead. For me, it was just not being used to working in Github after using another system for so long. I ended up finding a solution that surfaces each team member’s comments with images (designs) attached. That way, I can give design feedback without asking my team to add an additional thing to their to-do list. After all, I want them to focus on their work, not on fixing mine!
Last year, I read and listened to 20 books. This was way more than usual. I think its because I didn’t work for three months and because I discovered Libby, an app that I hooked up to my (okay, my sister’s) library card and it just made it super easy to find and download audiobooks to listen to on road trips. (I took a lot of road trips.)
I use Goodreads to keep track, which also tells me I read 6,225 pages across 20 books. They were, in no particular order:
Yes, Please by Amy Poehler
Annihilation by Jeff VanderMeer
Blue Nights by Joan Didion
Bossypants by Tina Fey
The Circle by Dave Eggers
Commonwealth by Anne Patchett
Dark Places by Gillian Flynn
Everything I Never Told You by Celeste Ng
My Brilliant Friend by Elena Ferrante
Heartburn by Nora Ephron
Hunger by Roxane Gay
1Q84 by Haruki Murakami
The Year of Magical Thinking by Joan Didion
The Making of a Manager by Julie Zhuo
Let’s Explore Diabetes with Owls by David Sedaris
What I Talk About When I Talk About Running by Haruki Murakami
Sorry I’m Late, I Didn’t Want to Come by Jessica Pan
The Summer of Naked Swim Parties by Jessica Anya Blau
Go Set A Watchman by Harper Lee
Wishful Drinking by Carrie Fisher
I bolded ones I would recommend to anyone reading this. Personal highlights include: finally reading a Joan Didion book after watching her documentary, discovering Murakami, and reading only one management/work-related book. (I find them mostly to be not great and too long/repetitive.) I’m excited to read more Didion and Murakami in 2020.
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.