Becoming the leader that you wanted to have

Join us on the Fail Faster podcast as we dive into the world of user experience design with Christie Lenneville, Vice President of User Experience at GitLab.

In this episode, Christie shares her journey from a creative writer to a UX leader, navigating the ever-evolving landscape of user experience in the fast-paced world of software development. Discover how GitLab manages to maintain cohesiveness and deliver a constant stream of new features while ensuring a seamless user experience. Additionally, explore the concept of the “papercuts team” and how reactionary design plays a crucial role in the iterative process.

Podcast transcript

Vandana: Hi, Christy. Welcome to the Fail Faster podcast. How are you today? 

Christie: I’m doing great. Really happy to be here. 

Vandana: Awesome. We are so happy to have you. Thank you for making the time. Let’s start by introducing yourself to the audience, Christy. Tell us a little bit about, maybe go back to your childhood. Tell us about what were some of the influencers as you were raised as a little girl, maybe eight, 10 years old, did you think you would be in this role today?

Christie: Absolutely not. The role that I do today wasn’t even a thing when I was eight or 10 years old, and frankly, wasn’t really a thing when I was 20-something years old and finishing college and starting my career. Yeah, I had no idea that this is the position I would be in one day. 

Vandana: Awesome. So how was the path to navigating to being who you are today and to come to this space of user experience design at this particular brand? 

Christie: Yeah, so I have about 25 years into my career now, and I think the way I got here was similar to a lot of people who are in, I guess, my age cohort. So what I will say is I have always been a creative person. I grew up thinking that I would be a professional writer. I was very interested in journalism.

I started my undergraduate degree at 17 years old as a journalism major, realized pretty quickly that wasn’t the right path for me. So I ended up getting my undergraduate degree in psychology, and through four years of being at university, about a semester before I graduated, my intention was that I would be a therapist. Very young, though, I graduated, I think I was 20 when I graduated from my undergraduate program. About a semester before I graduated, I realized that being a therapist meant listening to people’s problems all day.

Now that’s something that you think I might have realized sooner, but again, pretty young. I think the reality of it dawned on me and realized that probably wasn’t the right fit for me. This was in 1999. This was right as the dot-com boom was really taking off. So I ended up working in human resources for just a little bit, and in particular in technology companies. And that’s when I started to realize, oh, there’s something different that I want to do here. Yeah, so that’s a little bit about how I got to where I am. 

Vandana: Okay. Okay. And when did you start getting interested in the user experience side of things? 

Christie: Yeah. Okay. So I didn’t know it was user experience. I was interested in website. I was interested in designing them. I was interested in creating the content for them. And so I was doing this on my own, kind of as a side project, again, working at a technology company. I had decided to get my master’s degree in software engineering because that was the closest thing I knew to something that seemed like something I wanted to do.

Again, as I was finishing my master’s program, I realized, oh, engineering. I don’t know that that’s the right thing for me. I was really much more interested in what I now realize was the experience of what we were building in my master’s thesis focused on that. But again, this is 20 years ago between psychology and software engineering, that was about as close as you can get at time to user experience. I’m not going to say that’s 100% true.

There were one or two human factors programs available in the United States at the time and were certainly something that I knew about. But I began working in software and was a writer, was a technical writer in software and started getting exposure to user experience teams in a formal and proper way and went, ah, yeah. This is it. 

Vandana: Awesome. How cool. Can you relay some of the stories where you, where it was validating, you know, in your head that this is, this is what I wanted to always do? Like, was there some kind of any, anything comes to mind early on in your career or later where it gave you that sense of, yes, belonging to that, that, right? 

Christie: Yeah, there are so many here. Let me try and get more specific. I think probably the first time I remember thinking this was I was working as a technical writer, a content developer for an enterprise software program that were a Fortune 100 company. And they had actually just started spinning up a software division. I enjoyed writing. It’s absolutely part of the user experience. So even today as a VP of UX and in other roles as a UX leader, technical writing has been part of my department. I think it is absolutely critical to the user experience.

