Hiring for Scrum roles is harder than it looks. Making the wrong call can derail an Agile transformation before it even starts. In this episode, Brian and Cort unpack what to actually look for in Scrum Masters, Product Owners, and Developers—beyond the job title and shiny certifications.

Overview

What makes someone a great Scrum Master? How do you spot the difference between a capable Product Owner and a glorified backlog manager? And what qualities matter most in a developer on a cross-functional Agile team?

In this episode, Brian Milner and Cort Sharp dig into one of the most foundational (and overlooked) parts of successful Agile adoption: hiring. You’ll learn what to include—and what to avoid—in your job descriptions, how to interview for the “real” skills that matter, and why collaboration often matters more than technical brilliance. Whether you're filling new roles or leveling up existing ones, this conversation will help you build stronger, more resilient teams from day one.

References and resources mentioned in the show:

Cort Sharp
Blog: 7 Questions to Determine if Being a Scrum Master Is Right for You by Mike Cohn
#155: Preparing for Interviews the Agile Way with Tali Shlafer
#157: What Teams Are Struggling With Right Now with Cort Sharp
Agile Skills Video Library
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Cort Sharp is an Agile Coach, Trainer, and Scrum Master. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here again, Brian Milner, and today I have back with us the one and only Court Sharp. Welcome back in Court.

Cort Sharp (00:10)
Hey Brian, thanks for having me.

Brian Milner (00:12)
Absolutely. Court and I have been exchanging kind of war stories a little bit and talking about kind of some of the things that have been going on in our own coaching careers and some of the clients and things, issues that may come up in some of these engagements. And I actually had one come up recently that was interesting and I've had this come up multiple times with different clients, but this was an issue where they really wanted to

kind of redefine and refocus their job descriptions, think about how to get the right people in their positions. And that's a common thing that I've seen quite a bit is that a lot of organizations maybe don't have the understanding of, they might know the rights and responsibilities of a role, but how do I get the right people into this role? Have you seen things like that as well?

Cort Sharp (00:57)
Yeah, actually, I'm working with some organizations right now that are kind of facing that same deal where, you know, they're starting out in the Scrum process. You and I were talking about this not too long ago, actually, and we figured, This is useful for more than just us. So let's put this out into the world, right? ⁓ But just talking about, yeah, how do we, now that we've learned kind of this, the introduction to Scrum, we've gotten that intro stuff, we've...

Brian Milner (01:12)
Right.

Yeah.

Cort Sharp (01:22)
talked a little bit about what it means to kind of work in this new way or new to them way of working. I don't think scrum's really that new anymore. I don't think we can still call it new, But they've been facing the same kind of questions of how do we figure out who fills our scrum master role or.

Brian Milner (01:32)
Yeah.

Cort Sharp (01:42)
Maybe we're hiring scrum masters or looking to hire scrum masters or product owners or some someone in that scrum those scrum roles there What should we put in our job description? Who who are the type of people that we should look out for so? Yeah, I'm glad you've been This has been at the top of your mind too because it's been something that I've been experiencing here as well recently So I have a couple questions for you I'd love your your opinion on some of it your take on some of it ⁓ and I think just kind of starting out

Brian Milner (01:52)
Yeah.

Hahaha.

Yeah, yeah.

Cort Sharp (02:09)
I think the Scrum Master role specifically, if you're okay starting out with that one, ⁓ I think that one's often the most difficult one to kind of pinpoint down, like who is a good candidate or what type of person is a good person to fill this role specifically. And I think that's purely because it's working more on the softer, quote unquote, softer skills, softer side of.

Brian Milner (02:13)
Sure. Sure.

Cort Sharp (02:34)
The development process right because the scrum master is focused on the people and process side Which can be a hard box to kind of check off and fill in so? Or at least harder than like a product owner says I I decide what we're working on right? ⁓ That's a little more straightforward right so I guess What what's your take on who in general? Let's start on that the big broader side

Brian Milner (02:49)
Right.

