Leadership is where you start to have not necessarily a large
organization, but I think it's to do with a very wide scope and
a very wide impact and bringing lots of people along with you.
Org charts have got a bit of a stigma attached that there's
some kind of bureaucratic thing, but actually the org chart is an
incredible tool where if you design your teams really well,
you've kind of done 50% of your job already.
But long termism is, is really just always having a very long
term view about what it is that you are doing.
And I think that it's very, very easy, the default mode to get
sucked into the urgent day-to-day things because quite
often the pressure for the short term always wins.
The word meetings comes up a lot, but I really think that you
can be an incredibly effective leader by having minimal
meetings. Like you can be a very written
leader. I've seen many tenured and
experienced leaders kind of fall down in terms of their impact
because their writing just isn't up to scratch.
Rd. maps and projects and plans, they're all necessary, 100%
necessary. But the strategy is one of those
things that sometimes is missing.
Sometimes people sort of present a road map and say that's the
strategy. So no, no, no, that's not the
strategy. That's the plan.
The important thing is that you don't just write it once then
forget about it. You have to talk about it again
and again and again. You have to sort of make
yourself irritated by how much you talk about it, but like,
that's usually the level you have to get to for it to be
enough communication that people actually pay attention.
Hello, guys, Welcome back to another new episode of the Tech
Regional Podcast. I'm very happy Today we have a
history moment. So I have James Stanier coming
back for the third time on the podcast.
So if you know James Stanier, he appeared in the first episode
here talking about becoming a effective engineering manager.
And then we talk about remote work during the pandemic.
And after two years, he's happy to be back here again talking
about his new book, Become a great engineering leader.
So James, welcome back to the show.
I'm really looking forward for this conversation.
Yeah, thank you for having me. And as we were saying before we
started recording, I thank you for reaching out when you saw
that the new book was almost done.
I really appreciate it and it's always good to chat to you.
Right. I feel that this book is kind of
like the next evolution of your previous work, right?
So I can see some reference to the previous books.
So tell me the story why you ended up writing this book?
Is this something that you learn along the way and you just want
to share with the audience? It's a good question because
after I write wrote the first book, I thought I'm never
writing a book again. That was too, too much stress.
And then I wrote a second one and then a third one.
I think it all comes from the same thing.
Like I really enjoy writing as a means to think and anything that
ended up in a book is an evolution of anything that I
wrote on my website, my newsletter.
So everything is kind of like an iterative improvement all the
time. And it's kind of like batch
processing. It's like every couple of years,
like I've done enough writing that kind of can be batched
together in into a book. And I think a lot of people that
I'd sort of met over the years who'd read the first book always
sort of said, oh, hey, like, when's there going to be
something about what it means to be a director or AVP or like a,
you know, a leader in quotes? Like when's that one coming?
And at the time that I always didn't know the answer to that
question. But as the months and the years
went on, like enough material built up, I thought, hang on,
there is actually something here.
That is I think what I wish I had when I first started leading
more than one team. And that's where it came from.
And it's just a chance to really focus my brain, get it all down,
talk to people about it, get lots of people reviewing it.
And yeah, I think it's the book I wish I had in the past, which
is usually the the check box I try to tick when I write
something. Yeah, I think a few years back
your engineering manager book is kind of like one of the rarest
resource about engineering manager.
I guess over the time many people wrote about engineering
manager and engineering leadership, you know, like VPF,
engineering CTO. Those kind of roles are probably
not well covered and I'm really glad to see these resources
coming up as well. I think there are several other
books that are also covering this kind of leadership, you
know, engineering leadership topic.
So I think what makes your book unique is like you consistently
follow the same kind of style that you took when you wrote the
first two books, right? So it's really enjoyable, so to
speak, seeing the same styles. So I think in the 1st place,
maybe let's level set what is engineering leader in your point
of view, right? What is this role all about?
That's a good question. And I think it's changed a lot
over time. I mean, I think leadership now
can mean individual contributor as well as manager.
Obviously, the book does have a primary lens on management, but
really you could have ICS performing a lot of these same
functions as well. And I think what we've seen is
leadership is where you start to have not necessarily a large
organization, but I think it's to do with like increasing scope
and increasing impact to the most important things.
So lots of previous business books like, ah, you know, you're
1000 person org or 5000 person org, the companies are all
different sizes. So really the modern leader is
somebody with a very wide scope and a very wide impact.
And like if we end up touching on career progression, I think
that's the model you use over your career to to see if you're
still growing. And I think that's the narrative
that lets you go from a big company to a small company to a
medium company, but always keep growing.
It's to do with scope and impact being large and bringing lots of
people along with you. Yeah, sometimes talking about
size, right? So I can see from like big
corporate, big enterprise, this kind of title means like you're
at the top heading like, I don't know, hundreds or even thousands
of engineers, right. But I guess these days there are
also so many different start-ups, right?
Sometimes a small start up could also have VP of engineering or
even CTO, right? I think the the way that you
mentioned the scope and impact, I think it's really interesting
so that it can be applied not just on the traditional
enterprises, but also on the start-ups as well.
And I think you mentioned about few different skills for
engineering leader. What are the some of the stark
differences, if you can tell, between engineering leader and
engineering manager? Because you also covered
engineering manager in your past book, right?
Yeah. And just to to sort of finish
your previous thoughts. It was really, really valuable
actually, which is when I put this book together, I was really
careful to make sure that everything that's in it works if
you are AVP of a start up or AVP of an extremely large company.
And I've tried as much as possible to decouple amount of
people as the important thing because it the role is the same
in the different places, but you have to ignore the amount of
people. And to follow on to your
question really getting it right.
A few years ago now, I remember somebody sent me APDF, which was
from the US Air Force. And this was written a very long
time ago. And it had this really great
pyramid diagram of like strategy, operations and
tactics. And that's something that I
feature in one of the first chapters, which is the
orientation of like what, what even does any of this stuff
mean? And I think that one thing that
struck me when somebody sent me that US Air Force PDF was like,
OK, here's an organization that has been doing distributed teams
for, you know, thousands of years, so that they know what
they're doing in terms of organization of people and, and
chain of command and so on. And that sort of strategy
operational tactical pyramid is, is super useful.
So in terms of mapping types of leader, if you think of the
tactical layer, that is very much your frontline engineers
and your engineering managers, you know, who are executing
units of work projects, getting them done shipping.
And then you sort of step up a layer to operational.
And that's where traditionally you're sort of directors of
engineering lie, depending on the size of the company.
And that is groups of sort of interrelated projects.
So ownership of a large application and then you've got
all the teams underneath who are building all the features and
then going up another layer to sort of the CTOVP land.
You know, that's really the long term strategy view.
That's the kind of how much should we be getting into AI?
You know, how much should we be going in this particular
technical direction? Should we be taking the product
in this direction? That's sort of where those roles
should be living. And I think that when somebody
sent me that US Air Force thing, I was like, finally it makes
sense. Not the place I expected to
really see it written down. But I think just to finish my
long winded point, when I wrote the first book, the reason I
wrote it for engineering managers is because often people
got into that role and there was a severe lack of good training
material. And I think coming back to this
book, it's the same thing. So it really showed that even me
you'd been doing this for quite a long time.
We're still getting things that actually went oh, and now I
understand my role is so much better.
So this is me trying to gather with a luck into one place and
and and get it out there. Yeah, I think you in your book
you mentioned about this, right. So the biggest gaps in
engineering career, right is the first gap is like going into
management, which is like kind of like engineering manager.
And the second gap is like managing multiple teams, right
or managing managers. So I think engineering leader is
kind of like the second gap for everyone's career in the
engineering simply because there are not many resources available
and probably you have one or two good mentors, but I think that's
about it. Sometimes you're unlucky, you
don't have mentor and you kind of like have to improvise along
the way. And I think you mentioned about
this tactical, operational and strategic.
I think you refer to this as the three levels of warfare.
I think that's kind of like pretty, I would say appropriate,
right? So looking at the where should
the particular person or particular role focuses on?
So I think it's really good perspective to kind of like
explain each of the different roles and responsibilities.
You mentioned about size and you mentioned about scope impact.
How about tenure, right? Do you think somebody needs to
earn, you know, a number of years before they can become a
good engineering leader? That's a very, very good
question. Obviously at the extremes, it's
obvious you'd hopefully want someone leading A-Team or
leading multiple teams who has some experience.
But I think that tenure is something that can be
overemphasized as important because I can't remember who
originally wrote about this. But that thing about having ten
years of experience where you've just done the same thing for 10
years versus 10 years of experience where you've done
something completely new and challenging.
Every year, those two people end up on a very, very different
trajectory. So yes, I think if you plotted
it as an average, you would hope that the more senior people are
the most experienced, but the certainly there's nothing
stopping like incredibly talented, younger or less
experienced people taking on these roles if they are
naturally very, very good at them.
I mean, it's interesting in the Premier League football in the
UK, the new manager of Brighton, he's like younger than some of
the players on the team and it's just because he's an incredibly
talented manager and we should be looking for those people and
bringing them up through the ranks.
Sorry to mention football, it's a very stereotypical like
English. Things, yeah, that's OK.
I'm a football fan as well, very excited for the new season
anyway. So I think becoming an
engineering leader, let's just focus maybe more on the
operational and strategic view in your 3 levels of warfare,
right? So I've previously also
experienced this kind of a challenges becoming an
engineering leader, not much resources and have to learn on
the go, sometimes making mistakes obviously, and
sometimes also learn from other people that can give us good
guidance. So obviously there are many
things that I struggled back then, but obviously we can't
cover all of them. I'll just pick a few things that
I find interesting from your book, which I think could be a
good learning for listeners here as well.
So maybe let's start from the first one about tools,
techniques and, you know, managing the time, right?
So you actually started from one thing that is maybe not so
obvious for many people, but actually if you have experience
being an engineering manager or engineering leader, this is kind
of like an obvious thing as well.
So you cover about org chart. So maybe tell us the reason why
you cover org chart in the first place?
It's interesting, I find that org charts have got a bit of a
stigma attached that there's some kind of bureaucratic thing
or maybe just an unfortunate necessity that, you know, you
have to have a manager and they have to have a manager and so
on. But I think the one thing that I
learned, especially leading much, much larger teams in the
sort of the hundreds, is that actually the org chart is an
incredible tool where if you design your teams really well
and you give them really clear remits and clear goals and
metrics for success, you've kind of done 50% of your job already.
And likewise, if you design your org chart very badly, you can
actually cause many problems. You know, there's the whole
Conway's Law thing of shipping the org chart and all that kind
of thing. But actually org chart design is
something that is one really great and it should be thought
about carefully. We're not just talking about
like the number of direct reports and things, but like
clear areas that people belong to that fit your organization.
Because fundamentally the code that they produce will probably
look a little bit like the org chart.
So you can sort of get ahead of it by getting people in the
right place. And it's one of those things
where you can't change it every week.
So careful or chart design so that maybe when you do reorg
everybody maybe like once a year, maybe less, maybe more.
I don't know what your organization is like.
You can do it really well. And I've always found that even
though people think that reorgs are terrible, actually if
they're done really carefully, mindfully, they have a really
good reason. And you can really sell the
reason why this is happening in a way that empowers people to
say, hey, like the reason that you're being broken up in this
particular way is so that you can all get on with your work
autonomously with just the ability to be the masters of
your own domain. It's fantastic.
So it's not just the division of labour, it really is the sort of
the blueprint of the strategic aim of the organization.
Yeah. So I think definitely,
especially if you are working in a fast growing startup for
example, right, definitely you will have to design your org
chart simply because now that you have many people, right, you
can't just simply have a flat hierarchy because I don't think
it will be more chaotic by then. So I think designing an org
chart, you mentioned a few things like Conway's Law and
maybe you also cover about the team topologies and few other
best practices, right? You know, like that besides and
all that. So maybe specifically, can you
tell us the guidance, like maybe I don't know, it's a summary of
what are the best practices that engineering leaders should think
about when they design their org chart.
Yeah. So I think really being able to
design your org chart for autonomy is important.
So you really want every single team as much as they can to work
independently with as few outside dependencies as
possible. But also in a kind of dichotomy
way, you have to think that you don't want to silo people away
from others so that the wider view of either your architecture
or your organization or whatever it is that's your wider focus
doesn't break down. So it's, it's quite nuanced.
You know, you certainly need to think about skill sets and
seniorities. You know, what's the right kind
of ratio that you want of junior engineers to senior engineers so
that you can make sure that you've got mentorship in place
and that you haven't got sort of pockets of under experienced or
over experienced people. And then also, as you sort of go
up the org chart, you need to start thinking about, OK, for
your most senior individual contributors who are leaders in
their own right, because they will either lead a technical
area or lead the strategy of some particular piece of
architecture. How do you pair them with the
right managers so that they can almost become like Co processors
at different different levels of the org chart to really drive
the organization forward? So there's a lot to think about.
And I think one of the things that worked out better than I
thought it would in the book is you mentioned team Topologies,
which is fantastic. I tried to design A reorg using
team Topologies where you have a before state and then you have
like a team topologies definition and then you rework
it and do a reorg based off of that and it works out pretty
cleanly. So yeah, have a look at that in
the chapter. I think that's something I've
used as well in a reorg I did not too long ago as well.
It's incredibly useful tool. It's something that is always
mentioned about ORC chat as well.
This thing called Conway's Law, right?
Or the reverse, right, The reverse, Conway's law, Have you
had experience where you have to adopt to this?
Because sometimes you know, software architecture or
software result, right? Actually mimics the kind of like
organization hierarchy or communication pattern actually,
right? Maybe something to share here
about your experience with Conway's Law?
Yeah. I mean there's no hard or fast
answer for every org. But one where it comes up time
and time again is if you are working for a company that has
say a a desktop or a web-based application, but you also have a
mobile application. And then how do you design this?
Do you have like the mobile engineering org?
Is that like separate to the main applications org and then
somehow you have to kind of keep both of the feature sets In Sync
and then have like 2 Rd. maps or actually do you blend the two
together and you have the mobile engineers working in the feature
area teams with the people working on the main app so that
they can make the mobile version of whatever's in the main line.
There's no hard and fast answer here.
And the same is true for like, do you do QA as a separate orgs
or do you blend them within teams?
Do you do? You can go on and on here, but
certainly thinking about how you design your teams multi
functionally in a way that really helps the products and
you get to sort of exploit Conway's Law is something worth
thinking about. And yeah, mobile QA always comes
up again and again. Yeah.
So I think definitely it's kind of like no hard fast rule here,
right? Sometimes different organization
have different contexts, right? And especially depending on the
kind of leaders that exist in the organization as well, right?
So more teams also mean that you need to have kind of like
managers to run the teams, right?
Otherwise it can be also chaotic.
How about political right? Because sometimes in some
organization, no matter large or small, they are sometimes
politics. So is there any kind of orchard
design that you think would kind of like avoid politics much,
much effectively? It's tricky.
It depends what you mean by politics.
I mean, if you've got people who are naturally inclined to be
that way, it doesn't matter what role they're in, they're going
to be that way. I think what's important though,
is to think about your org design in such a way that
doesn't encourage people to, I've heard the, the term
sandbagging where you sort of like lay out the sandbags around
your team so that nobody can get in kind of thing.
And then you just become like a black hole, just needing more
and more people all the time. And I think that there is a
balance between, you know, do you design your teams based on
slices of your technology or do you design your teams based on
slices of your product strategy? Again, there's a hard and fast
rule. You obviously want for
particular specialist piece of infrastructure for them not to
be at the wing of a of a product road map type decision when it
needs to be a long term piece of work.
But at the same time you want teams that move fast when it's
it's product focused. But back to your point about
politics, I think that I don't have an answer to that question.
The reason I don't have an answer is that if people are
political and challenging, then they will always act in that
way. But I think what you have to do
as a leader is make sure that the people that you promote,
reward, give good performance ratings to are the ones who show
their kind of collaboration, their ability to do things for
the rest of the org chart. Classic example of something
very critical and urgent happens.
You have to de prioritize some things in your org in order to
get this particular thing done. This thing is not in the area of
any of the people in your org seeing which leaders, people are
the ones who say, hey, yeah, let's get this done, I'm going
to help. Those are the people that you
want to really hoist up over time because they're not
necessarily attached to what they are doing.
They're actually aligned with the the whole company
succeeding. The ones who will push back and
push back and say that's not my area, that's not my area, that's
not my area. Actually they are more inclined
to fight for their little Kingdom as opposed to being able
to really see that the longer term company direction is more
important and it's about with time.
Like rewarding the people that give that altruistic behaviour.
Yeah. So I think I can also relate to
that, right? So for me, the characters of the
people, the leaders and also probably the performance
management, right? So something that also you have
to think about, do you encourage political behaviour or do you
actually encourage collaboration and teamwork, right.
So I think definitely org chart is something that everyone as a
leader, right? You have to really think hard
about this, not just randomly move people from one team to
another, but actually there's some kind of a science behind
it. And don't forget some of the
best practice like Conway's law team topologies, you know, done
besides and all that two pizza team.
Those kind of things definitely are good references from the
other industries as well. So I think let's move on.
I've. Had just one more thought.
Yeah, just one tiny thought that came my mind as you were
speaking. There is just going back to
where we began talking where ensuring that your performance
system for leaders is not attached to size of their org.
If you really do reward your highest performers well,
regardless of the size of their team, but actually based on
their impacts, then the kind of behaviors that are political,
which are holding on to people trying to grow the immediate org
underneath them but not thinking about the rest of the org.
If you have the right framework in place to make sure that
regardless if you've got a small team or a big team, that the
person running the small team can either earn more or get more
senior than the person with the big team because of the
behaviour that they exhibit. Then I think that starts to
break that political behaviour down because it doesn't matter
if you've got a big org or a small org or medium org, like
it's about what you actually do and and how you help the
company. Sorry, that was just my
additional thought there. Yeah, Thanks for the addition.
So I think as engineering leaders who are at the highest,
maybe CT or VP, this is kind of like your responsibility, right?
To ensure that, you know, you manage the performance really
well and reward the behaviours that you want.
The other aspect of something that I'm sure like many
engineering leaders struggle are actually time management.
So I think 1, one good signal if you want to see an engineering
leader is someone who is always busy in their calendar.
So tell us a little bit more what kind of thing that they
should, I don't know, improve in terms of time management.
Because engineering leader, by definition, they have multiple
teams under them, multiple responsibilities, maybe multiple
big projects. How can they manage their time
better? Yeah, I think it starts with
really understanding. So sort of stepping back from
the whole thing in abstract and going, what is it on a
day-to-day week to week basis that I or you need as a leader
to really ensure that you are connected to all the teams that
you're steering things in the right way possible.
And this will completely depend on your organization as to what
the norms are here. Like there may be some
organizations where yes, you end up in meetings all day shop if I
where I work at the moment is very interesting.
I probably have the least meetings I've ever had in my
life as a director kind of role, which is interesting.
But that's kind of due to the company culture, which is very
much to do with only essential meetings.
We have a thing on our calendar invites that shows you the
dollar value of everyone who is participating in a meeting.
So if you call like a massive group meeting for an hour, it's
like you're costing the company a lot of money.
But this is a cultural thing. But I think it starts with like
really understanding, like what it is that you need to do your
job effectively every week, penciling in the critical
essential things like doing your one to ones with your direct
reports, any kind of skip levels or group meetings that are
essential. But I'm also going to sort of
stop myself and say that the word meetings comes up a lot.
But I really think that you can be an incredibly effective
leader by having minimal meetings.
Like you can be a very written leader that can work maybe even
better than someone who's in meetings all day.
And I think that at least personally, I know I'm biased
because I've written stuff and I'm, I can write quite fast and,
and, and that kind of thing. But I find that like my most
valuable time in terms of like actually things getting done and
decided comes through writing. And you certainly find that as
you work for bigger companies where maybe the leadership are
just completely unavailable to just hop on a call.
Most of the real action happens in the writing.
You know, it happens in Slack messages or emails.
And there is like a bit later on in the book talking about the
importance of writing. And actually, I've seen many
tenured, inexperienced leaders kind of fall down in terms of
their impact because their writing just isn't up to
scratch. Like being able to craft very
succinct, clear, unambiguous pieces of writing between the
people that matter, that make things happen and also have
clear actions and next steps is just so, so essential.
Interestingly, if sort of listeners and watchers look at
once a season of a little view into sort of some of the tech
companies at the top, there's AI.
Think internal tech emails sub stack where they sort of look
through various different emails that get put into the public
domain as a result of like antitrust lawsuits and things.
And they'll show like threads of emails between like Bill Gates
and Steve Jobs. And you get to see just how many
decisions are made via writing rather than meetings.
Anyway, I've digressed ever so slightly from what you should be
doing in your calendar, but personally get the critical
stuff in. We usually have 1:30 to 45
minute come to us with any problems per group.
So we have like five groups in my org and we have 45 minutes
for each where the leaders of each come to talk about whatever
they want. If they need help with things
being unblocked, if they want to tell us what they're doing, if
they want to demo something, the time is just theirs. 1 to one's
with my staff, skip levels go in there and then I very
proactively block out my calendar to have thinking time
as well. I'm quite lucky that on
Wednesdays at Shopify, it's always no meetings day.
So I by default I'm speaking to you on a Wednesday.
So as you, as you can probably tell now, but that's a day where
I do a lot of my deep work. For example, a few weeks ago I
was updating our engineering strategy and writing like a six
monthly update of everything that we'd shipped and things
that we'd done well and things that we hadn't done well at.
You know, those things generally happen on my Wednesdays and I
try and block out morning time as well, so I can always go
through my messages and my emails very slowly and make sure
I've got time to respond properly.
So always use your calendar to block out time for yourself as
well. Yeah, I think those are some
really great tips, right. And obviously depending on the
culture of the company, but actually sometimes the leader
needs to, you know, stand right, stand up and make the decision.
Do you want to be involved in all these meetings, you know,
get distracted, or do you want to become a writing leader,
those kind of things. Or do you want to be someone who
is thinking strategically, right?
Because I think the biggest gap, just like engineering manager
rights, when they started as an IC, suddenly they have to manage
people, right? For engineering leader,
sometimes it's not prescriptive, right?
The things that you have to take care about.
So yeah, here you go. You have a few teams, you have a
few projects, just run it. So sometimes there's no clear
direction from the top, accept probably some OK objectives from
the company, but largely kind of like the leaders have to, I
don't know, improvise or think about the strategy, the tactics
that they want people to follow on.
So maybe some tips here. How can the new engineering
leader bridge the gap? So before, like maybe they have
to take care of individual teams and projects and manage them
well, but now sitting at one layer above, they actually have
to start doing something different.
So maybe some tips for new engineering leader here.
Yeah. I mean, you obviously can't do
everything, but on the flip side, you don't want to be so
far removed from everything that you don't know what's going on.
I'd say like a pattern that tends to repeat itself in my
work life is sort of AT shape, which is the similar sort of T
shape engineer thing, but it's sort of T shape leadership,
which is where at any given time one of the many, many projects
going on will need a lot of attention.
And I'll find that I will be very, very close to that
particular project closes in, I'll opt into some of their
group meetings. I'll be in all of their Slack
channels, I'll be contributing to discussion, technical review,
and I'll have a very clear focus on that knowing that I'm
delegating the rest and what my sort of T shaped focus is from
month to month changes, there's usually always one thing that's
either a sort of a critical point or maybe a stressful point
or like a early stage designing point that's worth being close
to. So I'd say always be close to
one or two things at any given time and then delegate the rest
out and then decide how to delegate those other things and
then how you get informed about them.
Something that we do at Shopify is kind of a weekly written
update kind of culture, which works really well.
So all teams just do a long form update once a week of how their
projects are going. And it's very, very easy to just
read them so they come through your inbox.
But depending on how you do things in your organization, you
might need to implement something that helps you
understand what's going on. In your book, you also cover
this one thing called long termism, right?
So it's something that I think it's also good as kind of like a
reference for engineering leader who kind of like stuck or simply
like not knowing what to focus on.
So tell us a little bit more about this long termism.
How should people use it actually in terms of a
day-to-day? Yeah, long termism is is
interesting and I think it's sort of self descriptive.
It's really just always having a very long term view about what
it is that you are doing. And I think that it's very, very
easy, the default mode to get sucked into the urgent
day-to-day things. When you think about the whole
kind of Eisenhower quadrant thing, you're always in this
sort of burning Fire Zone. But it's really important and it
becomes ever more important the more senior you get to be able
to really have a compelling idea of what does the next year, five
years, or maybe even going as far as like, what would it mean
for the company to still be here in 20 years and being able to
spend time thinking about that. Because if you're able to very
clearly articulate what that means, then that can really help
you as a check when you're looking at the design of some
new infrastructure, you can think, OK, if the company is
going to be here in 20 years, how does this contribute?
Or is this really something where we're going down a route
where we're going to have to redo it again in another year?
And you find that certainly I find that the amount of leaders
who really are truly long term is quite few and far between in
my career because quite often the pressure of the short term
always wins. So having leadership that really
do fight for the long term, I think is really healthy and I
think can bring a lot of clarity to what you're doing.
So the classic thing is in engineering is like, you know,
deadlines estimation. If you have a very short term
focused company, then if your engineering team really haven't
finished something properly and they've built something that's
still not quite stable, they're worried about scaling, they're
worried about failover. But you've got a very short term
focus organization with maybe a lack of long term technical
leadership at the top. Then all the pressure will be to
ship it regardless and then potentially it will become a big
dumpster fire afterwards. But if you have a very long term
focus leadership, which is something that you know, you can
also be yourself, then you can be the sort of leadership that
go, well, you know what, let's make sure that we actually build
this properly. Let's move the deadline outlook.
Let's just delay it. You know, we'll eat the short
term pain of delaying it in order to make sure that
something lands properly when it goes out.
And I know that this is very easy to talk about and actually
doing it for real is a lot harder because it involves
dealing with other people. But I think really always having
your head in a place where you're thinking, where are we
going to be in five years? What decision are we making
today that's going to really cause problems.
And this can often be very small things, such As, for example, if
your company typically writes in two primary languages for like
back end and front end. And then a new project comes
along where someone says, OK, well, we're going to introduce a
new language here because this particular thing we think should
be built in this language. And in the short term, you think
that's great, It's cool. The engineers like, I get to
learn this thing. I don't know whether it's Rust
or Go or something new. And it's like, woof, everyone's
very, very involved. Who's doing that?
Thinking of like, OK, well, in five years when most of these
engineers maybe aren't here anymore, who is going to have
this like ability to train people in this new language so
that they can maintain it? And I think it's really healthy
to have that balance. Yeah.
So I think what you said, I can also relate, right?
There are not many leaders who have this kind of long term view
and sometimes it needs a lot of conviction, right, Because it's
kind of long term, right. So instead of doing long term,
sometimes people put more focus on the short term, maybe they
are burning fires all over the places or maybe projects
deadline to meet people issues as well.
But I think a great engineering leader is someone who always put
one eye on the future, right, on the long term view of the
company, the organization, the team, whatever that is, right?
And I think delegating well something that is definitely
very important because in order for you to spend time in the
long term view, you must have people who can run the
day-to-day operations really well.
And something that you cover a lot in your book as well about
delegation, which probably the leaders here can also look at
the book, right, in order to get the best tips.
So you mentioned a lot about writing.
I guess let's go to the next topic, which is about
communication, right? And I know that you like writing
and you have this strong point of view that a leadership is
writing. So tell us a bit more about why
your view that leaders need to write?
And what if the leaders doesn't like to write?
Yeah, it's, it's a good question.
It's something I covered in the remote workbook as well, because
obviously being remote you, you are writing a lot too.
But I think like doing very, very good leadership and
strategic work often requires doing a lot of work inside your
own head. Obviously you will talk to your
peers, you'll talk to your team, talk to your own manager or
whatever. But when it comes down to it,
like if you are needing to write an engineering strategy, if
you're needing to really think about the world, even if you're
just needing to retain information, and obviously the
more information you're exposed to at the higher levels of the
org chart, it can be very overwhelming.
You're getting into a habit where you are continually taking
notes, almost not necessarily journaling, but being able to
commit words to paper or digital paper every single day.
That builds up at sort of a knowledge database and audit
trail of everything that you've seen or thought really allows
you to sort of connect thoughts together in your head.
And also when it comes to producing pieces that require
you to think, you know, writing is the process where the
difficult ideas form. They don't necessarily always
form 1st and then you write them down.
It's while you're writing them that they actually form.
And the same is true for like if you're writing academic papers
or writing a book or a novel or something like you don't have it
all in your head and then you just put it down in the paper.
It's sort of like a back and forth like game of tennis with
the paper. So I think getting into a habit
of even if you're just writing to yourself is really important.
And similarly, more recently over the last couple of years,
those kind of second brain software like Log SEC or
Obsidian, and there's other kind of knowledge graph software out
there where you're encouraged to write notes and then link them
together based on keywords. They're one of those things
where you start using them and on day one you open it up and
just go, OK, there's nothing in here.
Like what's the point of this? And then you start writing some
notes. But then, you know, the months
go by and then maybe the years go by, and then you can look and
see that actually you've built up this entire knowledge base,
which goes all the way back through time that shows all the
things that you were thinking about, the projects that were
important back then, and you can capture particular learnings.
Then you won't repeat it again if you made a mistake.
So just writing all the time is incredibly important.
And I think that the times that I've felt my worst as a leader
is when I haven't had enough time in my week to really put my
thoughts to paper, even if they're to myself.
And going back to your point about meetings, when I was at an
organization that did seem like the purpose was just to be on
video calls all day, I honestly felt like I degraded in my
intelligence with time. Like having enough time in the
calendar to spend with myself in the quiet, Thinking, reflecting,
coming up with ideas is where I've become far, far better at
my job. Yeah, but I think some people, I
mean, who probably don't like writing, right?
Or some people or some organization which has bias for
action, kind of a mentality, right.
So I understand like writing sometimes take time, especially
if you have back and forth thoughts, you have other people
reviewing you brainstorm, put comments in inside the doc, it
could take quite longer, right? So maybe tell us a little bit
more like for those people who are thinking that action is the
best, right? What should they consider in
order for them to switch their mindset, maybe to consider
writing more? Maybe it's like those important
stuffs first, right? Not just everything in writing,
right? Maybe tell us a little bit tips
here for those people. Yeah.
I mean, one is to catch your bias of action sometimes and
just to think that maybe if you just waited a day or two or even
just one sleep before you do something, but that can actually
be very beneficial to no long term detriment.
I think the other thing that I have changed a lot, especially
since working remotely and also like now I'm in the UK and like
a lot of Shopify is on the East Coast.
So I do have a time zone gap. So I do have times in the
morning that are much more quiet than other people.
It's kind of changing my focus to how I was when I was in a
physical office, which was very much like a single thread and I
would just be executing on the single thread all the time until
it was done and then moving on to the next thread.
Now is very much like multi threaded.
So it requires good like To Do List maintenance, but I've
always got like multiple things that are in some stage of
progress at once. So for example, like a few weeks
ago, I was going in iterative back and forth with my
engineering strategy update with different people, you know,
updating it, sending out review, iterating and so on.
At the same time reviewing various technical documents.
And you kind of just you batch process things and you know that
like every single day that you put out a bunch of things and
then you wait for the next batch to come back and then you go
that way. And the way you get around it is
just by doing more at once. And yes, it does require being
more organised, but you can actually get quite a lot done if
you sort of have things at various stages of asynchronous
back and forth any time. Yeah.
So for those people who are into, you know, bias of action,
right, actually in your book, you also cover that writing
actually assists you in decision making, right?
Especially those decisions which are kind of like the one way
door thing, right, Because they're kind of like distill the
kind of insights, the thoughts that you really have to consider
before you take any action. So maybe tell us a little bit
more on this front, especially the concept of one way door and
two way doors. Yeah, it's something that I
think it's always been a concept that I had been aware of, but
since I started at Shopify, it's just the sort of phrases that
get used a lot. You kind of pick up on it.
But certainly being able to identify for anything that you
are doing, whether that is work being done in a particular team
or when it comes to decisions that you're making that are more
strategic. You know, think about whether
it's a one way door or a two day door, two way door, like two way
doors are easy because you can take that decision move forward,
but then you can just go backwards if you need to.
You could probably think of many examples there, but for example,
one way door is where it's scary.
So a one way door is where you know that if I make this
decision, I do not have the chance to roll it back.
And this can be anything from architectural decisions where
you know that you're going to introduce a big breaking change
and that's going to require say everyone that uses your API to
rewrite something that they've done.
That's a one way door. You can't roll that back very
easily down to personnel things like maybe if you're going
through a period and there are some layoffs, that's definitely
a one way door. And you have to do that very,
very carefully. And I think the idea is that if
you can identify whether something is a one way door,
then you know that that's the sort of thing that probably
requires deeper thinking, greater scrutiny.
And maybe if it's something that isn't particularly confidential,
sensitive, getting other people's opinions is really,
really useful there. For example, going back to the
start of this conversation, a reorg.
It isn't necessarily a one way door, like you could reorb again
the next day, but it's incredibly disruptive.
So thinking about that carefully and getting lots of people's
opinions and making sure that when it actually happens it's
the right thing, as much as you can predict ahead of time is
super important. Yeah, So I think the concept of
one way door, two way doors, for people who may have not heard
about this before, go check it out, right?
So I think it's really, really important to differentiate
before you make any decision. Is this one way door or two way
doors? One way door, definitely, you
need to spend a little bit more time and maybe consult more
people before you make the decision so that you don't get
it wrong, right? Because the effect of the result
for changing the decision is kind of like expensive and maybe
disruptive, right? And you also mentioned in your
book, as you go towards more seniority, you should move
towards more asynchronous communication mode, you know,
right, or maybe recording something, right, instead of
synchronous, which is like meetings, calls and things like
that. So definitely something that
worth to consider as you move up the ladder, you know, becoming
more senior engineering leader. And I think 1 aspect that is
also important, not just writing, but I think also
reading other people's writing, right?
So maybe doing, I don't know, document review or whatever that
is a little bit maybe here. Like what should an engineering
leader do in terms of reading? Good.
Question, I mean from personal experience, like the bulk of my
reading comes through design documents, you know, technical
design documents, making sure that where possible you are
receiving this is sounds very abstract, but receiving input
from all the places that matter. And if you've just started at a
new organization or maybe you've changed organization internally
or a different team, just stopping for a second and
thinking like what kind of fire hoses of information would be
really useful to have coming at my inbox so that every day I get
something that really helps me. And that to me comes from either
hanging out in particular Slack channels on adjacent initiatives
or particular like dev tooling projects that are going on.
So I can always just see the latest that's happening.
Internally at Shopify, we have like a project tracking system
that allows you to kind of follow projects as well, so that
whenever people do their updates, you get it in your
inbox. So I very sort of proactively
spend time going around and sort of choosing what's going to come
into my inbox so that I hopefully get smarter the next
day. And, you know, obviously not
just thinking about your company as well, you know, seek
information out there on on the Internet.
You know, I'm sure people who are watching or listening to
this already have done in order to find this podcast, but try
and find other views that conflict with your own.
Try and find people who write things or say things that
actually would, well, you would never do because they're very,
very different. Because you can actually just be
very useful to hear those opinions and strengthen your
own. Yeah.
So something that you mentioned about project updates, right?
So definitely if you have multiple teams under you, so
definitely do check out their status updates, right?
It could be weekly, it could be biweekly, whatever the cadence
is and give inputs to them, right?
It's not just like letting them do the thing and never check
back unless there's an issue, right?
So I think you do want to hear from them as well.
And sometimes you facilitate that through writing and giving
comments and maybe praises sometimes on the docs itself.
So I think that also work. That's a really good point.
Like for example, if you are receiving written updates from
your teams and maybe something comes through at the end of the
week saying all completed this round of scaling, you know, we
think it's production ready. Just taking 30 seconds to reply
to that and go, oh, you know, what's the throughput that we're
after? What are we expecting at the
busiest period of the year? What do we expect next year?
It really helps, not only helps you, you know, build those
connections with your teams because for example, if you are
running a large organization and this was written by a senior
engineer in one of the teams, maybe they don't even have a
chance to talk to you that much. And this gives them a really
great connection with you, but it also shows that you're
interested. And I think also often when
people write updates, they can sort of hide the details like
this if they're not particularly happy with them.
So I'll see most probing questions even though it's
uncomfortable to be on the end of them.
I think it really promotes the kind of culture that you want,
which is like just being always looking for that little bit of
extra on top of everything in like a positive, challenging,
healthy way. Yeah, so also from my
experience, right, because at the position, right, you might
have need to read a lot of documents, right.
So commenting on those documents actually showing also that you
care, right. So like making sure that people
know you are reading the docs and also trying to get to
understand what's the gist in the docs, right?
And giving good feedback and good comments definitely is
something that's showing that you care to the team as well.
So for leaders, do spend time on reading the docs.
So next thing that probably is also quite difficult for someone
new in the engineering leader position is setting up strategy.
So I don't think many people are trained in, you know, thinking
in strategic level. Some people are maybe more
talented, but I think for most people, something this is new to
them, right? So tell us a little bit more
about strategy, because as an engineering leader, it's kind of
like expected that you need to come up with some strategy for
the team to follow and also say no to, right?
Because a good strategy is something that can really define
what should we do and what should we not do.
So maybe tell us a little bit more about this.
Yeah, and it's quite deep. I spend like a whole chapter
going through strategy in the book.
But I think strategy is often, but there's a few things.
One, it's often a word that gets a bad reputation because it
sounds very kind of businessy and like words like synergy and
things like that. People think, oh, that's just
business nonsense. But it is very important and it
is like that top level of the pyramid as to what the most
senior people should be doing. And I think also strategy is
something that should be what Evergreen in the sense that you
should be able to read a strategy, engineering strategy,
for example, at any time and be really clear where you're going.
But it shouldn't always necessarily have an end.
You know, it should, in an ideal world, be kind of like an
infinite game that is going on forever and that's sometimes not
always possible to achieve. But that's the idea.
It's not meant to be a plan. The idea is that the plan comes
after the strategy. So what is it that you read that
then you really get aligned with where we're going, and then from
there the plan develops of what we're going to do and when.
Sometimes people sort of present a road map and say that's the
strategy. So no, no, no, that's not the
strategy, that's the plan. So writing a good strategy is
something that really captures where an engineering
organization is at a particular time.
You know, what is it that they are doing?
What are the critical things that are important through all
the pieces of work. So for example, maybe it's the
case that at the time that you produce a strategy, you're, and
this is the example in the book, like you are going through a
major rewrite of a kind of update of an old piece of
software and you're really bringing it into the future.
So that strategy then captures like what are the technologies
that we're going to be using? What are the kind of metrics
that we aim for when it comes to shipping?
What's the quality bar? What's the throughput?
What's our approach to using third party or paid software?
How should we be focusing our time?
What's our way that we write tests?
What's our way that we ensure that what we do is good?
You know, that's all the kind of stuff that a strategy
encapsulates. And depending on your
organization, maybe you will have a strategy that's in order
to be the most cost efficient as possible.
We will like host everything on our own hardware and that's our
primary way that we go about things.
Or maybe you're the complete opposite.
You know, we favour speed 1st and therefore everything that we
do is either cloud service or some kind of third party
provider and we focus on only writing the unique code to us
rather than needing to build things that are already out
there. So these are all the kind of
things that are strategy captures where, you know, an NGO
should be able to open it up and go, OK, I really understand
this. The narrative that is wrapped
around the work that I'm doing. And if I have to make decisions
on my team or my project, or even on my pull request, then I
can refer to the strategy to see which direction I should be
turning it. Yeah.
So you mentioned about this, I think sometimes it's not
natural, right. So you mentioned that strategy
is not a plan or road map we mentioned, right.
But actually some leaders actually work simply by putting
out Rd. maps. You know, here are the things
that we plan to do, I don't know, in the next one or two
years, right. So they think that's a strategy.
Is it something that is, I mean can also be accepted or do you
find that some particular thing that is uniquely different about
strategy that engineering leaders should focus on more
rather than building Rd. maps and projects and plans, you
know? I mean, everything that you said
there like Rd. maps and projects and plans, they're all
necessary, 100% necessary. They have to happen.
But the strategy is one of those things that sometimes is
missing. And I think that if you can do
that kind of thing as a leader where you can create an
Evergreen strategy that really summarizes the key ways that you
build software, then there's a few things that are good.
I mean, I think 1 is it means that some of those later things
take care of themselves. They start to solve themselves,
you know, in terms of what are our priorities, what's our
quality bar, what are the technologies that we use, what
are the languages that we use? And that all kind of comes from
there. Also, you know, how do we
measure success can come from the strategy as well.
If you say, you know, everything that we do has to be 999
reliability and you know, we have a certain SLA or whatever.
So that can make the latter a lot easier.
I think also one of the sort of long term views that you have to
have as a leader, it's like, well, what could you be
contributing today where if you were not there tomorrow could
last beyond? And I think that's the thing
that's tricky. Like with with Rd. maps, they're
very volatile when it comes to their prioritization.
A different product leadership or different engineering
leadership can have different opinions on what's more
important or not. Market conditions can change,
competitors can change, and then the whole road map goes in the
bin and then you start again. The idea with the strategy is it
should last longer than those things.
So it doesn't matter exactly what you're building or when
you're building it, but the way in which you're building it
should be informed by the the strategy.
So for example, like something in your strategy could be that
you want to run an organization where you have a strong advocacy
and use of open source software. You know, maybe you want to
build particular parts of your product in such a way that
you're open source and because you want to contribute back in
the same way that you use other open source software, you want
to put some back out. Maybe you want to build things
in such a way where for the stage of your growth you only
focus on particular metrics in one continent.
I don't know, because certainly going from fast in US East or
something to fast in the entire world is a very different thing.
So having all of this out there so that it reduces the amount of
decisions being made in the teams because they can see
what's important. I think we just make everything
more efficient. Yeah.
So maybe if I'm not mistaken, so strategy is not something just
the projects, the road maps, right.
But also there are some guiding principles or maybe it's some
kind of guard rails, right, that people should follow as like, I
don't know, like a compass or maybe sometimes before making
decisions, right, you have to always consult with this
strategy, right, in order to make sure that you actually
follow the same direction. So something that is not just
finishing a milestone or deliverables, right?
So something beyond that. So you mentioned about
Evergreen. So probably something that worth
to consider for ageing leaders who work solely by creating Rd.
maps and project plans. Yeah, something that might be
interesting is that's sort of like an extension of strategy.
At Shopify. We have this internal thing
called the Codex, which is kind of where important high level
decisions are captured. For example, like which
languages we use as our defaults, which messaging
formats do we use, which kind of.
Yeah, all these kind of things are captured.
And the idea is it makes it easier for teams to see what the
rest of the organization is going to be doing.
But likewise in your strategy as well, you know, you can make
very clear declarations depending on the size or the
maturity of your product or company as to what acceptable
means. Does something being shipped
mean that it's like 100% bulletproof failover, multi
failover 999? Or is it, you know, similar to
early days of Facebook? Is it the kind of like we don't
care about stuff breaking sort of done is better than good or
perfect? Those are the kinds of things
that the strategy can contain, and I think they can really
affect the behavior of the teams.
Yeah. So you mentioned about the
engineering strategy, right? Sometimes this is also tricky
because maybe in engineering it's kind of like obvious, but
how to communicate that also to the other parts of organization?
Because sometimes engineering strategy could feel a lot more
technical and a lot of jargons and very complicated.
So maybe tell us a little bit more, how can you communicate
your strategy well, not just within engineering team, but
also maybe with the CEO or maybe the rest of the organization as
well? Yeah, I mean like the obvious
stuff up front is like getting consensus and input from all the
people that that matter. But I think the important thing
is that you don't just write it once then forget about it.
What I do with my current strategy for I area is that
every six months I write an update document.
So this update process, effectively, I reread the
strategy, I then prepare an update that basically shows
everything that we've done in the last, say, six months,
grouped by the different areas. So that's actually where it
starts to link with the product strategy.
It's like, hey, we shipped these particular things that will
contribute towards this part of the engineering strategy.
We did this bunch of improvements in stability and
resiliency, and that fits that part.
And all those things are linked to like actual projects that the
teams have done. And I sort of write those and I
highlight them. I do a sort of a traffic light
system on the strategy because like the strategy has got kind
of like 6 or 7 main bits when I do traffic lights next to each a
group, the bits of progress that are very measurable that you can
show. And then if needed, I'll either
update the strategy with deleting something or adding
something and then I'll write about why.
And then also in that strategy update, I'll also go and sort of
show pie chart breakdowns of like where are we investing all
of our teams and our people? You know, like here's all the
people mapped to the projects and here's the sort of the pie
chart breakdown of 30% of our organization is working on this
particular mission, 20% on this. Just really kind of using it as
a, using the strategy as a messenger wrapper to show how
things are changing over time. And then I'll also spend that
strategy update spending time talking about the stuff that has
either gone wrong or has been really, really hard.
You know, either that's particular staffing
distribution. Maybe we have some areas that
are severely underfunded as a result of moving people around
to work on urgent things. Or maybe if there have been any
regressions in performance or stability that we've noticed
over time, you know, call that out, talk about any incidents
that happened. And yeah, just every six months
you kind of have that beating sort of heartbeat pulse of the
strategy in action. And then you always refer back
to the main strategy as well. So you kind of you have to keep
it alive yourself. It's all well and good.
Like putting it on a internal wiki page or something and
saying, oh, it's there, I'm done.
You know, it kind of updates every six months or so for me or
it could be even more frequent for you.
Yeah, I think you mentioned something that is really
important, right, Because a lot of strategy are written once and
forget forever. So I think yeah, you do have.
You have to talk about it again and again and again.
You have to sort of make yourself irritated by how much
you talk about it, but like, that's usually the level you
have to get to for it to be enough communication that people
actually pay attention. Yeah, so I think that's a really
good tip, right? Over communicate, right?
So not just once, but maybe multiple times, different
forums, different channels, you know, keep mentioning it until
people actually understand that that is actually an important
strategy. So the last part of the
conversation, I want to bring up this topic because I'm sure many
listeners here aspire to be an engineering leader, becoming
city of VP of Engineering engineering, whatever that is,
right? And you close the book with one
unique chapter. Maybe the title is called
Tarzan, you know, jumping from vines to vines, right?
So how can people actually follow a path?
Or maybe there's no path, you know, so, so that they become a
good engineering leader, right? So maybe tell us maybe from your
experience as well, how can you become a engineering leader
yourself? It's a very good question.
The reason that that chapter is called Tarzan Swings from Vine
to Vine is because there's a a really good YouTube video by a
content critical Casey Neistat who talks about his own career
as these like Tarzan rope swings.
And I think that sometimes people earlier on in their
careers or even in the middle of their careers and later their
careers whole whole of their career get very frustrated
because they get very fixated on one particular outcome.
That is the thing that they want.
But as you know, especially the longer that you spend in work,
you know that being able to get some particular role at some
particular time or work for some particular company isn't
guaranteed. Like that role may never exist.
Maybe if you're in your 30s and you're like, one day I'm going
to be the CTO of my company, maybe the CTO never leaves,
right? Like you just you can't, you
can't do anything about that. So I think what it's about is
going right back to the start of our conversation around scope
and impact, using that as a kind of narrative of, OK, I have
maybe some desirable outcome I want to aim towards.
Let's say you're a director of engineering for the first time.
You're like, you know, my goal is to be VP engineering of a
public company. You know, maybe that's what you
want. Getting there isn't particularly
obvious because it might be the case that that public company
doesn't exist yet because it hasn't started.
You can't always know what's going to happen in the future.
So you kind of have where you are and then where you want to
go, and you can kind of draw a straight line.
But the power that you take to get there is kind of like Tarzan
in the tree in the jungle knows where the end is, but the root
in the tree isn't very clear. So you have to just keep
swinging from tree to tree. So if at every step of your
career you're making a decision to do something new that feels
oriented towards your final goal is an increase in your scope and
your impact. So you know, you could go to a
smaller company and a bigger job.
You could go to a bigger company and a smaller job, but the scope
and the impact is bigger. Then what will also naturally
happen is that you will just stumble across things that you
didn't know before. Like I mean, you said for for my
own career, you know, when I was at university, I really wanted
to be a professor. That was my main goal.
That was my fixed goal. And I did a PhD and I did a PhD
in compilers, which was really good fun and I learned a lot.
And it was, it was great. But the reality was that when I
came out the other end of it, in the UK at least, it was the
recession and the funding for academic projects was just
disappearing everywhere. So getting that next step, which
was like a postdoctoral position to begin my research career for
real, there were no jobs, like there were literally no jobs
that didn't involve like relocating to the other side of
the country. So that forced me to do
something different. And I remember I joined a
startup at the time, which was in the, the town that I was
living in, and I didn't want to do that.
Like honestly didn't want to do that.
I almost felt like I failed because I'd done my PhD and like
this next step to me was so obvious at the time, but I just
couldn't do it. So I joined the startup and I
thought, well, that was a waste of time.
I could have just not bothered with the PhD.
But joining that startup and working hard at it, you also get
a little bit of luck. Like we had lots of funding and
we grew lots. And then I ended up to move into
these managerial positions for the first time.
And, and then that led to going to VPN's position and growing
the company to many hundreds of people.
And then we were required. And you know, I'm in Shopify now
and like, I couldn't predict any of these things, right?
The whole point is that I couldn't predict this stuff.
And if you'd have asked me when I was doing my PhD that I would
be living in the part of the country where I am doing this
particular job remotely, I couldn't have predicted it.
It unfolds as you go. So yes, have an overall goal,
but don't ever be afraid of doing something that's very
different or new because actually there's so much that it
can introduce to you, you know, different types of, if you're
thinking about just software, you know, you might not have any
exposure to a particular industry in software until you
have a go. And then you're like, oh,
actually this is amazing. I really enjoy doing this.
I want to do more. Or maybe you do it and go, I
hate this, I want to do something different.
And then it forces you to take a swing somewhere else.
And I think it's to do with being very open to new
experiences because you can't control what's going on in the
external world. You can only control what you're
doing in the present moment and what you apply yourself to.
And if you are talented and if you work hard and if you get a
little bit of luck, I'm pretty sure in 20 years you'll find
yourself somewhere really good. It just will happen.
Yeah, So I think those are some good tips, right?
Always look at the scope and impact that you're doing, right?
For sure. It has to grow, right?
Otherwise, I mean, you are not exposed enough to actually have
a good amount of experience to become an A leader itself,
right? And also I think you also
mentioned in your book this thing called earning or
learning, right? So when you move from job to
job, always think the learning aspect, right?
So what can you learn in the new role?
It could be new tech stack, it could be new domain, new
industry, whatever that is, right?
So the aim is actually for you to always learning and grow the
scope and the impact at the same time, right?
So I think, yeah, sometimes we can't predict the career and
sometimes you also cannot predict the time because the
opportunity may come at the wrong moment.
So that happened to me as well during the pandemic.
So I think there's something that also everyone has to think
about in terms of your career plan.
Maybe don't fix it on one route. Do check out other things
sometimes also do maybe other stuff that beyond your work,
right? Could be volunteering, writing
blogs, right? I'm sure it opens up a lot of
doors as well, just like in your case.
So I think this is really a good tips and thanks for sharing your
story as well. I think people might get
inspired from your experience. So we reached the end of our
conversation. So I think I ask you all the
time about this question. So I want to probably spin it a
little bit different. So I will call this a tree
engineering leader wisdom. So maybe if you have a different
version of the wisdom talking about engineering leadership, is
there anything that you want to share with us here, James?
Good question. So I'm I haven't prepared this,
I'm coming up with this on the spot.
So I think the first piece of wisdom, if you could call it
wisdom, is the quite often in any leadership position, there's
never a right answer. If you ever feel that you have
the definitive correct answer for anything, you're probably
wrong. So use that as your sort of
yardstick of like, if you're so sure about something, talk to
more people, seek more opinions, get people to challenge you
because you probably have missed something.
Nothing is ever very easy or straightforward.
The next one I would say is a bit related to the career
progression thing. Like it's very easy to say,
don't be completely fixated on one goal that you're aiming
towards in your career and let there be some spontaneity and
open yourself up to different experiences that maybe aren't
quite where you think you want to go.
But that's actually where the interesting stuff is.
You know, I think I've learnt that from my own career journey
is that if I'd have stayed 100% focused on and moving towards
being a professor in the future, then I would have missed out on
like all the cool stuff that we've built different companies.
I would have missed out on working for Shopify, I would
have missed out writing these books.
You know, I wouldn't have been able to work remotely.
So like there's all this stuff that wouldn't have been possible
if I'd have been like super fixated on that one goal.
So being flexible there is good for you and it's sometimes
uncomfortable, but it is worth it.
You know, you only, you only live once, right?
So you've got to make sure that you're doing something you're
interested in. And then I would say that the
last one is, and this is obviously difficult to say
because it depends on your situation and where you are in
your career, in your finances and so on.
But don't see money as the ultimate goal of your career or
wanting to be a leader of some kind.
I think the reason that I say that is that you've often got to
think about the earning or learning thing and when you are
hyper optimised on I want to earn the most money possible at
any given moment in time. I think you can end up with a
very short term dead end where either you work somewhere where
you become hyper specialised and then you end up with skills that
aren't super transferable to other places.
Or you miss out on taking that role at a company that's growing
very, very quickly where they can't afford to pay you a huge
amount of money, so you have to take a big pay cut if it in the
future, you have an insane amount of experience.
And maybe if you get offered a whole bunch of stock options
that mean nothing when you join, maybe they'll be worth something
in the future. Like who knows?
Like if you don't, if you get away from money, if you make
sure you're earning enough to live the lifestyle that you want
and to have a financially sensible future in some way,
don't sweat the rest of it. Like go towards the things that
really, really interest you and I guarantee that you will be
much more fulfilled and probably one more in the future anyway if
you go down that route. Wow, that's really a golden tip.
The last one. So I think as an engineering
leader, you should not be fixated or incentivized on, you
know, the money, the rewards, compensation, whatever that is,
right? So I think also think about the
aspect of your growing, your learning and also serving
others, right? So as a leader, also some parts
of it is about mentorship and coaching, right?
Which you also cover in your book.
So definitely one aspect of the job that is I feel is very
fulfilling, right? So money is not the only thing.
So thank you so much for this. If people want to check out your
resources the book is there any place they can find you online?
Yep, you can go to the Engineering Manager,
oneword.com, that's my blog, the newsletter.
You can find the link at the top there, and there's a book page
at the top where you can see the books too.
They're all over on the Pragprog website, Pragmatic Programmers
if you want to get the ebooks or whatever kind of bookstore that
does print books and will be your friend as well.
Maybe you should also create an alias the engineeringleader.com
so that people are not confused. Yeah, I mean, I'm bad enough at
remembering to renew the domain name as it is, so I don't want
anymore. Right.
So I think the book is really good.
So for people who would like to check out a good resource about
becoming a great engineering leader, definitely this is one
book that I highly recommend. Not just the things that we
discussed today, there are so many other topics.
And it's not just high level stuff, right?
It's also like super tactical, practical, right?
That you can also try straight away in your day-to-day job.
So thanks again for this time, James.
This is the third time I'm looking forward for your next
book so that I can invite you for the 4th time.
No, no, no, no, no, no, no, no, no.
I'm done now. I'm done.