Subscribe
Share
Share
Embed
The Product Engineering Podcast explores how software teams can move beyond shipping features and start delivering measurable outcomes. Hosted by engineering leader James Charlesworth, each episode covers practical ideas for product engineering, engineering leadership, team operating models and building products that create real impact.
It's definitely down to relationship
between EM and product because sometimes
you do have EMs that try to circumvent
what product managers want because that's
their way of doing it and they know best
and vice versa with product.
Welcome back to the
Product Engineering Podcast.
This week we are talking about
engineering management and what
engineering managers need to know about
product engineering and this week I'm
joined by Ryan Murphy.
Ryan Murphy is a
seasoned engineering manager.
He's the founder of EMaccelerator.com and
recently the founder
of Crying on the Sofa.
Tell us more about that.
So Crying on the Sofa is something that
was born out of just passion.
So I'm a big believer in mental health
and that everyone is fighting their own
demons whether you like it or not.
Everyone is.
Whether you know about
it or not, everyone is.
And it's just my way of creating events
with the goal of having one million
conversations about mental health.
I wanted to just write one conversation
at first but I upped my goal a bit.
I've always got one million conversations
and we're starting in Sheffield, our
first event and the
reception has been amazing.
We've been in the press about it,
Reddit has blown up a couple of viral
posts on Reddit about it and
yeah it's gone really well.
That's really good to hear.
I mean it's difficult one of these things
because people don't talk about it enough
and I'll be perfectly honest one of the
reasons why I started this podcast is
because I noticed a lot of insecurity
amongst software engineers when AI came
about and people who not just saw their
job as writing code but they saw their
whole identity as writing code.
I've known a lot of people outside of
work that are really facing a crisis of
identity now that AI is
writing all their code.
One of the things that we try and do on
this podcast is show people another way
that they can grow in their careers which
is moving towards product and product
management and product-led engineering.
It's not an exact crossover but it's
definitely one of the things I think
about quite a lot from the reaction
they've had to the whole AI revolution.
Yeah and one of the same, a similar
crossover I saw about people's identities
is when everyone was loving it when we
got to do remote work but then it started
to shift and it started to go back into
office again and I then saw the same, not
as bad but a similar shift with people.
So let's talk about
product engineering then.
What's your experience in general with
product managers over the years?
As a seasoned engineering manager you
must have had to work with a lot of
product managers over time.
So how is your relationship been?
What product managers have
worked well with engineers?
Which ones have struggled?
See I have, I generally put it into two
camps, big tech and not big tech and for
me that is a really interesting divide
because my experience is that when I
first became an engineering manager I was
at a company which had maybe like a 20
strong tech team and that was a mixture
of QAs, engineers, manager, CTO and maybe
25 at a push and at the time that's the
biggest company I'd worked at and I
thought, no it wasn't but the biggest
tech company I'd worked at because I
worked with finance before and I thought
well this is massive team, that's
amazing. 20 engineers
with me, like that's amazing.
So for us, product managers were very
ingrained into teams, they saw our
decisions on things, they bought outcomes
to teams and like that was, I guess I was
lucky to have that experience early so
that was my experience generally but as I
moved like for example in finance, it was
very different, it was more business
analysts, there wasn't any product
managers, I was told okay build this
feature for this, I was told build this
feature for this finance team and I'd go
and have to do it or
build it on SharePoint.
I didn't really have a choice, I had to
build it on SharePoint and like I left
that job, you can imagine and yeah then I
moved into Yelp and product managers were
still within us but the product function
sat separately to engineering and it was
like one product manager might sit over
like a whole space and like they might
not necessarily be as ingrained into the
team but they were ingrained into the
space and that was a little bit of a
shift for me whereas before it was like
we were just one huge team of 20 I guess
and that everyone was
ingrained into that.
Yeah that's an interesting kind of side
note about how product managers are
structured because I've seen both things
work and fail in both environments so
teams will typically take on more than
one work stream that's generally like if
you have a five or six person engineering
team you might have several epics that
are largely unrelated and I've worked at
companies where they have a product
manager for one or two teams and whatever
that team's doing that's your product
manager and I've worked for other
companies where a product manager is
assigned to an area or work stream or
something like that and so a team might
interact with two product managers and I
think as I first went into engineering
management that was the model I was
working in so one of my first jobs as an
engineering manager was to build up a
relationship with more than one product
manager and try and act as that bridge
between engineers and
their product manager.
Yeah.
Is that something you've seen?
Yes I have however like I don't like this
this middleman approach like I have
definitely seen that where the
engineering manager is like like these
are my engineers and we're responsible
for the how and come to me with the why
and we'll talk to the team and it's very
that's very like agile of a capital A for
me and it's a super interesting way to do
it but for me I would much rather like be
more ingrained in the team and then
presenting their problems and outcomes
directly to the team
rather than through me.
I agree why do you think organizations
fall into that model though of having a
barrier between the engineers because
some might say it was to protect the
engineer's time that's a common thing you
hear like they need heads down time let's
not distract them with
all that kind of stuff.
I might get trouble for but I think a lot
of it is ego and like people become
managers and they're like well I'm the
manager now like surely I should have a
say before the team sees it and I should
vet it before the team sees it and I'm
protecting the team by doing this.
Let the team just fire shots let them
just fire their shots because I guarantee
half of them are smarter
than you were doing it.
So yeah that's what I felt when I was
engineering it was just like just let me
out the product manager just let me out
of them and I used to love it.
Have you had many conflicts with product
managers and what kinds of things do you
think causes conflict?
Yeah definitely conflicts when I've had
product managers in the past say things
like well it's just a button and it's
like well it's not just a button it's a
button which adds a new payment processor
which we've got to add all the security
for all the socks checks around that
security and finance we've got to make
sure it's compliant and that button was
adding a whole new payment process but
it's not just a button it's actually a
year's worth of work.
So things like where there's a
misunderstanding but that's also on me
because when I had those conflicts I was
nowhere near mature enough as an
engineering leader or an engineer to be
able to talk properly during those
conflicts and help them see my viewpoint
it was just well they don't understand me
it wasn't I never thought well they don't
understand me how can I help them
understand me it was they don't
understand me they're the problem and
yeah for me it's maturity point yeah.
Yeah now absolutely so one of the things
that one of the ways that I've seen this
conflict come out is when product
managers don't know where their remit is
in terms of the task flow of their
engineers so you might sometimes see
product managers assigning individual
tasks to engineers and that creates a lot
of conflict with engineer managers
because they sort of see that as their
own thing and in a product engineering
world engineers see that that is their
job right like I should be picking up my
own tasks so is that something that
you've seen Yes yeah 100% and it's
definitely down to relationship between
EM and product because sometimes you do
have EMs that try to circumvent what
product managers want because that's
their way of doing it and they know best
and vice versa with product so I think a
lot of it is like a symbiotic
relationship with the EM and products but
yeah I've definitely seen it and it's not
great because people are just confused
that EM might label it to kit in another
way whereas the product wants it labeled
in another way they might want they might
want free in-flight tickets at one time
on the Kanban board where as the EM might
say four and it's little things like that
which slow you down they're a problem and
you need to address it.
Yeah so one thing I've seen being really
successful on combined products and
engineering teams is when every single
person on that team is given as much
autonomy as possible so engineers are
literally said this is the outcome we're
trying to get this customer you go and
speak to that customer yourself you read
their feedback and that only works if you
can pass context between people that know
about it and people that don't so in the
example you gave earlier on of a product
manager asking you to put a button on the
page and they didn't have the full
context of how much so you could say
that's a breakdown in how context was
transferred from some engineers to a
product manager but the same happens the
other way around I've noticed as well so
a lot of the time an engineer will say
for example the classic would be I've
done this it's shipped it's merged and
the product manager would say I mean okay
you did exactly what's said on the ticket
but it's not actually what we needed in
the end and so then the product then the
engineers will get really you know
they'll get their back up about that
because well they would say well you're
just scope creeping now you're adding
more to the scope and the product manager
will say well my job is to get the
feature to actually change the user
behavior the way it's supposed to so how
do you manage context flowing between
product managers and engineers explaining
the technical context to product people
yeah so I think a lot of it is I think
people dislike these meetings but a lot
of it is during like grooming and
planning and stuff like that which which
does help that's like the obvious answer
the less obvious answer for me is is
cultural things so for example onboarding
something I've done in the past very
successfully as an EM is every engineer
that's onboard I don't care how even if
you're coming in as a distinguished
engineer I don't care you're doing this
the first three weeks of your job you're
not touching code I don't care who you
are you're not doing that you're going to
spend one week in sales two days in
marketing three days in CS on the things
and for me the least important part of
domain knowledge is code and I've always
said that and look at AI now I've been
proven right 10 times out of 10 and I
chuckled to myself a little bit about
that because the engineers are going to
excel now and the people are doing
exactly what I said to do go and spend
time with them make you the person that
they think of when they've got a problem
and come to the outcome they need and
yeah so for me it's part of onboarding as
well which can help that but also the
psyche of things like what do you
celebrate do you do you celebrate high
technical talk and high technical
excellence in engineers or do you
celebrate engineers achieving outcomes
and stuff like that and if you achieve if
you celebrate engineers achieving
outcomes rather than technical excellence
and okay they've designed this awesome
factory pattern right okay cool but did
you reduce CS calls by five percent or
reduce CS wait time by 32 seconds which
made them impact on bottom line if you
say that's what matters then behavior
changes and the way people talk between
engineers and product changes as a result
of what you're celebrating that's a
really really important point I think
celebrating not just celebrating delivery
but celebrating hitting something because
I've you know teams will often celebrate
when an epic gets to the end or something
like that but ultimately if that epic
wasn't the right thing to be building you
know you very rarely celebrate creating a
spike that didn't work I think you should
I think I think if you spend three or
four days building a proof of concept and
then it turns out that wasn't the right
thing that should be celebrated
especially if you're a product
engineering thing yeah absolutely because
you've learned something you've learned
that that wasn't the right thing to build
right and you can spend the next three or
four days doing the next thing so I do
think we need to talk about AI how do you
think AI and particularly like coding
tools so I mean you talk about engineer
management you might think of oh I use
Claude to organize my thoughts but how do
you think coding tools have changed the
discipline of engineering management yeah
so it's definitely highlighting to people
the importance of that product focused
engineer because now even though I've
been off the tools for like I haven't
I've coded but not professionally for
years if I'm going to be honest with you
like if you're my old team ignore that
statement but I haven't coded in years
and I miss it because that was my craft I
found a love of it and I get these coding
tools and I feel my passion brewing all
over again and if I start working again
as an engineering manager let's say touch
with my my businesses don't work or
something like that and I've signed a
drink I'm gonna be a super freak I'm
gonna be it's gonna be an absolute
superpower of mine because I was always
that way as an and now I've got these
tools so what I think it's doing is it's
highlighting to people that actually this
soft stuff we've been talking about all
the time about communication and
stakeholder management and written
updates all this stuff stuff we've been
talking about while you've been hiding in
the corner doing your code it's actually
true it's actually more important than
ever and as an engineering manager where
it's so important is like how do you
coach people on that do you do by example
or do you actually take the approach of
not leading by example and letting people
fail at it and then coaching them
afterwards and so there's so many
different approaches how to do as an
engineering manager but yeah it's
definitely highlighting that we need to
coach our engineers in a certain way not
just push technical excellence what do
you say to engineers that just say I'm
just not very good at talking to people
I'm not good at communication yeah I get
that and I'm half introvert I'm half
extrovert so I definitely get that and
it's a problem but there are ways you can
do it for example you as an engineering
manager you can help these people by
saying okay right in meetings we'll have
a pre-read up front and you can add notes
and add action items that you wanted to
schedule a meeting before so you don't
have to necessarily raise your hand and
say let me interrupt the meeting let me
draw attention to myself and let me make
this point the points on paper and as an
engineering manager I can say actually I
know that you're an introvert and you
don't want to talk about this sort of
stuff necessarily and I can say hey
Ryan's made a point here subconsciously
let me bring that into the conversation
and maybe ask people that like Ryan might
be close to about in the chat and see if
that bubbles Ryan interest a bit so there
are ways of doing it um so yeah but I
would definitely encourage you to talk to
your about this and say like I just I if
I was a manager and I had someone come to
me and say to me look I'm not that good
at this or I don't feel comfortable doing
this but I understand that the way the
world's going it's probably an important
skill um can you help me and you'll know
the caliber of your manager but depending
on how they react if they're sympathetic
if they engage with that if they find
ways to try and help you then that's
great but if they just say well that's an
important skill you better learn it bucko
it's going to be a problem for your
career yeah no that's a really good point
so that's AI coding tools and how that's
changed people's identity from they have
to develop their soft skills how about
other uses of AI particularly in engineer
management like how can engineers and
engineer managers use AI to kind of
create that personal operating system
that we can do these days yeah so this is
something I've got coming to EM
accelerator soon is we've got a course in
this from Owen Lewis who's a who's a an
AI expert director at Oracle um and the
thesis that I go with the way that I
understand whether I used it and I've
seen people that I coach successfully use
it is to take the stuff that they don't
necessarily like away so I actually see
it making management easier because to be
a good manager whether you like it or not
whether you want to accept it or not you
have to be organized you have to be on
top of your tasks your outcomes your
metrics um your inputs your outputs you
have to be on top of it because it all
bubbles up and it all gets on top of you
all come crashing down and you look at
absolutely like snowfall so you have to
be organized so I think it definitely
helps you stay organized so it can
automate morning routines it can automate
creation of docs it can really help you
with not do it for you but going to help
you with understanding how you want to
approach performance conversations and
metrics around those performance
conversations and things like that so it
definitely helps there but it can also be
a partner to bounce back on to judge your
opinion on how you're viewing something
so okay is is my like I don't recommend
like just relaying what chat gpt says for
example but it can definitely act as like
a partner to say okay am I being am I
being a bit much here and stuff like that
so there's two ways there's the there's
the the coaching partner but there's also
the the superpower which I think in
people's operating systems it's going to
help you be a more effective manager
easier because there's two parts there's
management and there's leadership not
every manager is a leader and it's going
to help you be it's going to help you do
management better definitely I would also
say that not every leader is a manager as
well because a lot of like leadership is
involved in like staff software
engineering as a leader so I like you can
be a technical leader in certain area but
yeah no it's really interesting I do
exactly the same I don't use AI to write
slack messages but I will often run a
slack message through AI and just say is
this going to get me into trouble is this
the right level of politeness directness
is this going to be misconstrued no no I
completely agree with that but yeah I
think writing is an interesting one
because you know people do tire of AI
written documents and I'm sure you've
seen this as well I like you get the meme
is that somebody writes an entire
document of Claude and then the person
reading it just pumps into Claude and
says give me the tldr right so like where
do you think it isn't isn't acceptable to
use AI in writing I mean would you write
a product requirements document with AI
this is something I've got fairly strong
opinion on if you know me because at the
top of some of my blog articles which
people read I write I give a very big
warning this was not written with AI and
I do post on it and stuff like that and
I'm a big believer that if you don't have
the time to write it I'm not going to
take the time to read it and it takes for
me it takes personality out of it but for
me also like I've got a brother that's
dyslexic for example so it massively
helps him hugely in that so I don't think
we should ever take it away from people
either for that but what I do think is
for example the way I use it when I'm
writing maybe I can write on a blog post
is I'll say okay okay create a template
for me to write on okay have like
have like the headlines and I can like I
can like expand on the headlines and you
can do that with specification documents
you that have one pages for new features
at work for say you've got new features
like a one-pager proposal you can okay
outline bullet points for me that we've
discussed and then I can manually expand
on them so I think it depends on team
ethos a little bit in your personal ethos
because there is a bit of a should you
shouldn't you in the tech world at the
moment about about AI written writing
because you're right people do tire of it
and yeah you do need to be very careful
of it but also you need to be aware that
some people genuinely find it useful
because they've got things like dyslexia
which which genuinely helps them that's
fair one of my favorite chrome extensions
is the pangram chrome extension yes and
uh ryan's do always show up as human
written and that will stand out on
linkedin these days because it's very
rare to see somebody just posting human
written stuff yeah that's really
interesting what do you think um the
future is for engineer management do you
think now that it's so easy to use clodco
to build stuff the expectation is going
to be that engineer managers are also
going to be building things with clodco
and stuff see the truth is I can now the
type of software engineer I was and the
type of manager I was I believe that for
example if I walked into pendo tomorrow I
could do the output of a whole team
myself I firmly believe that like but
that is maybe why like I was like a bit
egotistical and maybe that led to like a
creator career and stuff like that
because of that because of that like
maybe like like unearned ego or something
like that right but yeah if I'm being
real for a second it's it's gonna be the
opposite of what a lot of people are
spouting right now so a lot of people are
spouting you see these blogs and
something from like james stania and
stuff that say okay people are going to
be much more hands-on and they're
insinuating that the people leadership
part of it is going to fade away and it's
going to be like huge teams and you're
going to be like almost like part of the
team but you're going to people are
insinuating that you're going to be like
that's that management person but a
normal engineering your team almost
that's why the huge team and facebook are
trying it and look how that's turning out
right but I firmly believe that the human
part of engineering management the people
leadership part of it is going to be more
important than ever and in a few years
you'll see people really really indexing
on that whether it's called engineering
manager anymore I don't know but the role
of being responsible for that for team
health and people will still be there and
I firmly believe it being more important
than ever because as we spend more and
more time talking to bots and less time
talking to each other it's going to be a
problem and people are going to burn out
much quicker I mean look at me like I
remember now spending 13 14 hours working
a day easily and I look up and I haven't
realized they've even done it and half
the time for a few hours of hours just
pressing enter on a keyboard and that's
just the honest truth whereas I think if
you have a team of people doing that it's
just going to all end up like drones
doing it and you need someone there to
help that human element part of it and
deal with that burnout and deal with the
team relationships and stuff which are
going to go missing I think that rounds
out this episode really nicely to go back
to talking about mental health because
I've had several points in my career
where I've found myself being an
unqualified counselor for people that
report to me and I kind of ended up in
this situation thinking I have to help
this person with something that I'm not
qualified to help them with because I
genuinely feel like I'm one of the few
people that have spoken to this about so
like what advice do you have for engineer
managers that will eventually find
themselves in that situation where you
are somebody's ear and you are you know
having to talk to them about things that
are really beyond the limit of engineer
management but you you feel like if they
don't talk to you no yeah there's there's
like the there's the process part I want
to get out of the way because people do
forget that you're a manager as well as
like a hopefully like a people leader and
the people leader is the part that we'll
talk about in a minute but for the
manager part of you you have to
understand what resources your company
has available for them what resources you
can do for them from a management
perspective in terms of is there like an
unpaid time off policy is there mental
health leave policy you need to
understand that that is crucial if you
don't and you come to this conversation
I'm prepared for that it's going to be a
bad look for you and you'll always regret
that that mistake so my first my first
advice is be aware of what you can give
them from a management side of it now the
leadership side is just try to shut up
just just honestly just just try to
listen just try to sit there and and ask
the old question but just be that ear
because a lot of my problems for example
creating crying on the sofa where I was
sitting on the sofa cry my eyes out deep
in depression and I didn't know where to
turn if I managed I started trying to
give me advice on that about like one up
it almost seems like one upmanship then
that'd well me up a little bit but
luckily I had a great manager at the time
and it was just listening it was saying
what I can do about leave and like having
an ear and saying okay is there anything
you need from a work perspective so it
was really good for me to have a person
just listen and just let me vent and I
really appreciated that yeah I've done a
lot of management courses and all sorts
of leadership courses over time the
greatest one I've ever been on was a
hostage negotiator that used to work for
Met Police and he did an active listening
course so we all went along and we just
learned how to listen yeah and we learned
the body language of listening and we
learned the questions to ask but like you
just said when to just shut up yeah so
yeah and it's it's when in your brain
when someone's talking to you are you
thinking is the first one in your head
but or when or however that's a problem
shut yourself down and just go back to
okay what they're actually talking about
yeah and that's my biggest advice about
active listening is it's your first word
is but yourself out of it yeah yes and
instead of yes but yeah cool well on the
theme of shutting up that's it for today
Ryan thank you so much for coming on stay
in touch and you'll find links to crime
the sofa and the e-me accelerator in the
show notes of this
episode thank you so much