#200 - Become a Great Engineering Leader - James Stanier

[00:01:40] Introduction

Henry Suryawirawan: Hello, guys. Welcome back to another new episode of the Tech Lead Journal 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.

James Stanier: Yeah, thank you for having me. And as we were saying before we started recording, like 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.

[00:02:19] Writing “Become a Great Engineering Leader”

Henry Suryawirawan: 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 learned along the way and you just want to share with the audience?

James Stanier: 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 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 a VP 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, like 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 checkbox I try to tick when I write something.

Henry Suryawirawan: Yeah, I think a few years back, your Engineering Manager book is kind of like one of the rarest resources about engineering manager. I guess over the time, many people wrote about engineering manager. And engineering leadership, you know, like VP of engineering, CTO, those kinds 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.

[00:04:21] The Role of Engineering Leader

Henry Suryawirawan: So I think in the first place, maybe let’s level set what is engineering leader in your point of view, right? What is this role all about?

James Stanier: It’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 perform 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 are the most important things. So, lots of previous business books are like, ah, you know, you’re a thousand person or you’re a 5,000 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 if we end up touching on career progression, I think that’s the model you use over your career 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.

Henry Suryawirawan: 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 startups, right? Sometimes a small startup could also have VP of engineering or even CTO, right? So I think the, the way that you mentioned the scope and impact, I think is really interesting so that it can be applied, not just on the traditional enterprises, but also on the startups as well.

[00:05:57] Engineering Leader vs Engineering Manager

Henry Suryawirawan: And I think you mentioned about few different skills for engineering leader. What are 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?

James Stanier: Yeah. And just to sort of finish your previous thought, because 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 a VP of a startup or a VP 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 a PDF, 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 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, okay, here’s an organization that has been doing distributed teams for, you know, thousands of years. So they know what they’re doing in terms of organization of people and chain of command and so on. And that sort of strategy, operational, tactical pyramid 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 your 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 CTO and VP 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, ah, 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 had been doing this for quite a long time, was still getting things that actually went, oh, now I understand my role so much better. So this is me trying to gather all that up into one place and get it out there.

Henry Suryawirawan: 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.

[00:09:36] Tenure Relevancy

Henry Suryawirawan: 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?

James Stanier: 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 10 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 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, um, 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 thing.

Henry Suryawirawan: Yeah, that’s okay. 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 three levels of warfare, right? So I’ve previously also experienced these kind of 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.

[00:11:30] The Importance of an Org Chart

Henry Suryawirawan: 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 experienced 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.

James Stanier: 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 org 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’s 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 labor. It really is the sort of the blueprint of the strategic aim of the organization.

[00:13:44] Org Chart Best Practices

Henry Suryawirawan: Yeah, so I think, definitely, especially if you are working in a fast growing uh, 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 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 a few other best practices, right? You know, like Dunbar size and all that. So maybe specifically, can you tell us a 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.

James Stanier: 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 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, okay, 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 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 an incredibly useful tool.

[00:15:55] Conway’s Law

Henry Suryawirawan: There’s something that is always mentioned about org chart 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.

James Stanier: 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 desktop or 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 application’s org? And then somehow you have to kind of keep both of the feature sets in sync and then have like two roadmaps. 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.

And there’s no hard and fast answer here. And the same is true for like do you do QA as a separate org 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.

[00:17:16] Avoiding Politics

Henry Suryawirawan: Yeah, so I think definitely it’s kind of like no hard, fast rule here, right? Sometimes, different organizations 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 organizations, no matter large or small, there are sometimes politics. So is there any kind of an org chart design that you think would kind of like avoid politics much much, effectively?

James Stanier: It’s tricky. It depends on 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 gonna 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 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 no hard and fast rule. You obviously want, for particular specialist piece of infrastructure, for them not to be at the whim of a, of a product roadmap 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 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 deprioritize 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 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 behavior.

