Navigated to Can You Take a Problem from Beginning to End? How to Read Signals and Manage “Synthesizers” (with Scott Williamson, Chief Product Officer at GitLab) - Transcript
This New Way

·S1 E89

Can You Take a Problem from Beginning to End? How to Read Signals and Manage “Synthesizers” (with Scott Williamson, Chief Product Officer at GitLab)

Episode Transcript

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, you can't delegate stuff that should only be done at the executive team.

Welcome to the super managers podcast, where we interview leaders from all walks of life to tease out the habits, thought patterns, learnings and experiences that help them be extraordinary.

Neri at the fine craft of management.

Our goal is to bring you the lessons in the insights so that you don't have to learn through your own mistakes.

But so that you can shortcut your way to being a great leader.

This podcast is brought to you by fellow a software platform that helps managers in their teams.

Collaborate on meeting, agendas track action items and turn chaotic meetings into productive work sessions.

Check it out at App.

Hey, fellow managers and leaders.

I'm Aiden and I'm the CEO of fellow dot app.

Today's guess is Scott Williamson.

He's the chief product officer at get lab, which is one of the world's largest all remote companies in today's episode.

Scott and I talk about what it means to be a servant leader.

And how to manage this type of person that Scott likes to call a synthesizer.

We also talked about the difference between kpis and okrs and how leaders can use each of these two methods to provide Clarity and focus for their team.

Each is used in different ways and they can be used at the same time and we go through that.

And we also talked about signals.

Scott looks for when he's going to determine where blocker is and we even talked about in some detail, what a first-class hiring process looks like and all the things that Scott has done at gitlab.

To implement one.

If you find this episode helpful.

Send us a note on social media.

You can tag me or DM me on Twitter.

My handle is just a tayden at a wide Ein and you can also send us an email if you want to join or exclusive group of managers out there.

We have this exclusive Community.

We've put together, send us a note to Super managers at fellow dot app to hang out with other super managers.

It'll be really fun and it's a great community of people.

Now, without further Ado.

Here's Scott Williamson on episode, 88 of the super managers podcast.

Scott.

Welcome to the show.

Thank you.

Great to be here.

Yeah.

So there's a lot that we're going to dig into today.

I know you've been, you know, product leader at a bunch of different companies.

Your VP product at sendgrid today, your Chief product officer at gitlab.

We are big fans of get lab.

We've had.

We've had a few like You mentioned, alumni from gitlab, 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, I get lab.

But before I dig in, I'm curious like if we're going to rewind, this is one of our, you know, favorite questions.

It's like we're going back to the, to the super beginning when you first started leading teams.

What were some of the mistakes that you made back then?

Yeah.

It was in 2009.

He and I had been an individual contributor product manager for a couple of years, but it 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.

Hold me.

Only been doing that a couple of years prior to that.

I'd 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 it.

My fair share of mistakes.

Big tube that I would call out one eye.

I tried to inspire performance through positive reinforcement.

I'm sort of a naturally low to have to have confrontation and it wasn't natural for me to provide super direct candid feedback.

I would prefer to try to lift people up and try to inspire them by complimenting on the them, on the things they were 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 clearly later on the value of candid direct feedback, and so it's didn't didn't In 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 Wiley technology which got acquired by CA and C, A tends to run R&D teams, really lean.

And so we had 250 Engineers, but only about 10 product manager.

So like a twenty to twenty five to one ratio is way too lean and I tried to compensate for that by trying to Everything myself by you know, just taking on too much.

I should have delegated more.

I should have demanded more resource to staff the team.

The way it should have been staffed because the net result was we were way too reactive and what we were doing.

So if I could rewind the clock, there's a couple things I would have done differently.

Yeah.

I know, that's super useful.

So I have to ask you so on the the direct feedback bit.

Do you remember?

Her 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, 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 before maybe I would have been a little hesitant to hear negative feedback, but once I started to learn to absorb that objectively, I learned a valuable 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 CA maybe two years after starting and management and 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 through that leadership, course helped a lot the The the delegating more thing.

