#28 - Becoming an Effective Software Engineering Manager - James Stanier

Episode Introduction [00:00:38]

Henry Suryawirawan: [00:00:38] Hey everyone. Welcome to another new episode of the Tech Lead Journal podcast. I’m always excited to be back with a new episode every week to share with all of you my conversation with another great technical leader in the industry. Thank you for tuning in and spending your time with me today listening to this episode. If you’re new to the podcast, know that Tech Lead Journal is available on major podcast apps, such as Spotify, Apple Podcasts, Google Podcasts, YouTube, and many more. Make sure to subscribe and get notified for any new episode in the future. Also do check out and follow Tech Lead Journal social media channels on LinkedIn, Twitter, and Instagram, where every day I post insightful quotes from each week’s episode and I shared them on those social media channels to help inspire us to get better each day. And if you’d like to support the podcast and make some contribution to the show, please consider joining as a patron by visiting techleadjournal.dev/patron. I highly appreciate any kind of support from all of you and your contribution would definitely help me towards sustainably producing this show every week.

For today’s episode, I am excited to share my conversation with James Stanier. James is the SVP of engineering at Brandwatch and the author of the book titled “Become an Effective Software Engineering Manager”. This book is one of the great resources that I’ve read that provides guidance for engineering managers or people who aspire to become engineering managers in order to become more effective and make great impact in engineering teams. James also writes frequently on his blog, theengineeringmanager.com, in which you can also find more of his writings about this topic. In this episode, James shared with me his insights on becoming an effective software engineering manager and how we can build and run effective engineering teams. We started off by discussing why the tech industry is facing a skill crisis because of the inability of many managers to manage people effectively, and the challenges faced by many engineers when transitioning to become managers. We then dived deep into the best practices to become an effective manager, such as how to get oriented, delegating effectively, letting go of control, and nurturing one-on-ones with your team members. James also pointed out the hardest things that engineering managers have to deal with, which are dealing with projects and humans. Towards the end, we then wrapped up with James’ tips on how a manager should handle failures and move forward from them.

I hope that you will enjoy this great episode. Please consider helping the show in the smallest possible way, by leaving me a rating and review on Apple Podcasts and other podcast apps that allow you to do so. Those ratings and reviews are one of the best ways to get this podcast to reach more listeners, and hopefully the show gets featured on the podcast platform. I’m also looking forward to hearing any comments and feedback on the social media, or you can also directly send to me at techleadjournal.dev/feedback. So let’s get the episode started right after our sponsor message.

Introduction [00:04:26]

Henry Suryawirawan: [00:04:26] Hey, everybody. Welcome to another episode of the Tech Lead Journal. Today, I have with me someone who is an author of the book called “Becoming an Effective Engineering Manager”. So I read this book actually. It’s one of the rare books that I find covering topics about engineering manager. I find it quite interesting the way he actually narrated the story, from joining a company as a manager, a new manager. Going through your first day and going through projects, working with people and things like that. Until at the end, thinking about the future, what the person should do, which I find is quite interesting. And just going through all the chapters one by one actually brings us in the manager’s point of view. The difficulties, the confusion, sometimes on what you can do, on what you should do. I think it’s really, really crucial. So I’m very happy to actually meet James Stanier. Welcome to the show, James.

Career Journey [00:05:15]

Henry Suryawirawan: [00:05:15] So first of all, James, for people who don’t know you yet, so maybe you can introduce yourself.

James Stanier: [00:05:20] Yeah, sure. Thanks. My name is James. So I live in England and I’ve been Vice President of Engineering, I’m Senior Vice President now for quite a few years. And I guess I didn’t really intend to do this as a job. And I’ll be honest with you straight up. My career has taken a whole bunch of twists and turns and various kinds of things I’ve tried and failed and so on. And if you’re interested, I can give you a little bit about the journey I’ve been on, if that’s interesting to your listeners.

Henry Suryawirawan: [00:05:44] Yep. Yeah, sure. Certainly. You can mention your highlights, your turning points.

James Stanier: [00:05:49] Sure thing. So initially, like when I went to universities, do computer science, you know, I was really, really intent on becoming a compiler engineer. That was my initial passion. It was one of those things where I did the compiler modules during computer science. I was like, this is so cool. I never knew anything about this. And I was fascinated. It was like a lovely balance between programming and theory and also just like magic. So, my projects at university as an undergraduate was compilers. And then as I was finishing up, my supervisor said, “Hey, there’s some PhD funding for doing compiler projects.” And I was like, “Yes, I’m doing that.” Okay. I’m a PhD student. So I did a PhD. And again, it was in compilers. So there’s a theme certainly at the moment. And after my PhD, I was absolutely sure that I was going to go and do a postdoctoral research. Maybe become like a lecturer or researcher in compilers.

But as I was finishing my PhD, I was interviewing in a few different places for positions. And there weren’t many at the time. This was like 2010- 2011. And it’s becoming clear that either I’d have to move halfway across the globe to do one of these research positions or should probably try and do something different. So I went to a few interviews. I narrowly missed out on a few slots and then there was a startup in my town at the time, which was Brighton in the UK on the South Coast. They just raised some seed money, and they were looking for people. And I must admit, I wasn’t looking to work there, and I was kind of hesitant. They phoned a few times. And I was like, “I’m not really sure if I want to do this”. I was actually in the interview process for Google at the time as well. And I was like, “Oh, that sounds way better”. Then actually, I went and then met this startup and it seemed really interesting. And then I was a backend engineer. So a number of years doing that. The startup did well. And we raised several rounds of venture capital funding. Which in turn grew the company, which then meant that we were needing to have our first managers. And that’s how I got into it, really. How do we actually structure teams? How do we run teams? Could I do that? Oh, okay. I guess I could do that. And nearly 10 years later, I’m Senior Vice President. So I guess that kind of worked out. So it was kind of an accident, kind of an opportunity, and kind of an interest all rolled into one. I don’t write any compilers anymore, unfortunately. But it’s a journey, right?

Henry Suryawirawan: [00:07:51] Well, instead you write a compiler for managing people.

James Stanier: [00:07:55] Yeah. True, true.

Henry Suryawirawan: [00:07:56] So I know this is like sometimes for us, it’s kind of like accidental journey. We intend to do something, but in the end we work on something else. So for you, how hard is it? Being like strong academia, kind of a background, going through post-doctorate degree and things like that. And then switching to joining a startup which I think to me is a big major turn in your career. So how did you analyze, looking back?