Henry Suryawirawan: 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 behavior 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 a some kind of a science behind it. And don’t forget some of the best practice like Conway’s law, team topologies, you know, Dunbar size 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…

James Stanier: I’ve had just one more thought. Just one tiny thought that came to 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 impact, then the kind of behaviours 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 behavior that they exhibit, then I think that starts to break that political behavior 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 how you help the company. Sorry. That was just my additional thought there.

Henry Suryawirawan: Yeah. Thanks for the addition. So I think as engineering leaders who are at the highest, maybe CTO or VP, this is kind of like your responsibility, right, to ensure that, you know, you manage the performance really well and reward the behaviors that you want.

[00:21:41] Writing Skills & Time Management

Henry Suryawirawan: The other aspect of something that I’m sure like many engineering leaders struggle are actually time management. So I think one, 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?

James Stanier: 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. Shopify, 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 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 and experienced 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, at, want to see sort of a little view into sort of some of the tech companies at the top, there’s a, I think internal tech emails Substack 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 one 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. One-to-ones 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. Um, um, as you, as you could 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 shipped and things that we’ve 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.

Henry Suryawirawan: 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, right? When they started as an IC, suddenly, they have to manage people, right?

[00:26:35] T-Shaped Leadership

Henry Suryawirawan: 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, except probably some OKR 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 the 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.

James Stanier: 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 a T-shape, which is the similar sort of T-shaped engineer thing, but it’s sort of T-shaped 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. Close as 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 cause 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.

[00:28:39] Long-termism

Henry Suryawirawan: 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 their day to day?

James Stanier: Yeah, long-termism 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 as a default mode to get sucked into the urgent day to day things. You know, 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, okay, 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 fail over, 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 out. Look, 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, okay, 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 engineer’s 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, okay, 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.

Henry Suryawirawan: 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 like long term, right? So, instead of doing long term, sometimes people put more focus on the short term. Maybe there 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 is 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 readers here can also look at the book, right, in order to get the best tips.

[00:33:02] Leadership is Writing

Henry Suryawirawan: 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 leader doesn’t like to write?

James Stanier: Yeah, it’s a good question. It’s something I covered in the Remote Work book as well, because, obviously, being remote, 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 all the 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 first 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 on 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 LogSec 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, okay, 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 and you won’t repeat 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.

[00:36:13] Writing vs Bias for Action

Henry Suryawirawan: 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 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.

James Stanier: Yeah, I mean, one is to catch your bias of action sometimes, and just to think that maybe if you just wasted a day or two, or even just one sleep before you do something, that 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 it out for 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 organized, but you can actually get quite a lot done if you sort of have things at various stages of asynchronous back and forth anytime.

[00:38:20] One-Way vs Two-Way Door

Henry Suryawirawan: 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 that 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.

James Stanier: 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 this 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 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 can probably think of many examples there.

But for example, one way doors are 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 or sensitive, getting other people’s opinions is really, really useful there. For example, going back to the start of this conversation, a re-org, it isn’t necessarily a one way door. Like you could re-org again the next day, but it’s incredibly disruptive. So thinking about that carefully, 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.

Henry Suryawirawan: 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 door? 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, writing 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.

[00:41:09] Reading & Seeking Information

Henry Suryawirawan: And I think one 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?

James Stanier: 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 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 obviously, not just thinking about your company as well, you know, seek information out there 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, you would never do because they’re very, very different. Because it can actually just be very useful to hear those opinions and strengthen your own.

Henry Suryawirawan: 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 bi-weekly, 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, uh, on the docs itself. So I think that could also work.

James Stanier: 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 asking those 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.

Henry Suryawirawan: 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 definitely for leaders, do spend time on reading the docs.

[00:44:46] Strategic Thinking

Henry Suryawirawan: 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, some think this is new to them, right? So tell us a little bit more about strategic, 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.