I was working alongside the UX team at that point, but I started doing some of the UX work with them. There was that as a writer, I almost kind of saw myself at that time as their first user. So they were designing things and I was really the first person outside of their team who was seeing what they had designed and offer feedback to them, visibility of some of their choices, which was really cool because they were very open. They listened to me. And then I also learned from them and I just found it so gratifying, so interesting to me. 

Vandana: Very cool. Very cool. And what a great way to really topple into the right areas that, oh my God, yeah, this is how it’s, you know, what I’m writing is getting translated to a product, right? Like a feature or whatever the translation expression was. That’s super cool. So let’s talk about the overview of what you are trying to create at GitLab. And I know that there is a velocity that you’re dealing with, which is super high in terms of UX. So let’s talk about your world today. 

Christie: Yeah. Okay. So today I’m the vice president of user experience at GitLab. GitLab is what we call a DevSecOps platform, but in simpler terms, what I’ll say, I always say it’s software for people who make software. Software teams work together to plan their software project and manage the code to deploy that code into production. And then also to make sure that code is secure, written in a secure way. Does other things too, but that’s probably close enough.

So what I will say is GitLab has unbelievable feature velocity, pardon me. We are known for that. We release a new set of features every single month. We have for well over a decade. And in each one of those releases, there are scores of new features. So a lot always going on. 

Vandana: Wow. So how do you, how do you manage all that? Because it’s not a usual thing for us, people who are sitting outside of GitLab to hear about features getting spit out that quickly. So how do you manage the cohesiveness of the UX? What are some of the challenges that you have to deal with day in and day out? 

Christie: I’ll start by saying it’s really exciting. Every designer has the experience of having worked on something for a long time, a year or more. You know, it’s gone through this long and laborious process. And at the end, it never sees the light of day. It never makes it into production. And that is frankly just, in my opinion anyway, demoralizing. It just hurts your heart when it happens. So being in an environment where the work that you do is shipping to production all the time, you can see the fruits of your labor and see its impact on people is really, really gratifying. And it’s hard. Okay. So how do I manage that?

Look, I had a really great teaming, so I would say, yeah, I’m a cog in the machine, but it’s not me. When I joined GitLab about four and a half years ago, the UX department was relatively small at about 12 people in the department. Now we have close to 70. They are a group of designers and UX researchers and writers. And the way that we have structured the team is that those folks are embedded with teams.

So the designers in particular, the designers are assigned to embedded with a specific product manager, a specific set of engineers where they can form relationships and also where they can really become subject matter experts. You already probably tell from my description, the subject matter, the content that we’re working on in GitLab as a product is really, really complex. 

There’s a lot of deeply technical things to know. So that’s something that I thought was really important as structuring the team is I wanted to give folks the opportunity to really become subject matter experts alongside their cross-functional peers. That tells you a little bit about how it’s happening in a team and feature team, but you also started to kind of get into the question of, okay, so then how does that happen across an entire product with many, many, many teams? And I’ll say, it’s not easy and I’m not going to tell you that it’s perfect, but there are some things that we do to help facilitate that. One of those things is we have what we call a UX showcase every couple of weeks.

In the UX showcase, designers and researchers and sometimes our writers show up and they take about 15 minutes to present something that they’re working on. This is our way of making sure that people are aware of what’s going on around them. So sometimes they’re sharing designs, sometimes they’re sharing research that they’ve either conducted or have finished conducting and they’ve learned something from it. Sometimes they’re sharing tips and tricks, best practices for how they work. Sometimes they’re sharing failures. That’s always an interesting one to see how we’re learning from each other and helping each other to stay aware of what’s happening across a really, really large platform. 

Vandana: That’s amazing. So what are some of the failures that you have dealt with that have kind of informed some of the leadership skills that you have today? 