James Stanier: [00:08:17] It was tricky. I found one thing. I had to completely change my own perspective of what me being valuable was. The academic world is very much about publishing papers. It’s about going to conferences, talking at conferences. I felt that I had to sort of cling to this, like, “Oh, I’m not just an engineer. I’m also like a researcher. This is important to me. I have to hold on to this.” But actually, as time went on, and as the startup started doing well, I really enjoyed being able to build things for people. Building things for users who like the product, who then pay us more money, then we get more users, and then we hire more people. It was a virtuous cycle. And I think that was the one thing I did realize in academia, it was that it’s fantastic. You work with some very, very smart people. But the outcome is a paper. Or the outcome is a talk. And I never really experienced that whole thing of really building for lots of users before. And as soon as I had experienced it, I was like, “Oh, actually this is way more fun. I really enjoy this.”

Why Writing Engineering Manager Book [00:09:08]

Henry Suryawirawan: [00:09:08] So, let’s go through why you decide to write this book about becoming an effective software engineering manager? What kind of problems did you see during the time?

James Stanier: [00:09:18] So the beginning of it was my website. We just discussed before we started recording, you were doing these weekly recordings for your podcasts. I set myself a similar challenge a few years ago, which was I really want to write an article a week on the management subject. Just because I felt like I’d had to learn a lot of stuff by trial and error. If I could at the very least just write it up for myself, even though it’s on the internet. That’d be cool. And if there’s a few other people, maybe people that I worked with who could read it as well and find some use in it, then that’s cool. That’d be great. So that was the original goal. I was like, I’ll start this blog and I’ll try and write something once a week and see how it goes. I just got into this nice cadence with that, where not only did I feel that people were actually reading it, which was cool. People came to the website, and the traffic kept growing. I had a few front pages on Hacker News and things like that. And that was really cool. But I found that writing something once a week was just a really great way of me better understanding the subject myself. Because all of these ideas are kind of complicated. And by actually focusing on writing them down, you really start to explore the idea. And then you come away and I can understand it better now that I’ve actually tried to write it to somebody else. When you teach something, you feel that you understand it better. So the site was the beginning.

About 10 years ago, when I was starting to read about management. This was before there was this little explosion of engineering manager type books. A lot of the books that I bought at the time were either like very businessy books, like a McKinsey consultant talks to you about management in Fortune 500 company. There’s bits in here that I relate to, but there’s also bits in here I really don’t. But there was one book that I did read that I thought was fantastic, which was “High Output Management” by Andy Grove. I mean, lots of people know him. CEO of Intel, engineering backgrounds, kind of Silicon Valley legend person. But, for people that don’t, what was really nice about him as the CEO of Intel is that he is an engineer at heart. So he thinks about things in very engineering ways that I can relate to. He ran a humongous company doing incredibly complicated things. But he wrote this fantastic book. It’s old, it’s like mid-eighties. But there were so many things in there. I was like, ah, he’s really thought about this messy human thing and manage to sort of put a process around it that makes sense to me. He talks about these anecdotes of like running a cafe. And then it’s like, okay, boiling eggs and like making toast and employing people. And then he’s like, Ah, because this is hard. Is this people management problem? And you’re like, Oh wow. It really is, like I can relate to that. So that was my first experience of this one book that I read. I felt like I’ve learned four years, five years of doing this job by just reading this one book.

So I thought there’s a gap in the market here. It feels like this information doesn’t exist. That’s why I started the site. And then after writing for several years, I thought I’ve got at least a book’s worth of material. As you mentioned at the beginning, there are other management books out there, and there are brilliant ones. There’s “Managing Humans”. There’s “Manager’s Path”. There’s “An Elegant Puzzle”. There’s lots of other management books out there. So I’m not saying that mine’s the best. But in the same way, that there’s loads of different books on management program, different authors have different takes on the same material. And I think sometimes it’s really useful to have different perspectives on the same thing. So I wanted to write something that was kind of, if I just started my job as an engineering manager now. If someone put this book on my desk and said, “Hey, just like, have a read of that.” Then I want to structure it in such a way that maybe they could read a chapter every few weeks. And then it would kind of unfold as they were doing their job, and then they could refer back to it. So that kind of a handbook that I wanted to put together.

Skill Crisis in Tech Industry [00:12:34]

Henry Suryawirawan: [00:12:34] Yeah. So when I read it, definitely it’s like a manual. So it’s like, when you are onboarded as a manager, you can literally read it, one chapter a week probably. And you can relate with so many things that you cover there. Either like your own productivity, hiring, working with people, influencing other people, and things like that. But I want to start with one first interesting point of view that you have in the beginning of the book. So you mentioned that there’s a skills crisis in the technology industry due to the inability of many managers not able to manage people. And I mean, if I can see these days, technology industries are really booming. There are more and more people being involved in the technology. So why do you start with that kind of a statement?

James Stanier: [00:13:16] It’s something that I’ve experienced myself is that in order for people to get into technology, especially software engineers, they’ve often had a hobby in the childhood. Maybe they’ve been really good at certain subjects at school. They learn to program. They practice for years. They’ve maybe done a degree. They’ve done all this work in order to get where they are. If you end up working for a company that doesn’t have very clear career progression. I mean, you work for a company that’s got very clear tracks and progression and as do the other big technology companies. Not everywhere does. So unfortunately, I think a lot of software engineers end up a bit stuck in their progression. They think, how do I earn more money? Or how do I get a promotion? Or how do I progress? And often, people who maybe don’t want to be managers end up going for managerial roles because they see it as a way of progressing. So we ended up with people who’ve never done it before, going into the engineering manager roles. And they have very little support on how to do that job properly because it’s a different job. Fundamentally, it’s a different job. It still has the same context of being an engineer. It still has the same company and domain. But the skills are totally different. And no one’s teaching them to you. And I think unfortunately, by nobody’s fault, it’s meant that a lot of people become managers that didn’t want to be, or didn’t realize what the job entailed, or just fundamentally don’t even know how to do a good job. Given the software industry is growing all the time, we’re always in need for managers. But it doesn’t feel like the support network for them is really there. So I thought, could I write something that could at least give people that friendly helping hand through the first 6-12 months of their job?

Henry Suryawirawan: [00:14:45] So in your opinion, do managers need to start as an engineer in the first place? Or anybody as long as they have a good management skills can become an engineering manager?