James Stanier: Yeah, and it’s quite deep. I spent like a whole chapter going through strategy in the book. But I think strategy is often, well, 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, well, 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 roadmap and say, that’s the strategy. It’s like, 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? And 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 favor speed first, 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 kinds of things that a strategy captures where, you know, an engineer should be able to open it up and go, okay, I really understand 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 in.

[00:48:05] A Strategy is Not a Plan

Henry Suryawirawan: Yeah, so you mentioned about this, I think sometimes it’s not natural, right? So you mentioned that strategy is not a plan or roadmap, you mentioned, right? But actually some leaders actually work simply by putting out roadmaps, 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 type of strategy, thing that is uniquely different about strategy that engineering leaders should focus on more rather than building roadmaps and projects and plans, you know?

James Stanier: I mean, everything that you said there, like roadmaps 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, one 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? 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 triple nine 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 is 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 roadmaps, they’re very volatile when it comes to their prioritization, 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 roadmap 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 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 open source them, 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.

Henry Suryawirawan: Yeah, so maybe if I’m not mistaken, so strategy is not something just the projects, the roadmaps, right? But also there are some guiding principles or maybe it’s some kind of guardrails, 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 engineering leaders who work solely by creating roadmaps and project plans.

James Stanier: Yeah. Something that might be interesting is, as 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 of these kinds 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, triple nine? 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.

[00:52:23] Communicating Your Strategy

Henry Suryawirawan: 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?

James Stanier: Yeah, I mean like, the obvious stuff up front is like getting consensus and input from all the people that matter. But I think the important thing is that you don’t just write it once and then forget about it. What I do with my current strategy for our area is that every six months I write an update document. So this update process, effectively, I re-read 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. Cause like the strategy has got kind of like six or seven main bits. And I do traffic lights next to each, I 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, a wrapper to show how things are changing over time.

And then I’d 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. Yeah, it kind of updates every six months or so for me. Or it could be even more frequent for you.

Henry Suryawirawan: 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…

James Stanier: 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.

Henry Suryawirawan: 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.

[00:55:39] Becoming an Engineering Leader

Henry Suryawirawan: 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 CTO, VP of 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 that they become a good engineering leader, right? So maybe tell us, maybe from your experience as well, how can you become an engineering leader yourself?

James Stanier: It’s a very good question. The reason that that chapter is called “Tarzan Swings from Vine to Vine” is because there’s a really good YouTube video by a content creator called 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 in 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, and 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 thirties 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, okay, 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 path 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 trees 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 in a bigger job. You could go to a bigger company in a smaller job, but the scope and the impact is bigger. Then what what will also naturally happen is that you will just stumble across things that you didn’t know before.

I mean, you said 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 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 then that led to going to a VP of Eng position and growing the company to many hundreds of people. And then we were acquired and, you know, I’m at Shopify now. And like I couldn’t predict any of these things, right? The whole point is 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.

Henry Suryawirawan: Yeah. So I think those are some good tips, right? So 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 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 this is something that also everyone has to think about in terms of your career plan. Maybe don’t fixate on one route. Do check out other things. Sometimes also do maybe other stuff that’s 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.

[01:01:56] 3 Engineering Leader Wisdom

Henry Suryawirawan: 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 three 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?

James Stanier: 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 that 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 learned that from my own career journey is that if I’d have stayed 100% focused on 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 and 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 optimized 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 specialized 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, but 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 there’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 will earn more in the future anyway, if you go down that route.

Henry Suryawirawan: 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, uh, is there any place they can find you online?

James Stanier: Yeah, um, you can go to ’theengineeringmanager’, all one word, .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 will be your friend as well.

Henry Suryawirawan: Maybe you should also create an alias, theengineeringleader.com so that people are not confused.

James Stanier: Yeah, I mean, I, I’m bad enough at remembering to renew the domain name as it is, so I don’t anymore.

Henry Suryawirawan: Right. So, um, 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, uh, James. This is the third time. I’m looking forward for your next book so that I can invite you for the fourth time.

James Stanier: Oh no, no, no, no, no, no, no. I’m done now. I’m done.

– End –