Craig Kerstiens: A couple weeks ago we dug into getting your first PM job, on
what skills you need.
This week, we're going to look a little bit at the other side
of the equation: when do you need a PM?
How do you go about hiring one?
What's that process, the other side
of the table, look like?
Rimas Silkaitis: When do you really need a PM?
This is going to be maybe a biased answer here,
but since we're PMs on the show,
I'm going to say: almost immediately.
Would you agree with that?
Craig: Little bit, not so much.
I've been a first PM at a couple places now,
and I think that's a very interesting, tough kind of time,
going from founders.
So this really depends on the size of company
you're looking at.
Rimas: Okay, so let's be clear here.
We're talking about startups here, or very small companies.
We'll get to the other side of it,
of when you're a large enterprise,
how the PM looks, that kind of thing.
But I think a lot of
our listeners are startups.
A number of Heavybit companies, or familiar with Heavybit,
At that point, you've got the founders doing a lot
of this early-stage, truly, product work. So we're on the same pages there.
Rimas: Okay, good. I'm glad we got that covered.
Craig: Now, we've got to scale up.
We add some engineers.
At what point do you hire the PM?
Rimas: I personally would say: when it's time for the founders
to start doing more business-type work and they need
to offload the rest of that to somebody else.
they're getting to the point where
they can't do everything anymore.
Craig: I think that makes a lot of sense.
I think I've seen some counter examples.
I've actually seen an interesting company that's scaled
to about 200 people.
Rimas: Without a PM?
Craig: Without a PM.
Rimas: Holy (bleep).
Craig: I think they're the exception.
But it's very interesting to say,
now what kind of engineers do you put in place?
So I guess that's more the exception.
Rule of thumb, what size of company would you say
that you should be thinking about hiring your first PM?
Rimas: In terms of number of employees?
Craig: Yep, and assuming this is mostly engineering.
Rimas: Yes, let's assume. You know,
tax-software type companies.
I'm probably thinking number five, six,
seven, eight, somewhere in there.
Definitely before number 10.
Craig: I think we're going to end up disagreeing, still, for now.
Rimas: Oh, man!
Craig: Because that was our, a little bit here.
I would say a little bit more like 15, 20.
Usually you've got the split of founders,
one that can run a lot of the business.
One that can do a lot of the product.
At Heroku we actually saw this.
We saw the founders still wearing a lot of that PM hat
a long time, until about 20, 25 employees.
This probably bleeds into the question of
do you hire a full-time PM, or do you hire someone
that's partially PM, partially something else?
In which case, you can do it a little earlier.
Rimas: Yeah, I'd agree with that.
So, we'll meet halfway.
Craig: Alright, alright. About that point when, you know, founders are busy
with a bunch of other things, busy with customers,
busy with the business things, they may still be involved
in the product, but maybe 15, 20 people,
you start to bring in an actual, true PM.
Rimas: Of course. And you know, from my perspective, I think
it's important that, when you bring that person in,
they're really dedicated to talking to those customers.
When we talk about the founders getting stretched
a little bit too thin, that's the opportunity where the PM
can really shine and say, okay, what's going on
in the marketplace, what the customers are saying,
and really collating all that information so that
that can get looped back into, you know,
what the engineering team should, quote unquote,
should be building.
Craig: Completely, and I think that founder's status
has a certain power in selling and talking to the customer
that no one in the company will have.
So you need to utilize that where it's most valuable.
So, at about that 15 to 20-person size company,
when you start to hire the PM, I want to talk a little bit
on, where do you find that person?
I think that person is very, very different from a
50-person company, a 100-person company.
That first PM
is a very kind of foundational role, and comes in
with a lot of barriers overall.
Rimas: I think, if I were to go look for a PM at that size
of an organization, I'm looking to my network.
Who do I know that has had good experience with somebody
as a PM that has maybe had prior experience?
Because you need to put a lot trust in that individual.
Because they're coming on so early, that the business
may be ambiguous, the product might be in a place
where some features or things might be ambiguous.
Being able to pull all that out
and undo that ball of wax,
understanding where the direction should be going,
I think that's very important.
And going to your network, and
back-channeling, whatever you've got to do,
getting those recommendations, is probably going to be
more critical than going to a job board
or something else like that.
Craig: Yeah, I would agree completely there.
I think within your network is huge.
Because at that early stage, that trust is so important,
that you do a lot based on trust.
You don't always have the bandwidth to do as much
deep dive and analysis as you'd like to.
Sure, they should be doing that,
but you don't always have the bandwidth there.
And not coming with the backing of the founder.
A founder has a certain extra level of credibility,
no matter what.
Maybe in part because they can get rid of you
if they want to, which a PM can almost never do.
there is that authority.
They've poured blood and sweat and tears,
years of their life probably, into it already by this point
at 20 people, that you need to have some level of trust.
From a network, a positive experience from
either a founder or another employee
or coming very, very highly recommended from someone
you've trusted is usually really key at that early stage.
Rimas: Just touching on the trust part a little bit more, if you're that founder and you've got a PM, that
you recognize that you need a PM, having that trust
will allow you to offload some of the, like you said,
you've got this baby, and it's tough letting go
of certain things.
But you need to
as your organization scales, because your role
kind of changes over time. And especially
at that lower employee number, if the trust is not there,
you're going to find yourself diving back in and saying, "Ugh, I've got to do this stuff,"
and that's not where you want to be.
Craig: I think even, regardless, you'll find yourself
diving back in. But that's a separate talk,
for a separate episode on
how founders do this kind of work with PMs
and other kind of parties. But as much as you can give them
that trust and then be as hands-off as you possibly can,
if the rest of the org doesn't see that trust
coming from you as the founder,
when you first make that call...
Rimas: Oh, then it's over.
Then no one else is going to trust that individual.
Rimas: Let's say your network isn't as robust
as it should be.
You, through friends of friends
or acquaintances of acquaintances,
you don't have a strong PM candidate. What do you do?
Craig: I think you hit on something there.
You find someone as a PM that has done it before,
maybe worked at a small-stage that you know, done good work.
My favorite thing to do is, throw out
one of those pieces that has been a PM before,
I think you look at counter-areas.
Now, this is a hard one because, as a founder,
you probably weren't a PM before.
You may not have that practice, no one else in the org may.
So they've got to start to learn it really quickly.
But I think if you find a good engineer,
you find a good sales engineer, some of these roles
transition really well into product management.
I've seen it kind of go both ways.
I've seen it go really well, where the individual
transitioning from one of those roles,
let's say engineering, recognizes that
their role has changed. And they
take it with gusto and start talking to customers
and defining scope and doing all that kind of stuff.
I've seen it go the other way, where the engineering
individual will take on the PM role, but it ends up becoming
into more of an architect role
where they're defining implementation.
And that's actually gone horribly wrong.
Craig: In thinking on it a little bit more,
I do think that when they've made the shift
to a new company, and they have to prove their credibility,
they can't shift to that architect role.
They have to rebuild their credibility, and they have to
do that by building.
So when you're looking at that, maybe, sales engineer
that's looking to come over to be product,
or engineer that's done some customer-facing things,
it's better if it's a shift, that first one at least.
Now, it may change on the second, third, fourth PM.
But in that first PM hire, if it's a shift
from another company, usually they still have to actually
do work to get that credibility,
which makes it go a little bit smoother.
Rimas: So if I'm looking from outside and I see somebody
that's a sales engineer and they're coming in
and this is their first PM role,
would I have the expectation that that individual grows
into a much broader PM role,
meaning that they start hiring PMs themselves?
Craig: I think, very possibly.
It depends on how successful they are.
That takes a lot of question of how do they grow
into that role, how do they move up?
It's a big open question there
and really depends on the person.
Rimas: I really want to talk about the skills
that you're looking for in PMs,
whether it's within your network or you're just going to have
to go out via maybe a job board or
accelerator or something else like that,
where they can give you references.
What kind of skills do you look for in a PM?
Craig: I actually tweeted this a couple days ago.
SQL is one of those skills that,
whether it's PM or not, I can't underestimate it.
The ability to dig in, do data analytics on your own,
is absolutely huge.
If they can't do their own analysis,
if they rely on a data analyst team
whether this is a 20-person company or a 2,000,
the ability to actually get your own insight, for me,
is almost a deal-breaker if you can't do that.
Rimas: But I've seen so many good PMs that
may not have that technical prowess when it comes to SQL,
but have the logic to kind of back it all up, come on.
Craig: I think there's an exception there. Yes, you can understand reason about it.
In most cases I've found they still aren't afraid to dig in,
and I think maybe that's the difference,
the afraidness, the, "It's not my job to dig in and deal with the data."
Rimas: I hate those words. "It's not my job."
I should almost never hear that.
Craig: But I think it's a common thing you'll hear of, you know,
whether someone likes a PM or not, if PM says,
"This isn't my job, you go do this."
Like, you're not going to win any friends inside the org,
whether you're 20 people or 2,000.
Rimas: Oh, man, I fear for the person that says that.
So, listeners out there, please don't ever say,
"This is never my job."
Craig: But I think on that SQL side still,
the PMs that you have found that are proficient,
that can do their own analysis, there's immediately
that higher level of respect already there
that they can do the work.
They can figure out what needs to be done
and then make the right calls.
Rimas: I will say both of us on this program
are data people, and again, I don't want to
recognize there's a bias here. But...
Craig: Even some of us are better than others.
Rimas: Oh, easy, tiger.
I will say that you can get pretty far,
even with just simple counting of rows,
and those other things with SQL that,
even with understanding distributions and things like that,
you're going to get pretty far.
You'll be much further than, let's say,
60-70% of other PMs out there.
So, I'm not saying the bar isn't that low. But I kind of am.
Craig: Yeah, and not necessarily just SQL.
I think SQL is the lingua franca of
how we do data analysis.
But it could be Splunk, it could be
writing some scripts to pull it up.
SQL is the one I would encourage, but if you are familiar
with one, whether it's like Splunk
or some other kind of deviation of SQL, the ability to do
some form of analysis puts you ahead of most.
Rimas: Okay, so this sounds like we're implying that this PM
needs to be data-driven.
Is that always the case?
Craig: Not all are.
I mean, there are absolute visionaries.
You look at a Steve Jobs. Was there any data
to say probably remove buttons from the original iPod?
Rimas: Probably not.
Craig: It was probably against all sort of data.
I think there's a balance there of vision and
I actually really like Facebook's term
of being data informed.
You look at Facebook Beacon
when they first launched it,
and all the data said it was an absolute failure.
Now, if you look today, Facebook Beacon has basically
been rolled out identically, again.
They redid it a little, rolled it out,
not so much negative press.
I think they actually did that two, three, four times.
I'd have to look back.
But there was still a broader vision
that they were going for. So I think having
some vision there matters. But yes,
absolutely, being data-driven is, hopefully,
an obvious requirement.
Rimas: Does that matter on the stage of
where your company's at?
I mean, we talk about smaller companies
needing a lot of vision there to be able to sell your product
sometimes to other customers and things like that, to get them onboard, that you're going to get to this place.
Is that more important, to have that at a smaller stage?
Craig: I think it depends on your level.
At a bigger company it's a question of whether you
are more of that visionary PM, at a larger company,
which you do as you move up in the ranks.
If it's at a smaller company, you've got to be both of those.
If you're at a 20-person company, you've got to be able
to say, "Here are the 10 features we're going to pull together."
And the engineers absolutely may care
about the broader vision, but they may just want to go work
on their feature.
What you need to be able to do is tie these things
together for a bigger launch, for a bigger coordination,
to actually do all of the marketing.
There's a whole lot more that goes into
that earlier stage.
Some of it is vision, and there's still a whole lot
of being data-driven.
Rimas: I'm getting a little worried here. Because if someone
needs to have the vision plus, you know, be data-driven
to some extent, are these individuals unicorns?
I mean, I know you and I are, but, you know.
Craig: I think you can sway one way or the other
And knowing where you're weak,
knowing where you're strong, is helpful.
I personally would not have seen a case
where pure intuition, at least at an early-stage company,
I've seen those people get hired and get a lot
of excitement, but over the long haul of,
refining the product, iterating on it,
those things aren't as exciting to them.
And the product tends to rot over time.
But, what are your thoughts?
Rimas: I would agree with that.
I think the intuition, the vision-type PM,
is somebody that, depending on where you're at
in your organization and the products
that you're working on, I think makes a lot of sense.
If you're talking about a greenfield project,
like for sure, I want somebody that has
that intuition and vision, I would like somebody with that data-driven bend
to them to help out when it comes to assessing
what's going on in the marketplace. But
that's not a deal-breaker.
Like you said, if this is something where the product's
been out there, it's been vetted, and you're starting to get
some traction, I'm less inclined to have the visionary.
Unless you're going for some bigger play where
you're building a, to use
big-company parlance, a program or something else
along those lines.
Craig: I think there's a couple things in there.
I think that that visionaries are getting their data
in different ways.
You hit on that a little bit.
At the big, 2,000-person company, you're looking at things
like a Gartner Magic Quadrant, you're reading user reports. You're thinking on a three to five-year timeframe,
and you're making big, big, big investments.
So, you're taking your data in, and it's a little more
qualitative than quantitative, but it still exists.
At the smaller company the visionary does tend to
drop down a little bit, and your vision is "What's
six months from now?" and how do all these features
Rimas: For sure.
One of the topics that I'd really like to talk about is
like doers versus delegators.
I don't want to imply that visionaries aren't doers,
but you know, sometimes that line can blur a little bit. And I think the two are a little bit orthogonal.
Is that distinction even important
when you're looking for a PM?
Craig: It definitely is.
At a small company, I've seen way too many times
where they've brought in a person
that's been a VP of Product, a Director of Product,
five times over, and is used to having 10 people under them.
And I think it applies outside of product too.
It applies to marketing. It applies to sales.
Rimas: Oh, even engineering.
I mean, possibly?
Craig: Right. A VP of Engineering probably hasn't
written code in a few years. And if you need them
to actually shift some stuff, unless they have
20 people under them, it's hard to do. So, it definitely applies on the size of the company.
I would tend to encourage, especially on the product side,
to steer more towards inexperience and that ability to "do"
and enthusiasm, than a, and again, delegator probably is
the wrong word.
If you loosely couple that delegator/visionary
that needs the resources under them,
you're going to be a little disappointed.
I think that's oftentimes where some sour taste comes,
when you talk at a startup-tech-focused company
and say, "Marketing gets a bad rap,
product gets a bad wrap. Sales gets a bad rap,
because you've brought in high-level people
that don't communicate on the lower level
and actually get (bleep) done."
Rimas: Yeah, I don't want to imply that one or the other is bad.
I think it really depends on your situation.
Sometimes the delegator, even in a small company,
can still do fairly well.
I mean, it really depends on how many of those delegators
you have across your organization and where you really need
Let's be honest,
even at the 20-person companies and below,
a lot of the roles are somewhat fluid
in terms of what people need to do.
I mean, I still remember having to jump in
and do sales, basically. I think we've talked about that in past episodes.
Craig: Yeah, and I'm with you a little bit there, too.
Delegators is probably the wrong term.
Think of it as a coordinator, someone
that maybe isn't doing the legwork but is coordinating
a lot of the pieces.
We'll have to come back, maybe, on a good term for it.
Rimas: We could probably spend a whole episode
just talking about naming things.
Craig: I think that was cued up for a future one.
Rimas: Okay, so we've got a set of skills.
We talked about being data-driven,
we talked about SQL,
doers versus the unpopular term of delegator.
We've touched on big versus small company a little bit.
When do you decide to kind of say, "Okay,
I'm going to pull the trigger on this individual?"
Or let me even rephrase that.
What kind of things do you do during the interview process
to say, "Okay, I have vetted this person
and I think they're a good hire"?
Craig: This probably devolves right into
your interview process,
which I'm actually really curious if there's another
Heavybit podcast that we can refer to
about interview processes for startups.
If not, maybe we could do a cross-collaboration there
with a few others.
For me, one thing is: get them doing it.
Get them doing real work. That's huge,
to actually test it.
It was described to me that Heroku created startup projects
way back when, which used to be a one to two-week
You would be a consultant.
We would pay you. It's like you're working for us.
It was described to me as dating before you get married.
It's a commitment on both sides;
you're really trying this out, you're invested,
and at the end of it you know if you're going to
take the next step.
For me, it's something like a starter project
where you're coming in, and maybe you don't have two weeks.
Actually, I think a lot of startups do.
You can find people that are consultants,
that have this time, that are sitting around.
If they don't, work with them.
But startups can pretty easily say, "Yeah,
we can bring you on as a contractor for one to two weeks.
Let's try this.
We have this project, get to work."
Rimas: I will point out that maybe you don't even need
one to two weeks.
Maybe you can do this in two to three days.
The point is that I think you need some
extended period of time, more than just one day,
where somebody comes in and sits down and talks, interviews,
actually about the mechanics
of doing the work.
I will point out that from my perspective,
I really think that if you do go down
the starter-project route, you really need to have that
individual do something that you're not sure
of whether they can fill that gap and the gap that you need
in your organization.
Because if you do not do that, then what'll happen is
you could misfire, hire the wrong person,
and then you're going to pay for it for, you know, who knows?
And if you have trouble firing, then
that individual could be there for months to years.
Craig: And I think, on that firing piece,
that's one thing if you're making a lot of investment
up front in the hiring process,
then you should be slow to fire.
If you're not making that investment up front,
then you should be very quick to fire them and say,
"We hired you too quickly. This was our bad,
Be long-invested on both sides,
or be quick on both sides.
Rimas: I'm sure we could spend
a whole other episode just on firing. Personally, I think it's demoralizing to the company when you're quickly hiring somebody
and then firing them, so caution.
Spend as much time up front as possible when you're hiring.
Craig: Agreed, on the same page there.
I think you do have to think,
if they're not working out, then you have a responsibility
to everyone else in the company to get rid of them quickly.
But yes, I think it is far preferred to spend the time
up front, spend the investment.
If you are doing a two to three-day starter project,
don't assume that you don't have to do more work up front.
I actually think with the one to two-week ones,
it's a little less work, maybe.
You spend more time over the aggregate of it,
but it's less up-front work.
So, if you're doing that compressed, two or three day,
and it's an actual project, you do have to do a lot of work
up front to make sure it's productive.
Rimas: Somebody's come in, they've done a starter project
with you. What signals are you looking for to actually
pull the trigger on a candidate?
Craig: There's a whole lot, and I actually want to get into that.
But I want to come back a little bit first.
What are they doing during that starter project?
What are some of the best ones
that you've coordinated and run and done?
Rimas: On the engineering side of things,
they're actually writing code, doing some kind
of project there.
On the PM side of things, it is actually things like, "Can you go through a planning process?"
If I do not think you can do that kind of thing,
is it, "Can you dive into customer feedback
and tell me what the real issue is here,
and then present it to the team as what we should take on?"
Things like doing presentations, mock sales calls,
things like that.
Craig: Yeah, I think that's spot on, and I was a little sad there
because I thought you were about to say, "It depends."
The prototypical project manager answer.
Rimas: Well, we should rename the show to "It Depends."
Craig: Absolutely agreed there.
And I think a previous episode with Raj,
we highlighted a great one, actually.
I mean, in sales. We basically did a swap
that was essentially a starter project
where he interviewed, like, 10 customers
about this potential feature we were looking at building,
figured out what we needed to do,
and then made a proposal at the end.
We talked to the engineers about what was feasible.
It was almost a perfect one, end to end,
that was talking to customers, talking to engineers,
figuring out the value, and then making a proposal.
And the rest of it
is pretty easy to manage, relative to
making those up-front decisions.
Rimas: One thing I think we might have left out in all this
is what kind of commitment does the whole team
need to have, relative to the starter project?
Craig: This is something I kind of wanted to hit on,
in that two to three days is really important for me,
to pay attention to when they have coffee,
when they have beers, how they are interacting.
The team is super critical in all of this
and should be involved, you know, time-wise, too.
I think there's the official capacity,
but then there's the casual capacity. Because as a PM,
chances are if you're a traditional org,
no one's going to report to them, and if so,
it's a more junior PM.
No engineers are ever going to report in to the PM,
which means you have to get engineers to buy into
what you're trying to do,
to support you without any of them reporting to you.
So you actually have zero authority.
Rimas: Yeah, trying to pull that off in two to three days
is pretty challenging.
But I think you can overcome it.
I know I have in past jobs.
Craig: But you're generally just looking
for the indicators.
Does the team like the person?
If you like them, it's a huge difference.
Now, for someone like sales, not to crap on sales,
which we tend to do, but well, to crap on sales, you know,
it's not my ideal, to go out drinking
with a salesperson, usually.
If you think of the used car salesman type, the stereotype...
Rimas: Do those exist anymore, I mean?
Craig: Well, with Tesla, probably not soon.
But yeah, I mean, I've seen salespeople come in
with their black books.
I've seen those get hired at startups,
and I've seen those close deals.
So it's a question of how you want
to structure your org.While they might be right for my business,
the engineers aren't going to have to hang out with them.
With the PM, your engineers are going to have to interact
with them on a daily basis.
So I do want to see that there's a rapport there.
Rimas: I sure hope there's a rapport there.
If not, then you have to really question
this individual during the starter project.
You know, one of my favorite things to do is
have PMs get up and give that presentation.
I think that is probably the seminal activity that I've had
all of the ones that I've interviewed actually do.
They do the slide where, sell me on some idea,
and I'm going to come back at you.
Whether or not the questions I'm asking are based
in reality or not, I am going to poke holes in everything
that you're saying up there to see
how you react to pressure.
Craig: See, it's really interesting
because I take a different approach there,
where I heavily coach and prep them, but then
basically tell the engineers to go at them.
Rimas: Oh, so you tell the team to do it.
Craig: I tell the team to do it and see
how they defend themselves against the engineer,
how they hold up, how they look at that sort of probing.
Within the starter project, I try to be
their cheerleader, their support, prep them
on every step of the way. But then I want to see
how they debate with the engineers.
I have to do it all the time. I want to see how they do it.
Rimas: So if there is any dissent within the team,
if anybody says a maybe, or there's that one person
that says no, is that enough to just
kill the whole hiring process for that PM?
Craig: This comes a little bit back
to your company's hiring policies.
I've seen where anyone says a no, and
that's an outright no, across the board.
I think if you do build really high-quality teams,
fow much do you build
teams that are too homogeneous, there is an open debate.
I think it depends.
There's a little bit on the why.
Why are they saying no?
Is it because they didn't think they understood
the technology, and was that the goal
of the starter project you gave them?
The engineers don't always have the full insights.
You set them up with some info, hopefully your engineers
aren't spending all three days with them.
You're spending the bulk of that,
but the engineers are spending some time.
So, you've got to make a call there,
based on why they said no, why they objected,
and can you reason about it with them?
How strong is that no?
It really varies there.
Rimas: I wholeheartedly agree.
I think it really depends on your situation.
There I go again. I said, "It depends."
You know, if you're in a situation based on your company's
hiring practices, where it's not like your hands are tied,
but if you're in a situation where
the candidate has been vetted, but
there's minor dissent, sometimes that's okay.
That's good enough.
I would concur with what you're saying,
that it really depends on the goals that you'd set
for that candidate when they came in and whether or not
they made those goals for you as hiring manager
looking for this PM.
So, you've gone through,
you've finished your starter project.
Is a starter project the only way to do this?
Craig: No, I think there's plenty of ways.
It's a matter of how much time and effort you have.
You can go through a traditional interview process.
You're still looking at a lot of commitment from the team; can you give them homework?
Can you give them, here's what we're talking about,
interview an engineer?
I actually used this for a product marketing candidate, "I'm going to have you interview the engineers
about this stuff, and now I'm going to have you write
the launch blog post and create the launch plan.
And I'm going to see what you come up with."
I understand it's a little
throwing them to the wolves, because they didn't understand
the technology. But there's other ways that you can do this.
I think it is really imperative,
at least on a first PM hire, to actually have them
do some of the work.
Rimas: I think I'd agree with that.
So, you make the decision, you say yes.
What happens next?
Craig: At that point, hopefully,
you make the job offer, they accept. And you're done...? No.
The starter project I really like
because it is more of that dating before you get married.
You're both trying each other.
Hopefully, you both walk away knowing that, "Yeah,
this is great. This is what I want to do.
This is going to work."
Rimas: Have there ever been instances where the candidate
doesn't do that? Like, the opposite direction?
Do you know what I mean? They're not really interviewing you,
they feel like they're just being interviewed?
Craig: On a first-PM candidate, I have not found that
to be the case. There's still a little of both sides.
Now, at a later-stage PM, at a PM two, three, four
at a 100-person company, yes, I have seen that.
That's a completely different discussion,
and there you know you have a very capable PM,
they've come through references,
you're seeking them out. And at that point,
there's a whole different playbook of
whather you really need this person.
Rimas: For sure.
When I finish a starter project,
I think one of the last things I like to do,
before saying yes to a candidate,
is just being clear the tasks that they have to do,
so they understand what they're getting into
before it actually happens: "The starter project should illuminate a lot of that,
but just to be clear, PM candidate,
this is where I need you. This is what you need to do,
and these are the expectations."
That way, so long as it's written down and you guys
are agreed to them, when they show up
to the organization, especially the 20-person company,
they should know what they're getting into starting in,
and where to focus their time and energy.
Craig: I like to do the alternative to that
side as well, and say, "What do you want out of this?
What's your goal here?" Especially on the first one.
On the later ones, it's pretty clear
there's a clear growth path.
If you're coming from someone that's maybe not
a first PM, but it's their first PM job,
that's a big one of, "What do you want
to get out of this?
Where do you want to grow in your career?
What skills do you want to improve on? You're helping out, in a way, here,
but I also want to support you long-term."
There's both sides of that,
and I think having that discussion is really important.
Rimas: I don't want to imply that
it's a set of tasks that need to be done,
but it's more of, like,
"These are the problem areas that we have
that are acute right now.
I need you to go and fix those things."
Craig: So you don't want to imply it's a set of tasks
that needs to be done, but it is a set of tasks
that need to be done.
Rimas: It depends.
Craig: Absolutely. Like, "Here's what's burning,
does this make sense?"
Then, "What do you want to tackle?"
It's an open-ended discussion.
Rimas: For sure.
I think on that note we've rounded the horn on hiring. If you have any more questions or want to dive deeper
into this, hit us up