James Stanier: [00:14:55] That’s a really good question. And I think maybe there’s two sides to it. So I would say you don’t have to be an engineer, for sure. People who are fantastic managers could do a good job. But it really helps to understand how to share and release code. How to work with other engineers. And also unfortunately, there is a respect element as well. If you are an engineer, knowing that you report to someone who has been an engineer really greatly helps. Because you can offer that technical support to them as well as the manager. You can help them think through problems. You can have your past experience to help them through things. So in theory, you don’t have to be an engineer to be an engineering manager. But in practice, really, it’s super helpful for both sides.

Individual Contributor Track [00:15:33]

Henry Suryawirawan: [00:15:33] So I also realized this kind of pattern in the industry like what you mentioned, right? A lot of these superstar engineers or developers, the one who are really, really strong technically. They can go from high level, low level, whatever that level, coming up with great design of scalable system. Once they reach a certain number of years, then people just want to promote them to become a manager. Not knowing probably that person doesn’t want to do that. But the progression, like the benefits, the money and all that only comes by being a manager. Some companies do have progression for individual contributor, but I think many in the industries do not. So how do you see we can solve this kind of problem? A strong individual contributor, but he doesn’t want to do any management role.

James Stanier: [00:16:11] Yeah, it definitely requires change on the company’s part. One of the latest chapters in the book goes through this exercise of defining the two career tracks. So it starts with shared competencies of just very general things that are increasing the time in terms of responsibility and expertise and scale and output. It does make a distinction between having a management track and an IC track. And really, what companies have to realize is that they are two separate jobs. That’s the thing. People can live between them. People also can act as a hybrid. So there are definitely people who can be strong engineers, but also can manage a small team. But it’s really making the distinction. I mean, two things. One is that the higher part of the management track. Really, if you’re doing that job well, and you really are being an excellent manager and you’re managing a large division, for example. You just don’t have the time to do any good programming. And even if you did, what could you do? It’s like, Oh yeah, I’ll do that one point ticket to like, fix that one bug. It’s not the best use of your time.

But conversely as well, to say that, Hey, like not only can we get it from a graduate engineer to a senior engineer, but then what about positions like staff engineer, principal engineer? Really promote those as ways forward as well, going up on the IC track. To say, Hey, there are ways if we frame these roles as less about you just need to write the code. But it’s more about you can build consensus, you can inform design, you can really make impactful engineering decisions that affect the bottom line of the business, you could propose a re-architecture of a system that saves half of the money that you were spending before, or make something twice as fast or more efficient. Those, it’s framing the impact of those roles at the higher end of the IC scale. So, hey, these are the things you should be thinking about.

Getting Oriented Tools [00:17:45]

Henry Suryawirawan: [00:17:45] So, I read your book. It’s very interesting how you structure so-called the big sections. You start with what you call getting oriented as a manager. Which to me sounds like you want to focus as an individual first. You know, like improve yourself, being highly effective and things like that. And I like the things when you mentioned about getting organized. There are four different tools, which I find quite relevant, even though you’re not a manager. Can you cover a little bit, what are those four tools?

James Stanier: [00:18:08] Yeah, sure. A background on the beginning of the book. Actually, when I was thinking about writing it at first, I kept thinking, “Hang on, is this stuff too simple?” This needs to be just like somebody has to go getting things done or like some organization book. But then from experience, I know that one of the real sort of superpowers you can have as a manager is if you were just organized. This is like really basic stuff, like organizing your time and your tasks and your input messages and things. If you can just get a handle on all of that and have a process that sorts through it, then you actually realize how few people do that really well. Because all of a sudden you can reply to people quite quickly. You can put something on your to-do list and then you can actually do it. And then someone says something, and you followed up and like, wow, you actually followed up on that thing I was talking about. And you’re like, “Of course, yeah.”

So there’s these four tools that I talk about. And I’m trying to sort of unpick some of the bad habits that people have. Fundamentally, organization of your time is your calendar. And your calendar is really, really important as a manager. You’ve got limited time. Often you have more meetings as a manager and you just have to be very strict with your time in order to be effective. The next is organizing your tasks. It’s surprising how few people have to-do list. And just as a kind of like cross-section of talking to peers and people that I know. Just having a to-do lists and having a nice, simple routine just to keep it organized, keep it prioritize does incredible things. Not just in terms of you actually being able to execute what you say you’re going to do, but just keeping things out of your brain. There’s only so much working memory that you have as a human, and it’s always taken up by stuff all the time. It’s very easy to get distracted. So, having a routine with a to-do list where you can write things down, forget about them. Fantastic. That really, really aid you.

This next bit is fairly opinionated. Personally, I think that given how many different platforms we’re expected to communicate on from Slack to various DM applications to emails to GitHub to everything. I really vouch for saying route everything through your email inbox. Have email notifications, everything, all routed to one place. And then that’s your canonical view of the world. So you can actually triage it and go from there. And of those three tools, there’s one other, which is just a place to capture information when you’re not near anything else. So this could be if you’re in an office physically. It might be, you just carry a little notebook with your phone around with you, just to jot things down. Or if you’re at home, just a piece of paper on your desk or something, post-it notes. Because you always hear something interesting, that is worth following up or finding out more about. It’s just getting in that habit of like, Oh, I’ll just write that down. And then it’s out in my brain and it’s there. It’s really useful.

Henry Suryawirawan: [00:20:27] So I like the simplicity of these four tools. One of the challenge, of course, like we all know, these days information comes from everywhere. Like you have so many devices, you have so many tools within your work. You have casual conversations. You have so many, maybe newsletter that you read. I think people are sometimes overwhelmed on how they can actually start to organize this. Although it sounds simple, right? Executing it and having a discipline to actually put everything in these four. I think that itself is pretty tough start, I would say. What do you think about that?

James Stanier: [00:20:55] I think it’s true. It is tough, and it does require a lot of self discipline. But I think when you give it a go and I’m not saying that my solution is the best solution, there are other ways in which you could organize things. But when you do have a routine and you do make it a habit where you actually forget about the process. You would just automatically doing these various little cycles every day of gathering information and putting them in one place and then executing through them. You do it without thinking after a while. And actually, you then have all these moments just as I mentioned earlier, where someone will thank you for following up on something because they didn’t expect you to do it. Or someone mentioned something to you last week, and then you actually went and sorted it out for them. You got back to them a week later and they’re like, “Oh wow, you actually did this.” You get all these nice little kind of reinforcing positive behaviors that having these habit loops is a good thing. Actually, I think I would feel really lost if I didn’t have my habit loops now. I find it really, really hard. I’m lost without my to-do list just because I rely on it so much.

