#200 - Become a Great Engineering Leader - James Stanier ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fd3t3ozftmdmh3i.cloudfront.net%2Fproduction%2Fpodcast_uploaded_nologo%2F6336609%2F6336609-1679195199932-b698770720e3b.jpg&w=100&h=100) ## Metadata - Author: [[Tech Lead Journal]] - Full Title: #200 - Become a Great Engineering Leader - James Stanier - Category: #podcasts - URL: https://share.snipd.com/episode/0059edc0-c973-4864-862e-55ed75532ca4 ## Document Notes ## Highlights - **Modern Engineering Leadership** - Modern engineering leadership is less about organization size. - It's defined by increasing scope, impact, and bringing people along. Transcript: Unknown Speaker It's a good question. James Stanier 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 increasing scope and increasing impact are the most Important things. So lots of previous business books are like, ah, you're a thousand person or you're a thousand 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 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. ([Time 0:04:29](https://share.snipd.com/snip/a019f66a-e416-442c-8e4c-66115379935f)) - **Engineering Leader vs. Manager** - Engineering managers are tactical, executing work and projects. - Engineering leaders are strategic, focusing on long-term vision and direction. Transcript: Unknown Speaker And I think you mentioned about a few different skills or 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? Yeah. James Stanier 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 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, well, 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 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 the luck into one place and get it out there. Yeah, ([Time 0:05:57](https://share.snipd.com/snip/a69e7705-be66-4c04-a088-aed9ee82820c)) - **Org Chart Importance** - Design your org chart carefully for team autonomy and clear goals. - A well-designed org chart can significantly reduce future organizational problems. Transcript: Unknown Speaker So you cover about org chart. James Stanier 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, larger teams in 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. Yeah, ([Time 0:11:47](https://share.snipd.com/snip/d769ef4e-e8b4-44e0-8afa-46bc7ba59468)) - **Org Chart Best Practices** - Design org charts for team autonomy, minimizing dependencies while avoiding silos. - Consider skill sets, seniority, and pairing senior ICs with managers for optimal collaboration. Transcript: Unknown Speaker So I think designing an org chart, you mentioned a few things like Conway's Law, and maybe you also cover about the theme topologies and a few other best practices, right? You know, like number 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. 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 particular piece of architecture, how do you pair them with the right managers so that they can almost become like co-processors At 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 works 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 ([Time 0:13:59](https://share.snipd.com/snip/4f33919b-2508-49e8-bad9-cb699caac35f)) - **Mobile and Web Team Structure** - It is best to blend mobile and main application teams together. - Separating mobile and web teams leads to roadmapping and synchronization issues. Transcript: Unknown Speaker I've used as well in a reorg I did not too long ago as well. It's an incredibly useful tool. Yeah, something that is always mentioned about OrgChat 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 desktop or web-based application, James Stanier But you also have a mobile application. And then how do you design this? Do you have the mobile engineering org? Is that separate to the main applications org? And then somehow you have to keep both of the feature sets in sync and then have 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 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 multifunctionally in a way that really helps the product and you get to sort of exploit Conway's law is something worth thinking About. And yeah, mobile QA always comes off again and again. Yeah. So I think definitely it's kind of like no hard, fast rule here, ([Time 0:15:50](https://share.snipd.com/snip/29206e0f-ab83-4ee0-8a97-3b47184da075)) - **Time Management for Leaders** - Identify essential tasks and proactively block time for deep work. - Minimize meetings and embrace writing for effective leadership. Transcript: Unknown Speaker So I think 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 week-to 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 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. 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 can write quite fast and that kind of thing. But I find that my most valuable time in terms of 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. It happens in Slack messages or emails. And there is 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 it 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 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. 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 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, 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 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 ([Time 0:21:48](https://share.snipd.com/snip/44b099db-21be-4400-9a6a-b6549e4fae74)) - **Long-Termism in Leadership** - Maintain a long-term perspective, focusing on sustainable solutions. - Resist short-term pressures that compromise long-term stability and maintainability. Transcript: Unknown Speaker This one thing called long termism, right? So it's something that I think is 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 the day-to Yeah, long-termism is interesting. James Stanier 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 things. 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. ([Time 0:28:40](https://share.snipd.com/snip/2f099172-8131-4264-aebb-208e5c3621a8)) - **Leadership is Writing** - Use writing to clarify thoughts, make decisions, and build a knowledge base. - Writing is a powerful tool for leaders to process information and formulate ideas. Transcript: Unknown Speaker 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? James Stanier Yeah, 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. 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 a 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 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 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, 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. Having enough time in the calendar to spend with myself in the quiet, thinking, reflecting, coming up with ideas is where ([Time 0:33:04](https://share.snipd.com/snip/85834b19-9e62-4a6f-bac2-c6f50eddfbb1)) - **Balancing Action and Reflection** - Counteract bias for action by pausing before acting and considering alternatives. - Adopt a multi-threaded approach, managing multiple projects concurrently. Transcript: Unknown Speaker 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 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 stuff first, right? Not just everything in writing, right? Maybe tell us a little bit tips here for those people. Yeah. James Stanier 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, that that can actually be 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 is 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 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. Yeah. ([Time 0:36:10](https://share.snipd.com/snip/e6201c09-c25e-42e1-a096-4c8c2e33a136)) - **One-Way vs. Two-Way Doors** - Identify one-way door decisions (irreversible) and two-way door decisions (reversible). - One-way doors require more thought and scrutiny. Transcript: Unknown Speaker 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, especially those decisions which are kind of like the one-way door thing, because that Kind of 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 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-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 or 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. You could reorg 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. Yeah. So I think the concept of one-way door, two-way doors, for people who may have ([Time 0:38:20](https://share.snipd.com/snip/e9678162-2faf-433d-ab5f-68bdda1b0cf3)) - **Strategy vs. Roadmap** - Develop an evergreen strategy as a guiding compass for your team, not just a roadmap. - Roadmaps change; strategy informs how you build, not what or when. Transcript: Unknown Speaker So I don't think many people are trained in 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 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. James Stanier 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 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 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. 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're 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? 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 kind of things that a strategy captures where an NGO 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, ([Time 0:44:53](https://share.snipd.com/snip/3e4c5837-5b54-425b-998f-c42e3bd349ec)) - **Communicating Strategy Effectively** - Communicate your strategy frequently and integrate it with progress updates. - Show how projects align with the strategy and discuss challenges openly. Transcript: Unknown Speaker 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 theo 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 then Forget about it what i do with my current strategy for iarea 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 all 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 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, 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. 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, 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 an internal wiki page or something and saying, oh, it's there, I'm done. ([Time 0:52:20](https://share.snipd.com/snip/72e4cccd-cb8d-47e8-92fa-de92b29c7228)) - **Career Progression for Engineering Leaders** - Focus on increasing scope and impact throughout your career, embracing new opportunities. - Don't fixate on one specific goal; be open to unexpected paths. Transcript: Unknown Speaker 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 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, the 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 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 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 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 will also naturally happen is that you will just stumble across things that you didn't know before. Like, 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. There were literally no jobs that didn't involve 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. 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 VPN position and growing the company to many hundreds of people. And then we were acquired. And I'm in Shopify now. And I couldn't predict any of these things. 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. ([Time 0:55:30](https://share.snipd.com/snip/c7b2cac5-5450-4a55-8cb0-e563158a1437)) - **Three Engineering Leadership Wisdoms** - There are rarely definitive right answers in leadership, so seek diverse opinions. - Be open to new experiences and prioritize learning over maximizing immediate earnings. Transcript: Unknown Speaker 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? Good question. James Stanier So 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 been Able to work remotely. So there's all this stuff that wouldn't have been possible if I'd have been 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 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 they'll be worth something In the future. 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. ([Time 1:02:01](https://share.snipd.com/snip/919bb47f-7142-4920-a8bf-5ddac378ca84))