This 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 make the decision of what to delegate?

I guess.

Like, you know, how did you get better at it?

Yeah, you know, I've been in staling environments for the last 15 years where product lines have been growing fast, and we've been hiring fast and The 10 million dollar Revenue company is a lot different than a 30 million dollar revenue is a lot different than a hundred 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 seen 10, I've seen 100 at same 300 and you get better at figuring out what to what to hang on to and what to delegate.

One of the key decisions is Wendy, bring in a director.

Let's say your head of product.

At what point, do you bring in a director and that relationship between the head of product and the director, or director is a super important to get right?

And you know, there were some learned growing pains on that but 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 you can't delegate stuff that should only be done at the executive team and finding that balance is tricky.

So you really piqued my curiosity now, so let's talk about that.

Like, how do you how do you, how do you know that you need to bring on a director?

If you're a head of product?

Well, I think want to spin control.

So I don't think a product leader can handle more than about six.

Product leadership is demanding.

There's a lot of customer interaction.

There's your managing relationships across the whole company, engineering leaders could probably handle more, you know, there are certain functions where, what eat, you can handle more product leader should not have more than 6.

So if you're, if you're getting to where you have more than six, that's a key Point.

Another one is, do you have multiple product lines?

If you have multiple product lines, that can be a great reason to bring in, you know, director for each one or if you just have so much scope.

Like, for example, get lab is a single product that it's freaking gigantic.

And so, we've had directors for a while, even though we only had one product line.

And we, you know, at this point, we split up and I like Dev second Ops and enablement.

And so if the product big multiple product lines or the team, Gotten big enough where, you know, you need help.

Those are all good signals.

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 to direct reports or like, how do you break things up?

Once you yeah, great point.

We 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 all the way to principal product manager.

And then there's a leadership one, which starts at a little called group manager, and you have can go all the way up to see po.

Group manager could be an interesting role, the way I think about it as a group manager should have two to four reports in a director should have four to six.

And so, if you're in that mode and I would To group manager to be more of a player coach, where maybe they, on some product scope directly manage two or three people and it's sort of a split roll and that can be useful as you're scaling a team because it's not always possible to for everyone to have a clean four to six reports and it also allows for some stratification and experience level, you know, director should be quite quite independent and quite experienced a group manager, you could bring in a first time.

I'm manager and let them sort of gradually move through that transition of being, an individual contributor to a manager by having them do both for a little while and then as scope increases in team size increases, you can put them into a purely director, kind of roll, got it.

And so this, I know that a lot of, a lot of work, coming out of gitlab is, you know, available in the public, your device Career Development framework, is that Available online.

Yeah, you can just search, our whole handbook is the vast majority of what we do is published transparently and so search for get lab product, Career Development framework and you find it.

Okay.

That's awesome.

We'll definitely 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 really like how you specifically break it out.

Into your job, as a servant leader, being to provide Clarity, removing obstacles and coaching.

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?

There's several things that have been a key part of the product system that I've run that help provide Clarity, one is a written product strategy.

Now sort of an Amazon style, 6 pager type duck, that get lab.

I own one for the whole product line.

I mentioned devstack Ops enablement.

Each of those leaders have one at their level PM's have one at their Charter level and so by writing this stuff down.

It becomes really clear what the scope is, what you know, and I'll 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 it is about two year time frames.

So if that's clear and they know what I'm trying to accomplish cross, the whole product line for the next two years and then it ladders down from there.

Then thin the directors have their statement about what they're doing in their piece of product line and the individual PM's 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 p.m.

Is doing doesn't matter.

And it doesn't make sense.

So, that's one great way to provide Clarity and then you can let him run like, okay, we've established your strategy to make it happen.

And then I don't have to get involved in tiny decisions about what to do in that couple other things, clear.

Kpi's.

So each we call them groups.

There's about 40 groups of get lab, which is a, you know, p.m.

And a designer, an engineering manager and engineer.

I need to group owns its own Charter.

So to speak.