Effective Manager [00:21:47]

Henry Suryawirawan: [00:21:47] So as you mentioned, as a manager, most likely you’ll be in meetings, a lot of meetings. Meeting a lot of people, discussing a lot of things. One of the biggest challenge as a junior manager, so to speak right, is to become effective and productive manager without thinking like, Oh, why, do I waste so much of my time going into meetings, talking to people? I don’t produce any code. I don’t write any design doc and things like that. So how do you navigate yourself throughout this chaos and somehow assume productivity that you think are satisfied for you?

James Stanier: [00:22:17] Yeah, that’s a good question. I mean, the initial thing people struggle with is just how you judge your output as an individual contributor is so different. Like as an IC, it’s like, Oh, today’s been great. I pushed three things to production. I worked out what that bug was. I’ve tied off that feature. It’s like all these tangible things are happening where it’s like, I did this stuff and I can point to that stuff and go that was done. And that was done. So, this actually isn’t my idea at all. I wrote about these things from Andy Grove’s book, “High Output Management”. But what he did, which really opened my eyes, was he categorized four different activities, which you can kind of bucket your time into as a manager. One of them is information gathering. The second one is decision making. The third one is nudging. And the fourth one is being a role model. And those four things start to frame how you can be effective even in the most boring meeting ever. Like someone’s invited you to this meeting, like 15 people. You’re like, Oh my God, why am I in this meeting for two hours? It starts, you’re like, this is going to be awful. And you can sit there and you can get frustrated and you can feel you’re clenching your fist, want to be somewhere else. But actually, if you think about it, it’s definitely an information gathering opportunity. You could be looking at that meeting. Hey, is there anything here that’s being said that would be really interesting for my direct reports to hear? Well, maybe some of my peers to hear? You also the opportunity to make decisions as a manager. People will ask you to make a decision. It’s pretty straightforward. The more subtle and interesting thing is nudging. And the way Andy Grove frames nudging is he says that anytime anyone really asks for your opinion is because they probably respect you. They think that you’re knowledgeable and they’d like some input. So you have an opportunity when someone speaks to you to say, “Well, hey, actually I really think we should do this.” And that’s an impactful thing to do. If you classify those kinds of conversations, I’m nudging things in a direction I think positive things to be doing. Then that’s a good use of your time. And then even if you have absolutely no opportunity to impact anything whatsoever, then just to think, how can I act at the moment in a way that is a behavior you’d like other people to emulate it. So, could I be in this terribly frustrating meeting, but listen very attentively, agree with people, offer my opinion, and do things in a really good way that you’d expect others to emulate. And even that is impactful. Because as a manager, especially as like senior manager, if you’re the CTO or the CEO for example, people look to you as a role model to be like, how should we be in this company? What are the values that we embody and how should I act? So, just by being a good human being and doing a good job, you can have a positive impact as well.

Henry Suryawirawan: [00:24:40] So you have this four different buckets of activities, like you said. But again, okay, you maybe categorize your time, where do you spend most of your time? And then what’s the equivalent formula to actually say, okay, if I spend time equally maybe, or maybe one is more than the others. How do you actually come up with the effectiveness or productivity score, so to speak, for manager?

James Stanier: [00:25:01] And again, this one’s lifted from Andy Grove as well. It was one of the things that I originally read at the start of my career. So he says the output of a manager is really the output of the manager’s team plus the output of the organization that they influence. That sounds really straightforward. And you’re like, Okay. Yeah. But that actually is kind of deep. Two things. One of them, how do you, as a manager, best impact the output of your team. And that actually can come up in loads of practical situations. So one thing you see with new engineering managers is like, they’ve got less time because they’re in more meetings. Sometimes they fall into this kind of like janitor role, where it’s like the team is working on this stuff and the managers got less time. So what they’ll do is they would try and still do some IC work, but they’ll do like all the stuff that no one else wants to do. Like, “Oh yeah, yeah. I’ll do that like little ticket or there’s this like really annoying. I’ll do that.” But no, no, no. That’s not your job to like sweep up after everybody. You really should be thinking about the output of the team. Spend time on making sure that the priorities are correct. So the people will work in the most impactful stuff. Maybe make sure that people that need mentorship are getting mentorship so that they can get better. Because that in turn makes the team better. So it’s like framing the activities in that first part of the equation.

And then the other bit, which is talking about the organization that you influence. That is something I wouldn’t naturally think about, but it’s actually really interesting. Building your network at the company that you’re in increases your influence. So that the more people that you know, the more things that you can affect. And that isn’t meant to sound like some kind of like a political, bad thing. It’s more like if you see that things could be better, how can you build a network with other people to help make things better together? The more people that you’re connected to, the wider the organization is that you influenced. Therefore, you have a good reason to network and you get to know lots of people because your influence then spreads and gets bigger. So it’s like focusing on your team, making them impactful. Getting to know more people, building connections, building relationships with people so that you can influence more people. You see it at any company you work for. There’s always a few people who just like, why did I always hear about this person? And like, I always see their work. And like they’re always involved in everything and it’s not because someone is asking them to. It’s just because they’ve really mastered this way of being really helpful, really useful, and being really influential with people.

Delegating Effectively [00:27:06]

Henry Suryawirawan: [00:27:06] So actually this is also a good segue moving into like working with individuals. Because obviously as a manager, like you said, you want to increase the output of your team. And for that, you need to work with individuals. First of all, I think this is one of the key thing as a manager or any kind of leadership, right? How do you delegate effectively? And again, coming from an IC background, I think for someone who has been doing things solo, individually ins and outs from start to end, it’s very hard to actually sometimes delegate to other people. Especially to someone who is more junior or less experienced or someone who don’t even come from the same domain as what he has been doing for many, many months, or many years. So how do you actually be able to delegate to other people well?

James Stanier: [00:27:47] Yeah, that’s a really good question, and I think lots of managers struggle with that. Hence the janitor thing. It’s like, “Oh, I’ll just sweep everything off after you.” So firstly, it’s not a boolean thing of like “I do it or you do it”. That’s the first thing to sort of look at. It’s not either or. It’s actually kind of a spectrum. And it very much depends on the task that you’re delegating. But one end of the spectrum where you don’t delegate anything, so you do it yourself. It makes sense, right? It’s like I’m doing this myself. I’m not delegating anything. And then at the other end of the spectrum, I’m completely delegating this, so you are doing it. And those are the two ends. One thing that’s important is that even if somebody else is doing it, a manager shouldn’t delegate the accountability for that thing to somebody else. Fundamentally, the manager’s still accountable for everything that’s happening. The best way to explain that is like, if it all went wrong, who’s to blame in a way. And I don’t mean this in a negative way. But who does the buck stop with? It’s the manager. They are accountable for getting the team’s work done.

