Meet Aiden Bordner, Senior Design Manager at Evernote. Aiden leads the Core Experience Design team developing the product design vision for Evernote’s applications, as well as maintaining the Evernote design system. He manages a team of six designers and a design research lead.
Today we chat with Aiden on all things design management and leading the design team at Evernote. He’ll share his insight on whether design management is right for you, what to look for in IC candidates when hiring, best practices for implementing new design processes, and more.
How did you shape your career in design management vs an individual contributor track?
I started leading teams at a fairly young age (in my late 20s). However, like many young aspiring managers, I gravitated to it for the wrong reasons—namely the desire to be in charge (e.g. the “Creative Director”). It took me a few years to realize that successfully leading a team isn’t all about making design decisions but requires a set of skills that are very different from being a great designer. Fortunately, I also realized I had better possession of these skills than I did in raw execution ability, so I stayed the course and I’m glad I did.
Picking between management vs. an individual contributor track really comes down to what altitude of design you want to focus on. The great reward of management is being able to share a sense of accomplishment in achieving really massive efforts that are too big to be tackled individually. The associated burden is that you’ll need to primarily focus on things like process, culture, team satisfaction, and (arguably the hardest part) managing the performance of your direct reports.
If you like the idea of building machines that do big things and aren’t going to be deeply disappointed to relinquish control of the pixels to someone else, then you’re probably a good fit for design management. Depending on your culture, you likely retain the right to set the quality bar for design and to teach and mentor into the weeds. But in the most successful teams I’ve led, including at Evernote, I’ve delegated a lot of that responsibility to the senior ICs.
How do you align the Evernote team around a shared design vision and strategy?
In a word, conversation. Our team does about four hours of full-team design review every week (typically two, two-hour sessions on Tuesdays and Fridays). The purpose of this isn’t just critique (although that is part of it), it’s also to give designers who are focused on a specific area of the product the ability to provide strategic input to other areas and contribute to the collective product vision. We’ve fostered a culture where design is deeply partnered with product management in defining and conceptualizing the future, and this allows our reviews to socialize big questions about how to evolve features, information architecture, the new user experience, etc. Additionally, both our executive leader and research partner are always invited to these reviews to ensure we are aligned to broader corporate goals and the realities of the customer.
How would you implement a new process as part of the product design process?
We’ve been doing a fair bit of process evolution since I joined and most of it has been pretty successful. I would say the key to that success has been going slowly and collaborating with the team in crafting the plan. A good example of applying these principles was our migration from Sketch to Figma last year. I had used Figma in a prior role and knew it could be helpful for solving a few active problems, but I also knew the team wasn’t going to immediately embrace changing their primary creative tool. So, rather than simply announce the change and set a date, I let the process occur more organically. We started by announcing we were piloting the change and invited the team to explore the tool on their own for a month with some trial licenses. This led to some self-motivated exploration, trial and error, and created a couple of advocates for the migration among the ICs.
When enough of the team had self-selected into using Figma for production work that it had reached a critical mass, we developed a rollout plan to the whole org—and we did so with a lot of input from the designers who had become internal champions of the tool. These designers also became a de-facto support system for the more reluctant team members, helping them learn tips and tricks and how to recreate their Sketch workflows in the new system. The entire process took about five months, but I think it actually would have been much harder (if not just as time-consuming) to achieve a successful change if it had been a top-down decision.
How do you approach giving and receiving feedback with your team?
There’s two kinds of feedback—design feedback and performance feedback. For design feedback, I try to deliver it all in group settings for a couple of reasons. First, it helps create efficient consistency. If we reach a decision about a specific designer’s choices, the rest of the team also gains the benefit of hearing that feedback and can apply it proactively to their own work later. Secondly, it provides everyone an opportunity to add-on or challenge that feedback with more accurate information or another perspective. Just because I manage the team doesn’t mean I’m right 100% of the time.
Performance feedback, on the other hand, should always be given 1-on-1 and should be strictly confidential. In delivering negative performance feedback, I always try to empathize with the team member and focus on asking questions first rather than simply lecturing on what needs to improve. I pre-plan and rehearse these conversations, and build in lots of space to allow the team member to talk. Most performance management solutions arrive from listening and acting on a critical nugget of information that a direct report shares with you, not some deep well of manager wisdom.
As far as receiving feedback, I do a couple of things that have worked well. First, I strive to meet 1-on-1 on a weekly basis with every team member. During these conversations, I regularly and explicitly ask for feedback. Secondly, I hold a design team retrospective each sprint where we share what went well, what needs improvement, and what subsequent actions should be taken. We use a neat (and free) tool called FunRetro to do it while we listen to some music and it’s been a good venue for the team to voice their concerns or approval of process changes.
What should you look for in IC candidates when hiring?
Naturally, a good portfolio is a strong start, but it’s only part of the equation. In early application materials, I typically look for evidence of a rigorous (or at least curious) design process. The type of things that resonate with me are diverse, creative explorations that hone in on an objectively superior solution, concise but sufficient narratives in project case studies, and a simple, well-formatted resume. Please, don’t use gauges or meters representing your software skills!
In early interviews, I’m more focused on determining if a candidate has enough experience in a delivery environment of scale. In other words, do they understand how software gets built, do they have a working understanding of scrum/agile, do they know how to collaborate with PMs and Engineers, do they understand the importance of KPIs and research, etc. Finally, on-site it’s about storytelling ability and culture fit—and these are both absolute make-or-break areas of focus. A candidate can be successful in every other stage, but if they can’t communicate the narrative behind their work or, worse, the team gets bad vibes, this will invariably lead to me deciding not to hire.
Words advice to new or aspiring design managers?
These days one of the first things I teach new managers is to avoid trying to drive your team into the solution you have in your head. Instead, let them come up with their own solution. Otherwise, they aren’t learning, and they can’t come back with something better than what you were thinking.
Want to keep up with team Evernote? Find them on Dribbble and at Evernote.com.
Find more Interviews stories on our blog Courtside. Have a suggestion? Contact stories@dribbble.com.