We call them categories Market categories and each group has one or more kpis.

And we review those kpis monthly super clear.

What?

They're trying to drive.

And that's another way to provide Clarity.

A third is okay.

Ours we use.

Okay, ours, get lab.

We use them quarterly.

And the purpose isn't to be an 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 an 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 okay are so between the strategy, clear kpi and quarterly of Errors with the signal my focus.

All that really helps.

And then in terms of that person's performance, how am I doing?

We have regular CD of career development framework reviews.

I review where people are against that CDF every couple of months.

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 and what they need to do to improve.

That's also, important piece of Clary.

Yeah, that's awesome.

That is like very I guess like, I mean, it's very clear that you have Clarity around like however, I 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?

Friend because like I assume you want to move the okay are so sorry.

You want to move the kpis?

So is that then an okay are like, how did the to relate?

Yeah, good question.

Kpi's 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.

Okay?

Are for, I'm not suggesting.

It's the only way to handle.

Okay, ours the okay.

Ours, it get lab or more about driving.

And it 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.

Instead of key result is typically a, you know, it's a number, you're trying to hit, it's something, it's something quantifiable.

You know, we're going to improve response time by 20% on ex-service, might be an example of a KR.

For reliability or four per for performance, but those tend to move like those, you know, once we hit that we don't need, you 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 to take apis 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 going to not do that.

But if something is different, you want to focus on it, then you make it an objective that the yeah, that's it.

That's very clear.

So let's talk about removing obstacles and coaching.

So what are your thoughts on doing those two things?

Well, there's a few regular forums that we have were that I use for signals about what roadblocks need removed in gives me.

Unity's to coach one is weekly one-on-one.

We, you know, we have those make a point to attend.

Let let them look at 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 is to keep chance to identify these things.

I also have a product.

Shit call once a week where we talk about the hard stuff that we can resolve a sink, get lab, 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 is a group got call those couple out as regular.

Sinks that help get that done.

Yeah, that makes sense into, I mean, you know, it get 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 are synchronous sounds.

Like these that leadership development meetings are synchronous.

But yeah, beyond that.

What what else do you do that?

Synchronous, and the obviously, the vast majority of things or a sink.

We have synchronous kpi reviews.

For each what we call section.

So devstack Ops those different sections.

We have we spend about one hour a month gone through kpi reviews for each of those sections that sink.

We could do it a sink but I think there's a lot of value and the conversation that we have about it.

Another form that we have that synchronous recall opportunity canvas reviews.

This is on the front end of our development life cycle.

I expect PM's 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 form sort of forces the PM's to get their thoughts together, in a holistic manner, about the problem.

And I find these conversations highly useful as well.

I learn a lot about what they're trying to do.

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 to knit 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 got it.

And so this so 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?

Like, doing that really?

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 really need to develop particularly.

If you know, you're a nice person.

And, you know, you just may be shy.

From some of these things like like, how have you gotten yourself to be better at this?

Yeah, It's Tricky.

Like I said, I don't naturally gravitate towards 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 care personally about your team and then challenge them directly.

And if you get that combination, Bow, right.

It's magical that book.

I thought that explained why this is the right thing to do, really clearly.

So I'd recommend those two books.

Those both helped me kind of get my head in the right place about about it.

Well, you have to what you have to believe is that providing direct feedback is in their best interest.

I think a lot of people shy away from it 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 they'll be performing at a high level.

It gets a lot easier to deliver that feedback.

So I think just coming from that place as huge as a huge benefit.

We've actually had Kim Scott on on the show.

Nice.

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 there are feedback, you're robbing that person from 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.

Well, it's a word.

I made up.

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 or or making their own 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 being right, that what they say, be helpful, you know, we're reluctant to talk out loud.

And so I, that's why I think about a synthesizer.

Yeah, that makes sense and show being a synthesizer.

What kind of thing.

Do you do to make yourself operate at the best level?

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 are 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, is you have to, you have to try to meet in.

The middle and adjust your own behavior because leader, that never speaks up.

In, 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 6 pager style docs.

