#200 - Become a Great Engineering Leader - James Stanier

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.