Christie: I’ve had plenty. Don’t let my make you think that I’ve… Some that have shaped me as a leader. Okay, I’m going to take this in a very different direction, but this is something I talk about pretty frequently, especially when I’m mentoring people. Just thinking about my leadership skills. When I was an early leader, one of my first management roles, I think one of the hardest transitions for me to make was understanding the balance between doing the work and managing the work. This is something that I’ve seen.

I’ve had lots and lots of leaders on my teams over the years, and one of the reasons I bring this up is I think this is really, really common. You go from being an individual contributor who is doing the work. You’re cranking out designs. You’re the one who’s responsible for the words on a screen. You’re doing the editing. You’re in there hands-on yourself. Suddenly you’re put in charge of a team, and that’s not your job anymore.

Your job is to empower your team, unblock your team, getting the feedback that they need so they can do the best work that they are equal of doing, but that transition is tough, and my failure was it took me a little while to realize that. 

I stayed too hands-on and stayed too close to the work. I did too much of the work for my team, and in retrospect, once I realized it, what I realized I was doing was I was stealing from the team. I was stealing opportunities for them to learn. Part of it was a pursuit of perfection, right? In my mind, it’s like, you know, I’ve been here. I’ve done this work before. I’m helping them to make it better. Well, I mean, sometimes yes, sometimes no, if I’m being really honest.

I mean, I’ll be the first one to tell you my team very frequently have better ideas than I have, but also giving people an opportunity to put it out there and have it not be exactly what it needed to be, but giving them the opportunity to learn from that is really, really important. So I always jokingly say, I am a kind person. The way that I did this, and frankly, it’s micromanagement, right? I didn’t have mean or a rude way, so my team didn’t hate me, thankfully. And I realized pretty early on that this is what I was doing. And I pivoted and really intentionally worked to become the leader that I wanted to have. So, but that was absolutely a failure that shaped the leader I am today. 

Vandana: Amazing. What a great way to look at it, become the leader that you wanted to have. Yeah. How cool. So from there, like as you are leading teams now, as you guys are getting into, you know, these really high velocity challenges, situations, releases, showcases, what are some of the things that you do to learn from the reactionary design team? I know you mentioned that a while ago, when we talked last time, there was something called paper cuts team. I want to know more about that. Like that’s such a cool concept. And if you can unpack it for us, that would be great. 

Christie: Yeah, happy to. And we’re certainly not the only company who does this. I don’t claim credit for the idea, but it’s something I’m really excited about. I think it’s something that works particularly well in an environment like GitLab where we are moving so quickly. We’re also an open source core tool, which means we have contributions, not just from internal team members, but from the wider GitLab community. Anyone can submit something to contribute to the GitLab product. Uh, when you are moving this fast, when there are not super tight guard rails around experience, you end up with UX debt, uh, it’s inevitable.

And like every product has UX debt. There, there’s no way around that. That is going to happen. One of the things we think about a lot as a leadership team at GitLab is, um, balance, where is it important to really know for a fact that you are getting something right, because it’s so impactful, so important, so risky that you really got to, you got to get as close to the right thing as you can the first try, and where should we be more experimental, um, where can things be a little less polished, and usually that’s on either newer features or things that are of lower usage. 

Well, when you do that, what that means is you’re getting things out the door quickly, which means you’re getting feedback quick. That’s really, really good. But you also know, yeah, there are rough edges. Uh, and so a reactionary way that we deal with that is this paper cuts team.

So we have two designer developers right now. They are wonderful. I’m so impressed with the work that they do. And when we spun this team up, uh, the director of design on my team and I basically told them, go nuts. You can do whatever you want. Y’all are great designers. You’re super smart. You’re good developers. You understand the product well. And we don’t want to tell you what to do. We think you know what to do better than we know what to do. So in there, just fix the things that you think need to be fixed. In the first two and a half months, I believe it was, that this team of two worked together, they did over 150 fixes to the product. It was just incredible.