Cort Sharp (02:58)
The general side, who fills in in a Scrum Master role well? Like what are some characteristics that you look for in someone when you're saying, this person would probably make it for a good Scrum Master. What ⁓ do you look for, Brian?

Brian Milner (03:10)
Yeah.

Yeah. I mean, that's a really important question, I think. And because I think you can derail things really early if you have the wrong people in these positions. let me, I, you know, just in hearing you talk about it, I thought, you know, it's really important. I preface this a little bit to say, you know, if you're an organization entering into this kind of change, I think it's important to understand that

that does not necessarily mean you need to have new head count. It kind of depends on some factors I'll try to describe here, but you could get by with people that you already have that are on staff that you could just fit in very well. It's not a one-to-one with another job title. I think it really depends on the person. But I, Corey, as I was thinking through this, I kind of tried to divide it into a couple of different like buckets. One was sort of, what do I?

What do I ask for? What's the job description look like? And how do I phrase things in the job description that will surface a more talented candidate pool? And it's a tricky one here for the Scrum Master part because you want a person that has examples of leading without authority. You want them to show how they've been able to

make change and go from places that aren't as experienced to more experienced. I want to ask for things about team leadership, about how I need someone who has good team leadership skills. I'm looking for softer skills in the job description. And that's a mistake I think sometimes people make with Scrum Masters is they

will list a bunch of things like, you you have experience with these programming languages and all these other kinds of where maybe in some roles, maybe, but I would say the majority of them, it's really not gonna be about technical skills like that. It's more about, you know, conflict management skills, you know, trying to help teams become higher performing.

systems thinking, are they able to get to root cause analysis, those sorts of things. That's the kind of stuff I'd want to put in my job description so that I would start to surface a class of candidate that isn't basically an engineering manager, right? I think that's the mistake sometimes is that basically we just take an engineering manager kind of.

job description and both the Scrum Master title on top of it, which some of those skills carry over, but I would say there's a lot more skills that are needed that are not overlapping with that sort of same skill set. that, you know, I focus on, you know, that they teach, that they helped, you know, learn and grow and improvement.

Those are the things I want to call it in a job description. Are there other things you can think of, Court, that you'd say for a job description would be important?

Cort Sharp (06:16)
Job description specifically, I don't think there's anything that I would necessarily add, Just sticking on those softer skill sets and trying to find the people who have those little more softer skills. I'm trying to find a different word than softer, right? Mushy skills. ⁓

Brian Milner (06:32)
No, no, no. think I know it's people

have a problem with the term, but I don't really have a problem with the term as long as we know what it is we're talking about. I mean, I would, I will say certification wise, I, you know, I do train and pass on certification. So I do have a bias, but I will say that, you know, I, my personal

kind of stance if I'm hiring for a Scrum Master, I would want to see at a minimum something like a CSM, a Certified Scrum Master or Professional Scrum Master, PSM from scrum.org. Those two organizations to me are sort of the foundation. I'm gonna get in trouble maybe with some listeners here.

I'm not trying to say that there are others that aren't legitimate. think other organizations have legitimate ones like SAFE. I think those are legitimate certifications. I think Scrum Inc. is a legitimate certification, but that's about it. There's very few beyond that that I think really would have any weight at all. And of the ones that are out there, think Scrum Alliance and Scrum.org are the two that

in my opinion, personal opinion only, carry the most weight. So I'd want a minimum of sort of that CSM, PSM, but ideally I'd want the higher level. I'd want an advanced certified scrum product owner or certified scrum master, or a PSM2 would be the equivalent in the world of scrum.org. And it's not because I think that that by default makes them better, but it does give you a...

level of confidence that they know what they're talking about. You know, that they're, they're invested in being getting better at this. And I think even just that, right? If I see someone with an advanced certification or PSM two, I know that that person is invested in this, that they're not just here to mark the day, you know, and fill a slot. They, they want to be, you know,

highly achieving. want to be a good scrum master, which I think says a lot.

