Can You Take a Problem from Beginning to End? How to Read Signals and Manage “Synthesizers”

Aydin Mirzaee (Fellow.app)  01:57

Scott, welcome to the show.

Scott Williamson (GitLab)  02:40

Thank you. Great to be here.

Aydin Mirzaee (Fellow.app)  02:42

Yeah, so there’s a lot that we’re gonna dig into today. I know you you’ve been you know, product leader at a bunch of different companies, your VP product at SendGrid. Today, your chief product officer at git lab, we are big fans of GitLab. We’ve had, we’ve had a few like you mentioned alumni from getting lab, Darren was on the show yo, who’s now at remote was on the show. And so yeah, we can’t get enough of like, I guess leaders or get a lab. But before I dig in, I’m curious. Like if we’re gonna rewind, this is one of our, you know, favourite questions. It’s like, well go back to the super beginning when you first started leading teams. What were some of the mistakes that you made back then? 

Scott Williamson (GitLab)  03:26

Yeah, it was in 2009. And I had been an individual contributor, Product Manager for a couple of years. But I was fairly senior at that point and got promoted quickly into a director-level product leadership role. But I was fairly new to product management. However, we have only been doing that a couple of years before that I had done sales and biz dev. And it was my first management gig. So I was learning quite a bit all at once. And so made my fair share of mistakes, big two that I would call out one. I tried to inspire performance through positive reinforcement. I’m sort of naturally loath to have a confrontation. And it wasn’t natural for me to provide super direct candid feedback, I would prefer to try to lift people and try to inspire them by complimenting them on the things that we’re doing well and sort of intuitively thought that would be enough to lift the performance of the team but turns out that that wasn’t enough, learned later on the value of candid direct feedback. And so it was didn’t maximize that right away. The other thing I could have done better is delegate more we at the time, I was at a company called wily technology which got acquired by CA See a tends to run r&d teams lean. And so we had 250 engineers, but only about 10 product managers. So like a 20 to 25 to one ratio is way too lean. And I tried to compensate for that by trying to do everything myself by, you know, just taking on too much. I should have delegated more, I should have demanded more resources to staff, the team the way it should have been staffed because the net result was we were way too reactive in what we were doing. So if I can rewind the clock, there are a couple of things I would have done differently.

Aydin Mirzaee (Fellow.app)  05:39

Yeah, no, that’s super useful. So I have to ask you, so on the direct feedback bit, do you remember, like, what series of events led you to realize that maybe you weren’t giving, like enough candid feedback? Like, how did you come to that realization? Well,

05:55

um, I think, well, it was a, it was a few things. First of all, eventually, I had managers who gave me super direct feedback, maybe I would have been a little hesitant to hear negative feedback. But once I started to learn to absorb that, objectively, I learned to value that myself. Also, once you know, I think a pivotal book for me was called Crucial Conversations. And we, I was on a leadership development course at CAA, maybe two years after starting in management. And we, we read that and reviewed that. And that was kind of a tipping point where I’m like, Oh, I have not been having enough of these. And so reading that book and going into that leadership course helped a lot.

Aydin Mirzaee (Fellow.app)  06:46

The delegating more thing is such a problem. I feel like I’ve been doing this for a while, and I still don’t feel that I do a really good job at it. How do you decide what to delegate? I guess, like, you know, how did you get better at it?

Scott Williamson (GitLab)  07:03

Yeah, um, you know, I’ve been in scaling environments for the last 15 years where product lines have been growing fast, and we’ve been hiring fast. And, you know, the $10 million revenue company is a lot different than a $30 million revenue is a lot different than 100 million, which is a lot different than 300. And so, over time, you get better at calibrating what you ought to be doing as a leader at each stage, and what you ought to be delegating. So you know, this can be non-intuitive if you haven’t lived it. So you know, at this point, I’ve lived quite a few of these cycles. And I’ve, I’ve, I’ve seen 10, I’ve seen 100, I’ve seen 300. And you get better at figuring out what to hang on to, and what to delegate, one of the key decisions is, when do you bring in a director? Let’s say you’re head of product, at what point do you bring in a director, and that relationship between the head of product and the director or directors is super important to get right. And, you know, there was some learning Growing Pains on that. But in general, you need to think hard about you need to give people the maximum amount of autonomy that they can handle at that level. Where they can, they can sort of run and you trust them to do what they need to do without asking them to do too much like you can’t delegate stuff that should only be done at the executive team. And finding that balance is tricky.