However, what you can delegate is the responsibility for doing the task. That’s the key thing. Because if you delegate away with the accountability, then you basically abdicating saying this isn’t my problem, and that’s not a good thing. Because you’re then not in control. And then it’s a spectrum. So it isn’t just you do it or I do it. Fundamentally, there is a scale, and that scale dictates how often do you check in with people when they’re doing things. How much mentorship they need? How much of your time needs to sit with them while they do it or give them clearer instructions? And it’s the manager’s job effectively for whatever is being done to work out who’s the right person, and then also, where do they sit on that scale? So this a task that is really easy for the senior engineers to do. I can pretty much just hand it over to them and they will just let me know when it’s done. Or actually is that an opportunity for a less senior engineer to learn, and I could delegate it to them. But then I’ll spend more of my time with them because maybe we need to pair program, they would need to look at it together upfront, just talk through it.

The one other thing to unpack from there is there’s this education theory thing with the zone of proximal development, which is quite interesting. The idea is it comes from kids in schools, which is that you should always be trying to teach material to children that’s like just one step outside of their comfort zone. Because there’s this zone of proximal development where people really learn quite quickly with assistance. I mean, we’ve all seen it like when we were in school. If you get given stuff that’s too easy, it’s just like boring. You don’t learn anything. If you get given something that’s too hard, you just get totally lost. But if the teachers are able to kind of identify material to give you, it’s like you built up some scaffolding. And then the thing that you’re learning next, it’s like the next thing on the scaffolding. Then it’s like, “Ah, okay. I get that. I can build on what I know and I can learn that.” And then what you know expands. So as a manager, it’s like identifying things for people to do where it’s kind of things that just challenge them enough that they’re able to learn and they’re interested. And that’s what’s a part of the delegation things. Like how can you give things to people to do that’s interesting that makes them learn the challenges then? Because, in a sort of a silly example. You could have like a senior engineer and a junior engineer. You’re like, okay, well, the senior engineer gets all the hard stuff. The junior engineer gets all the easy stuff. And then you have two people that just get bored and then they don’t really progress. But if you mix it up enough, everyone has a mixture of work. They get challenged. There’s mentorship opportunities. So yeah, it’s a continuum and you have to pick the right place.

Henry Suryawirawan: [00:30:58] So let’s say, imagine you are a manager of a number of people, right? How do you track all these different delegation? Or do you work in a project management style? Or do you keep track, like again, coming back to your to-do lists or calendar? How they actually keep track of each of these delegation and the spectrum which makes it even more variable? Like a lot of these things. How do you actually check in back about the status of the approach, progress, and things like that?

James Stanier: [00:31:22] Yeah. I mean, the way I’ve done it with time is just I’ve tried not to use any additional methods or tooling. Really, it’s kind of just a mindset that is baked into how do you think about how the work is done in your team? Using it just as a check, like when, say, for example, that you’re doing a sprint planning and people are sort of saying, “Oh yeah, well, I think could do that.” Are there ways then that you could talk about who might best work more in order to better improve the output of the team in the future? If you see that there’s a junior engineer about to do something that’s quite difficult, can you as a manager identify that ahead of time? “Oh, Hey, like let’s sit down and do that together to begin with. Let’s pair program that.” Because you can identify that maybe if you sat with them and you gave them some more mentorship then they would progress quicker. So it’s less about having the spreadsheet and like each task to each person, but it’s more just the way that you think about the work’s getting done every day.

One-on-Ones [00:32:10]

Henry Suryawirawan: [00:32:10] So another thing that is quite important for me personally, right? I’ve been also fortunate enough to experience this. There’s a good amount of spectrum of one-on-ones between different manager and its subordinate. So I’ve experienced like a weekly cadence kind of one-on-one. There are times where I don’t have any one-on-one except maybe quarterly or maybe during performance review, or maybe just casual chat during lunch and dinner or whatever team activities. In your book, actually you advocate having one-on-ones quite frequently, if not weekly. So what is the reason, the main motivation behind that?

James Stanier: [00:32:41] That’s a good question. So, I mean, I think it’s less to do with the output of the one-to-one, or like the exact what you’re doing. But for me, it’s a more human, personal reason. In dedicating like some time, every single week with one of your staff, just in fundamental shows that you care. It’s also a safe, private space where you can talk about anything. You will have one-to-one where you don’t even talk about anything super important. But the whole point is you’re giving opportunities to get to know each other better and to build trust. Because that’s the foundation that all the important stuff is built on. I think also having that weekly cadence as well. One, it’s just nice to have habit and routine. Again, you get it in the calendar. You get to in to-do list. You forget about it. It just happens. You don’t have to remember explicitly.

But there’s just so many things when it comes to people. And these can be career development conversations. These can be little frustrations that are building up with time. If all of these things sit for too long, without any attention, they always boil up into something that’s just way bigger than it needs to be. So if you don’t have a one-to-one with your staff at all, and your staff really feels that they’re underpaid, or they’re really frustrated with their job, or they’re really annoyed about their colleague, and they’re just not got an opportunity to talk about it. Then what could be just like you have a little chat about it and it takes 10 minutes, “Is that okay? Yeah, this is much a problem. Don’t worry. We’ll sort it out.” Over a quarter, it could become like, “I’m going to quit my job if that person says that one thing once more.” These things can really bubble up. So, they just give that nice opportunity for someone to just really continually unload their thoughts, and you can unpack how they’re thinking. Going back to the manager productivity thing, like you’ve got loads of opportunities to help make decisions, to gather information, to nudge their thinking about, “Hey, how are you working on that problem?” “So, oh yeah, so I think probably going to store that data in Redis, and like, I think that probably be a good way in order to get like good cache hit rate.” And he’s like, “Yeah, but you know, is that the right way of doing it? And maybe what about this thing?” And it gives you a chance to nudge every decision that they’re making as well and have a lot more impact.

Henry Suryawirawan: [00:34:34] So you mentioned about safe space. That sometimes it’s a bit tricky. Like how do you actually cultivate a safe space during the one-on-one? Like for example, you mentioned about somebody who is not happy about a situation or somebody, and maybe they express that. As a manager, you listen to that. How to build that kind of safe space? Because of course you want to take action about it, right? You don’t want to just be a channel where they just say something, but nothing is being done. So what’s the balance here? How do you create this safe space?