Cort Sharp (08:34)
I agree with you and that's a really good point there to say like, there's this extra level of confidence that you get when you have some certification and it's not just specifically Scrum Master certifications. because I don't know, I kind of struggle with lot of certifications because they oftentimes are just like an introduction. I'm a certified Scrum Master. That means I'm the master of Scrum now. Are you really? Do you actually like...

Brian Milner (08:58)
Yeah.

Cort Sharp (09:02)
want to focus on the people in process, maybe you have this introduction here and you see, you understand, you know the Scrum process now with that certification, but those advanced ones, that's a good point there to bring out of that gives, if you're throwing out hiring for a Scrum master, that does give that extra level of confidence there to say, not only do you understand Scrum, not only do you know the process, but now you have that extra layer of

drive to further your education, further your skill set, and want to actually pursue this a little bit more than just like, I read online that if I want to get into tech, certified Scrum Master is the easiest way to do it, right? ⁓

Brian Milner (09:40)
Yeah.

Right, right. It needs to

be the certification plus experience, right? And it's not one or the other, but I think that those two things together just give you a higher level of confidence. And if I'm looking for a higher level of candidate, that's what I'm looking for. I think there's another half of it too though, which is, all right, now that I have a good pool, how do I winnow that down into really good candidates for it? And for a Scrum Master, I think when I interview them,

Um, you know, some of the same things I want to hear, like, I want to ask questions like, uh, can you give me an example of when you, um, were able to influence without authority, right? When you didn't have the authority to make changes, but you were still able to influence and get things done. Um, you know, can you give me examples of how you were able to get to, uh, the root cause of issues that maybe were long lasting in the organization, but, uh, you know, and how you made progress toward actually getting those resolved.

I want to be very careful. Like you think about red flags. I want to be careful if I hear them talk about things that are kind of more meeting centric language that, you know, they, well, I ran this meeting and I ran this and well, okay, great. That's great that you were able to do that, but that's wasn't effective, right? What did you actually get out of it? know, tool ownership. Hey, I was the, the JIRA admin for this. Well,

Cort Sharp (10:58)
Right. Right.

Brian Milner (11:05)
Again, great. Like you may know how to set Jira up really wonderfully, but how did that translate into actually getting the team to improve and get better? it a tool that actually helped that or was it a tool that was kind of in the background and it never really made an impact? So it didn't really matter if we used it or not. I'd be careful if they have languages about enforcing Scrum. That's a really key telltale sign, I think that

Cort Sharp (11:28)
Mm. Mm-hmm.

Brian Milner (11:33)
there's sort of a more traditional background that's kind of more insurer on time, on scope, on budget delivery. And if they use any of that kind of language about insuring and forcing, know, kind of leading through authority, that's something I'd probably want to be a little bit more careful about.

Cort Sharp (11:47)
Right, right. Not having what that communicates to me is like some kind of hierarchy mindset where it's like, I've been ensuring that this happens all the time, meaning the responsibility ultimately falls on me and I drive the developers to get it done on time, on target, on scope, on budget, all that stuff, right? Which a lot of those don't even fall under the role of a scrum master. So someone's talking about, hey, I make sure that things happen.

on budget and it's all on time and I define all the scope of stuff. Well, I think that's indication number one. You don't really know what a Scrum Master does then and you don't understand the role that you yourself are in theory applying to. I think there's this aspect of, because I don't know, I struggle with figuring out how to frame questions and even what questions to ask to get.

those softer skills to bubble up to the surface, right? Like how do you figure that out? And I like what you were saying there of, me, give me an example of a time where you led through influence versus not, right? Or, you know, looking out for those red flags where the answers are very systemic of like, I led this meeting, we did this, we do all the scrum ceremonies. I...

Brian Milner (12:38)
Yeah.

Yeah.

Cort Sharp (12:58)
fill out everyone's JIRA tickets and make sure the JIRA board's up to date. Well, guess what? AI can do all of that, man. Like, that's not... What benefit are you bringing to the team to say, I build good relationships with stakeholders and leadership within the organization so that any time something comes up, they're not going directly to the team, they're talking with me, and we can figure out the best way forward without interrupting the team's...

Brian Milner (13:02)
Yeah. Right.

Right.