Aydin Mirzaee (Fellow.app)  08:39

So you’ve piqued my curiosity now, so let’s talk about that. Like how do you know that you need to bring on a director if you’re ahead of the product?

08:49

I think one is span and control. So I don’t think a product leader can handle more than about six directs product leadership is demanding there’s a lot of customer interaction, there are your managing relationships across the whole company. engineering leaders could probably handle more you know, there are certain functions where you can handle more, a product leader should not have more than six. So if you’re getting to where you have more than six, that’s a key point. Another one is doing you have multiple product lines. If you have multiple product lines, that can be a great reason to bring in, you know, a director for each one. Or if you just have so much scope, like for example GitLab is a single product but it’s freaking gigantic. So we’ve had directors for a while even though we only have one product line, and we’ve you know, at this point, we split it up into like dev second ops and then enablement and so if the products big, multiple product lines, or the team’s gotten big enough where you need help, those are all good signals.

Aydin Mirzaee (Fellow.app)  10:00

And when you do something like that, and you bring on a director say you have six direct reports you bring in a director? Is it okay for that director to maybe only then have two direct reports? Or like, how do you break things up? Once you see a

Scott Williamson (GitLab)  10:16

great point,, I’ve also worked hard to create what I call a career development framework. And so there’s an individual contributor track that goes from a, you know, Associate Product Manager to principal product manager. And then there’s a leadership one, which starts at a local group manager. And you can go all the way up to CPOE. Group Manager could be an interesting role. The way I think about it is a group manager should have two to four reports. And a director should have four to six. And so if you’re in that mode, and I would expect a group manager to be more of a player-coach, where maybe they own some product scope directly manage two or three people. And it’s sort of a split role. And that can be useful as you’re scaling a team because it’s not always possible for everyone to have a clean four to six reports. And it also allows for some stratification and experience level, directors should be quite, quite independent and quite experienced a group manager, you can bring in a first-time manager and let them sort of gradually move through that transition of being an individual contributor to manager by having done both for a little while. And then as scope increases, as the team size increases, you can put them into a pure director kind of role.

Aydin Mirzaee (Fellow.app)  11:45

Got it. And so this, I know that a lot of work coming out of GitLab is you know, available in the public, your developer Career Development Framework. Is that available online?

Scott Williamson (GitLab)  11:57

Yeah, you could just search our whole handbook is the vast majority of what we do is published transparently, and so search for GitLab, product career development framework, and you find that,

Aydin Mirzaee (Fellow.app)  12:10

okay, that’s awesome. We’ll link to that in the show notes. So let’s talk about the concept of servant leadership. I think a lot of people, you know, have heard the term, but I like how you specifically break it out into your job as a servant leader is to provide clarity, remove obstacles, and coach. When you break it down that way, it sounds a lot more, I guess, specific and descriptive. So I’m curious if we could spend some time on all three of those. But let’s start with the clarity one. So what is providing clarity? Like very tactically speaking, what does that involve?

Scott Williamson (GitLab)  12:56

I think several things have been a key part of the production system that I’ve run that helped provide clarity. One is a written product strategy. Now sort of an Amazon-style six pager type doc, that GitLab ion, one for the whole product line. I mentioned dev SEC ops enablement, each of those leaders has one at their level, PMS has one at their charter level. And so by writing this stuff down, it becomes really clear what the scope is what you know, all strategy docs, I think about, you know, what’s the situation? What are our problems? And how are we going to resolve those problems? And I think there are about two-year timeframes. So if that’s clear, and they know what I’m trying to accomplish across the whole product line for the next two years, and then it ladders down from there, then then the directors have their statement about what they’re doing in their piece of product line, and the individual PMS have a similar one it can get it gets pretty clear about what you’re trying to do. And it also becomes clear if what an individual Pm is doing doesn’t ladder up, and it doesn’t make sense. So that’s one great way to provide clarity, and then you can let them run like, Okay, we’ve established your strategy, they’ll make it happen. And then I don’t have to get involved in tiny decisions about what to do in that. A couple of other things, clear KPIs, so each, we call them groups. There are about 40 groups that get Lab, which is a, you know, a pm and a designer, an engineering manager and engineer. And then each group owns its charter, so to speak, we call them categories, market categories. And each group has one or more KPIs. And we review those KPIs monthly, it’s super clear what they’re trying to drive. And that’s another way to provide clarity Third is OKRs, we use OKRs GitLab, we use them quarterly. And the purpose isn’t to be all-inclusive. You know, if it’s not on this list, don’t do it kind of thing. But it’s meant to provide focus. And I tend to use them across the whole product line for things that are hard to do across 40 groups. You know, hey, we’ve got to improve our reliability. And so everybody’s gotta work on speeding up the response time of.com, you know, something like that might be an example of an OKR. So between the strategy, clear KPI and quarterly OKRs, that signal, my focus, all that helps. And then, in terms of that person’s performance, how am I doing? We have regular CDs, career development framework reviews, I review, where people are against that CDF every couple of months. And so the first few I mentioned are kind of clarity of direction and what you ought to be working on. And then if you can also provide clarity on how they’re doing what they need to do to improve. That’s also an important piece of clarity.

