Why Your Operations Team Is More Like Your Product Team Than You Think (With Drift's Tim O'Brien)

Sean Lane: Hey, everyone. Welcome back to Operations, the show where we look under the hood of companies in hypergrowth. My name is Sean Lane. So we have this thing at Drift called donut dates, where you go through this app and you get randomly matched with different colleagues from throughout the company to go get out of the building, get to know that person, get a coffee, go for a walk, whatever. So recently, I faked the system a little bit and I proactively asked my colleague, Tim O'Brien, to go on a donut date with me, which Tim later pointed out was just a long- winded way of just asking my coworker out on a date. But anyways, Tim is the Director of Product Design at Drift. And I originally asked him to go out on a donut date with me, or a regular date, to just ask for some advice. And that advice had nothing to do with being a designer. I'm not an aspiring designer on the side, but what I quickly realized from our conversation was that there were way more similarities between our two teams, operations and design, than you might think at first glance. So with that in mind, I of course, had to drag him into the studio to explore these commonalities a little bit further. And what came out of it was this laundry list of things that we, as operators, can beg, borrow, and outright steal from our counterparts in product teams. We've had guests on this show before that have referred to operations as an internal product team where the product that you work on is the company itself. And I walked away from my conversation with Tim believing that more strongly than ever. So first, why should you, as operators, take lessons from a design team? Let's start with how Tim's team is structured and what they're responsible for here at Drift.

Tim O'Brien: So it kind of plays two roles. One is that I manage all the designers who are partnered out on the product teams, and the other is that I manage a team of one right now, but one and myself, of what we call design operations, which we should have seen the similarities way sooner.

Sean Lane: So that should have been crosstalk.

Tim O'Brien: The name of the show. Where our job is to facilitate and support those designers that are on the teams and kind of our philosophy is that we want to make it easy to do design the Drift way, no matter what team you're on. And so, you're going to be working on a different product or with different people, but we want the experience of the designer to be about the same and certainly like the quality of work that they're able to do to be the same. So they're not like starting from scratch if we invest in a new area or acquire a new product, et cetera.

Sean Lane: And so each of those designers is kind of embedded inside of a different product team?

Tim O'Brien: Yeah. We staff about the same way that our product manager would staff. So designer usually supports two teams here. We call that a squad. So that's six developers and then one product manager and one customer advocate.

Sean Lane: Got it. And so the way I translated that in my brain to my team is we talk about our team as a centralized ops resource, right? With different spokes of our ops wheel, to use a different metaphor, where sales ops goes out to sales, marketing ops goes into marketing. And that kind of seems like it compares in the nicely with your pod structure? What was the name you said?

Tim O'Brien: Squads.

Sean Lane: Squads, squads.

Tim O'Brien: Yeah. I mean, I'm not sure if the percentages are the same, but we... Mostly, the designer considers themselves part of the product team that they're on. The way I rationalize it is that they're on a team, but then they're also are part of a function. And so we're the design function.

Sean Lane: Right, and the design function, those kind of centralized resources or fallbacks or principles that you're trying to make consistent across all of those different squads, if I'm a new designer at Drift, how do I take advantage of those? Or how do I use those to help me be successful inside of my independent squad, but while still taking advantage of those backup resources?

Tim O'Brien: So the nice thing that we have is that our output is expected to be similar. So you can think of yourself like when you are buying Nike shoes or like when you're using another application, you're not aware that there's a different designer working on these things. Maybe in the case of some shoe or sneaker heads. But the point is that, we present one similar voice. So design has this kind of inherent tension where a product teams want to be very discreet, we're going to discrete problem and be independent of one another. But design wants to be that kind of connective tissue, that to the customer looks seamless. So as a designer coming on, you kind of expect to say like, well, I at least need to like have the assets, like I need to like copy and paste a logo.

Sean Lane: Right. Colors, something...

Tim O'Brien: You kind of have this like built in knowledge that you're going to have to make it look like Drift. So it starts there like this necessity, but then we have an onboarding, that's a functional onboarding where we teach them the tools and the expectations of being a designer at Drift. So that's teaching them how to use our design system, which is basically a library of those assets, like the logo, or like the way our buttons look. But then also how to contribute to that. So we haven't defined everything yet. And then a big part of it is the way that we work. Your expectations of how you interact with both the function and the product teams themselves.