James Stanier: [00:35:01] So I mean, the practical stuff is like making sure that you’re having your one-to-one in private room, or if you’re at home, just in a zoom meeting. Somewhere where you can’t be heard, and fundamentally, both of you can talk in confidence with each other. But one of the things that I talk about in the book is this exercise called contracting, which is quite useful. So usually you do it when you first start managing somebody. It gives you just a bunch of questions to work through as the manager, but also as a direct report to really talk about what does meeting up once a week mean? Like what sort of things are you going to talk about? And what things might you need help with? When might there be some frictions between both of you and your personalities? But then also what’s important is you can say what’s the confidentiality of what we talked about.

And just being able to do that explicitly is really powerful. Because if you’ve explicitly told each other that, “Hey, like everything we talk about in our meetings is totally confidential. And even if you come in here one day and you’re so angry about the way that your colleague constantly does this thing. Honestly, just vent. It’s cool. Like you can vent about it. I’m not going to say anything. It’s safe. It’s all cool.” Being able to like establish those boundaries ahead of time just makes the whole thing much better. And I think it just builds that rapport. A manager can ask their direct report, “Okay. Every week when we meet, you always like, bring up this particular thing that’s happening. There’s this really broken process that’s just infuriating you.” Or like, “You keep saying that the CI build is slow. But you know that you can’t do that much about it. Should we actually do something here? Like, how can I help you?” And I think it’s just always putting yourself forward as I will help you and support you in whatever you’re trying to do. Just let me know how I can do that.

Henry Suryawirawan: [00:36:29] So another challenge as a manager, right? If let’s say we are doing this, one-on-one very, very frequently, you will eat up a lot of your time, more meetings. Meeting everybody either like 30 minutes, one hour, right? If let’s say you reach 20 people under you. That’s like 20 hours gone, just having this one-on-one from the week. So is there any limit on how many a manager should have this one-on-one?

James Stanier: [00:36:51] Yeah. I mean, well, I guess I’ll sort of flip it and say, I think there’s a limit at how many people you can have reporting to you, and still be effective. I’ve read people who’ve got like 50 direct reports. It’s like, really? Do you actually spend good time with each of those 50 people? How many hours a day do you work? So I’ve always said somewhere in between. It depends on the person. I usually cap it as if I had to do everyone’s one-to-one in one day, ideally one day of the week would be what it would take up. And it can depend on, maybe you manage someone, you only need like half an hour a week with them, or maybe you only need to meet once every two weeks. But really, I still try to stick to that weekly hourly cadence. Even if you don’t use the time. And that’s cool if you don’t use the time. But really sticking to managing seven people ish, plus or minus one or two, is about the limit I think, in my experience. Because any more, I don’t think you can do a good enough job of working with each of those people and also maintain the balance of taking part of doing what your team and being a part of the wider department. So if you’ve got 20 people reporting to you, maybe talk to your manager and say, “Hey, can we maybe promote somebody, like another manager?”

Henry Suryawirawan: [00:37:55] So also don’t forget. You are having one-on-ones with your subordinates, but you also should have a one-on-one with your own manager. It’s like a chain on the top. You have more and more one-on-ones down to the bottom.

Projects and Humans Are Hard [00:38:05]

Henry Suryawirawan: [00:38:05] You mentioned a lot of things about individuals, so now let’s go to the bigger picture. There are two things that I noticed you say is hard in the book which are projects and humans. I know like these things might sound easy to figure out. They are hard. But why specifically working with projects and humans are hard? Like maybe you can tell some of the things that you find interesting.

James Stanier: [00:38:26] Yeah, sure. So this chapter has kind of just have a whole bunch of different sort of experiences and anecdotes of just either like behaviors or various things that you see all the time. We all know that estimating software is hard. Well, how long is it going to take to do this? You only really know it when it’s done. I’ll tell you when it’s done. Because then I’ll just tell you how long it took. But that’s not good enough. Doing software project well is difficult. And you could write an entire book on that. But I just wanted to sort of highlight some of the techniques, really, that as a manager you could use to help you with your prioritization. To help you work better with your product owner, product manager. To talk about also the way in which people are motivated. You know, the kind of like, don’t use the whip to get people to do things. Don’t be like, crunch time, let’s get stuff done. You need to motivate people with the carrot instead. Where the people think about their autonomy, their mastery, their purpose, and so on. Like how can you really give people the skills to get interested in what they’re doing? To really want to achieve. And then the work is a side-effect.

Really, those two parts are different scenarios that I think people will experience. And one of the ones in the humans are hard bit is this Mount Stupid concept, which is the article on my website that gets the most hits. I think cause it’s the first hit in Google for Mount Stupid. But it’s just this phenomenon of a combination of impostor syndrome, which I think many people experience. So you have these wonderfully talented people. But because either because they’re new or yet they’re doing something for the first time, they’re not vocal enough, they don’t speak up enough because they feel like an impostor. And then almost the inverse of that problem as well, which is that very senior people who are nowhere near the actual day-to-day getting things done. Think they know everything. And this is horrible combination of these two things at the same time. That means it’s just everything always goes well. You’ve got like the executive who ends up putting the deadline on a project, even though it’s the engineers who should come up with a deadline cause they’re doing the work. But it’s really unpacking a lot of these scenarios in like motivation of people, common things and fallacies in projects. And just trying to give the person reading the book, like these are things you’ll notice. Don’t worry, this is normal. And here are some ways that you can tackle it.

On Project Management [00:40:26]

Henry Suryawirawan: [00:40:26] Any good tips and tricks from all your career experience so far on what maybe is framework strategies that you can use to manage project well? Is it like the agile thing, or is there any other thing?

James Stanier: [00:40:37] I think the best advice I can give is that it depends. I mean, that’s the answer to any complicated question is it depends. I mean, I’ve seen and worked in and work with teams that have used Scrum and it’s worked fine. But they’ve also used Scrum, and it’s worked terribly. I’ve seen people use Kanban brilliantly. I’ve seen them use it terribly. I’ve seen people who literally do no planning at all and do amazing work. And those that do no planning at all and do terrible work. So there’s no answer to this. But really, where it comes from, it’s just like understanding people, understanding the type of work. And then just trying to pick some way of getting things done that fits that particular project and that particular people. I think as soon as you start to force one way at everything, it starts to break.