Cort Sharp (13:25)
development process or constantly interrupting the team with new ad hoc requests or whatever. Or even flip side of that, whenever the team is faced with a problem that I can't solve right out of the gate, I build up these good relationships with stakeholders, with business people and everything so that they can get removed because it's outside of my domain of influence necessarily, right?

Brian Milner (13:48)
Yeah.

Cort Sharp (13:50)
I would argue through that, you still influence stakeholders or people who could remove these impediments to benefit the team, right? But at the end of the day, it is about how are we helping the team so that the team can maximize their time and the value that they're delivering on whatever it is that they're working on, right?

Brian Milner (14:06)
Yeah,

and huge bonus there as well if their description includes language about how they don't necessarily solve the problem, but that they help the team solve the problem or that they ⁓ build the capability in the team to resolve that kind of problem. I don't want a Scrum Master who does, is the rescue for every single thing that happens. want them to build the team's capability to solve those kinds of things.

Cort Sharp (14:18)
Yeah.

Mm-hmm.

Right. Oftentimes I hear and see, especially again, when organizations are first starting out with Scrum or first implementing Scrum and you kind of touched on this earlier about, Hey, I don't just want like an engineering manager to just fill the Scrum master role, right? There's, are different skillsets. There's different things going on in each of those roles, but I do see that a lot where when organizations are first starting out, we don't necessarily have the capacity or need to hire new, new people right out of the gate. Right.

Brian Milner (14:46)
No.

Cort Sharp (15:01)
So who can we use here internally to fill the role? And there is that tendency to say, Scrum Master, they lead through influence. They help the team remove impediments, things like that. I think people really hear the leadership type stuff. So let's just put a manager in there, right? Do you feel like there are...

managers that could fill that role because my personal take is like if you have someone who's more on the people manager side of stuff where they're managing the people not so much the technical aspect of things I could see that work but do you have kind of guidance either within that manager position as a whole where it's like yeah you're a manager in this type of way that's a good sign that you would probably be a good scrum master or do you feel like there's a better role that tends to lead into that scrum master role or fill in that scrum master role

a little bit easier or smoother.

Brian Milner (15:53)
Yeah, I would say, you know, actually with Scrum Master or Product Owner, you want to be careful about having a manager in that position. If you do, then if at all possible, try to avoid having anyone that's reporting to that manager also on the team. That creates a weird power dynamic in the team that could really cause some havoc. But in general, what I'd say is it kind of depends on the relationship of that person to the team, not even just the person.

I, got an experience with that when one of my first roles, because I was manager of two teams and I became the scrum master of both teams at the same time. and one team that worked really well, the other team had didn't really work very well. And the difference was really how the team saw me. One team I was very, kind of, peer had more of a peer relationship without all the members of the team. We hung out a lot. We went to lunches together, those sorts of things. The other team.

were more junior and they very much looked at me as their manager, the person higher than them. And you can tell, you know, one of those that worked and one didn't, it needs to be, they need to see you as a peer. So that, that would be kind of the dividing line for me, not even the title, but how the team sees them. I want to make sure we talk about the product owner as well, because there's a lot of really good, important stuff here for the product owner. For example, if I'm putting a job description out for a product owner,

Cort Sharp (17:06)
Yeah.

Brian Milner (17:13)
I wanna make sure that I'm getting someone, I'm gonna make a comparison here between the product owner and developer, even though I'm trying not to skip ahead. But if you're gonna hire for a developer, you're gonna look for a certain kind of technical skills. And I think that that same thing applies for a product owner, that you need to have some product discipline in general that is outside of Scrum. So you need to make sure that they understand general business principles about how a product...

is successful and how to understand the market and the competition and you know how to make a plan for something to present whether something is going to be successful or not. You know kind of weighing the pros and cons of an approach to doing something. I think that's a general product skill that that's outside of Scrum that they Scrum expects you to have inside of Scrum. I think you need a good communicator. So I want to I want to