Sean Lane: So in the operations world, this idea of centralized ops is relatively new and it's not widely adopted necessarily. It's becoming, I would say more popular over time, but everybody kind of has their teams set up a little bit differently. And this idea of a centralized team is I think just starting to gain some popularity. You hear the terms like rev ops, a lot revenue operations. You like that?

Tim O'Brien: I like that.

Sean Lane: So forgive me, because I don't know. Is the setup that we have at Drift and the setup you have on your team... Is that normal across like tech SAS companies of our similar size and type, or is this something novel?

Tim O'Brien: I mean, I don't think completely novel. So you usually find one or the other. So a lot of, especially earlier stage companies, they'll just have one designer or maybe a few designers and they'll work in like an agency model. So there'll be completely centralized and someone will like say," Hey, we need these design assets." This might even be someone external, like your first version of your application could be an agency like an actual agency use. But basically put some requests into a list. And then that team's going to work through that. I think our marketing design team works that way. So they have like our creative director and he's managing and like handing out tasks to the designers there. So that's pretty typical. And then faster moving startups kind of like Lean Startup, if you've read that book or agile says, you want a team that's completely independent, they have no dependencies so that you don't hold up a release based on a centralized team. And that's the way that you maintain speed and product development. So kind of like a V2 product company might lean in that direction. But then the more advanced version of that is when you grow up a little bit, you start to realize that in general teams that operate independently, drift no pun intended, apart in their... The way that they work and the way that they present an experience. And then your customers begin to notice. So they want things to work the same way, no matter where they are in your product. In design, we call that like showing your org structure. And that's like an embarrassing thing to do. Like you never want to show your org structure to your customer. They're like," Oh, that must have been Tim that designed that."

Sean Lane: Yeah. crosstalk If I'm a customer, I'm like," Oh yeah. Like this is definitely a different team making this feature."

Tim O'Brien: Yeah. So you probably hire a head... Or promote a head of design at that point. And then that person takes on the responsibility to make sure that things start to look and feel the same. And then you get to this point where that becomes like a team function. And what we're trying to do at Drift is we're trying to federate the responsibilities of that team. So we're saying that as a designer on a product team, you not only have the responsibility of working on that team, but you also contribute to the centralized function. So we're kind of trying to get away with having the benefits of people who aren't on those teams while continuing to have mostly designers sit on teams, do product work.

Sean Lane: To me, this is such an interesting balance that Tim and the designers at Drift are trying to strike. They want speed and autonomy, and yet also they want consistency and efficiency. And of course they do who doesn't want all of those things. Ops is no different. The challenge comes when you actually try to have all of them at once. Can you have small autonomous teams and still avoid creating silos across your organization. At Drift, and on this show before, we've talked a lot about dichotomies and the idea that when you are asked a question, the answer is oftentimes both. One such example where we strive for this idea of both is this pair of terms that I learned when I first started interviewing at Drift: centralized defense and decentralized offense. I asked him to apply these terms to the team structure he's built in design.

Tim O'Brien: But decentralized offense team would be those product teams, which are trying to tackle customer problems. And that's always going to be our goal, right? Is that like, we need to drive towards a customer outcome. And then what the decentralized part of the designer's life is or what my whole job is, is to help those teams do their job as quickly and efficiently as possible or in my case with as much consistency as well.

Sean Lane: Yeah nd that was honestly one of my questions when I first got here, which was how can we believe in these small, independent agile teams while at the same time be setting up this centralized ops team, right? That was like a hard connection for me to make. But then if you think about it for all those different, small invented teams are the decentralized offense, they're out there working with customers, solving their problems in the go to market side that would... Could include like your sales teams, your marketing teams, things like that. And then your centralized defense is like my centralized ops team, right? Where you have a lot of your systems and your processes and the things that you need to be uniform and clean. So that those teams don't go out and start showing their org design.

