Skip to content

How to be a Teacher—Not an Oracle

Democratizing UX is crucial for any scaling org—but what does that look like in practice?

Words by Tony Ho Tran, Visuals by Emma McKhann

When was the last time you had a phone call?

Maybe it was this morning when your mom called to check up on you. Maybe it was yesterday when your Postmates delivery driver rang to let you know they were at the door.

For some, phone calls mean more. Meet Behzod Sirjani, the Head of Research & Analytics Operations at Slack. He discovered his literal calling through them.

“I had family in Iran and Europe, and also friends in different places,” he recalls. “So I tended to have a different relationship with phone calls than a lot of people my age.”

Through his early experiences, he developed a deep interest in the way people communicate with one another. This unique relationship with communication is embedded at the backbone of his career as a UX researcher—and it’s one that has taken him from the offices of Facebook where he worked as a Senior UXR to Slack where he helms Research & Analytics Operations. There he’s tasked with scaling and democratizing research for the organization.

After all, what is communication if not the ways we share and distribute information?

For Behzod, that means championing the ethos of democratization—something he has a wealth of experience in. At Facebook, he helped co-create a mentorship program that helped develop core research and design skills for junior researchers over the course of a year.

We caught up with Behzod recently to discuss his background, the relationship between non-researchers and researchers, and how we can best democratize research processes throughout our orgs.

dscout: You created a mentorship program for researchers at Facebook. How did that program come to light?

Behzod: When I was at Facebook, I was one of the youngest researchers on the team, and I was also one of very few people that didn't have a PhD.

I had a very different orientation than everyone else on the team because, while I had come up in somewhat of the graduate academic training, I hadn't spent four to five years really focused on a specific space. I wasn't a subject matter expert. I wasn't a method expert.

What I had, instead, was rigorous curiosity as an orientation. At Facebook, we had a lot of people come through who had a lot of potential—but didn't have some of the traditional markers of success like a PhD or have spent like an X number of years in the industry.

After a while, we realized that these people would go on somewhere else and, with a little bit of training, they ended up being very successful. So I began pushing on leadership and pointing out that we have a large concentration of incredibly talented people. And it's our responsibility to grow the practice.

Part of that means we needed to take on the burden of bringing in people who maybe don't have some of those traditional marking of a “successful researcher” but have really high potential. Let's actually build a program to grow them.

So, I worked with Annie Steele, who's now head of Research at Stripe; and Christina Janzer, who's my manager at Slack, and we spent a fair amount of time thinking about what kind of model we wanted to build. We decided to bring in people for roughly a year in this apprenticeship model, where they would spend the first quarter just learning and understanding what it means to do research in industry.

From there, they slowly ramped up to becoming more and more active to where they were self-directed. The goal was that, by the end of the program, they were placed somewhere in the company. We really wanted to say, "Look, we're going to invest in you for a year so that you can be here and kind of grow and be successful." I'd like to think this model was a success because it's in its fourth year.

In what ways have you brought that ethos of mentorship and development to Slack?

The Slack team is small. We're a joint research and analytics team so the whole team is 30 people or fewer. And the actual researchers on that team account for less than a dozen. What’s been interesting at Slack is we made a decision that we were not going to touch everything. And the mandate of research was not to become product police.

One of the things that I've focused on is how do we identify where there are other research activities taking place within Slack and then make them better. Instead of saying, "Okay, you're someone who works on customer success and you're sending bad surveys to your accounts," we're actually saying, "Hey, what are the kinds of touchpoints that you have with customers and where do you wish you could get more structured information?"

While the sort of democratization that happened at Facebook was very team-focused and internal, at Slack, it's been external to the research team. I look at the whole company as 2,000 junior researchers who all care deeply about serving our customers and consider how I can make them better at every customer touch point. Whether it's talking to customers, understanding customers, thinking about who their customer is. And then we've just built programs and structures to augment that in various parts of the company.

A lot of people are scared when they shouldn’t be. If you look back, we have thousands of years of people building and making things where there was no researcher involved.

Behzod Sirjani

You're going to be leading a workshop at the UXR Conference on the topic of democratizing research. I love the subtitle of it which is "What Giving Away Legos Looks Like in Practice." What's that mean?

Molly Graham has a piece on First Round called “Giving Away Your Legos and Other Commandments for Scaling Startups.” It’s about this idea that you have an area that you've been playing with, and this results in responsibilities that you can look at as a set of Legos that are yours. You're trying to build stuff with them. But then new people come in and there are only so many Legos. So you have to share them.