ask for that in my job description to say, you know, this person needs to be an excellent communicator. They need to be able to talk to stakeholders, to developers. So they need to be able to translate between these two groups. I think they need to, I want to put in in their job description that they validate assumptions, that they find ways to, you know, pre-qualify.

They don't just throw everything at the team and expect some things to work and some not. But they actually try to do the work in advance to find out if something's going to be successful or not. I'm looking for also, I'm going to put in my job description that they have to be comfortable saying no. I need a product owner that's not just going to say yes to everything, but they can do that in a diplomatic way. And that they're data driven.

that they have a way to evaluate what we can do based on actual data, not gut feeling that can be heavily influenced by bias. But do you have data sources that you regularly return to to try to tell whether this is going to be successful or not? And then I'm going to ask questions all about that when I get to the interview. I'm going to say, me examples of how you use data to try to determine what's the most important thing to do. Give me examples of

of where you've had to say no to a stakeholder in the past. Give me examples of where you've had to deal with a difficult stakeholder that's maybe over-aggressive or trying to push their direction when you know it's a better option or a better idea to do something else. I want to hear stories and I want them to be able to, and part of it's just hearing them communicate the story, right? Because if I need a good communicator,

Cort Sharp (19:38)
Yeah.

Brian Milner (19:41)
If they use a bunch of big jargon, if they start to get, you you start to feel yourself kind of feel like, my gosh, I'm tuning out with what this person's saying. That's not a good sign, right? It's not a good sign for that person to be a product owner because they're probably not great communicator if that's the case. And your stakeholders are gonna feel the same way. And your developers are gonna feel the same way. They're gonna tune out.

So I need a visionary. need somebody who has an idea for the future, the direction that they take ownership of that direction. And they can give some clear examples of how they've done that in the past.

Cort Sharp (20:16)
Right. I want to stick on one thing there because you're talking about being data driven in decisions, which to me that screams metrics. What metrics are you tracking? What metrics are the product owner tracking? And that's something that I would throw into an interview position there and be like, hey, what metrics do you track to make sure that you're delivering value, to make sure that things are making the marketplace that actually matter, not just

the new shiny object type thing, right? ⁓ So what metrics are you tracking or you are having your product owners track, I guess, Brian, to keep an eye out for to say, OK, this is a green flag. Are there any metrics that are red flags for you? Yeah.

Brian Milner (20:40)
Right.

Yeah, yeah,

absolutely. This is a great question because this is where I want to hone in on, right? Because I want to know green flags, things that are going to be good are outcome-based metrics. I want to hear them talk about how they measured success based on ROI, on user adoption or attrition rates or...

customer satisfaction. These are outcomes, right? These are things we try to drive with the things that we prioritize. I'm going to be very, very leery of someone who presents something like, yeah, we were able to increase story points that the team delivered by this much, or we went from delivering three features to five features. Great.

But it's only great if you actually did your job as a product owner and made sure that those five features were actually all really important. So, right. So how did you do that? Right? ⁓ That's what I want to know. so I think you're absolutely right to hone in on that. Is it an outcome based metric that they kind of have used traditionally to judge success? Or is it an output based metric that's all about volume?

Cort Sharp (21:47)
Yeah, that they actually mattered. Yeah. Right.

Brian Milner (22:05)
⁓ Volume doesn't really tell you anything.

Cort Sharp (22:05)
Yeah, yeah.

Right. Which I love that you mentioned story points because boy golly, have I heard so many instances where people are like, oh, well, my team's velocity is 100 and Brian's team velocity is only 50. So obviously my team's better. And even just like that's such an internal metric and something that everyone kind of sticks to.

Brian Milner (22:26)
Right.

Cort Sharp (22:35)
How do you show product owners then, I guess? Let's get into, you know, little outside the interview process stuff. But how do you show product owners, like, we don't want to just increase our velocity when in fact, stable velocity, a little more consistent velocity that is stable, is actually a better metric or actually a better indicator that the output or the outcome is much better than just a volumetric output.

Brian Milner (23:01)
Yeah,