Tim O'Brien: Right. Yeah. And your turn there, need to be uniform and clean. Like I think the key is defining that really tightly and making sure that it's not just building the org and just trying to like lock down and control and like have standards that aren't actually impacting the problems that those decentralized offense teams are solving. So what can happen at bigger orgs is that you just create these centralized teams and they have their kind of own agenda and it gets too far away from the customer problem or the business problem that you're trying to solve. And it's really their goals kind of start to look like a little bit more like, well, you're just doing that to make your own life easier. So if you set up that organization to be completely in service to those decentralized offensive teams, I think that you're in a better spot. You can and need to be careful about like getting to this point where you just have the centralized team that doesn't end up really doing anything except kind of like locking down and just setting standards and crosstalk

Sean Lane: Yeah, and they don't own anything. And they're like a weird policeman.

Tim O'Brien: Yeah. The bad version of that and designed is called like the brand police. And that's someone who just sits around and they're like tells you that you're wrong because you didn't put enough padding around the logo and they don't do anything else. Right? When really, does that affect the customer's lives at all? Maybe if like...

Sean Lane: We talk about that all the time on our ops team about how do we continue to position ourselves as a strategic partner, as opposed to either in the best case scenario, you're getting a whole bunch of stuff and requests and things like that. But all of a sudden that becomes too much and you're super... They're super dependent on you. Or the complete opposite. You're a complete bottleneck on all of that. And so finding that balance... That was going to be the other thing I was going to ask you about, which is... It feels like having some of those decentralized offensive pieces, it would be very helpful to a team like mine from a prioritization standpoint, because otherwise you do end up with just this endless laundry list of requests and things to do that hit this centralized team. And I would assume you told me that the designers who are embedded with each of their decentralized units, they can then make that prioritization decision within their team without necessarily having to compare it to everybody else's.

Tim O'Brien: Yeah, that's right. Yeah. Yeah. And I mean, we benefit from being somewhat small at the moment, but it is nice that they're solving their own problems. So what I generally say is an expectation of these people... Of these designers is they solve the problem. And then if it works for them, the expectation is that they at least talk about it to their teammates and say," Is this a way that we should approach this problem all the time?" And if so, I want to work with someone else to try to make them successful. And then we standardize. And so in that way, the prioritization is never like the decentralized team saying," Hey, let's go practically try to solve this thing." It's instead trying to say, here's a problem that we have in front of us right now that we have solved, let's make that a standard so that everyone can solve that problem in the same way. And so we're still able to kind of get away with that at the size that we're at right now.

Sean Lane: But the next time that one comes up, hopefully either the person who solved it originally, or someone in the centralized function is able to identify it and identify... I think the next harder part is to identify the fact that we have already solved this problem because we deal with that all the time and operations. And unfortunately then like not sexy hard answer to that. It's usually just like really good documentation and being able to identify problems, but that is what it takes to be able to not have to rehash and resolve that problem the next time it rears its head.

Tim O'Brien: Yeah. I actually... I find myself doing that for most of my time to be honest. Is that, I'll be reviewing designs or like in a one- on- one and I'll be like," Oh, actually, we've, we've done something similar enough. Like just go talk to Vincent or just go talk to Kristen". And like, we don't really need to reinvent that because we've been successful at it before, especially now, we're taking on new products in kind of like different code bases right now. So it's a very obvious time to reuse stuff right now. But you see in general, like teams are like," I have this unique problem." And so they want to start from scratch. So what I find myself doing constantly is just saying like," Let's just do it this way or let's approach this problem the same way." So you can also get away with it by just having like someone... One person just sit there and look at things that are happening and connect people together.

Sean Lane: I kept coming back to this same thought throughout both my initial conversation, my donut date with Tim and then in the conversation for the show. And the same thought was everyone thinks their team is special, but these themes like prioritization, org structure, serving your internal customers... Whether you're in ops or design or any other team, you aren't that unique, you aren't that special. And there's lessons to be learned from one another. And in fact, one of the places that I'm blatantly stealing from our product organization is their team's concept of product principles. Our VP of Product Craig Daniel, with Tim and the rest of the product leaders have compiled this concrete list of product principles that they present to every new hire on the product team at drift. And then they use these principles to guide the teams work on a daily basis. It's a living breathing document. And I wanted to get Tim's perspective on what it means to have these principles. And more importantly, how you take things that are written out in a deck or on a piece of paper and put them into practice.