And some of them were smaller things. Some of them were letters of white space problems. Um, it could be alignment issues. Some of them were bigger problems that they were fixing. Interaction patterns that they felt just didn’t work well. And it’s, it has been really transformative for our team and for the product, I’m really excited about this. 

Vandana: How cool is that? That’s such a great idea. I don’t think I’ve heard of that. Uh, you know, having a different team taking care of that. Normally the product team fixes the debt as well. But, uh, but yeah, that’s, but I do see that with the velocity and the things that you do, it definitely makes sense to have this team. Um, what are some of the other things? I know you talked about navigation redesign. You wanted to touch upon that. I, I would love to know more, like what, what do you mean by, like, what is your angle in that? 

Christie: Yeah. So I was just mentioning that some things we can be a little quick and dirty on and other things we know we have to get right. Navigating is one of those things you have to get it right. So important. So we knew navigation was a problem. Uh, when I joined the company again, four, four plus years ago, we started running a quarterly usability survey.

In that survey, we asked for, uh, free, free text feedback. Um, and one of the themes that came out of those verbatims was around our navigation. We knew that it was a pain point for our users. Um, also our CEO, he, he kept bringing it up to me, Christy. And I feel like our navigation is overcomplicated. We really need to fix it. I agree. Um, so it took us a while to get there. 

Again, it was a very small team when I joined. The problems that we had with the navigation, it’s just, it, it’s just, you know, the navigation had grown organically over time. And frankly, we had outgrown it. Um, one, it was, it was overcomplicated. There were too many items in the navigation. The way that we were bucketing items, there were too many top level items and there was overlap in them. And it just, it just didn’t have the, the guide posts, the markers, the discoverability that we knew that it needed. And it took a while, but I campaigned. I went on a campaign.

It seemed to focus specifically on platform level concerns within the product and navigation. And we knew that’d be the first thing that we would focus on. And we took a very different approach to navigation than we take to many features in the product, which is, I said, okay, this one, there’s no ifs, ands, or buts, we have to have a really clear vision of what they’re going to do here, we need to really understand the end state. 

Now that is not to say that we don’t do that in general, every problem you’re trying to solve in a product, I think you have to take a step back and think about what makes sense for that problem. There is no one size fits all, right? You don’t want to use the same approach, the same methodologies for something as big and strategic as navigation as something where it’s like, Hey, we just, we need to add a text field over here and we’ve got a good reason for it and go, right? Okay.

So for navigation though, okay, we’re, we’re pulling out all the stops on this. We did so much user research, did a lot of diverge, converge, so we, we had some design sprints with the team where they cross-functionally came up with different ideas, we got those ideas in front of our users, got some really great feedback, we were able to narrow, I think it was more than usually, I think we had six different approaches that the design team had come up with, narrowed those down to two, got two, shored those up, got those back out in front of users again, got a lot of really great feedback, came back, narrowed it down to one approach, but incorporated some of the best things of the other approach in that navigation, ran that through user research again, so I mean, this was months and months of user research that we did, and we started to build it out. 

At GitLab, we try to be very iterative, so iteration is one of our company’s core values, and it’s something that’s deeply ingrained in how our R&D team thinks about how to build software. So iteration, you know, that means talk about doing the smallest thing possible, getting out the door as quickly as possible. We knew we couldn’t do that with navigation.

We had actually tried to do that in the past with navigation. We had made some real small changes, and we thought, well, maybe this will make a difference. And I’m going to say this, but hyperbolic, it was like, you know, shifting the deck chairs on the Titanic, right? It just, those chinks didn’t make a difference. In the end, we knew we needed this huge overhaul, so that’s what we did. It was, we just released it into the product. We did it with a lot of caution. So, Fab is the type of product that our users, many of them use it every single day to do their jobs. And take our product really, really seriously. 