and this sometimes blows product people's minds when you enter this discussion because what we're actually proposing in Agile seems counterintuitive to a lot of people. And that is that doing less can actually be better. As a product person, there's that part of the Agile manifesto that says simplicity, the art of maximizing the amount of work not done is essential.

you know, there's a great drawing that Henrik Knieberg has, sorry, I got it wrong, has where he shows kind of a person loading up a truck full of just regular old bricks, and then another person loading up another truck with gold bricks, but the regular brick truck is full, the gold brick truck only has a couple of them in there, but you see that and you recognize that's what we're trying to do as a product person is find the gold bricks.

not just loaded up with any old brick that we find, but we want to find the things that are going to actually deliver value. And if that slows our overall output pace, that's actually OK. Because again, if we're taking the time to find the gold bricks, then we have more gold in our truck at the end of the day. And that does take more work to determine that.

But that's kind of what I'd want to try to emphasize with a product owner to get them to understand is it's okay for the team to actually do less as long as the things they're doing, you are investing enough time in an advance to make sure that they're actually valuable.

Cort Sharp (24:38)
Right. Absolutely. Yeah. Let's dive over to developers now. What, I mean, obviously very dependent on what type of product you're building, very dependent on what the foundation is that's already been established at the organization. Right. I don't want to be looking for, you know, an HTML developer if they're, if we're working primarily in database structures, right. we don't need.

Brian Milner (24:42)
Yeah.

Cort Sharp (25:03)
We don't need a front end person necessarily right out of the gate there, right? Those aren't the skills we're looking for. But outside of the specific like programming languages or programming skills, what are there, are there any indications that yeah, this, this person would be a great developer on a scrum team specifically, right? What do you look out for for that?

Brian Milner (25:22)
Yeah,

it's a great question because I think you're right. A lot of times we stop at just the technical skills and say, well, I just need someone that can do this, that, and the other. that's what I'm going to look for, which I'm not saying that those aren't important, but I'm saying that if you want them to be successful in the Scrum team, there's other qualities. And this is going to get into my performance review of them as well. I don't want someone who is the lone wolf that can kind of

or the term that people used to use all the time is rock star. That's my rock star developer. And usually what that meant was they went and put their headphones on and worked by themselves. They could knock anything out, but they kind of worked as a lone wolf. They worked on their own, were not really a team player or a teammate. And so that's what I'm looking for in addition to the skills for a Scrum team is a team player.

I want to ask things in the job description. I want to make sure they're clear as well, because frankly, some developers are just going to say that's not for me. And that's OK. I'd rather know that upfront, right? But I want to put in the job description that I need a team player. need someone who is focused on not just the quality of their work, but the quality of the team's work and trying to raise the temperature of the entire group around them, not just themselves.

And having that to always get to the next level, right? Of constant improvement and getting better. I want them to have a testing or quality mindset that it's really important to them that they do high quality work because I need them to own that, right? I want them to own that as a team and as a developer. And this one is, some of these things you may not be able to...

Cort Sharp (26:58)
Yeah. Yeah.

Brian Milner (27:08)
to suss out in the job description, you may have to be the actual interview, but I wanna test their comfort with ambiguity. I don't wanna have someone who needs everything spelled out. ⁓ So what level of detail are you expecting before you start work on something? Do you need to know everything? Are you looking to know the basics of it so that you can get started and then explore and figure out what's the right stuff to do?

Cort Sharp (27:18)
Yeah.

Brian Milner (27:33)
These are all things that I think are really important and being able to slice work down into smaller segments so it's not just one big chunk. And that's what I want to ask questions about in the interview as well is, you tell me examples of when you had to break something down into smaller portions? Can you give me an example of when you had to work on something that you didn't really know all the details about yet, but you were able to, you were okay with that ambiguity and able to.

to figure it out with the team as you went along. Can you give me examples of when you helped another teammate improve and get better? That's the kind of person I want on my team. And I will be honest with everyone here as well. I would rather have less technical skill and stronger collaboration skill than the reverse.

Cort Sharp (28:00)
Right.