Tim O'Brien: Yeah, I'd say that that document and that training is kind of a parent to what we've been talking about on design. So if product at Drift is a term that encompasses product design and engineering, that document is kind of like, okay, in general, here's how all of these functions are going to work together. So that's our most high level version of a centralized way that we work document. And that's really so that we can, as a management team, but then really that those teams can just work in the way that we know works well to what I was talking about earlier, it's when you transfer teams or when you start a new team here at Drift, we want it to feel the same. Like you're going to know what to expect. Like in general, this is the way that we build products here.

Sean Lane: And I'm thinking about that for people who are listening, who may have been used to a more like service operations model, where they're getting a whole bunch of tickets put into them, as opposed to a centralized team or a team that might be embedded inside of sales or marketing or customer success, and then had to switch between some of those different models. How hard do you find it for people who are coming in, who come from an organization that is not set up either with these specific principles or have other preconceived notions or preconceived principles that fly in complete contrast to the ones that we have? Is it hard for people to make that change sometimes?

Tim O'Brien: Yeah, definitely. Yeah. People bounce off it. We try to be very upfront in the interview process that we really want people who are open to learning the way that we do things. And we definitely want your ideas, but we've recently redone our onboarding to be this document called a 7, 30, 60, 90, which is our number of days. And Craig's been very deliberate to basically say that 30 days of that is just learn the way... Like we hired you for your ideas and your experience, but like for 30 days, like just learn the way that we do things. What I say to people is play the sheet music and then we'll learn how to like improvise together. So it's 30 days of just like do the job the way that we expect everyone to be able to do the job. And then it's set up so that the 90 day mark is when you're expected to contribute back and use that fresh perspective plus experience to contribute back and say how can we level up the way that we do work? But yeah, it can be really hard if those first 30 days don't go well, or maybe a team's not like really jelling or performing well, and yeah, it's not worked out in the past for sure.

Sean Lane: My version of play the sheet music is like a crawl, walk, run type of trajectory. But I kind of like the sheet music. I might steal that. Okay. So some specific principles that I wanted to ask you about that I also want to steal. One of them, and this is something that I think if anyone listening has heard anything about Drift and its product team at any point in time, they've probably heard, but I want to challenge a little bit is this concept of no roadmaps. Maggie, whose show you were on before Build, she did an amazing episode about what this means and I actually think there's a ton of transferable lessons for people in ops. And so we'll link to that and stuff like that. But as an ops person, if I don't understand what's under the covers of that no roadmap statement, it kind of freaks me out a little bit.

Tim O'Brien: Oh yeah.

Sean Lane: Right. And so not from the perspective of I need to know what's going to happen a year from now, but more from the perspective, okay, this is the now, the next most important thing that's going to drive the next most amount of value for our company. So this is what we're going to do next and then prioritizing that way. So help me understand how you think about it first. And then maybe I can come around to this.

Tim O'Brien: Sure. I mean, so there is always a thing to do. Like...

Sean Lane: Of course.

Tim O'Brien: No roadmaps doesn't mean like you don't do things, right. You are usually if not always working on a thing that would be on a roadmap, like a feature or fixing the previous feature. But the point of no roadmaps is really that as a product team, we want to be more about the why than the what. And so roadmaps are usually just lists of whats, right? So it says, we want to ship feature a feature B feature C. Then philosophically, that kind of ignores the why, which is what Drift was founded to be about, which is solving customer problems and being customer centric. What we do is we form teams that are based around wise, making customers more successful in certain, pretty specific areas. And then we are less concerned about the what, so like what they build or maybe the how, like how they get there. But it does translate down to a specific project at one point. But philosophically, that's why I love it is that it reminds everyone that works in our product organization that you're not here to ship a feature because it doesn't really matter if that feature is out in the world and not being used. And Stewart Butterfield who's my career hero. He's the founder of Slack has a quote that I'll probably get wrong, but it goes something along the lines of like" the only measure of innovation is a change in human behavior." Which I love, because what he's saying is that it doesn't matter that you like made something novel and cool and no one used it. Like what's cool is that people don't send emails anymore. They Slack each other. That's pretty cool. Even if it's not that novel. So that's really what the no roadmaps thing is about. It's let's get focused on these whys. And we also don't want to change a why just because we finished a certain feature. Right? So if your job at Drift as a product team is to make salespeople incredibly happy and successful at responding to incoming chat messages... because you built one feature that you think could make them happy and successful, doesn't really matter. Maybe it takes a hundred features, maybe it doesn't, but like we want you focused on that why because that's what's most important to us.