If you 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 synthesizer type.

And so this concept I mean the writing a 6-page strategy document in 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 the process of writing this down like as someone like if you consider yourself a A sizer, like, do you sit down and just like in one hour at type, this out?

Or is it like you?

It's a process over a period of many days and you're constantly like rewriting.

It many times until it gets to the finish line or how do you operate more of the latter?

Yeah.

For sure, you know when any complex project you're going to be taking in inputs over a long period of time, you know, I just wrote a strategy.

It's going to confidential topics.

I won't I won't mention what it Was but over the course of weeks, you know, I updated this thing.

As we learn more and I used it, as the way to capture the latest thinking if we hadn't had this doc would have been really 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 it was a living dock 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, you think is going to evolve so very much the ladder.

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 and practice and management.

That's why we've spent It 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 single spaced font, you know, lots of tax.

There's 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 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.

Yeah, and it's very interesting to go into it, knowing that you're 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.

Put what other things can you do?

Yeah, there's a couple things that get lab does courtesy of being an eight-year.

A Cinco remote company that really helped synthesizers.

I think one is the meetings always sent out the agenda sent out in advance.

And so synthesizer, I go in.

I look at the agenda in advance.

I can get the topics in my head.

I can come into that thing with more fully formed thoughts of much, come more comfortable, speaking up.

So the more that you can signal exactly what you're talking about, lay out the agenda, someone who is more of a synthesizer can can add a ton more value.

The other thing is we we keep a an agenda.

So real time is meetings proceeding and so let's just say it's on a complex tell, you know, pricing topic of something and you just add your questions of dock in order.

And what that does is it, you get away from the loudest person in the room, just dominating whole thing.

And you just go down the list and loud person has to wait.

And so, you know, as a synthesized, you don't have to barge in and interrupt somebody, you just put your question on.

Doc and then you're going to get to it and that helps increase the number of voices that are heard.

So I really like the super tactical but they work really well.

No, we love tactical.

So I guess like the question is, how much in advance is is good.

And obviously, like some things are way more complex and you need more time, but like for the average meeting, I think, for the average meeting, if you can post agenda, at least 24 hours in advance, you know, it can be hard to To keep up with.

The way I manage my own calendar is, I always have a block at the end of the day so that I can check out the counter the next day review.

All the agenda is like make sure I understand what's going to be covered.

So it's kind of fun you to prep that you can build in a time to take advantage of preset.

Agendas and topics that are teed up in the following day.

If you don't then, you know you walk in cold just like normal, but for people who are pretty Active in value.

You know having that topic in their head ahead of time you can you can you can help yourself.

And so for people that are you know, because 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 what kind of ways do you communicate asynchronously like, are there things say that are on the calendar that are me?

Things.

But they're like a synchronous meetings or like what how does most asynchronous communication happen?

Mmm.

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 to the team Channel.

Most of what I communicate to the team attended T up in agenda, docks 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, Join, they know where to find updates from me.

If they tend to be in these either leadership meeting 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 to hey, it all the updates from Scott are going to be in the agenda and 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.

Notes rather than listening to talk track because it's sometimes like you said it's hard to wait things.

And also are there tips around like how you know people like say that there's an asynchronous communication or their 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 is some sort of validation are there like A tactical things that you all do that.

Like allows you to know that the message has been broadly received.

Well, super tactical one, you know, do this all that often, but when I really need a message received, I'll send out a gitlab issue with check box for each person.

Like, hey, I've gotten this message and they have to check it and if they don't, I buggin.

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 That's a way to make sure every once C.

We also leverage the product leadership team to make sure that the smaller because they have meetings with their own groups.

And so if there's something that's super important needs, reinforced.

I'll ask them to cover it again in their own meetings.

And then you know, multimodal communication is key.

Put it in the agenda, send out slack messages, cover it at different levels and team calls and then you'll increase your odds of The message being received.

Yeah.

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's like thousands of people that work at get lab.

You've been at, 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 a process?

Well, I'll just tick off some things.