It’s important that as a company grows, you give away your Legos to other people so that they can build. You can give away that responsibility or parts of your job. And I think I experienced that strongly at Facebook. When I started, we were less than 4,000 people and when I left, we were at 28,000 people. So we roughly doubled every year for four years. What my job was, and the number of Legos I had to play with, all of that changed all the time.

For some people that’s scary, because you are constantly looking at new ways to add value. But I think that in the context of research, a lot of people are scared when they shouldn't be. If you look back, we have thousands of years of people building and making things where there was no researcher involved.

Considering that, it's empowering because your job is not to touch every product or to be right in front of the customer. Your job is to think about, "Okay, in this process, where are people being curious or looking out in the world and how can I simply help them do that better?"

The goal of the workshop is to examine the alignment of research capacity and finding things that are really important for your team to do and how to enable them to be done. As you set up some of these structures, you're making sure you're protecting your customers and you're being respectful of people's time.

After you lay that foundation, you share that responsibility with everyone at the company because then those people can advocate on behalf of their customers. They can advocate on behalf of research.

I'm not going to throw you a total kit of 10,000 Lego blocks and say, "Build a car." But I can give you a car kit and the instructions. And if I put together and thought about what blocks you had, you're probably going to be successful assuming you can read instructions.

Our responsibility is not to have all the answers, but to be in the business of helping the people around us make good decisions and learn by example.

Behzod Sirjani

How should individual orgs approach sharing their “Legos”?

You want to ensure that you understand what the organizational appetite is for research. And that's not evenly distributed. Different teams want different kinds of research. So who you serve is going to be different, and what you do for them is going to be very different.

The other piece that I think is really important is the organizational metabolism for information. Some teams can deal with more decisions or more information or less information on different cases. And so you need to think about what you're doing and who you're doing it for. If those pieces are in misalignment, that erodes trust.

For example, you're doing a usability study every week for someone who needs one-time segmentation. This is a huge problem because the thing that they needed and the thing that you're doing are out of alignment.

If you can think more about how to prioritize that work, you can then say to yourself, " There's a whole team that needs work more often than I can do." or maybe “This team needs work that's actually not valuable for me to be doing, BUT I can help them do it to the level and the frequency they need.” Then that's where you end up having a lot more impact because you don't have to be the person doing all of the research.

A lot of small companies make the mistake of thinking that because they hire one researcher and delegate all research activity to them. What happens is that person becomes a bottleneck and everyone has a bad experience with research.

What I am hoping that people take away from the workshop is this idea that, in many cases, there is not just a bright future but a really impactful way that you can do right by your customers and do right by the company even if you yourself couldn't talk to customers anymore.

What exactly does a good relationship between researchers and non-research teams look like?

I encourage researchers to see themselves more like teachers and less like oracles. I think our responsibility is not to have all the answers, but to be in the business of helping the people around us make good decisions and learn by example.

I think if you follow that framing into the next step it means to think of your stakeholders as students. Instead of finding yourself frustrated with ridiculous requests or an unreasonable deadline, you can have a more empathetic and authentic conversation with the about their goals.

The way that I talk about this is, "What's the decision you're trying to make? What's the evidence you need to make that decision? And what's the timeframe for that decision-making process?" These questions invite them into my process and open up a conversation of what is ethical and practical to do, as well as the cost and value of us doing it.

That student-teacher orientation ends up with a much better result because it's not about whether I can give you an answer, it's about us working to help you make those decisions that are important in your building a product.

Sometimes the answer is, "We can't do anything. The thing that you want to do is impossible, it's too difficult, it's going to take too long, etc." Then we can figure out what's another way for you to get close to the evidence you need for that decision.

It makes research not just another part of the development process.

Exactly. Humans are curious by nature and some people argue that being curious is actually very core to who we are. So in that light, researchers are just professional humans and what kind of cooler job is there than getting to be human professionally?

The more that you can make research less of a black box and help other people connect, you help other people recognize all the different ways that research is a part of what we do. Even if you and your partner are going to go to dinner and you ask, "Oh, where should we go?" The next thing you do is basically research. What's open? What is not going to have a line? All of these things are very natural to us and I think that's where one of the biggest contention points come

A lot of people think, "Well I can research" and researchers reply, "No you're going to do it wrong." The thing is: you're both right—but instead of stopping there, let's say, "Oh, I think these are things that you are going to mess up. Let me prevent you from making those kinds of mistakes for your sake, for my sake, for the business, and for the customer.”

Tony Ho Tran is a freelance journalist based in Chicago. His articles have appeared in Huff Post, Business Insider, Growthlab, and wherever else fine writing is published.

Subscribe To People Nerds

A weekly roundup of interviews, pro tips and original research designed for people who are interested in people

The Latest