Sean Lane: I'm smiling because I'm thinking about numerous times where I've built this... What I think is the most beautiful dashboard in the entire world. And I say that with affection, right? Okay, like this thing is going to solve all of our problems. Like I'm going to put this in front of this sales leader, this in front of this marketing leader, that's going to have all the key metrics that they need. And this is it. This is what's going to run the business. But if you lose sight of like the questions that you're trying to answer with that information or the actions you can take from it, and you're just building the dashboard for the sake of building the dashboard so you can have this thing, then it's exactly what you're talking about. And you all of a sudden are just got this list of what's and you've lost sight of the why. And we talked about that a lot with the team too, as requests come in from 70 sales reps and a bunch of marketers and a bunch of customer success folks. It's impossible to prioritize within that if you're not asking the why behind those things.

Tim O'Brien: We see that all the time is that the list of things that people ask us to build the whats is essentially infinite, but what you need to do... What we call system thinking or product strategy would be look behind all those what's and say what problems are they actually talking about? Craig would say like," Ask five why's." And then you can get to some really common whys that are interesting to solve. And then again, like the what's they matter, figuring out which of them has the highest potential to go solve a customer problem. There's certainly an art and a science maybe to that. But in general, they're less important than the why behind that. Like you're saying your dashboard is an important making sure that your sales person has the numbers they need when they go present an ELT, that's very important.

Sean Lane: But I think the common theme between this and what we were talking about before, this is being able to recognize those common patterns, right? The person who was building the documentation before was able to recognize it and say," Hey, we've already solved this problem. Use this. Here's how you can solve it." And now when you're talking about taking in these requests, being able to find the common patterns between them to figure out what the actual real pain point is, or one of the common pain points is for customers. It's a similar skillset.

Tim O'Brien: That's interesting. Yeah. You're like an internal product team. I didn't think of you that way. That's kind of cool.

Sean Lane: See? We have so many things. I have another one that's in the product principles that I wanted to ask about. This is a... Not just a product principle, this is a Drift wide principle, but I think it emanates from product is the concept of showing your work.

Tim O'Brien: Oh yeah. Yeah. I mean, especially with what we were talking about with these decentralized teams, there's no way we could maintain the consistency and quality that we had with the amount of management that we have without people being expected to work kind of in public. Again, to say that like teams that are decentralized by their nature are going to start to diverge. You just need some function to pull them back together and showing your work is the only way to do that. So I say it's our unfair advantage as a design department. So a lot of design teams will have this thing called Crit, which is where designers come together and show their work and kind of pick each other apart. People teach in art school. I didn't go to art school, but I guess it's legendary for being like mean to one another. That's like where... What people do. But anyway, part of the point is that is to like make things consistent. We kind of invert that. And we say, instead of like once a week, should we come together? We say like every day, can we show what we're currently working on and get benefit from that? And that's really what we've done. So in Slack, we have a channel called design. Every designer is expected to post there at least twice a week. And then once someone posts there, a random other designer gets tagged to be the person to give them feedback.

Sean Lane: Oh, wow. That's like systematized.