Aydin Mirzaee (Fellow.app)  16:17

Yeah, that’s awesome. That is like very, I guess, like, I mean, it’s, it’s very clear that you have clarity around clarity, like, that is awesome. One thing I did want to kind of ask is you it’s interesting, because you have KPIs, and then you also have OKRs. So how do those like, how are those two different? Because like, I assume you want to move the OKRs? So certainly, you want to move the KPIs. So is that then an OKR? Like, how did the two relate?

Scott Williamson (GitLab)  16:51

Yeah, good question. KPIs, I would say are more durable. So KPIs are gonna, you can change them, there’s, they’re not set in stone. But most KPIs for most groups are pretty durable. And you’re always kind of trying to drive that stuff. But things change market demands change, you have to make a big push for X, Y, or Z. And that’s what we use OKRs for, I’m not suggesting it’s the only way to handle OKRs. But OKRs, GitLab is more about driving an extraordinary amount of focus on something that’s otherwise hard to move. And so, you know, there’s an objective, and then there’s a key result. So the key result is typical, you know, it’s a number you’re trying to hit, it’s something, it’s something quantifiable, you know, we’re gonna improve response time by 20% on X service, might be an example of a KR, for reliability, or performance. But those tend to move like those, you know, once we hit that we don’t need you to know, that doesn’t need to live on, that’s more of a temporary point of focus to make sure you move the needle on the thing you’re trying to move. So that’s how we separate the two.

Aydin Mirzaee (Fellow.app)  18:17

The KPIs are like almost like ongoing things, say like, we want, I don’t know, 99.99% availability, and it’s an ongoing thing, we’re never gonna not do that. But if something is different, you want to focus on it, then you make it an objective that yeah, that’s a that’s very clear. So let’s talk about removing obstacles and coaching. And so what are your thoughts on doing those two things? 

18:44

Wel, there are a few regular forums that we have, where that I use for signals about what roadblocks need to be removed in gives me opportunities to coach one is weekly one on one, we have, you know, we have those, I make it a point to attend, let I let them, it’s a bi-directional agenda, but it’s more or less their meeting. And so I want them to be bringing things to me that are tough that they need help working through that. Maybe they’re stuck on. And so that weekly one on one as a keep chance to identify these things. Also have a product leadership call once a week, where we talk about the hard stuff that we can’t resolve a sink GitLab gets a lot done a sink, but some things are just hard and it helps to talk through so that weekly leadership team call is also a signal for me about where blockers are. And it also gives me a chance to provide clarity and coaching to the team, you know, to the leadership team as a group. Call those couple out as regular sinks that help get that done.

Aydin Mirzaee (Fellow.app)  19:59

Yeah, that makes sense. into I mean, you know, Git lab, obviously, famously all remote from the get-go. You do a lot of work asynchronously. I’m curious. So you mentioned I assume one on ones or synchronous sounds like these leadership development meetings are synchronous. But yet beyond that, what else do you do that is synchronous and obviously, the vast majority of things are async.

20:23