Their success in their jobs is reliant on our product working well for them. It has to be able to be productive in our product. There is no give. Yeah. So, we rolled it out to a small group. If you actually, we rolled it out internally first. Yeah, because at GitLab, we use our own tool to do our own daily work. So, the primary tool that I work in is GitLab.

We rolled it out to the internal team first, got a lot of really good feedback, made some changes based on the feedback that we got, and then we started rolling it out to small groups of users and getting feedback and making adjustments until finally we felt comfortable. And we actually did this part pretty quickly, felt comfortable rolling it out to everyone. Now, we were prepared for mass chaos. We were prepared to get some really negative feedback on navigation because it’s muscle memory.

I mean, people have been using this tool for a decade. Like they knew where things are. And instead, the feedback has been really positive overall. I’m not going to tell you that no negative feedback even. It did. We actively solicit that. We are looking at it. We’re making some adjustments based on some of the things that we’re learning. But the feedback overall was very, very positive, which was really exciting to see. It’s really exciting when you see people get on Twitter and proactively say, GitLab, we saw you change your navigation. So much easier to use now. But I’m really excited about the story because it really shows the difference in approaches that you need to take depending on what it is you’re working on. Like there isn’t a one size fits all. 

Vandana: Yeah, yeah. And I love that you took all the cautions, you know, at the right stages. And that’s probably what is needed, you know, for such a big undertaking. So congratulations on that. Looks like it’s going well. What’s the next thing on your plate? 

Christie: Oh, goodness. We always have so much going on that I don’t have a good answer for that. No, I take that back. We’re working hard on integrating AI into our platform. Many, many companies are. This is very new for everyone, right? So the UX team, it’s new to us. Learning from it. But we’re introducing some cool new features, but also figuring out how do you design for this new thing? How do you research this thing? And so I think that’ll take up a fair amount of our attention over the next year, probably. 

Vandana: Awesome. Well, that is exciting. I know that we are almost at the time. Is there anything, Christy, that I haven’t asked you that has been on top of your mind before we wrap it up? 

Christie: Oh, my goodness. That’s a big question. Nothing that I can think of. We talked about some of the things I’m most excited about. 

Vandana: Yeah. Like if there was one golden nugget that you were to give to somebody like maybe you in your in your past, let’s say your past version, what would that be? 

Christie: OK, I’m going to I’m going to kind of double down on something I’ve already said, which is there is no one size fits all. That is company to company, that is project to project. So I’m the first person to tell you that the approach that we took to navigation, while it was the right thing for navigation, would have been absolutely the wrong thing for a feature because sometimes you do need to move a little faster, sometimes you need to get things out the door, start getting feedback from your users. That’s within within one company as a company to company. Company cultures are really very, very, very different from company to company. 

And what worked at one place does not work at another place. So any time I started a new company, I go in with the mindset of, I don’t know how to do my job here. I don’t know what the right thing is. I’m here to learn from the people around me. A pretty good amount of time just talking to everyone and trying to understand what do you think is first of all, what do you think is going well? Or change the things that are going well. I’ve seen that happen before.

Things actually are going pretty well and then someone swoops in and they say, well, that’s not the quote right way to do that and they start battling and then suddenly things aren’t going so well or not want to change. And then teams know usually what’s not going well. So, and then you just think about, okay, how do we want to approach this? So I think that’s, that’s the big thing is no one size fits all. Think about every situation independently. 

Vandana: That’s amazing. And just the question of, you know, how do they do my job here? I mean, that’s huge. Very, very insightful. And you know, if people can take a little breather and not take for granted that this roles means this, you know, and really understand the nuances of where they are, they would do a better job at their job.

Thank you so much for joining us, Christie, and good luck in all that you do. And I am so happy to see the impact that you’re creating. And there is that feeling of excitement, you know, in, in, when you’re sharing your life with us. So thank you for taking the time again and coming here. 

Christie: Thank you so much. It has truly been my pleasure. 

Vandana: Thanks.