Tim O'Brien: Oh yeah. And then even... We even have an expectation for the number of times that you give feedback. So like there's something else that tracks the amount of feedback that you give. And that sounds like very maybe big brother- y that we'd watch all that stuff, but really designers here want to work in the best way possible. And so they want that stuff to be tracked for them. They almost like having like the scorecard. That's like," All right, I'm improving my feedback and I'm showing my work enough." And I think that's because they understand the benefit they get from it. So if you think about in a traditional design environment, you might get feedback from your peers that once a week, and you're waiting that six days to get back to that design Crit meeting. If your work even gets shown... Here you can post whenever you want, it could be happening while we're talking and someone will give you feedback.

Sean Lane: Yeah, and I think there's additional effects of that outside of just making you a better designer, right? There's other career growth inside of that, like learning how to give feedback, right? And practicing giving feedback and giving feedback to different types of people on different types of projects. All of a sudden the people on your team are going to become more skilled at giving feedback. And they probably feel like they're getting more career growth out of it. And they're also probably getting exposure to parts of the product that they wouldn't normally get exposure to because through the sheer fact that they're on those different decentralized squads.

Tim O'Brien: Yeah. A hundred percent true. Yeah. I mean, there've been places I've worked where you won't see any design work from another designer for six months or a year, nor like would you be expected to, because they're working on a different product line. But yeah, here you're expected to know enough about all of the businesses that we run, that you could give effective feedback for the user's experience. And that is a higher expectation, but you're right, that there's a big benefit from that. And the other part of it is that they are learning how to present their work, as well. So to a very wide audience, that's a public slack channel and our executives are in there and senior leadership. And the first question I always get is like this wide eyed," Am I going to get feedback from the CEO?" And my answer is yes, you are. And it's probably going to be disruptive, but it's feedback that you have to understand how to incorporate into your work or not. You could say no to the CEO. That's totally fine. Maybe that's why I'm not on the show. And then you have to present your work, knowing that you're going out to this wide audience that might not have all the context that your product team has. You can't use the same kind of shorthand words that you would use on your team. So yeah, there's a huge benefit to it, I think relatively low cost.

Sean Lane: Yeah, it's really interesting you say it that way and having to consider those other audiences. I also think it forces you to simplify, right? So an example from my world is one of the ways that I show my work is have this internal newsletter style thing called the Operations Observer. Okay. I'll send it to you.

Tim O'Brien: Wow.

Sean Lane: You got to get on this distribution.

Tim O'Brien: This is nice.

Sean Lane: And one of the pieces of feedback that I got from our CEO was that the headlines inside of it only made sense to ops people, right? And so I needed to rewrite those headlines. Other people who are reading it, again depending on your audience, they don't care about the workflow or the formula field or the thing that I built under the covers to make this thing work. What we need to understand is translate this into: this change is going to drive more pipeline. This new distribution rule is going to make it simpler for reps to convert leads into meetings. Right. And like that changing then translating those headlines, I think is just a common skill clearly across crosstalk

Tim O'Brien: In both those cases too, you were saying that simplifying is actually focusing on why to. Because if you say to an ops person like," Oh, we're going to do this type of dashboard." They're probably like,"Oh, that's the one that generates more pipeline." But for me, I'm not going to understand what you mean when you say like X type dashboard. I can't even generate a random one that I don't even know what they would be.

Sean Lane: And that for me is the biggest lesson here. Strip away all the design terminology or the ops lingo. When you zoom out and look at the commonalities of showing your work or a lack of a traditional roadmap, what you're left with is the why. The why behind your work. The why is the thing that can be translated across any team or audience and the why can also be a clear path, defining your team and your individual goals. And Tim thinks about that intersection of the product principles and the goals they set in a really interesting way.

Tim O'Brien: So the principles are way we work. So they're the way that work kind of flows through the system and then goals are part of that. So goal setting is something that teams do... Product teams here do every quarter, we as a function do it on a yearly basis. We say here are the yearly goals for the design function, but then the designers themselves set personal goals every quarter to coincide with their product teams. And so then the way that those goals work is that because they have this kind of dual citizenship, they spend about 60 to 70% of their goal... If that's a resource, on their product team and then the rest on their functional and personal goals in terms of like their head space and time at work.