We have synchronous KPI reviews, for each what we call section. So dev SEC ops, those are different sections. We have spent about one hour a month going through KPI reviews, for each of those sections that sync, we could do it a sync, but I think there’s a lot of value and the conversation that we have about it. Another form that we have that is synchronous, we call opportunity Canvas reviews, this is on the front end of our development lifecycle. I expect PMS to study the problem before they get into the solution. And so this is essentially a problem opportunity review. And it’s early. And, you know, this, this forum sort of forces the PMs, to get their thoughts together in a holistic manner about the problem. And I find these conversations highly useful as well, I learned a lot about what they’re trying to do. And I think, you know, if you get the right people at the table, you can provide invaluable feedback early, to help them decide whether to proceed or not, to help them tune it before it gets into development and gets expensive. So those are the things that are typically synchronous, I also have a full product team meeting once every two weeks.

Aydin Mirzaee (Fellow.app)  21:48

Got it. And so this, it sounds like you know, you know, some of these things, provide the opportunity to review things, make sure that things are on track. Let’s talk about the concept of, you know, holding people accountable. What have you learned about doing that well, because that is a topic that again, a lot of people may not, may not be very good at, or it’s a skill that you need to develop? Particularly if, you know, you’re a nice person. And you know, you just may be shy away from some of these things like, how have you gotten yourself to be better at this?

Scott Williamson (GitLab)  22:33

Yeah, it’s tricky. As I said, I don’t naturally gravitate toward confrontation. So this one was a hard one for me. I mentioned that crucial conversations book that was important. The other book that was just great is Radical Candor. And her. Her philosophy is to care personally about your team and then challenge them directly. And if you get that combo, right, it’s magical. That book, I thought explained why this is the right thing to do clearly. So I’d recommend those two books, those both helped me kind of get my head in the right place about it, what you have to believe, is that providing direct feedback is in their best interest. I think a lot of people shy away from that because they feel like it’s going to hurt their feelings, or it’s going to ruin their day or, or whatever. If you can come to believe that direct feedback is the best thing for them and that they’re going to be far happier in the long run, because it’ll be performing at a high level, it gets a lot easier to deliver that feedback. So I think just coming from that place is a huge benefit.

Aydin Mirzaee (Fellow.app)  23:47

We’ve had Kim Scott on the show. Yeah. So yeah, I mean, she’s, she’s incredible. And that makes a lot of sense. I do agree. It’s almost like if you’re not giving that direct feedback, you’re robbing that person of potential development. And that’s not a great thing. So that makes a lot of sense. Let’s talk about this concept of a synthesizer. So you have a read me where I guess like people can learn how to work with you and some of your quirks the things you like and dislike. What is a synthesizer?

Scott Williamson (GitLab)  24:25

Well, it’s a word I made up I you know, I don’t know if it’s a commonly understood term, but the way I think about it is it’s someone who takes in a lot of signals and takes a little while to process it before they’re comfortable. Coming up with a conclusion or making their points about it. Some people think out loud and talk out loud and they’re really good. Typically in debate-style environments, where you’re just reacting to whatever comes your way. People who are synthesizers don’t always shine in those environments, because they’re like, they’re trying to process it. And it’s important to them. That what they say be, right, that what they say be helpful. You know, we’re reluctant to talk out loud. And so that’s how I think about a synthesizer.

Aydin Mirzaee (Fellow.app)  25:21

Yeah, that makes sense. And so being a synthesizer, what kind of things do you do to make yourself operate at the best level?

Scott Williamson (GitLab)  25:32

Well, you know, as a synthesizer, you have to relate, you have to understand that that can be a disadvantage. If you’re not vocal enough, and people aren’t hearing from you enough, that’s bad. And so you have to push yourself outside of your comfort zone, to speak up, even when you may not have fully formed your thoughts. So that’s one as you have to, you have to try and meet in the middle and adjust your behaviour because a leader that never speaks up in a group setting is not going to be effective. You can also leverage, you know, I like I said, I’m a big believer in six pager style docs, if I write stuff down, you know, if you write stuff down, you can put your best foot forward, when you’re making an argument about something prep for big call prep for a presentation, like, there are ways that you can put your best foot forward and big moments, even if you’re more of a synthesizing type.

Aydin Mirzaee (Fellow.app)  26:33

And so this concept, I mean, the writing a six-page strategy document in the way that you said, I mean, it seems like such a such an effective way to put the vision on paper, provide clarity for everyone. I’m curious about the process of writing this down, like as someone like, if you consider yourself a synthesizer, like, do you sit down and just like, in one hour, type this out? Or is it like you, it’s a process over many days, and you’re constantly rewriting it many times until it gets to the finish line? Or how do you operate?