Henry Suryawirawan: [00:41:19] But I mean I can see these tendencies in any team, any companies. First of all, I don’t know why they seem to like buying like enterprise project management tool from the whole company. Everyone is just using that. Is that such a good idea? Or is it better to have the team actually decide what tools they want to use?

James Stanier: [00:41:36] The latter is better for sure. But you can also sometimes see why people might want everyone to work the same way. Let’s consider this, like you’re the CEO. And you’re like, okay. So I want to really understand what’s going on in the whole software part of the business. So what if everyone uses Jira? And then everyone does two weeks sprints. And everyone reports in the same way. Then surely that means that someone could write some wizard Jira SQL thing. That every two weeks we’ll deliver this amazing dashboard of the burn downs of every team, and what was achieved, and then we can roll that all into the release list. I get that. But does that ever work? I don’t know. And again, it depends. I can see why people do it. And sometimes people spend money on tools, when actually what they should be spending time on is working with the people themselves to say, “How can we work better?”

Letting Go of Control [00:42:24]

Henry Suryawirawan: [00:42:24] It’s very interesting that you say that. Because a lot of managers probably, I mean, I don’t know, maybe the traditional manager mindset is like, they want predictability. The reason why they want all these analytics dashboards and things like that is they want to be able to predict. Which I think, again, coming back to software industry, it’s sometimes difficult to predict. Part of this also is like you mentioned in the book, letting go of control, right? Like probably you predict so much, things will probably happen in the right way anyway, in the end. So how can a manager let go of control? This is I think one tough part, especially if you are still accountable for what people are producing.

James Stanier: [00:42:58] Yeah. It’s a hard one. I mean the general thing that always works is how do I deliver value quickly? If you’re able to coach all of your staff, all of your teams to be like, whatever problem you’re working on, as long as you’re thinking about what’s the highest impact thing that you can do in the shortest space of time, that doesn’t obviously create like a huge mountain of technical debt and horribleness as well. That’s a general good indication of where you should be going. And if you can release frequently, that’s great. That’s like the agile thing at a super high level. Cool.

But the letting go of control thing is interesting. I didn’t use to have to worry about it so much when I was managing one team. But as soon as I started managing multiple teams, so I was managing managers, you get this strange feeling that, “Hang on a second now. If there’s 20 people reporting up into me in some way, how do we even know what’s going on?” And you’re like, “Ah, am I meant to know what’s going on?” Well, maybe. And am I doing a good job? I don’t know. This starts to get really difficult and then you think, okay, well, what does this mean? How does like the CEO of a Fortune 500 company feel when they’ve got 10,000 staff and they don’t know what any of them are already doing? And it’s like, yeah, this is weird. So it’s kind of building on that delegation thing of if you’re able to really accurately define what it is that you’re accountable for, then you’ve got a framework for delegating the responsibility for all of the different parts to different people. And then you can feel comfortable that as long as you’re delegating well to people who are doing good job, then you can feel comfortable with letting go of the control of what’s happening.

You instead just have to set really clear expectations for this is what it means to do a good job. And this is how we want to work together. And go. And then you can just manage your productivity things, managing people, making decisions, gathering information. I’m just being comfortable that it’s okay to not have to know exactly what’s going on. And then what’s really nice actually is that the more that you delegate away, not only does that allow people to grow more, you then free up more of your own time to do stuff that’s even more impactful. My role, for example, I work really closely with the CTO in sort of department wide strategy stuff. So it’s like, look, if all my stuff’s taken care of by my teams, then can I help make our performance review process better? Can I make our process better? Can I spend time getting better benchmarks on pay so that we can make sure that we’re paying people fairly? Like that’s where you can in turn your attention to. It’s like you free up time to do stuff that’s really impactful.

Henry Suryawirawan: [00:45:14] Yeah, for me personally, those things are really, really one of the blind spot of a manager. Especially coming from an individual contributor. Especially as an engineer where you probably have a good input and the good output. And in between, you kind of know like where things go wrong or go right. So as a manager, sometimes we don’t know what’s a good input, what’s a good output. So it’s really tricky and difficult, especially coming from individual contributor. And the letting go here is like, okay, accountable for what people are producing. So I think the IC mindset here is really, really tough. Any tips on how these ICs can learn or can read or whatever that is, to start having this let go mindset?

James Stanier: [00:45:54] Yeah, I think it has to do with just being really clear what a success is. Whatever it is that people are working on. And then not getting so caught up on how people get there. Everyone works in different way. If you’re like super controlling and you’re like right, you know, so we need to build this API. And then as soon as people start working, you say no, no, no, no, no. Like you need to extract to your controllers and your repositories and your middleware. That no, no, no. This way. You need to let go of that. It’s like we need to do this API and it needs to work this way. Work it out, let’s go and do it. Let’s just get on with it and see what happens. Because people will take their own path to the outcomes. So as long as you’ve decided what the outcome is, and it’s clear and how to measure it, then just let people get there their own way. And that’s actually a way better thing because actually you learn more. You find that some of your team do something in a completely different way than you’d expect. “Oh, wow. That’s way better than how I would have done it. This is great.” Letting go is really positive. And as I said, it just reduces your own anxiety over control. And it allows you to spend more of your time on impactful stuff as well.

Balancing Time [00:46:49]

Henry Suryawirawan: [00:46:49] So what kind of balance do you have personally on spending time on the day-to-day stuff versus thinking the things that you can improve? Like what you mentioned, improving comp, improving how you hire people. What kind of balance for a manager they should spend their time?

James Stanier: [00:47:03] I would say what works for me. I can’t say what works for everybody. But usually if I patched together one-to-ones with my direct reports, it’s about a day. I don’t actually do them all in one day. Cause I think I’d probably pass out if I had to do them all back to back. It’s about one day a week is spent on one-to-ones. I’d say maybe half a day to three quarters of a day a week is on various kind of like group meetings. Like the R&D leadership group that meet it’s like an engineering leadership group and various kind of actions and things come out of that. I try and block out, like at least two days’ worth of time in my calendar for doing stuff. And that can change from week to week. If it’s the end of the year, you’re writing performance reviews. It could be that you’re reviewing pull requests. It could be that you’re writing some documents up and designing something new. It could be that you’re writing up something. As you say, like comp plan, process, and so on. So I try and have two days a week that I have for that. And then the rest of it, I try and keep free.

