Stack Overflow’s design team had been flat. All designers and UX researchers reported to the design manager. In 2019, though, we grew to a point where our design manager had too many direct reports. To remedy this, we created team leads as a form of middle management (individual contributor > team lead > design manager).
This resulted in a reporting structure where some researchers reported to a designer, while other designers reported to a researcher. A researcher managing a designer is less common, so we decided to share both perspectives of the pros, cons, and what we’ve learned along the way. Perspectives
- Beth: UX Researcher, manager of Ted
- Ted: Product Designer, reporting to Beth
1:1s: Keeping good pace
Beth: As a new manager, I knew it was important to track Ted’s concerns, goals, and conversation topics, and I knew that if I didn’t write something down, I would forget it. I made a shared 1:1 document to keep me organized in our ongoing conversations, as well as to show Ted that I cared enough about our work relationship to document things we discussed and wanted to hold each other accountable for down the road.
We typically focused on big picture ideas or roadblocks to design and how we might improve them.
This takes more energy but was more rewarding for both the depth and the quality of our conversations. Ted always came prepared with topics, which was a big part of this working well.
In the specific case of a researcher-designer relationship, it’s important to acknowledge the designer as the domain expert in design and admit your own neophyte status. The benefit was that I couldn’t micromanage Ted. I had to trust that he was capable of executing the work, which he was. The obvious drawback to this setup is that I was not qualified to get in the weeds with Ted on highly specific design skills, decisions, or schools of thought. Instead, I tried to be a helpful sounding board for ideas or situations he shared. I learned a lot about design and the design process from Ted, as well as gaining his sage wisdom about working at Stack Overflow since he’d been there a few years longer.
Ted: Beth and I had already been working together as peers, so having regular 1:1’s didn’t feel like a huge change. I was, however, surprised at how organized Beth was! Early on she suggested creating a template to track our 1:1’s, including talking points, action items, and follow-up reminders. I’d never had a manager take such a structured approach to their direct reports. I was impressed and could tell she was taking our relationship seriously.
One thing I appreciated was learning from someone with a different discipline. Researchers are particularly adept at perspective taking as they are often trying to empathize with their users, and this pattern appeared in other aspects of Beth’s work. Therefore I unexpectedly saw myself level up in my own ability to see a situation from multiple perspectives, more so than I’d done before.
Performance reviews: A welcome challenge
Ted: I spend a lot of time on my performance reviews. When I’m asked to write a few paragraphs evaluating myself, I’ll write five pages. When it comes to promotions and raises, I want to sell myself as best I can.
During last year’s review, Beth had been my manager for only a few months. When the results of my evaluation, though, I was happy to see Beth that spoke with all the folks I worked with closest. She put in a lot of effort to ensure she received a complete picture of my accomplishments and what it was like to work with me.
Her feedback was also very well organized in my review (Beth is a very organized person, if you can’t already tell 😉). Each category included both positive feedback and opportunities, often punctuated with anonymized quotes which made the feedback feel more “real.” Beth’s research background came in handy here.
My performance review kinda felt like a research findings report, but the topic was ME!
Beth: I entered performance reviews in the mindset of servant leadership, which means that I saw myself as a champion of his work and influence within the Enterprise product team as well as the larger design work within the organization. Ted’s self-review was a great starting point to see all the work and impact he’d achieved in the past year.
As I am not a product designer nor have a personal lens of design to influence my perspective of Ted’s work, I sought to collect as many peer reviews as I could get (~10) so that Ted would feel that he was evaluated fairly. I treated this similarly to a user research project: collecting data, looking for themes, writing up the findings and calling out particular places of achievement and opportunity for growth. So while it wasn’t easy, nor quick, as a researcher I felt capable of gathering and organizing the data.
That being said, with someone at Ted’s level of seniority a fair performance review remains an enormous challenge. Ted already knew all the basics of design and then some. There were few, if any, designers on our team with more experience. Who was I to tell Ted how to be a better designer?
As it turns out, a senior designer has good reason to focus more broadly on design leadership and strategy than the specifics of design itself. Therefore I focused on leadership and strategy topics like coalition building and stakeholder relationships, which were areas I personally worked on as well.
Career development: Wow, that’s a steep hill
Beth: Career development was the aspect of management that I felt least practically equipped for, yet the most theoretical informed about. Prior to my UX career I spent a decade working in academia studying the individual experience of work — topics like professional identity, coaching, and career transitions. I looked to that knowledge to build worksheets that would guide discussions around career development, asking questions like, “Where do you want to be in 1 year? 5 years? 10 years?” or having Ted identify and map out several potential paths along those timelines and then react to them.
I found that worksheets lent structure to big picture thoughts and aspirations that otherwise tend not to manifest into action, and also helped me understand Ted’s short and long term goals. This in turn helped us identify opportunities to move Ted closer to those goals, like mentoring a more junior designer, or teaching another colleague Ted’s specialized skills to free up his own time for other skill development.
Ted: Honestly, I was a little apprehensive about this topic. I’m a product designer and Beth is a UX researcher. We’re cut from a similar cloth, but our backgrounds are different. I wondered about her ability to lead a design team without having the experience of a seasoned designer.
How can she provide meaningful design feedback? Or guide me through difficult design challenges? Or help me grow in my career without having fully experienced the same path herself?
However this didn’t turn out to be a huge issue. These days the skills I’m trying to improve aren’t things like color theory, responsive design, or CSS layouts… they’re things like emotional intelligence, business acumen, and leadership skills. Reminds me of this tweet:
junior engineer: I'm going to learn all the tools and syntax! when I'm senior, this knowledge will help me solve important problems— Ian Coldwater 📦💥 (@IanColdwater) April 29, 2020
senior engineer: wtf? the most important problems are people problems, this doesn't have anything to do with code at all
These skills aren’t unique to designers. Beth was incredibly good at coaching me through these topics and suggesting opportunities at the company to practice what we discussed.
In summary: What a trip
Ted: Despite Beth and I coming from different backgrounds, my experience was very positive overall. Beth took her role seriously. She gave our relationship structure which allowed us to be strategic about our time together, follow up on topics, and hold ourselves accountable.
I don’t know how much I improved my hard skills as a designer working under Beth. Since she has a different background, she couldn’t help me with things like improving my interaction design skills and learning CSS Grid. But instead of saying “Ted you should look into X” or “Here’s how you should do Y”, Beth would make more general suggestions and leave it up to me to figure out the details. Besides as I mentioned above, I was most interested in people and business topics, and Beth was a wonderful mentor and coach there.
The managers you trust the most make you feel like they’ll break the rules for you.— Steph (@Soengle) April 21, 2020
Beth used her platform as a manager to recognize me in front of the company, find me leadership opportunities, and relay information she was privy to within the company. She always made me feel valued and I felt like she had my back.
Beth: Learning to manage designers as a researcher was a challenging and rewarding experience for me. My strategy for managing Ted catered to his advanced level, so I had to adjust for the other designers based on their seniority. For a new or mid-level designer, this meant finding design mentors for them within the organization, as well as spending more time discussing learning goals (as opposed to leadership goals). Across all levels, however, one thing was clear:
The success of this experiment relied upon building a foundation of trust between us.
If Ted did not feel like I was in his corner, he wouldn’t bother to bring up questions, concerns, or observations with me. And I would not be much use to Ted as a manager if every week was a simple variation of him saying, “All good!” I am grateful Ted gave me a chance to prove myself a worthy design manager.
As a researcher, managing a designer successfully relied on the same principles of management that any pair would follow. The onus is on the manager to demonstrate genuine interest and good faith in their new team member, and set the stage for that person to grow as much as they would like. Then it’s up to the other person to reciprocate.