I think need to be there.

You need a great job description.

That sells the role well and accurately.

You need an interview team knows their role with little to no overlapping questions.

You need to tight interlock with the recruiter in the sorcerer to make sure they think like you do, like when they look at it a person, they look at a resume.

They know what's we really need on this team and that takes a lot of back and forth.

Sometimes especially for new roles to make sure you have the same line.

I think you need frequent Huddle's and Retros, to uncover process, bottlenecks, and scheduling.

Bottlenecks, and calibration.

We have a weekly sync on open hiring roles.

The recruiter and the Sorcerer, for example, you need people to prioritize interviews.

You have to optimize the candidate experience.

And if they're waiting weeks to for the whole thing to play out.

It's a bad experience and you have, you have two teams.

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?

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 and sure 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, make the best candidate win from there.

But once you have a diverse pipeline, we have a much higher chance of ending up with a diverse team.

It sure.

Did you say that you stop doing outbound?

We stop doing inbound.

Oh stop doing inbound right now.

It's kind of a hybrid because we got so many resumes that you'd end up with a funnel.

That wasn't particularly the Verse, so we had to sort of overcompensate and go look for people who were from underrepresented groups to make sure that the funnel look like we wanted to.

So, sometimes you have to overcompensate that, that frankly slowed things down, but we made a major move and the diversity on a team.

Particularly from a gender standpoint and I was really proud of it.

Yeah.

That's awesome.

It's very nice to hear like that what it takes and sometimes you have 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, it's like a lot of the problem is you just need to make sure that you have the right pipeline.

Yeah, I think it's just being intentional about the whole thing.

When I came in to get lab.

I told everyone who would listen, that hiring was my number one priority, and there are things that I didn't do.

The first six months has is a CPL that you would have expected.

Because I was so focused on hiring and, you know, you just have to make that sacrifice in order 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?

I'd like I'm not I'm not in all that many hiring Loops anymore because the people who report to me now.

I'll know how to do it themselves.

And so it you can get scale out of it over time.

Yeah, makes sense.

That means just going back to that like, concept of like the strategy.

Doc, it provides Clarity.

I assume there's like, you know, like you said a great job description, a great like, knowing everybody knows what they're looking for.

And what each person's role is, what have you learned about like, hiring great product leaders, like, what are the things 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?

Well, you know, we have a career development framework and y'all can check it out.

There's five different dimensions.

And so I want to make sure the check the box on all those business skills, communication skills, people management skills, validation skills and build skills, or the five buckets.

If you will, the thing that cuts across all over my, I found that I think is really interesting.

Sting is systems thinking like, can you take a problem from the beginning to the end?

Can you do, can you work the problem in a systematic way?

I think is what differentiates great product people from.

Not so great.

And so I try to test for that too.

In addition to those five buckets.

I mentioned 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 Like walk through the solution 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 text 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 a really telling, like the answers are really interesting.

It's a 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, 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 Are there any tips tricks?

Your final parting thoughts or words of wisdom that you'd like to leave them with?

I guess a tip 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, caused me to write down my own product team or product leadership principles and you can These on get Labs handbook as well.

And I was the first thing that I rolled out and get lab and it really 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?

And that underlying sense?

So as an example, number one is hiring, his job, one.

That was my first principal.

Like everybody's, we got to lean in on building this team because a player's attract a 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 really valuable to me because get life is complex its way different than my last company.

And so I didn't come in and say, hey we're going to 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 first principles 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 really 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 what have you that's that's great advice and great place to end it Scott.

Thanks so much for doing this.

You're welcome.

It was a pleasure and that's it for today.

Thank you so much for tuning in to this episode of the super managers podcast.

You can find the show notes and transcript at www.fafsa.gov / super managers.

If you like the content, Don't be sure to rate review And subscribe.

So you can get notified when we post the next episode and please tell your friends and fellow managers about it.

It'd be awesome.

If you could help us spread the word about the show.

See you next time.

Never lose your place, on any device

Create a free account to sync, back up, and get personal recommendations.