Brian Milner (28:18)
And I think that's the mistake a lot of times organizations will make is they'll put the technical skill first and then, if they have a little bit of this other stuff, great. I want the collaboration skill one, because if they do that, then it will cover all the knowledge gaps, right? If I'm on a team of five people, I can't know everything. No one else on the team is going to know everything, but collectively we can. Collectively, we can pool our knowledge.

Cort Sharp (28:26)
Right.

Brian Milner (28:45)
And that only is going to be beneficial to us if we are comfortable collaborating with each other. yeah, it's kind of an opposite kind of thing that I think a lot of people look for, but I would put the collaboration as kind of even more important than the technical skill.

Cort Sharp (28:51)
Right.

I 1000 % agree with you on that one. In my own personal experience, my own personal life, I've experienced this many times. And also just talking with some of my friends and colleagues who are in various organizations around at various levels, right? It's so much easier to teach the technical skill and the technical know-how than it is to teach how to work well with other people, right?

you, I think you again, just really nailed that one there where the technical know-how often is the first thing to say, yeah, we need someone who has, you know, 10 years experience working in this language on these platforms, blah, blah, blah. Right. But I don't, I don't know if, if I was in a position where I was hiring, I would much rather want to work with someone that I enjoyed working with.

Brian Milner (29:55)
Yeah.

Cort Sharp (29:55)
⁓

And that I and that my teammates enjoyed working with or my team if I'm hiring for a team my team enjoys working with whatever right Because this the technical skills can be learned they can be taught they can be very very much so I'm not gonna say easily pass down or pass from one to one person to the next but it's significantly easier to Teach the technical skills than it is to teach Here's how to work with people. Here's how to work together, right? ⁓

Brian Milner (30:19)
All right. Yeah.

Cort Sharp (30:22)
so much of so many hiccups, roadblocks, and just holdups in any kind of process, doesn't matter if you're strong, agile, or working in tech or not, so many times the problem just comes down to this person does not work well with this other person, or this person doesn't work well with this team, right? And for whatever reason, right? And oftentimes the people don't even recognize that we're not working well together.

Brian Milner (30:40)
Mm-hmm. Yeah.

Cort Sharp (30:48)
Right? It's just, yeah, we kind of bicker, we butt heads, but in the end we figure it out and the thing gets delivered. Right? Well, is that the best outcome? Is that really what we're trying to do here? So I'm curious, Brian, would you at some point in the interview process or hiring process, I guess, would you ever bring the team that this person would potentially be on into the process at all to say, hey, let's do a little bit of a litmus test of one, does this person

Brian Milner (30:49)
Yeah.

Cort Sharp (31:14)
like the teammates here that they're working with or could work with? And two, does the team like this person or work well, right?

Brian Milner (31:21)
Absolutely, absolutely. I would say on that inner, like I would want a standard kind of form that I would give to the team as they interview different people. And one of the things I'd want on that form is cultural fit with a team. You know, how would you rate their fit with a team? I want to be careful about that because I don't want it to be, that can be carried to an extreme, right?

where now you're just into biases. But I want to coach them to not go into that area, but I do think it's important to say, do they fit? Do they feel like they fit with the remainder of the team and that this can be an effective team working together? Absolutely, I want them to have feedback on that. One of the clients I worked with recently had this really great way of thinking about some of these skills we've been talking about.

They divided them up into skills that could be taught and skills that needed to be innate. That this is an innate quality of that characteristic of that kind of person. If they don't have it, they're not going to have it. And I would say for all of these roles, that's kind how I would think about it as well, is what are those non-negotiable things? What are the things that need to be innate in the person that you aren't going to be able to teach them if they don't have it?

you know, if, if, and this developer wants a great example, right? If they're not collaborators, if, if they are diametrically opposed to working with other people and they, they want a way of working that is individual solo, I need to go put my headphones on and not talk to anyone. I can't teach that. Right. that's a preference. That's a choice. That's how they, they're made up. And I can teach them about how long a daily scrum should be or what they should do in a daily scrum. But I can't.