27:12

More of the latter? Yeah, for sure. You know, in any complex project, you’re going to be taking inputs over a long period. You know, I just wrote a strategy. It’s a kind of confidential topic, I won’t, I won’t mention what it was. But over weeks, you know, I updated this thing as we learned more. And I used it as the way to capture the latest thinking, if we hadn’t had this doc would have been hard. Because, you know, you get inputs, and it’s in 40 Different docks, and it’s in 40 people’s heads. And so it was a living doc, in a way to articulate what I thought the strategic position should be on this complex subject. So I think, if it’s a simple topic, maybe you don’t need it. But on complex topics, your thinking is going to evolve. So very much the ladder.

Aydin Mirzaee (Fellow.app)  28:08

[AD BREAK BEGINS] Hey, there. Just a quick note, before we move on to the next part, if you’re listening to this podcast, you’re probably already doing one on one meetings. But here’s the thing, we all know that one on one meetings are the most powerful, but at the same time, the most misunderstood concept in practice and management. That’s why we’ve spent over a year compiling the best information, the best expert advice into this beautifully designed 90 Plus page ebook. Now, don’t worry, it’s not a single-spaced font, you know, lots of tax. There are a lot of pictures. It’s nice, easily consumable information, we spent so much time building it. And the great news is that it’s completely free. So head on over to fellow dot app slash blog to download the Definitive Guide on one on ones. It’s there for you. We hope you enjoy it. And let us know what you think. And with that said, let’s go back to the interview.[AD BREAK ENDS]  Yeah, and it’s very interesting to go into it knowing that your thinking will evolve. And just like knowing that it is a living document in that way, in terms of the say that you are not a synthesizer, but you have other synthesizers on your team, and you want to make sure that collaboration is very effective with them, and you’re getting the best out of them. So one is, you know, as we talked about, call on them in meetings and ask them to, like provide input. What other things can you do? 

29:39

Yeah, there is a couple of things that Git lab does, courtesy of being a single remote company that helped synthesizers, I think. One is the meetings always sent out the agenda sent out in advance. And so the synthesizer I go in, I look at the agenda in advance Get the topics in my head, I can come into that thing with more fully formed thoughts and much come more comfortable speaking up. So the more that you can signal exactly what you’re talking about layout the agenda, someone who is more of a synthesizer can add a ton more value. The other thing is we, we keep a, an agenda, sort of real-time as the proceeding of the meeting. And so let’s just say it’s on a complex tie, you know, pricing topic of something, and you just add your question to the doc in order. And what that does is it you get away from the loudest person in the room just dominating the whole thing, and you just go down the list, and the loud person has to wait. And so you know, as a synthesizer, you don’t have to barge in and interrupt somebody, you just put your question on the dock, and then you’re going to get to it. And that helps increase the number of voices that are heard. So I like those super tactical, but they work well.

Aydin Mirzaee (Fellow.app)  31:03

No, we love tactical. So I guess, like, the question is how much in advance is, is good. And, like, some things are way more complex, and you need more time. But like for the average meeting,

Scott Williamson (GitLab)  31:15

I think for the average meeting if you can post the agenda at least 24 hours in advance, you know, it can be hard to keep up with the way I manage my calendars, I always have a block at the end of the day. So that I can check out the calendar the next day and review all the agendas like make sure I understand what’s going to be covered. So it’s kind of on you to prep. But you can build in the time to take advantage of preset agendas and topics that are teed up for the following day. If you don’t didn’t, you know, you walk in cold just like normal, but for people who are proactive and value, you know, having that topic in their head ahead of time, you can help yourself.

Aydin Mirzaee (Fellow.app)  32:03

And so for people that are you know, is I think like for a lot of folks, you know, they’ve had in Office experience and now like they’re going remote and trying to replicate a lot of that asynchronous is obviously like a big part of making remote work. What kind of ways do you communicate asynchronously, like, are there things say that is on the calendar that is meetings, but they’re like asynchronous meetings? Or like, how does most asynchronous communication happen?

Scott Williamson (GitLab)  32:34

