The discussion centers on enhancing engineering effectiveness by focusing on how to best direct effort, close the gap between problems and problem-solvers, and measure outcomes rather than just output.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
Hello, everyone.
Good afternoon.
I'm Joe Levy, CEO and founder of Uplevel.
We are an engineering effectiveness company.
I was an engineer a long time ago and moved into various business roles and
founded Uplevel in 2018 to focus on the challenge that engineering leadership has.
We'll talk about that a bit more.
And of course you can go to our website and other materials, but really the
agenda today is to talk to someone that I've met about a year and a half ago that
I've been very impressed with Jason Yip.
Jason, what I thought you could do is maybe give us a little
background about yourself.
Tell us who you are, how you got to where you are, and sort of what you do today.
So, I guess starting out, I'm kind of an old school extreme programming, agile guy.
First heard about extreme programming back when I was still in grad school and one
of my colleagues pointed out, Ron Jeffries had this website called xprogramming.com.
One of my colleagues said, you should check out this article
about extreme programming and that's kind of where it started.
We just started talking about that all the time to anyone who would listen,
got involved in the online forums on usenet, on the original wiki.
Yeah, right.
Yeah, it's kind of funny.
Like I don't even know how many people even know about the original wiki now,
cause they only know Wikipedia, but yeah, there used to be a time before
Wikipedia, when just this idea of an editable website was a new concept.
But that's where the extreme program crowd hung out.
Then we kind of got into agile.
you had like things that was like comp, I guess the equivalent today would be like
Reddit, kind of, but yeah, there was like comp.object, comp.softwareengineering.
And that's where we would have arguments about extreme programming, which is
kind of wacky now, even today, people think they come up with a new argument.
I said, no, I argued about this 20 years ago.
I already heard this before, kind of stuff.
So it's, it's kind of weird.
but that got me into the community.
My advisor helps set up the first extreme programming conference in Sardinia.
met up people, got hired by ThoughtWorks, cause I was originally
from, I'm originally from Canada.
got hired by ThoughtWorks, moved to Chicago for about a year, went back to
Canada, and then, moved to ThoughtWorks in Australia, where I was there for about
12ish years, before joining Spotify in New York City, I was there for about 8 years.
And then, I'm currently working as a senior manager and product engineering
at Grainger, since, March last year.
which is kind of been a shift because I've mostly, done software stuff and
Grainger does industrial supplies.
So now there's like a physical component of that.
It's kind of interesting because I've been along the way, was
also very interested in lean.
They talk about lean as in moving stuff as opposed to just the lean software stuff.
So it's kind of interesting to get that, you get people who get concepts
and then you're just helping translate to, the software side of things.
What particularly interested me about a lot of what I see in your Medium post,
so for those that don't know Jason has a fairly active Medium blog, we'll put links
in the show notes here and definitely encourage you to go follow that.
One of the things that I see you write about in your various topics is focus.
How do you balance
that thinking when every problem is different, every solution to it is
different, and yet you have to stay focused and get something out the
door in some reasonable timeframe?
Yeah.
we talked a little bit about this before.
I think there's this kind of framing sometimes when people think focus, they're
almost thinking about what they're losing.
and I think that's sort of the fundamental trap.
So, when you go, "I could potentially do all of it.
And by focusing, I've lost all the stuff that I could potentially do."
And there's this thing of just realizing, no, you're not going to get anything.
And you have to decide, given all these things, where can you direct your
effort to create the most leverage?
and that's what focus is about.
Focus isn't just do one thing rather than 10 things.
It's pick the right thing that gives me the most impact for my limited
effort, which is almost always less than the 10 things, The point is where.
Let's unpack that a bit because I think that's a really good concept,
but it sounds hard practically.
A fictitious dev team, someone listening out there, they are assigned
10 things to work on, over the next sprint, a month, whatever it is.
And they're all that, you know, they didn't get on a list because none of
them are unimportant, but certainly they have some varying levels.
What's your approach to say, okay, two of these things can be ignored, one of
these things is absolutely critical.
You know, like how do you kind of get the team rallied around that?
Yeah.
This can get really complicated.
So, I'm going to go with the easiest version is this team is, let's say
they're not mature or good enough that I don't have to say anything.
If they were really good, I don't have to say anything.
They know how to deal with this.
So the top level advice is just, Hey, we can talk about, here's
all these things you could do.
.You only have so much effort that you can allocate.
Think about that and just work out how to maximize impact.
Like, that's all I want you to do.
Maximize impact, right?
Some teams that's enough.
Good.
Like I just had to kind of push them over the edge, done.
That's the easiest one.
The one below that they go, "I don't know how to do that."
A lot of that is to understand the context of every request, right?
It's not just someone asks you to do something.
Why did they ask you to do that?
What does it give us?
Do you understand the thing that you're providing and how it fits
within the broader context of the organization you're working in?
And you might have to go, okay, I'm going to have to walk you through that.
Cause you don't know how to reason about that, which is why I'm talking to you.
Cause otherwise I wouldn't need to, cause I would just say, Hey, just do the same.
So that means they don't really understand their capability and
their place within the organization.
So we have to kind of talk through that, And then I might go even further
than that and go, "Oh, even with that, they don't know how to deal with it."
Then we start going, okay, maybe we play with some tricks here.
There are some things which are more practical stuff.
There's another, director I talk to, and, sometimes they're going,
"You know what, sometimes I don't really want to have to have people
dynamically negotiate every decision."
Sometimes you just kind of make a close enough type call, so you
say, I'm going to do a strategic allocation, and then you do it that way.
And then in the long run, it's close enough.
And I save a lot of time in the negotiation argument.
Okay, so let's take the, I'll just do, I'm gonna do the assumptive, you're
close to the top of that chain, like every team by design, you have some new
hires or someone a little bit younger.
But I'm relying on the senior people to keep them in line.
Yeah, that's right.
But you do have some people that are maybe, still learning
and coming up that ramp.
So you have to sort of balance that out.
You're halfway into that and they're like, you know, now that we're halfway
through this problem, actually...
They're devs, right?
Like devs at heart.
The best thing about this whole world is like, look I've built half the Lego
blocks, but I thought of a new way to build the castle that's even more fun,
right, like architecting it as it's going.
How do you balance that pressure?
When that happens, most of the time, I would suspect that they were being
cut off from the consequences of it.
So they don't, there's a open loop somewhere, right?
This is why like really experienced people, they kind
of go, ah, don't do that.
Right.
It's like for new people.
I'm going to try to get them to go through that loop as quickly
as possible, so they feel it.
Right and this is why, you do things like, you're going to try to get
something shipped to production.
You're going to do a stint, which will be supported because
you might not be ready yet.
I like to do an on call.
So you kind of get a feel for it and then you're closing loops.
So when you're, we have a decision, you're not just thinking about right now.
You're thinking about the entire loop, which helps.
That doesn't like, it doesn't mean you're perfect.
Cause sometimes you just can't anticipate it, but at least you go,
"Oh, no, I understand that this call has a consequence, which is not going
to be someone else's consequence.
It's going to be mine because I'm part of this circle of life."
And they make better calls.
Yeah.
I've always been like pairing a lot.
These days, everyone does ensemble, but it's like you pair.
So you were never on your own either, but it's still like, there was no expectation
that it would be someone else's problem.
It was yours.
So like that generally, that's how I go.
Like when people say, "Hey, I'm going to do this thing cause it's fun," almost
always they're sacrificing future self,
That's
which you don't tend to do when, future self gets beat up a few times.
Yeah.
That's totally fair.
I think the challenge that I hear a lot in that is you don't want to stifle the like,
maybe it actually was a much better idea.
And the path we were on was, you know, problematic for some other reason.
Right.
Like there's this part of trying to people talk about, Hey, when do you
just do boring stuff versus that stuff?
I mean, there's no perfect answer here, I get, but
it's hard and if we go super meta cause this becomes a strategic call, not just
software stuff, when do you rely on, like, there will be a point when you go,
Hey, right now I'm going to use reliable technology because I'm not going to try
to get advantage through the technology.
I'm doing something else, but over time, in a broad sense, if you
don't, at some point, up and coming technology can dramatically just kind
of changes the underlying context
and you miss that, then that's dangerous.
So you go, Hey, how do I deal with that?
And that's almost like at a strategic level.
I almost don't even want a team necessarily to worry about that.
It's more like, "Hey, we'll think about this more broadly" because
you could do stuff like, okay, we're going to, do some bake offs.
Oh, sure.
I don't know which one is going to win.
Do an AB test.
Some people don't actually like to be on new stuff.
People keep thinking, "Hey, every software engineer is like super innovative."
No, some software engineers look at some of the new stuff
and say this stuff is garbage.
Like there's no tooling.
There's no libraries.
This thing is super unreliable.
Every time I do something, it's not working yet.
Cause I haven't built it yet.
It's super buggy.
And they like the thing that's sort of fleshed out and they, they optimize it.
They're kind of in that mindset.
So.
it's not like the B team, A team.
You just go, Oh no, some people like to play with the new stuff.
Okay.
We'll do that.
And some people like to play with the solid, reliable stuff.
And they do that.
And we can kind of do a little bit of a bake off.
And you're going to have people who kind of cross the line a bit and they'll
have to help with that connection.
So you can do that more systemically.
I know some teams that do this where they say, Hey, we're gonna, we're
gonna allow for it's 10 percent magic.
Everything else solid, 10 percent magic.
That might not be enough with some more dramatic stuff.
Like,
I think, these days people, LLM, some of that is not a 10 percent problem.
No, no, no, no.
we've seen much more than that for sure.
It's like trying to get a 10 percent Ph d.
it doesn't work that way.
because it's not a straightforward answer.
You actually, this is what I was talking about before.
You have to actually reason about this.
Because there's no universal heuristic that just works.
No, that is a good segue.
So we've been talking a lot about the technical side and managing the people
actually doing the work and thinking about there's a set of problems and how do we
just scope those problems enough that they can run, but not so much that it's
micromanagement and love some of your tips for how to think that through a bit.
Now let's talk about the other half of what makes engineering management
so just impossibly, getting it from all sides is the business side.
You know, something comes along and says, oh my goodness, there's some customer
fire drill, or an incident, or, something happened and we need, some support outta
your team or some new features right away.
Or you have to pivot into this, but by the way, we're not giving up on the thing
we originally asked you to do as well.
How do you face that?
What are your tips for those out there listening to say, okay,
you know, it's barely enough to do to keep the team focused.
Now I'm also have to deal with these sort of external threats.
The ideal thing is, is there's no real separation.
Right.
So, and this is sort of what we're trying to do here, right?
Let's say we have like Grainger's branches, so like kind of retail stores,
and they have problems that are associated with just dealing with a retail store
and the software there, the point of sale system, inventory management within the
store, all this kind of stuff, right?
The ideal version is technology person,
I hang out with the branch people all the time.
They know me because I'm there all the time,
right,
right?
Then the conflict's not the same because it's not like they have
a problem, I don't know about it.
I know about the problem.
I already know they have an issue.
I know what the long term issues are.
We already know about it because we talk about it a lot.
Right.
That's the easiest one.
Then you don't really have the separations.
Like, Hey, how do we do this trade off?
We're already talking about short and long term goals together.
So I don't have this, like, it's not a separation.
Yeah, that's the dream,
The path there is you have to do certain things, but I feel like that's the idea
though, like, Grainger talks about this.
We win as a team kind of thing, which granted is sometimes the generic thing,
but you understand what it takes, right?
Because it's not just a software tech to stuff.
There's a lot of moving parts to make sure like, Hey, someone gets
a thing that shows up on time.
it's a lot of moving parts to say, Hey, this team's together.
We were kind of on the same page.
We all have our different roles, but we're scoring in the same game kind of thing.
Sometimes people on the software tech side, they're still in the, "Oh, there's
this kind of barrier" type thing.
And that's not one team.
You think you're playing a different game, but you're not.
right,
so let's say that's the easiest one is that you're already close.
Now, how do you get there?
Like again, one level back.
They're asking for stuff that I wasn't already aware of
because I wasn't keyed in.
One of the things that we're looking at right now is just at least saying,
hey, here's a regular sync with all the stakeholders, all the people, part
of that same kind of capability on all sides, not just the technology, all
of them, and we're together and we're just talking through all the stuff.
Like, what are you seeing out there?
Cause there's all these crazy stuff that happens at the field.
But I always talk to people like everything works in the lab, which
is like our desk and stuff, but we've got stuff when they're out there.
I can't even guarantee what temperature the thing is going to be at.
So, you know, you need to know that context.
So having more contact helps you do this.
At one point I was talking about like, Hey, what's a fundamental kind of agile
principle that people don't really get.
There was an old colleague of mine, he called it "closing the distance
between customers and developers," I called it closing the distance
between problems and problem solvers.
I don't care what you're doing.
It's like, there's a problem.
There's problem solvers.
You need to close that gap.
Let's just talk about that for a second because that is the fundamental thing
you're talking about is bringing a great team of people who are solving the problem
as close to the problem as you can.
So I'm not trying to optimize for this negotiation.
I'm trying to bring it together.
I don't want to spend a lot of time getting fancy with a negotiation.
I want to remove that.
In one of your posts, I saw you talk about a concept that I thought was really
interesting where you described leverage and I might be interpreting wrong.
So I'd like you to check me on this.
But I feel like the best leverage you can get for a team is to maybe instead of
thinking about the technology or the scope of problems, it's just to think about
how close you can get them to the problem
Yeah.
like maybe that's the better framing of the engineering leader's job:
get these folks with the right skill level, of course, as close
to the user challenge as I can.
Yeah.
there's a couple of things there.
Like one, if I get them close enough to the problem space they will be able
to see collectively with their partners there, "oh, this is what we need to do."
It becomes, almost super obvious that you go, "Oh no, we got to do
this thing to contain this thing," but almost all our collective
intelligence will point at something.
It's still technically possible that we're wrong, but we have the
least likelihood that we're wrong.
Cause we're collectively think that's the way to go.
There's a certain skill set here, right?
If we talk about engineering, not a technician, like engineering, it's
like even old school engineering, like you're in the field, you're not in a
lab, you're a tech, you're a scientist, you're not an engineer, engineer,
you make contact with the problem.
like, especially old school engineers, you barely had any math.
Yes, right.
Like, it looks super fancy now because you learn a lot of stuff, but back
in the day, it's like, you just out there, you just deal with it.
Right.
But like that kind of mentality.
So you're, you're there, which means there's a certain skill set of being
able to deal with, the ambiguity of a real problem, as opposed to a
like a lab control problem that there's a skill set expected there.
So.
I love this point, which is get the depth of folks as close
as you can to the problem.
That's where you get the leverage.
And then it kind of solves these underlying, you know, should we use
that tech or this tech or rearchitect?
Because again, you're just close to the problem on that.
Give me your top three tactics for how you feel like you've seen that go well, and
how you've seen that go horribly wrong.
" They can't talk to customers", right?
Like Office Space.
There's all these middle layers that tend to exist in an organization
explicitly that you'd have to sort of bust through to get to those problems.
Right?
And it's not by any fault, but the engineer's job is to build, not--"
I've met managers before, who would say it's not like, they're
not trying to be ineffective.
They truly believe that, "Oh, this person's good at this and I
want to make sure they dedicate all their time on that skill.
Right.
they're thinking of,
"our game is to coordinate specialized technicians and then
we'll have coordination roles who will direct them correctly."
It's funny because this is like old school 19th century manufacturing.
Right, but they won't know that because they probably
don't read or study management.
I go, Hey, you're, you're reproducing this weird 19th century management
approach, which you wouldn't have done if you read about it.
Right.
I have people who are specialized.
They're good at the thing.
I'm going to direct people to only do the things that they're really good at.
and if I do that, therefore I need some kind of management person to
coordinate it because obviously you're going to need that now because they
don't have the exposure to the context.
Now here, our approach, my approach, or the better thing is I'm actually saying,
I want to be able to point you randomly in a general direction and you can handle it.
That's my ideal.
And then you say, hey, how do you build up to that?
That's what I want to know.
It's staging up, right?
Because you're saying, maybe they're not ready for direct exposure.
But I could still say, Hey, what's your next thing?
Like, even just talking more with your intermediaries first.
Right.
Oh, now you're going to be with the intermediary when they're
having that conversation.
And then, Hey, maybe you're running that.
And they're just watching and helping facilitate that,
right.
When you do that, do you feel like there's a language or a data set or a
goal or something you have to communicate?
I've just gone, like the job is to solve the problem.
This is not a university lab.
Right.
It's not, we're not, we're not here to have fun in grad school.
That's not what this is.
We're here to solve a problem.
Like this is like a mission of our organization.
Grainger's like, we're, we're here to keep the world working.
That's the problem.
Right.
So, which means you need to understand what's stopping
people from able to do their job.
And then we help them, we do that.
But how the heck are you supposed to understand that if you're going
through multiple layers of translation?
Right.
Like, and I go, you got a technical background.
You can get this right.
You're going through multiple layers of translation.
Do you trust that signal?
You want to get direct, like there's a little bit of kind of
getting people's heads there.
cause sometimes people don't do it, not because they don't want to do it.
It's just like, they don't know how to do it.
Right.
Most people I would say who are in engineering, they do it because
they want to solve a real problem.
They don't want to waste their time.
Doing stuff that effectively was pointless.
Like I built a thing, no one's ever going to use it.
You might as well have tossed it.
Your life has no meaning.
Like it's no, most people that's not appealing at all.
So here we're kind of saying, Hey, we're going to give you an opportunity and
even the trust too, because there's this kind of buildup of trust, to say, no,
I'm going to say, here's this thing.
I'm not going to even tell you how to solve it because you have the capability.
Just take a look there and tell me how we deal with this.
I feel like one of your posts, there was kind of a controversial McKinsey
article on developer productivity.
And you had a really good analysis.
It was one of your most popular posts again, I encourage people to go find
it, and I think a conclusion I took away from it was you really try to
help the team focus on outcomes.
Which I feel like is really the spirit of what you're just saying, there
tends to be, and maybe I'm trying to bring this full circle here, it's very
tempting to say, how much, you know, things did this person produce, not
say, what was the problem they solved.
That's a shift in thinking that doesn't, it's quite hard practically,
because we're so tempted to measure everything in a way that's that.
So let's say you do everything you do with the great team you have, and they're close
to the problems and all those pieces.
It's sometimes a little hard to say we solved the problem
or we have this great outcome.
How do you try to set up measurements of an outcome?
There's the two things that pop in my head.
Like one, I think people in the, at least the extreme program
background, like we have like test first tester and development.
And like, this is just feels very similar to that.
I still get people who go, how can I write the test?
I haven't written any code yet.
I'm going.
What are you talking about?
but some of that, like, I realize that's because I've been kind of trained
that habit for like 20 plus years.
I always start with, Hey, here, what am I trying to do?
And then I work out how to do it.
Imagine we magically completed this feature and it produced the
outcome that we're looking for.
How could we tell?
That's all I'm saying.
Yeah.
Are you sure you know what you're doing?
That means you don't know, you don't really understand the problem.
This is a great thing about Grainger, because I get this coming from other
people too, which I go, Oh, excellent.
Because they'll say, Hey, what problem are you trying to solve?
And I'll say, Yeah, that's a good question.
I should have thought about that.
So you go, Yeah, so what problem are you trying to solve?
But like, to understand a problem, it's not just, Hey, I
have an answer to that question.
It's that I know very clearly what it looks like when the problem is solved.
Right.
Yeah.
You could say, I'm going to introduce something that I'm going to see
an observable behavior change in a user or customer or in a process
or something, I can see that.
Right.
Now there's a logic, like the broader logic is if I get people
to engage that behavior, it'll produce this impact financially.
Yes.
That we check.
I'll get some analysts to monitor that over a few months, which means I can't
use that as a product development thing, or at least not a day to day thing.
Yeah.
There's some time, like at small scale, you can see it immediately.
At large scale, if you have enough people, you can see it.
I think the really great sound bite there as the conclusion is setting
the team up to measure outcomes.
Know what problem you're solving, right?
Like, you can't say I understand this problem if you don't know what
it looks like when it's solved.
That means you're not clear about what the problem is yet.
It's an interesting conclusion to think about here of really shifting
the thinking of engineering leadership as hard as we can into outcomes.
I think that's a great takeaway.
I love the sort of laddering up to that method of thinking about that, like have
a team today of those are listening here who, maybe you're trying to get
there and it's not like you can do that overnight, but you know, just slowly
kind of move in that direction to think about the distance from the problem and
the distance from the customer and try to put that over time in a smaller way.
Those all feel like really solid ways to bring focus back and to kind of have
that leverage you were talking about.
So, Jason, great.
Love the conversation.
Again, thanks for your time.
Thank you.
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
