My first year as a design manager
Note: This was originally published on UX Collective — one of my favorite design publications on the web. It was added to the KeepTruckin Design Blog to coincide with its launch in April.
I remember feeling a mix of unease and excitement when Khushnood, our design lead, shared he’d like me to manage KeepTruckin’s growing product design team in Pakistan.
I was uneasy because I hadn’t formally managed a team before. Sure, I do coordinate with freelance writers for PriceOye’s product pages, but that is an ad-hoc affair. This felt more high-stakes, and I did not feel ready.
What if I failed?
But I was also excited because this was wholly new territory, and exploring newer territories helps me grow fast and feel engaged.
Now more than a year later, I’m happy to report there was no catastrophic failure, though there were many teachable moments.
Today, I’d like to share key lessons from my first year as a design manager. I hope they’ll benefit both first-time managers, as well as individual contributors looking to collaborate better with their manager.
Key principle: strive to be a leader, not a manager
At its core, management is about coordinating employees and resources to achieve company goals. Management is required only because team members don’t have access to all the information and resources they need to succeed, or because they don’t know or can’t communicate with colleagues that have that information.
As a manager, you generally have better information access, and a bird’s eye view of things that helps you connect people and resources for moving projects forward.
In an ideal world, all this information would be perfectly documented, easily accessible, and everyone would communicate and collaborate like a hive-mind. In this ideal world, you would be a leader instead of a manager, providing mentorship, growth, and vision to your team.
This is the world you need to strive for.
You always need to be 1) identifying gaps in knowledge and collaboration, and 2) always be fixing them — all the while instilling self-management skills in your team so your efforts multiply over time.
Here’s a quick example of this 2-step process in play.
Example: Fixing the daily standup
In a previous company, our team manager would call for daily standup meetings where each individual contributor (IC) would share what they did yesterday, what they’ll do today, and if they need help on anything. These “scrum meetings” are common at many software companies.
The problem is they’re not scalable. Standup meetings might work for a small, highly collaborative team that’s working on a single project, but for larger teams it’s a waste of time for everyone except the manager hosting them. It breaks everyone’s state of flow, and unless meetings are aggressively time-boxed, everyone just zones out until it’s their turn.
I despised the daily standup as an IC, so when I saw this wasteful pattern in my team’s daily routine, I decided to fix it.
Today, all product designers share their day’s tasks on Slack whenever they start work. We all post to this channel — so every designer knows what their teammates are working on to get that bird’s eye view that is generally exclusive to managers. If required, I can then reach out to individual designers for more details.
I also worked with every team member to build a habit of sharing their progress at the end of each day. It’s just a good habit to reflect on your day before you head out, so you can do better tomorrow. And since our Slack channel is public for all to see, it is also effective for maintaining accountability.
More often than not, team members now even share their next day’s tasks before they go home. Planning for tomorrow in the evening is also a productive habit: it helps you hit the ground running the next day.
With that example out of the way, let’s talk about effective practices for identifying those knowledge and collaboration gaps, and fixing them.
Step 1: Identifying gaps
1) Schedule regular 1:1 meetings with every team member
I enjoy having deep conversations on life, career, relationships, and growth so when I learned about 1:1 meetings, I immediately adopted them in my team.
1:1 meetings are absolutely gold for building rapport with your team members, understanding each other’s strengths and weaknesses, identifying issues at work before they become serious, and hopefully becoming friends.
My team enjoys them so much we affectionately call them “Heart to Heart” or H2H sessions. We talk about everything from how to live life, about happiness at work and at home, passions and side-projects, our ambitions, fears and insecurities — almost anything meaningful goes except for ongoing projects. H2H sessions are also great for sharing candid feedback with one another.
There are many resources available online for having effective H2H sessions. I encourage you to explore them. You can also check out my H2H questions. Remember: starting with just “how’s life?” and actively listening often goes a long way.
2) Actively solicit feedback from everyone you collaborate with
In any given project, you and your team may collaborate with product managers, customer support specialists, front-end and back-end and QA engineers, graphic designers, marketing managers and more.
By asking collaborators for feedback after each project, I’ve identified several company-level process problems. In these feedback sessions we discuss what my team and I did well that we should do again, what we should improve, and where we completely screwed up that we should fix immediately.
Documenting this feedback and reviewing it when starting a new project ensures we learn from our mistakes, and keep getting better. It also provides value to other teams in the company for identifying internal process problems.
These two practices alone helped me identify important issues, but after a few months my pool was running dry. I was identifying issues based only on my limited experience.
To get better at identifying problems, I found great help by learning from accomplished design leaders like Julie Zhuo, Aarron Walter and Eli Woolery. You can do this too by poring over their design management articles and books, and applying it to your own management practice. I promise you’ll see amazing results.
Now that you’ve identified issues, it’s time for…
Step 2: Fixing them
1) Take bold initiatives
You have more power than you think.
My key takeaway from Tim Ferris’ 4-Hour Workweek was the principle of “seeking forgiveness, not permission.”
Instead of waiting around for someone’s permission, I’ve found it more effective to just solve the issues I feel strongly about. If I wait for my manager, or my manager’s manager’s permission to do something, it’ll take forever to fix things — risking the health and productivity of my team in the process.
Chances are if you think deeply enough about the issue and its fix, consider the perspective of affected team members, and cater to any untoward scenarios beforehand, implementing a good fix right now is far better than implementing a great one later.
In the odd case you do genuinely screw up, take a deep breath, seek forgiveness, learn from your mistake and try better the next time — but don’t lose your momentum.
I’ll share an example from my experience below.
Example: From Photoshop + Google Drive to Sketch + Abstract
When I joined KeepTruckin, we were designing mostly in Photoshop, with some projects in Sketch. All files were sync’d on Google Drive, and were versioned manually by suffixing “v1”, “v2” and so on along with a summary of changes within file names.
It was a mess that was slowing us down, and causing undue stress — as it did once when a team member worked on a crucial file locally, and forgot to sync it before going home, fell terribly sick at night and couldn’t come to work for a few days. We had to grab the file from their computer to get the time-sensitive project back on track. Thankfully, both the designer and their designs recovered fine, but we lost precious time and energy because of a poor toolkit.
So I pushed for and led the move to Sketch, along with Abstract for automatic version control, despite resistance from team members. We delivered a project in Sketch without asking every stakeholder for permission, and proved that this was a superior process. Today, Sketch and Abstract are central to our workflow.
2) Document, document, document
As mentioned earlier, one reason why management is required in the first place is because team members don’t have access to the information and resources they need to make things happen.
You can continue sharing information and providing resources each time collaboration breaks down, or you can document them and make it accessible to everyone. It frees you up to focus on more valuable work, while helping your team be more productive.
For example, I noticed every time a new designer joined us, I would spend more time telling them about tools and how to get access to internal tools, than getting to know them as a person.
So to improve onboarding for new designers, we put together a welcome deck that has everything they need to get up and running. We personalize the deck for every new hire, get it specially printed it out for them, and gift it to them on their first day.
There’s a lot more you can do: document user research notes in a shared folder, share meeting minutes with relevant stakeholders, build a comprehensive design system, record system walkthroughs, print and hang your personas near your workspace, and more.
3) Hire the right people
Now hiring is a different ballgame, but it is fundamental to your long-term success. Your fixes will remain temporary without the right people to follow through on them.
When I started at KeepTruckin, there was just one other designer in my team. Since then, we’ve hired 5 people who constantly raise the bar for great work, help build team culture, and are just plain fun to work with everyday. They also happen to be awesome product designers.
To find these fine folks, I reviewed hundreds of profiles and portfolios, and interviewed dozens of designers. My core finding thus far is you need to hire for both skills and attitude, with slightly greater emphasis on the latter. Avoid egoists with excellent design skills; instead hire kind, growth-oriented people with great design skills and coach them to excellence.
Of course finding people can be a challenge in the first place. I’ve found more success in active, local communities than on international platforms like Dribbble or Behance.
You could join and participate in these communities or go one step further and create one yourself. Community building is a separate topic, but the core gist is you need to provide some value to people: whether that’s through a regular design newsletter, a design blog, or a fun Facebook group is up to you. I started UXDP because I enjoy community building, but it is also now a great talent platform for local companies and designers alike.
Another helpful principle is to hire for skills at a team-level. KeepTruckin’s product design team started off with generalist visual designers. We then hired for generalist interaction design skills, followed by specialist user research, specialist visual design and frontend development skills. So every time we need more people, we think deeply about how we can balance skills at a team-level.
Today, we have a product design team that is greater than than the sum of its parts. We have the skills we need to deliver successful outcomes, and a fun culture which encourages play, and growth through knowledge sharing.
There’s a lot more to hiring, of course. You should check out Jared Spool’s and Julie Zhuo’s articles on hiring for more insights.
4) Have a vision, and rally the troops
Nothing unites and motivates a team like a bold vision for the future. As a manager, you need to think what your team will achieve, look, and work like 1 year, 5 years, and 10 years down the line. Will you create robust, evolving personas that will be adopted by the entire company? Build a comprehensive design system that outlasts everyone on the team? Have dedicated UX researchers? Skip remote interviews for in-context, ethnographic research? Design a new product that fundamentally changes an industry?
Thinking about this vision, and sharing it with your team in 1:1 meetings, all hands, and design reviews keeps our team motivated, and helps us retain talent.
Of course, it matters that you actually make progress towards that vision or your team won’t trust you. If six months go by and you’re no closer to your vision than before, it’s easy to lose that motivation.
All this talk about vision makes it easy for me to end this article with one of my favorite quotes.
“If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.”
— Antoine de Saint-Exupery, French writer