Well, we use Slack a lot. So you know, if there’s something time-sensitive that I think the team needs to know about, I’ll certainly send a slack out to the team channel, most of what I communicate to the team, I tend to tee up in agenda docs where we’re all together. And that gives me a chance to write it down and talk to it. And then if somebody can’t join, they know where to find updates. For me, they tend to be in these either leadership meetings, or the product team meeting. If you blast out stuff all over the place, it can be hard to figure out where the important nuggets are. And so I think the team has become trained that hey, all the updates from Scott are going to be on the agenda on the bi-weekly product team meeting. And so I tend to put my updates there, if people can’t attend, they can still get 80% of the benefit by just reading the notes rather than listening to the talk track.

Aydin Mirzaee (Fellow.app)  33:32

Because it’s it’s sometimes like you said it’s hard to wait for things. And also, are there tips around like how, you know, people like saying that there is asynchronous communication? Are there tips around like how you can know if, like, how do you know, a message was heard, like when everybody is in a room? You know, presumably, I mean, they might be distracted, but like, presumably, like there’s some sort of validation? Are there tactical things that you all do that allow you to know that the message has been broadly received?

Scott Williamson (GitLab)  34:05

Well, a super tactical one, you know, do this all that often. But when I need a message received all send out a GitLab issue, its checkbox for each person, like, Hey, I’ve gotten this message, and they have to check it. And if they don’t, I bug him. And so that’s a, you know, pretty hands-on way to ensure I don’t feel the need to do that all that often. But that’s a way to make sure everyone’s seen it. We also leverage the product leadership team to make sure that the smaller because they have meetings with their groups. And so if there’s something that’s super important needs reinforced, I’ll ask them to cover it again in their meetings. And then you know, multimodal communication is key, put it in the agenda, send out slack messages covering different levels and team calls and then you’ll increase your odds of the message being received.

Aydin Mirzaee (Fellow.app)  34:59

Yeah. I think for it’s kind of like radio advertising sometimes like, you just need to hear it five, six times and eventually, right. So let’s talk about hiring. I mean, I think there are like 1000s of people that work at GitLab. You’ve been, you know, fast scaling companies, like you said, for the last 15 years. You’ve defined this term first-class hiring process. What is a first-class hiring process?

Scott Williamson (GitLab)  35:26

Well, I’ll just tick off some things that I think need to be there. You need a great job description that sells the role well, and accurately, you need to interview the team to know their role, with little to no overlap and questions. You need to tight interlock with the recruiter in the source to make sure they think as you do like when they look at a person, they look at a resume. They know what we need on this team. And that takes a lot of back and forth sometimes, especially for new roles to make sure you’re on the same line. I think you need frequent huddles, and retros to uncover process bottlenecks and scheduling bottlenecks and calibration, we have a weekly sync on open hiring roles with the recruiter and the source, for example. You need people to prioritize interviews, you have to optimize the candidate experience. And if they’re waiting weeks, for the whole thing to play out, it’s too bad an experience. And so you have to the team’s got to be committed to making that high priority. You know, for me, it’s second only to customers’ stuff. Use metrics. You know, how many people have been sourced how many people have been screened, how many people have been team interviews, how many people are at the manager interview and treat it like a sales funnel. And if you’ve got a bottleneck, go figure out how to fix it. And then finally, I believe in diverse teams, and I think the great hiring processes ensure that there’s a diverse pipeline, for example, we stopped doing outbound for a while, and we only sourced to try to make sure that we had a diverse pipeline. And then you know, maybe the best candidate went from there. But once you have a diverse pipeline, you have a much higher chance of ending up with a diverse team.

Aydin Mirzaee (Fellow.app)  37:27

It sure did you say that you stopped doing outbound we stopped doing inbound, Oh, stop doing inbound right now.

Scott Williamson (GitLab)  37:35

It’s kind of a hybrid. Because we got so many resumes that you’d end up with a funnel that wasn’t particularly diverse. So we had to sort of overcompensating and go look for people who were from underrepresented groups to make sure that the funnel looked like we wanted to. So sometimes you have to overcompensate that that, frankly, slowed things down. But we made a major move in the diversity on a team, particularly from a gender standpoint, and I was proud of that.

Aydin Mirzaee (Fellow.app)  38:07

Yeah, that’s awesome. It’s very nice to hear like that, what it takes, and sometimes you have to do the work. And I guess like if you’re don’t have a very refined process, you may just rely on what comes in. And so then, you know, like, a lot of the problem is you just need to make sure that you have the right pipeline. Yeah,

