Péter: Welcome everyone to the Retrospective, engineering Leadership
podcast with Jeremy and I, Peter.
We are starting our third season and we are focusing in this season.
on usable, self-contained engineering leadership content.
The idea is that just like we did in the previous season, we are
selecting one topic for one show.
Try to keep it short and discuss all aspects.
So with that being said, Jeremy, what do we have for today?
Jeremy: it's great to be back for our third season.
and today I wanted to talk about, task relevant maturity.
it's a concept that's helped me a lot and it's a concept that has also
allowed me to help others as well.
Péter: Cool.
Let me play the reporter.
What is just task relevant maturity?
Jeremy?
Jeremy: Well, actually maybe before we dive into what it is, maybe we can
like talk about some of the challenges
that managers face.
So, one of the things I've seen with brand new managers and often
companies are promoting someone who's very strong, technical, very, who's.
Sometimes, often the, maybe one of the best engineers in the team.
not the best pattern to choose either, but what ends up happening
is that those new managers end up micromanaging everybody in the team.
they slice up the work and they dish it out.
and they plan all the stories in advance.
when people are doing the work, they can run into issues with,
with our team members because.
Team member we're talking about knowledge work here and people,
don't like being, micromanaged.
at the same time, you also have then some people who, are totally the opposite.
They are totally hands off and, then I. Things go off the rails or, people
get stuck and work doesn't progress.
and then you have like the worst combination of all, which is
where you do both and the way
Péter: Yeah.
Jeremy: where you throw stuff at people and then you kind of dive
in later and micromanage them.
I guess the problem is like how do you adjust your style get the
best from the people in your team?
Péter: Yeah.
And just to add to the worst challenges, I also so often that, perceived
seniority of the person and say things like, you're already a staff engineer.
you're a senior engineer.
This, this should be natural for you.
And, and just expecting the same level of, you know, being comfortable
and being able to perform quickly on a new subject just because of their
previous, achievements or experience.
Jeremy: Exactly.
And, it's, it's a challenge.
And, and by the way, you
By the way, you know, it's.
know, we talk about we talk about these concepts like we know them
really well, but often have to be reminded myself, as well.
think we all regularly fall into traps, you know, are around
how we manage, how maybe how.
Particular with particular people, we connect in different
ways and all the rest.
I feel like this is a
can help a lot of people.
Péter: Yeah, I agree.
And, and even the framework, like thinking about what, what you will
explain later how to, how to identify when to use this tool, how to assess
someone's task, relevant maturity.
And then knowing that this assessment means that the approach I should take
is more hands-on or less hands-on.
That's a very useful framework that can be, can be used in the day to day.
Jeremy: Exactly.
So let's dive into what is
maturity, because it's a weird
weird way you call it?
I have to use weird name.
It's not
I should not necessarily directly,
in one sense.
so the origin of Grove.
Andy Grove was, one of the, would say is one of the famous,
tech CEOs of, of all time.
And, he's, he's really the.
he was the CEO of Intel, but Intel's a company that's
struggling now, but he was also the
Intel did so good and
in a dominant position.
And, he wrote a book called High Output Management.
And, this is one of the concepts, from the book.
And essentially, it's, it's a very simple concept instead of, you know, you talked
about senior people and, junior people and so on, instead of, Having a specific
style for senior people and a specific style of, of, managing work for very
more junior people, graduates and so on.
So his, his point is that you need to
adjust.
style
style of,
based on both the person
task that they're going to do.
for example, you know, let, let's take something super
simple like you have a graduate,
Graduate.
Mm-hmm.
and you're asking them to do a fairly simple task and you know,
they're capable of it, like.
maybe send a weekly email about, you know, how, what work you've done.
And, and you might find that
Might find that that graduate actually entirely capable.
that, you know?
Might find that
is actually struggling much more to do that.
so you've gotta adjust.
the, the key insight on this, framework is that it's not by person,
but it's really about the person and the task combined together.
he identifies like, Based on their maturity to do a specific task.
You adjust your
Either, have like a, a higher, pay higher attention and coaching and
Or you,
or you?
You back off.
lower management intervention in, in what they're doing.
Péter: Yeah.
Yeah.
I, I like that.
'cause when, when I'm talking about delegation with people in my teams, when
I'm managing managers, I always describe it them as like a balance or a slider
where, where you adjust the slider.
on, based on how much, well, a lot of stuff based, based on the person's task,
relevant maturity, the level of your trust in the person and, and their execution.
And this is where it comes in, that it's not just the task, it's the person also.
And maybe you take a different adjustment based on the task itself.
'cause it's, if it's a critical, super high profile test, then.
Maybe the person would do an okay job and it would be a great learning opportunity.
Maybe you would adjust the slider to be more collaborative
and less autonomous for them.
Because, because of the, the risk of the task
Jeremy: Yeah.
And one of the, think one of the things that.
I often, miss and, and most people
of people miss when.
with this concept, is actually having a discussion upfront with the person
about this specific task and, and having this language of task relevant maturity,
not just be something, it's theoretical that you as a manager know and they
don't, but actually introduce this task in the team, in your conversation,
and then you say, okay, for this task.
do you feel like you need me?
that it's, it's a game changer to have that conversation upfront about,
because then you agree a level together.
Péter: As we started, this is not about the person, it's about the task.
So what it does is it removes the responsibility for the person.
It creates a safe space for the person to say, I'm not comfortable in this task.
This is new to me.
And, and this is not gonna be about their performance, it's gonna be
about their task, relevant maturity.
I love, I love this idea.
Jeremy: Yeah.
Yeah.
then, you know, talk about then what does that
what that mean?
how do you then respond as a manager for, for different levels?
Péter: Mm-hmm.
Jeremy: if the person has low maturity, as a manager you need to
give much more structured, guidance.
Really, really clear expectations.
And I think.
the majority of the time when it goes wrong is you haven't, as a
manager, articulated clearly what it is you're actually expecting.
You just, that's often where I see things going wrong and to be honest,
even on different levels as well.
it's also about the
that you then, check in with that person and, the level of
feedback that you give to them.
And the, kind of going back to the expectation, like
what's the success criteria?
What does good look like?
the, work with them every day,
seeing that the tasks are moving and and so on.
and I think, I think that's, the number one thing is it's,
this is not micromanagement,
it's really
specifically agreeing the level and then going to the level that helps
that person be successful in the task.
Péter: Yeah.
Yeah.
even when handholding or collaboration is, is useful and required, like in
these cases, micromanagement is such a bad word to describe it because
what, what it says is basically that the other person is just, clumsy tool
that I'm trying to operate things with that, through this person.
and and that's really not what happens here.
As you said, it's about helping to structurize the.
Task making expectations clear and and being a bit more prescriptive and
giving them a little bit less autonomy.
So, so they, they, they get back to closer to their comfort zone.
Jeremy: And one of the things I found that, on the, on this
particular one, it can surprise you,
You
you might think that the
think that the person to have,
when you
your expectations.
But you are often, I
that you are, The, the person didn't actually get it.
Péter: Mm-hmm.
Jeremy: and you'll see the signs as you start to see the work, being done.
instead of, I think one of the things that we would then
do wrong is we, our feedback,
can get frustrated.
We, the feedback comes
you know, 'cause it's taking, it's very time consuming as well.
I think go back to the
To the point of what trying to achieve,
Why am I asking
Why am I saying.
way?
Uh, what did I not explain to you or what did you not understand
when I explained it to you?
so I think that it, I think like most of the people we work with have some
level of competence in, in the job.
We interview for it, we hire for it, and so on.
so the, I would say that often it's a misunderstanding.
the why or the reasons for specific things.
Péter: But here's the thing, like if, if you're working with someone who has a
low, task relevant maturity in a, in an area, it doesn't necessarily mean that
you need to provide the extra information.
Maybe it's gonna trigger you as a manager to pair this person on
this single task with someone more experienced in this area, and,
and then just, and then you can.
You know, optimize your time a bit better and, and, and delegate in a different way.
So it's, it is just about that person needs a bit more
collaboration on this task.
Jeremy: Exactly.
Exactly.
Yeah.
And so
to
move someone, maybe it might actually be worth talking about like that where
someone is high task, relevant maturity
Péter: yeah, that's easier.
Jeremy: middle.
'cause it's easier to go to the extremes.
So I would say someone who, you know, feels like, yeah, I, I get it.
I know what I'm doing.
Here you are.
you're
Your dream together,
the high level
high level.
you're kind of, run things.
It's an they're gonna be kind of independent, and they should be mo,
they should be very independent.
I, I would say that someone who has a high task relevant maturity, also
able to know when they're stuck and know how to ask for help on the task
Péter: It's very important.
Jeremy: Yeah, I mean, and we obviously talked about that in the past about
senior engineers and what it means
and so on.
but I think like here, what you want to focus on is, providing
the business context because as a manager, maybe you have a more of
a context around what's going on in the business that they may not have.
I think setting in place some kind of gates with the person, you know, where
you say, Hey, can you, you know, when, when you're planning the project out, can
you, can we, can you, show the milestones that you're planning to do and so on.
What time boxes will you have?
I think
Think having a discussion about
okay are, you know, it's more of like a
more of like a
about the, the goals they've set or the, the key technical points that they're,
the decision points that they're making.
so you're more partnering,
partnering.
Péter: Yeah.
Yeah.
And, and just as we said in the last, the other extreme, maybe this
is a case also where it's not me who's gonna, you know, validate and
collaborate with the person, but maybe a principal engineer from another
team, maybe a, maybe a product manager.
it can be, it can be anyone else.
Yeah.
Jeremy: And I think, you know, the mistake or when things go wrong is where, fail
Fail
more of the strategic or business
business context,
to, because.
because
You are
you are often as a manager, more focused,
of the
more of a wider,
of your job is to do the stakeholder management wider within engineering
and, and inside the company.
And it's
that this individual contributor understands those things.
Those are the constraints.
because it might, and obviously this is also a conversation with a product
manager, Maybe we don't need all the bells and whistles, but we need to
ship something now to win a deal.
Right.
that the, the, context can make a big difference,
Péter: Yeah, it's it's all about making it very clear, not necessarily what we
are developing, but why, the person really understands and can make those decisions
it's interesting that you call this out as a big risk because I saw another big risk
this is more about trust, I guess, when the manager recognizes that the person
can have a high level of autonomy and they delegate the task efficiently and when.
The developer comes back with a solution.
It's different from what the manager would've done.
this is, this is really a hard situation because, well there, there are no
prescribed solutions for everything.
But once you give.
I guess what I'm telling to my managers is that decide if you're gonna
trust the solution from the person.
Make sure that if you have some kind of internal acceptance
criteria, make it explicit.
don't assume these kind of things.
And if within those criteria it comes back with a different
solution, then be happy with it.
There's a good chance they, they chose a better technical solutions
because they are more technical.
But this is very hard for some managers, especially hands-on managers when
they, when they are very close to the code, where they're very close
to the tech and somebody comes with solution that's different than theirs.
It's, it's hard.
Jeremy: Yeah, I think, I think the risk here isn't, about the risk of dealing with
the person and their thing going wrong.
It's actually what goes wrong inside you they present their solution.
the this in this particular situation where you have high task relevant
maturity, as you say, the biggest, challenge is allowing that to happen.
And, the worst thing you can do is say, I don't like that solution.
Don't do it that way.
Do it this way.
you, you know what I would, so this is a learning that I've, I've
had, that I. Still fail at doing.
But when you have that moment of like, why are they doing it this way?
I would never do it that way.
Turn your solution engineer, brain and ask questions, did
this?
Why did you not, consider this option?
you know, and, You know, I had this other favorite library that I really like.
Why didn't you use that?
You know, or this tool or whatever, or I came across this thing somewhere
else and either, they actually did consider it and, and they give you a
logical reason or maybe, maybe not.
And then you have a conversation.
the moment you impose your solution back down on them, you break
everything, you break the relationship and you break their motivation.
And, it's super toxic.
It's the worst thing you can do to someone.
Péter: Yeah.
Yeah.
Because it essentially says that, initially I told you that I trust you,
but jokes on you, I don't trust you.
And, and that's, that's not, not a good in, in these cases.
I, I, I tell people to, I. Well be transparent,
indexing, index it down a bit.
Say that I, I know that you have all the skills to do this.
Maybe it's my fault, but this is an important project for me.
Let's work a bit together, at least on the first steps, so, so we can discuss all the
details and you dial down a little bit the delegation, knowing that this might not be
ideal, but you need to take into account your level of trust with the person and
your level of comfort if the solution is different from what you would've chosen.
Jeremy: Yeah.
And I
Péter: But do it initially and do it transparently.
Sorry.
So don't, don't do it at the end and, and don't, don't hide this.
Jeremy: Yeah.
and I would also say like when you plan and you see that, oh, that's
a different approach, put in agree earlier tests of the strategy, to
de-risk it, work on the milestones, around what, what's being done to.
if you feel that maybe your experience is telling you that it's a different,
maybe a different way would work better, just put in some checkpoints for the
risks that you see about their solution.
Péter: Yeah.
Jeremy: in fact, then what you're doing is you are, undercutting
them, that's a great idea.
I think there could be some risk with that.
let's de-risk it by doing these things and so much better.
Péter: Yeah, but a lot depends on the details it's, it's easy to.
Come across as micromanaging as
as we said, so, you should really have a transparent trust-based
relationship with the person.
So they don't assume that you're just hiding that gonna micromanage them anyway.
And the task you're posing is just a quiz to find out what the boss would've done.
So
Jeremy: Yeah, exactly.
Péter: don't do that.
Jeremy: I guess the, the hardest thing about task, high task relevant maturity
people, especially people who demonstrate that consistently for many, many tasks
is, you push them out of the org.
eventually because you, because you don't give them the right level of autonomy.
to do what they need to do.
And that's, and when they leave, they'll say, I felt it was micromanaged.
Péter: yeah.
Well maybe that's like, do you wanna talk a lot about the middle?
'cause I have some other questions about assessing and not sure
what advice we can give at the middle, but let's jump on into it.
If you have something
Jeremy: you're more focusing on, coaching.
I.
and I think you.
You, you need to be ready to adjust your style up or down, depending on
how it kind of starts to pan out.
you're often focusing more on, make sure we get the high level architecture
right, and then and we can work together.
Or you have, have someone else, work with them and then they're often
able to do the execution It might be that they needed a bit of help
structuring a few things, but then in the actual detail they're, they're okay.
I think this one is really hard because you are, you need to adjust,
Péter: Yeah.
Jeremy: or down your style constantly.
Péter: Yeah.
Jeremy: but you know, I think like as long as.
You're, you have regular check-ins.
they're not gonna be daily.
I mean, you expect this person in the daily standup if you have one
or whatever, or however you're, you should see status being updated
on a daily basis, in my opinion.
that's a warning sign for anybody that's not happening.
you might, you might just have like, they're gonna, every week
they're gonna turn up and do a demo.
Right.
so on.
So this one's tricky, but, usually there, what you're doing here is
helping them to unblock themselves.
coaching, like, you should go and talk to this person.
I think they're, et cetera.
It's helping them with their network in the company,
Péter: Yeah, I, I guess the, the tricky thing in this situation,
being in the middle is that.
It's, it's hard to plan far ahead.
you need to be flexible of changing your approach almost at every interaction.
Maybe what you, on Monday, you plan that this guy has it and I I don't need to
pair with them during the week and Tuesday you find out that's actually not the
case you spend half of Wednesday on pair programming with them explaining some
concept that you assume they will know.
So,
Jeremy: Yeah,
Péter: but, but I, I find that, well, first of all, I think.
most people are in the middle somewhere, so extremes are
rare, so get familiar with it.
But on the other hand, I really like it because this is the place where, where
I think the most growth can happen.
because the
is not super lost and they are not peaked neither.
They, they are.
Ideally they have some good momentum and they are learning something.
Jeremy: Yeah.
that's a good, point to segue to what, what we should all be trying
to do here, which is helping people move up the levels of maturity.
so if you do the, if you do it once, maybe the next time you're, you know,
you're much more capable of doing it,
with less, with less help.
And, and, and the, the number one message for managers is.
One size fits all.
Management style does not work.
Don't do it.
getting good to ask, asking questions of your most experienced, capable
people, you know, adjust your style.
Go, you know, and have the conversation up front.
You know, and even like, I think the key thing here is we, we talk about
spotting signs when things, when things go off track, but the key thing is.
It's not a, a one and done conversation.
it's, it's, you do it in the project.
You can do it during the project.
You can say, you know, we talked at the beginning about like how we would
work together, but I feel like you're really struggling here and maybe we
can meet a couple more times a week
Péter: Mm.
Jeremy: to to, to see if how we can unblock you.
Péter: Yeah.
Yeah.
Or, or on the other way around, like, like I expected to have a four hour
session with you where we discuss the framework and, and actually I had the
idea that maybe you don't even need that and, Yeah, I, I guess what we could a
little bit talk about is, how to assess someone efficiently and effectively.
I really liked that you started out with just be transparent
and as the question from the person, how comfortable they feel.
I'm wondering if you have any other tips or tools or anything that a
manager could use to assess the task relevant maturity of an individual.
Jeremy: Well, I think like if you have someone who has done the task a million
times, then you kind of, you know, you, you cannot, well you, put this?
can end, end up having a situation where they do it a million times, but they
do it really badly all, all the time.
Péter: Yeah.
Yeah.
Or, or actually, yeah.
Jeremy: I'm, I'm going for that.
You've done it.
A lot of times you kind of, you, you just know they're
gonna do it well and, yeah, I.
So the, the, the thing you shouldn't do is just say, this is a senior person.
I have a one size fits all style with them.
and, and so I think part of being able to assess is having a trust-based
relationship with people where they feel safe to tell you and, and I'm struggling.
I'm a bit stuck or whatever.
But yeah, I, I think this is, I think the other bit of
assessing is when you sense that.
Things are not going well between you and the other person project,
and you're like, why are they kind of getting upset with me?
You know?
And, is it, is it because I'm like all over them, you know, like I give them
a lot of feedback on this document and I told them that I really wasn't
happy with the approach they took.
and then, you know, they, they gone a bit dark on me or whatever.
Like, that's a sign that maybe you need to adjust your style, you know?
Péter: Yeah.
Yeah, yeah, that's, that's actually a good approach.
I would say that.
Trust your instincts, like you're the manager of this team and of
these people, and you know them.
So trust your guts, but only set the initial level as we discussed This is,
this can be adjusted during the project, so find a good starting point like.
I believe this person has a very high task revenue, maturity.
So I'm just gonna give them, explain the requirements and watch
their reactions, what kind of questions they ask, everything.
And even during that discussion or, or the next one, you can balance it
a bit more down or start from the other extreme and watch out for signs.
If the other person feels that you're telling them stuff that
they know, then adjust it.
Uh,
but yeah, as as you said, not treating it as one, you know, judgment and, and
keeping to it, but keep on adjusting it.
Being flexible is, is important.
Jeremy: I think the other important thing to note is that as a manager.
You don't just manage the people and, and dish out the work and stuff.
You to some extent, you actually manage the system of work,
how people work in the team,
Péter: Hmm.
Jeremy: know, the, the dailies, the, the retrospectives and so on.
And so.
What you also need to think about is how do I adjust the system of work in the team
when things are going off track and to help people have that level of autonomy.
How do I, how do I pair people up, in their, in their work?
And, you know, how do you know, think there's a lot of controls that you can do.
And if you put in, I don't mean controls in a kind of like
micromanage sense, I mean like.
Little checkpoints, like standup, you know, like, in the standup show, the
Kanban board or the sprint board of the team and say, Hey, this one hasn't moved.
You know, like use it as an opportunity to use visual management
to highlight the things that, where things are going off track or not.
and you have a lot of influence in how you run the system and the team to,
To spot where things are going well, where they're not going well and so on.
And I think that control of the system, of, of work, is a way to
also assess if the maturity is right or not of, of a particular,
Péter: Yeah.
Yeah, that's, that's, that's well said.
Yeah.
I have a last question to you.
Usually we as managers, we want to ensure that people in our team are growing
in their personal careers, and most of the learning is happening outside of
someone's comfort zone where they can be free to make some mistakes and learn
from those mistakes and everything, but.
Sometimes we get projects.
Oftentimes we get projects that are super critical and we cannot allow any kind of
delay because somebody made a mistake.
How, how do you balance these two needs, of, of having to, you know,
deliver appropriate good outcomes and, and ensuring that people have
the safety to make mistakes and learn from it so they can grow.
Jeremy: So the number one mistake that managers, especially hands-on managers
make is they do the thing themselves.
Péter: Yeah, Yeah, yeah,
Jeremy: so don't do that.
but be like close.
I think I. Offer critical past stuff.
first of all, have people work together.
you know, really important stuff.
I think we talked about you have management judgment, you
I have this person.
Maybe that's a great challenge for them to prove themselves,
like they're going for promotion.
they, they're looking for
Péter: Mm-hmm.
Jeremy: and so you sit down with them and say, Hey, this is really important.
but I think you can do it.
I'm gonna, I'm gonna sit with you and, might be a little bit closer, but I'm,
I'm just trying to make sure that, you know, because this is really important,
tell me if I'm too much, you know, you can have these kind of conversations
and, then you can adjust your style depending on how
it's going and, and so on.
and, and in some cases where it's really critical, you might have, A
weekly meeting with a customer, a weekly
you know, with internal stakeholders, the boss's boss,
the CEO or whoever.
so you, you know, like, you might need to provide a little bit of
air cover for the team, especially if someone's not used to it.
I would say like you just, you, you kind of those still as an
opportunity to grow people.
Péter: Yeah, no, I mean, I think you nailed it in the beginning
when you said pair people.
'cause I, I found it so powerful, like working together on, on a single project
pair programming or even more programming.
This is so beneficial for, for the more senior and the less senior people too.
And I. It, it results in better quality software also because there
are more people catching problems.
They, they can argue with someone.
They don't need to keep their assumptions inside.
And, yeah, I really like that as a tool to balance execution, you know, high
risk, projects and, and personal growth.
Jeremy: Yeah.
Yeah.
Nice.
Yeah.
that's, that's what I wanted to cover.
You know, basically I. As a manager, adjust your style based
on the task that, people are doing.
not don't, don't just have it adjusted, but for each person, but
actually for what that task is, what that person is doing on their task.
And, The more mature they are, the more you ask questions and the better
questions you ask and the less mature, maybe you can be a bit more directive
Péter: Mm.
Jeremy: in between you, you know, you use your coaching
skills to move people up, the
Péter: Yeah.
Yeah.
Awesome.
Just one more thing to add to reemphasize, because I love this.
It's not always you who has to be the person who gives them the context or pair
them with, maybe you can find someone in the team and organization and, you
know, I don't have a better expression, but kill 2 1 2 birds with one stone.
I, uh, yeah.
Jeremy: You
your
task, relevant, mature person now being, having to grow by not just
doing the task themselves, but grow someone else to be able to do
like them.
Yeah.
Péter: exactly.
Jeremy: Yeah, yeah, yeah.
And, you know, ultimately that's the whole point.
You're a multiplier as a manager of the team.
your, your goal is not to be a superhero of the team, but a multiplier.
Péter: Yep.
Jeremy: Okay.
what I'll do is I'll put some in the show notes, a few links, to some, some, well,
the book and, and a few other articles that might be helpful for you to digest.
some of this if you want to go deeper on the topic.
Péter: Awesome.
Thanks Jeremy.
That was super timely, I think in today's high pressure era where we need to balance
execution and, and efficient delegations.
Thank you
Jeremy: Yeah.
Péter: and thanks everyone
Jeremy: It's great to be back doing our podcast in season three.
Péter: Yep.
Yeah.
See you in the next episode where we will tackle a similarly exciting
engineering leadership problem.
See you folks.
Jeremy: Cheers folks,