necessarily change someone's mind to all of a sudden say, don't you think it'd be better if you got other opinions? Don't you think it'd be better if you actually got the best idea out of the group rather than just leaving it to your own brain? Those kinds of things are more innate. And I think for each of these roles, you have to kind of separate those things out and say, what's the things they have to bring to the table on their own? What's the things we can teach once they get on board?

Cort Sharp (33:21)
Yeah, yeah, that's a really good just kind of upfront filter, I guess, to try to filter out relatively quickly. But then it just makes me think like, OK, what if I was in that person's shoes, that developer's shoes who had the teachable skills, but not the innate skills, right? How would I go out and try to gather those skills or get those skills? But I think that's a different conversation for a different time. think we're kind of on the edge of time right here.

Brian Milner (33:47)
Well,

yeah, and you just, think, you if you're one of those roles and you're listening to that and thinking, hey, maybe that's one of those things that I don't have, then I think you have to just kind of ask yourself why, right? Why don't I think that's important or why is that something I disagree with or why is that something, what's behind that? And some of the stuff gets really into your personality type and you have to kind of do some self exploration to say, is there a reason why?

Do I really feel it's better or is that just what I've always done? Does my personality make it more comfortable for me to not have to talk to people? And I think there's self-exploration there, but from a hiring standpoint, I want the best person for the role and there's plenty of candidates, right? There's always plenty of candidates. And if I want to distinguish myself, then again, if I'm hiring people, I want...

stories. I want to hear examples. I want to say, give me an example of when this happened. Tell me about a time when those are the interview questions I want to ask in the actual interview to try to see if they have an answer for it. It's obvious if they don't, right? They'll make something up and it'll be very vague, right? But

If you ask for a specific example, give me a specific example where something like this happened, how did you handle it? yeah, there was a time when blah, blah. And it's that kind of stuff that you start to gain that confidence that this person not only knows the stuff, but they have experience in doing this. They're going to hit the ground running when they come in.

Cort Sharp (35:22)
I also, on top of that, because just while you were saying that last little bit there, it made me think, oh, stories, right? We all wanna share the stories. We wanna have people who have the experience and the stories. But I think we're seeing a lot of recent college grads, kinda younger people who don't necessarily have the experience. So I would want, instead of someone who, yes, obviously, I want the experience. Yes, obviously, I want people who have the stories to tell me.

But I would also look for someone who they get to the interview process. I ask them, hey, tell me a time when this has happened or you experienced this. Instead of them making something up to try to tell me something that I want to hear, I would very much still look for someone and appreciate someone who is honest and said, you know, I haven't faced that scenario yet in my career, in my growth, in my career path or development that I've been through, but here's how I would approach it.

if I were to be faced with it in the future. And here's what I would do to see if my approach was appropriate or not and the takeaways that I would learn or the things that I would look out for to learn there as well. ⁓

Brian Milner (36:30)
Yeah,

or there was a team I was doing a project on in college where we did this thing. I don't care if it's an example from college. That's fine. That's experience. So it doesn't have to be in a business context. Especially if you're interviewing for more of an entry level kind of thing. Yeah, just give us an experience from your life.

Cort Sharp (36:48)
Sure, yeah, absolutely, 100%. But I think the honesty is the bigger takeaway there, the bigger point that I'm trying to make of, honestly, I haven't been faced with that in a business setting, but here's the college, closest thing that I've experienced, whether it's a project in college, project in high school, whatever, or just outside in life in whatever way. yeah, ⁓

Brian Milner (36:56)
Yeah.

Yeah, I agree. Yeah, the honesty is very important. Well,

Court, I appreciate you coming on. This has been a good discussion and I hope that, you know, maybe there's people out there listening who are about to enter this zone or maybe it's time again to enter this zone. And, you know, you're kind of thinking through these kinds of things. So I appreciate you coming on and helping us kind of walk through this a little bit and talk through, you know, kind of the ins and outs of filling these positions.

Cort Sharp (37:37)
Yeah, absolutely, Brian. It's always fun sitting down and chatting with you and able to talk about things that help me out in what I'm working on, too. So I appreciate it, Brian. Thanks for your time.

Brian Milner (37:43)
You