Scott Williamson (GitLab)  38:28

I think it’s just being intentional about the whole thing. When I came into GitLab, I told everyone who would listen, or it was my number one priority. And there are things that I didn’t do the first six months as a CPO that you would have expected because I was so focused on hiring. And, you know, you just have to make that sacrifice, to set the thing up and make sure everyone has the same expectations about what you’re looking for, make sure the bar is clear. It takes a lot of work. But once you get it rolling, you know, just like any other system, it can start running itself and people can you don’t like I’m not in all that many hiring loops anymore, because the people who report to me now know how to do it themselves. And so you can get the scale out of it over time.

Aydin Mirzaee (Fellow.app)  39:18

Yeah, it makes sense. I mean, just going back to that, like the concept of like the strategy doc, it provides clarity, I assume there’s like, you know, like you said, a great job description. It a great like knowing everybody knows what they’re looking for and what each person’s role is. What have you learned about hiring great product leaders? Like what are the like, when you think back to some of the best hires that you’ve made? What are some things that like really stood out, in your opinion? 

39:49

Well, you know, we have a career development framework and y’all can check it out. There are five different dimensions and so I I want to make sure that check the box on all those business skills, communication skills, people management skills, validation skills and build skills are the five buckets if you will. But the thing that cuts across all of them that I’ve found that I think is really interesting is systems thinking. Like, can you take a problem from the beginning to the end? Can you systematically work the problem, I think is what differentiates great product people from not so great. And so I tried to test for that too, in addition to those five buckets I mentioned.

Aydin Mirzaee (Fellow.app)  40:35

so systems thinking like how do you test for that? Like, do you give them a, you know, a problem, and then ask them to walk through the solution?

Scott Williamson (GitLab)  40:46

case interview? It’s, it’s kind of a funky little case question. That’s non-tech because I want to get out of acronyms and tech-speak and all that. And just like how do you work a new problem? How do you? How do you think through something that you haven’t faced before? And it’s telling? Like, the answers are really interesting. It’s, it’s a fun thing to do. But anyway, that’s the best thing I’ve come up with, to test systems thinking like Kenya, like, okay, it’s a brand new problem. How do I break this thing down? How do I, how do I work it even though I haven’t read the answer before?

Aydin Mirzaee (Fellow.app)  41:31

You know, this? You know, this has been a fascinating discussion. We’ve talked about, you know, servant leadership, providing clarity coaching, real-time feedback, first-class, hiring so many different topics. Now, we’re talking about systems thinking. And, you know, one of the questions that we always like to ask all of our guests is for all the managers and leaders out there constantly looking to get better at their craft of management. Are there any tips, tricks, or final parting thoughts or words of wisdom that you’d like to leave them with?

Scott Williamson (GitLab)  42:07

I guess a trip is to lead from first principles. And this advice was inspired by a book called principles from Ray Dalio, which I thought was great. And after reading it, it caused me to write down my product team or product leadership principles. And you can see these aren’t git labs handbook as well. And I was the first thing that I rolled out and Git lab, and it helped me set expectations with the team, not so much about how things should be done. Well, that’s a bunch about specifically how it should be done. But what was kind of under what was important in that underlying sense? So as an example, number one is hiring is job one. That was my first principle, like everybody’s, we got to lean in on building this team because players attract players. And we’re only going to get leverage out of the system and consistently get consistent results if we have a great team. And so there are 10 of them. And I won’t go through all of them. But having that set of principles was valuable to me because GitLab is complex. It’s way different than my last company. And so I didn’t come in and say, Hey, we’re gonna do it exactly like this. Like, there’s some playbook. Not really, every company is different, has different DNA has different cultural values. But if you have this sort of the first principle that you deeply believe in, you can communicate that to the team, they can understand what’s important to you, and then the how specifically how is debatable. And so it helped me come into a new complex situation and still feel pretty grounded, even though a lot was going on. And it was way different than I experienced before. And it can help you as your product line matures, or if you move companies or, or what have you.

Aydin Mirzaee (Fellow.app)  44:15

That’s, that’s great advice and a great place to end it. Scott, thanks so much for doing this.

Scott Williamson (GitLab)  44:21

You’re welcome. It was a pleasure. And that’s it for today.