Sean Lane: Okay. This, by the way, since our date is something that I have completely co- opted. And so in that hub and spoke off model I was describing, let's say you are the marketing ops resource. Lynn, who's on our team, she'll have goals this quarter for marketing, the function that she serves and that they're her customer... Goals that are specific to marketing ops and ops as a function, how do we make our team better? And then lastly goals for herself in terms of her own personal development. And so that format or structure has been super helpful.

Tim O'Brien: Oh, nice. I'm glad. I'm glad to hear it. I didn't invent.

Sean Lane: But you told me about it. So therefore I to ascribe it to you.

Tim O'Brien: I will take it. I will take the credit.

Sean Lane: Before we go at the end of each show, we're going to ask each guest the same lightning round of questions. Ready? Here we go. Best book you've read in the last six months.

Tim O'Brien: Oh, let me think. I actually just read a book called Difficult Conversations, which is interesting. It's like one of those things that's going to affect your work life and your personal life. I find myself... I have this downside of... I am very aware of when my fight or flight kicks in and I don't think, I think as clearly. So it was like good frameworks for having difficult conversations.

Sean Lane: Nice.

Tim O'Brien: Yeah. It was really cool.

Sean Lane: Favorite part about working in design ops?

Tim O'Brien: Oh, there's the tailer. I, in general, love it when I see people be successful. And so I think that, in general, it's a role that allows you to just like do that. And it is not the most glorious work. Like you don't get to like post something and be like," I designed this and it's beautiful and people are using it." But although they're less frequent those moments where you see someone's work. And you're like, I think I had something to do with that. I think they're the coolest moments.

Sean Lane: Least favorite part about working in design ops?

Tim O'Brien: Oh, probably that. The other part of that. The hardest part about moving to management and design ops is it's kind of like that, is you started on this function because you are good at a skill. So like as a designer... Maybe not good. But at least a passable designer and you had this like catharsis of like, you would make a thing, post it, or like ship it and people would use it and give you feedback. And it felt really good. So like you miss that, you miss that like," I fully did this myself and here it is."

Sean Lane: I feel like that's the evolution of any individual contributor who's successful crosstalk

Tim O'Brien: Like we were talking about earlier. Like I'm not unique in any way. So yes. Yeah.

Sean Lane: Someone who impacted you getting the job you have today.

Tim O'Brien: Oh, Craig. For sure. Craig Daniel, our VP of product. It took a while for me to think I was good enough to be at Drift because this is a really... It's a performance culture, like in the people here... Like you, we worked together before. And I really remember... I'm not trying to flatter you to be on your show because I'm already on your show. But I remember thinking being like, Shawn's one of the best people I worked with at Swipely and now called the Upserve. And it was always like that, like Drift would attract people from places I've worked, but it's always the best people. So I was like, I don't know that I'm there, but Craig and I had a lot of text conversations where he was trying to build my ego up enough to come in here. And I said that too Alyse in my interview, I was like," I don't know, man, like you guys are also good at your job. I don't know if I belong here."

Sean Lane: look at, you know, you've been on two different podcasts.

Tim O'Brien: This is the only accomplishment I've had.

Sean Lane: All right. Last one advice: for someone who wants to have your job someday.

Tim O'Brien: Read a lot, like we talked about. You can just learn from the way that your role model companies are doing it. I would say this is.... Might be specific to design, but designers like in general can get too hung up on the ego part of their work. What I was talking about like, they're the person who created it. And so I see a lot of design leaders still doing too much of the design work and the most impactful design work themselves. And I think the most successful design leaders learn to let go. It's going to be fine. There are very talented people out there who can design those interfaces for you. That's pretty specific pitfall that I see is a lot of designers who are looking to transition out of the IC track fall into.

Sean Lane: Thank you very much to Tim O'Brien for joining us on this week's episode. If you want to hear more from Tim or you want to learn more about product or product design or product management, you've got to check out Maggie Crowley's podcast called Build. It's one of the other shows from us here at Drift. Check it out, I'll put a link in the show notes. If you like this podcast, the Operations Podcast, please, please, please make sure you subscribe using whichever podcast provider you prefer and leave us a six star review on Apple Podcasts. Six star reviews only. Thanks very much for listening. That's going to do it for me. We'll see you next time.