And then it’s just kind of flex time for, okay. Well, I can work with people closely on something. I can ask some questions. I always try once a month meet with some of my peers, just have a one-to-one with my peers. And also just some of the people at other parts of the business that I know provide really interesting information. We can do that in both ways. One of my colleagues heads up all of the measurement of all of our financials and product metrics and the business. So he has an amazing view on revenue and churn. And it’s like, well, if I meet once a month with this guy, he’s telling about what’s going on and it’s like, wow, that’s great. I really understand all these frontline problems with the business and how we’re selling it. So, yeah, it’s a mixture of those things.

Managing in Startup vs Enterprise [00:48:29]

Henry Suryawirawan: [00:48:29] So another classic thing for individuals to think about going to this managerial role, right? There’s this startup versus enterprise. And there are so many startups these days. There are so many also big enterprises. Some startups do turn up into a big enterprise as well. So how should someone actually weigh that their decision, whether to join as a manager in a startup or to join as a manager in enterprise?

James Stanier: [00:48:50] That’s a really good question. Yeah. So again, from my experience, working in a larger enterprise is a great way of, hopefully if it’s a good enterprise, having a whole bunch of support around you from the start. So if you join as an IC, big tech company, you’ll probably have established career tracks. You’ll probably have a good manager already. You’ll be on their team. You’ll have good colleagues. There’s a whole lot of processes and things that already worked out. And hopefully they’re good. Where if you just want to learn and also get compensated well, because if you join a big company, usually they pay higher than startups do. It’s a good place to learn the ropes. However, there are downsides. If you join a very large company, then sometimes progression is difficult. Especially if you want to become a manager and go down the management track. Because you’re one of many, many people. And if it’s a large company, it depends how quick it’s growing, maybe the opportunities won’t come up so much.

But then if you are up for taking a bit more risk, maybe the upside of that risk is a faster personal development, then a startup could be really good. So that’s where I think I was fortunate. I joined the startup. It was very little people. But then as the funding rounds came in and we hired lots of people, suddenly, it was like, okay, we need teams. We need lots of teams. We need managers of those teams. We need managers of managers. And like suddenly all these career progression things where I’ve never done them before. But we were kind of figuring out as we went along. So I got the opportunity to try these things for the first time. If I was probably applying for that job at a larger enterprise, say, “Oh yeah. I want to do Director of Engineering.” And they’re like, “Well, you’ve only got like a couple of years experiences. In the end, we could just hire a more experienced director from somewhere else.” You have a better chance of experiencing those things for the first time in a startup.

Handling Failures [00:50:24]

Henry Suryawirawan: [00:50:24] So another important question as a manager is that not every manager is successful in everything they do, right? Sometimes they will find failures, the project failures, people quitting on them. Good, great people quitting on them. Maybe not to say that they are doing bad stuffs, but it’s just happened like the good people have better opportunities. So how would you advise these managers on handling failures? Or what kind of mindset they should bring in order to, you know, overcome those failures?

James Stanier: [00:50:48] Yeah. Firstly, I never take it personally. And I know that’s hard. Especially if you care a lot about your work and you’re really invested in your work. Especially if you’ve got a really good person in your team, they leave. You can’t help but take it personally. It might just be that they want to do something different. Maybe their partners got a job somewhere else and they’ve got to move. So many reasons why someone might leave. It’s rarely ever about you. So it’s rolling in that kind of letting go of feeling personally responsible for everything. Stuff happens and you just have to deal with it.

Really, if you just always use every opportunity to learn something. So if a project is a complete disaster, are there like three to five things that you now know that if you did it again, would never happen, most probably. And then bring those into the next project. If somebody has left for a particular reason, is there something that you can learn from that departure that can make it better for everybody else? Is it because they were really frustrated about their pay for a year or two years, and they never talked about it? Well, okay. That’s a shame that that happened. But next time, with all of your existing staff, talk about that pay. Ask them, what do they want to earn in the future? What’s the route for them to get there? Make sure that all the past frustrations and failures are things that you can roll into improvements in the future for sure.

3 Tech Lead Wisdom [00:51:55]

Henry Suryawirawan: [00:51:55] So, James, thanks for spending your time. So I have one last question, which I normally ask for all my guests. Would you like to share the three technical leadership wisdom from all your experience, your career for us to learn from?

James Stanier: [00:52:08] I can try. So I thought about this when you asked me before. And three that I came up with. The first one, and I think it’s especially true for management, is that many people experience a gap between their own personality and then their work personality. So like the personality of the manager or the leader, like I got to be this person. I’ve got to pretend to be this person. And that just causes you pain. Realizing that if you are able to get an engineering manager role, that was because you can do it. So just be yourself. You don’t have to pretend to be some manager person or some leader person. Just be you. That’s the best thing you can do. Reduce the gap between your personalities. Cause it’s hard otherwise. That’s the first bit of wisdom. Just as a kind of self awareness thing.

The second thing is, if you find yourself unable to justify something, then always question it. Companies, people, teams, projects, all contain many bad decisions. Rarely because people are being silly, or rarely because they’re doing a bad job. It’s just all the stuff were really complicated. So I think always question things that you don’t understand or don’t make sense. And if you have any kind of bad smells, like if there’s a decision that just seems a bit weird, follow it up, try and find out why. If there’s a piece of infrastructure, you’ve got some big distributed system, like once a week, it goes down for half a second, don’t ignore that. Follow that bad smell. There’s probably something weird that you want to check out. So always kind of like question things and follow your nose.

And then the last thing I think is even though software is really hard and people are really hard, fundamentally, everything can always be solved by first principles, asking questions, and common sense, and working together. I don’t care how hard something is. You can always draw a little box diagram with some arrows that explain the process. And usually it becomes much simpler at that point, and you’re able to talk to people about it. So, nothing is ever as complex as it seems, and that there’s always a way for it.

Henry Suryawirawan: [00:53:51] Thank you so much for sharing those wisdom. So James, for people who would like to know or contact you further, where they can find you?

James Stanier: [00:53:59] Sure. So on Twitter it’s jstanier. That’s j s t a n i e r. I also run theengineeringmanager.com. So it’s all one word, theengineeringmanager. And on there is links to pretty much everything. I try and write every couple of weeks. And there’s a whole bunch of stuff on there, and links to the book, and so on.

Henry Suryawirawan: [00:54:14] I do highly recommend your book. So for people who either like they are engineering manager now, or aspiring to be an engineering manager. So please check out the book. I think it’s really cool. I like it when I read it. It’s really, really fun. And I can put myself in the shoes of the actor, the figure inside the book which is really fun. So thanks again, James, for spending your time. It’s really great. And I wish you good luck in your career.

James Stanier: [00:54:35] Thank you.

– End –