Biography
James Stanier is a Director of Engineering at Shopify. He is also the author of Become an Effective Software Manager and Effective Remote Work. He holds a Ph.D. in computer science and runs theengineeringmanager.com
Links and Mentions
- Become an Effective Software Engineering Manager: How to be the Leader Your Development Team Needs
- Effective Remote Work: For Yourself, Your Team, and Your Company
- Progression/growth frameworks at https://progression.fyi/ and the Brandwatch version
- Articles by James: Contracting and Don’t make yourself redundant
- High-Output Management by Andrew S Grove
- James’ socials: Twitter, LinkedIn,
Transcript
Patrick Kua: Welcome to the Managing Managers podcast. I’m your host, Patrick Kua, founder of the Tech Lead Academy and curator of the newsletter for leaders in tech, Level Up. In this podcast, I’m chatting with senior engineering managers, directors, VPs of engineering and others who have walked the path of managing other managers, where we will uncover some great stories and lessons learnt.
Let’s get started.
Patrick Kua: Hi everyone. I’m very excited to be joined by James Stanier today. James Stanier is a Director of Engineering at Shopify. He’s also the author of Become an Effective Software Manager and Effective Remote Work. He holds a PhH in computer science and runs the engineeringmanager.com. Welcome James.
James Stanier: Hey, thanks for having me. Yeah, yeah. I always forget I did a PhD. It was a long time ago now.
Patrick Kua: Study is a long time ago for a lot of us I think. I’m really excited to be here because I think our our interests align quite well. You’ve done a lot to help people move from going from IC or individual contributor to engineering managers. And then the next hump which you’ve already gone through which is the transition to managing other managers and so I’m very excited to have you here today.
James Stanier: Yeah, thanks, it’s an interesting topic to get into and I think when I was first starting out in management, there wasn’t any material at all and now I think we’re in a pretty good place for managers. But we’re not in a good place for managing managers. So it’s like the next the next literature hump I think as well.
Patrick Kua: Absolutely and looking forward to exploring some of your ideas. Before we begin, let’s talk a little bit about your background. I know that you spent a lot of time at Brandwatch and grew through lots of different roles. So. Can you tell us about your leadership journey there and maybe the different transitions that you had?
James Stanier: Yeah, sure. So you know when I joined brandwatch, it was a small startup. I think I was employee 20 something. We’d had a seed round but in terms of the company, it was really just a clump of engineers with no structure, just building stuff. You know this was before we were really any, well, anything as a success as we were. I think I got into that startup. I’d like to say it was all planned but it wasn’t. I did do a PhD and I was working in compilers. I loved compilers. When I came out the other end I really wanted to go into academia. It was around about the time of the financial crisis. So all the funding had dried up for for academic positions. So it was more of a necessity to get money, because I needed to pay rent and eat food, rather than some pre-planned destination. But I did join this small company and the reason that I joined this startup at seed round was because a lot of people who I actually taught at the university, when I was doing my PhD had gone on to to do their first job there and it just seemed really exciting. It was a really interesting product, doing lots of big data web scraping, social media stuff for the first time. This was ten years ago and I just gave it a shot. It was down the road quite literally. Walking down the road to this company so it was super convenient.
Patrick Kua: A great commute.
James Stanier: Ye a great commute. And you know back back in the day. So a lot of it was was out of necessity that I joined this company but it just so happened that it was a fantastic place to start. Not long after I joined you know we went through into a Series A round and after Series A, we had B and C, so raising VC capital and all of this meant that the company grew very very quickly. As you probably know, and as your listeners probably know, if you want to really learn 10 years in 1 year over and over again, you go to an early stage startup that’s growing very very quickly. That’s where I progressed through these different job roles. At the beginning we didn’t have very San Francisco facing job titles, which was something I worked on a lot later on, to make sure the careers track lined up. But that was my first management gig. It was also my first managing manager’s gig. As the company grew expressing my intent, obviously startups can’t pay huge amounts of money, so you also have that opportunity if you’re there and you’re a trusted employee you do get a chance to step into these roles and have a shot at them and that was pretty much the fundamental reason that I got to do it.
Patrick Kua: Amazing. Yeah. Absolutely a wonderful career growth and totally agree in terms of that startup and high growth. So much learning opportunity and from your experiences you spent some time doing engineering management, which turned into that book, Become an Effective Software Manager. And then at some point you ended up managing other managers. So what was that transition pivot point and what was that like for you?
James Stanier: I mean the first time I led a team, a single team of ICs, I think there were only 2 or 3 teams in the whole company.I mean we weren’t very big. So that was the chance I got to build that trust and to prove that I could do the job. As you mentioned about the book,like the reason that started to develop as the blog at the time and then later, the book, was just the material wasn’t really there. So we were all learning this stuff for the first time. And then I think history repeated itself as we went from Series A to Series B. We got this very very big Series B round and it’s like, okay well, part of this is we’ll double or maybe even triple. I can’t remember exactly but significantly grow the engineering department size. I think the same thing is true. You’re adding an extra layer into the department. You’re chopping things up by responsibility areas or product areas. And I just pretty much put my hand up and said, “Hey. I’d I would love to do this. Obviously, I respect if you want to hire people externally.” But, at the time, and this was pre-remote, down in Brighton, which is on the south coast of England. We weren’t in London. So I think in terms of the talent that we could persuade to relocate and come down to Brighton or commute to Brighton, for less money than people would get in London, was not the most attractive proposition. So it was a great great opportunity for people coming up in the ranks like myself. To say, “Hey, I’d love to do this. Let me have a go. At least see how I can do.” So that’s how that turned out.
It was a team of 4 leads reporting to me when it got to full size. So each of those leads had a team of 8 or so and then I also had senior ICs as well, as right hand roles.
Patrick Kua: Got it. Awesome and then let’s talk about that transition a little bit more. By that time when you put up your hand, how long had you been an engineering manager for and then when you stepped in what did that change for you?
James Stanier: Yeah, good question. So I think I’d been at the company maybe for about 4 years by the time that happened. I mean each 2 year period I found at Brandwatch and the reason I stayed there for so long is that each couple of years was very very different from before because of various things that were going with scale and pivots and acquisitions and all sorts of stuff. So it was always very very interesting. I could always tell that narrative externally of, “Look. Yes, it may be above average time spent at a company for many people. But you can bucket it into these like 6 or 7 stages which were very very different.” But yeah, going back to your question, so I think I was there for a year and a half before I managed anybody. That’s about when the team structure started. And then I did that role for probably another 2. And that bridges the Series A to Series B gap that we had and we raised that money at Series B and then the hiring pipeline became just stuffed full of people and we needed to grow. Grow more areas than teams. I think I must have been there about four years, four and a half years by the time I stepped into that. So I felt that I had the the gig down pretty well. In terms of provably demonstrating that I could do management of ICs. And I think I’d had enough opportunities because the size of the company and also being closer to the exec there because we were small, that they could trust me with the elevated responsibility, privilege, access to information, I think which is very very important as you start to go up the org chart.
Patrick Kua: Yeah, amazing., And then when you transitioned, I mean it’s great that you had that opportunity. You’d been studying I guess like management at a team level for a while to do that job really well, how did you start responding to these new responsibilities or scope? Like what was your reaction to oh now I’m allowed to do this, but what does that mean?
James Stanier: Ye I mean the reaction is that there isn’t really a list of things that you should be doing. I think that’s the thing you start to find when you get to the managing manager’s level. I think the the blueprint of managing one team is pretty well locked down. You know, coach your coach individuals. Ship the things you need to ship. Prioritize work. All of that is quite tangible. And even though every company is quite different, you can probably fit that model to most single teams. But managing managers is different, because you may have different levels of experience with your leads that are reporting to you. Some maybe need a lot of hands on coaching, because they’re doing it for the first time. Others may have just as much experience as you have in that role, and you don’t really need to have that high touch with them. So I think that’s where you start to firstly work out exactly what your leads and your reports need. Because I think it becomes very different because 1 person being hands-on with them is super useful. The other person you’re meddling and getting in the way.
So you have to really understand for each team, each person what they need and establish those contracts and boundaries between each of them and then I think, additionally, it’s where you start to find yourself getting more detached from the hands-on code. Now I still think you should absolutely be technically involved. Architectural decisions. Technical direction. All that stuff. Yes. 100%. But when you begin to have multiple teams, which sometimes, are working on quite different things, it’s odd to say, want to still be very hands on with what one team is doing but then not be hands on at all with another. I think that’s where you start to need to think about, OK, well if I have a given week, 70% of my time is already allocated for. Then there’s that 30% self-directed time. You need to start making very conscious choices about how am I actually going to spend that time for the good of my teams and for the good of the company and for the good of my manager. And that’s where it becomes quite fuzzy I think.
Patrick Kua: Yeah, Amazing. Let’s go to that. As you transitioned into that. You talked about that contracting and try to work out what your leads need from you? When you stepped into that role leading other people were you starting to manage your previous peers or how did that work and what did you have to do contracting wise to establish boundaries?
James Stanier: Yeah, good question. I think one may have been a previous peer, for sure. I think we had one person who was an external hire. I think, yeah, I mean personally I never found it too difficult to transition into the whole, being someone’s boss thing. I mean that exercise that I wrote about on my blog and in my book called contracting, which is just a simple set of questions that you start a new relationship with somebody to just say, “Hey. What do you really need from me? What do I really need from you? How do we know that this is working out? How do we know that it’s not working out? And just having all of that conversation upfront I think really helps set the foundation of that relationship. For example, managing a peer, who used to be a peer, you already know them really well. You already know their strengths. You may know their weaknesses but you know that they have all the context that they need. So, in this particular individual example, it was just, “Hey. I fully trust you. I’ve worked with you before. You’re great. I’m here. If you need me, let’s work out what we need to keep each other updated on. Let’s work out how we can you know meet together every week and and work together every week in a way that’s really productive for both of us.”
But fundamentally you can say, right, of all the effort I need to spend, you’re on the the low end of the list. And that’s good because actually being able to delegate fully to people and trust people fully means you can over-index on the errors that need you more. You’ve only got so much time. And you have to really understand in that contract with everybody who reports to you, what needs an outsized amount of your input and what needs a lower amount of your input.
Patrick Kua: Great. If I understand it right, one of the other people that you were managing was a new hire. Were you involved in their hiring process or was that already done by the time that you transitioned into your role?
James Stanier: Good questions. So I think around about the time that we hired lots and lots of people, I think that was going back to some of your earlier questions where I started to get exposed to the more department-wide things or company-wide things. If you’re a small company and you’ve word of mouth hired or hired people you recommend in the very early days, you don’t know how to have a hiring process that works really well. You don’t know how to do good job descriptions. You don’t know how to structure the interviews. So we came up with all of that stuff. So a lot of people who are coming in at Series B stage were people that are gone through the pipeline that we come up with for the first time. Nothing was particularly original.
It was lots of reading around and seeing what other companies do. Taking the best bits that work for us and ignoring the bits that don’t. But the way that we structured our hiring was quite high touch in terms of the amount of time that we got to really understand what people wanted. Because certainly people who are working for a startup you have to be really realistic with the upside and the downside of of this position and we really wanted to over-index on people who wanted to learn, who wanted to be experiencing new things for the first time and we could offer as much of that as people wanted. But if you have people coming in who maybe you’ve worked at larger roles or roles where they’ve earned loads of money and they’re coming in with super hard expectations on what they earn. We’re a startup. We can’t offer all of these things. It gave us a chance to really get the right people in who who fit for us at the time.
Patrick Kua: That’s really great. And I can imagine in that rapid growth environment, you’re doing a lot of hiring. Doing a lot of onboarding. A lot of individual contributors. But I guess you’re not doing as many management hires yet. So did you have to build out that process and thinking about onboarding for engineering managers, and is that something that was already there or did you have to improve that?
James Stanier: We had a tiny proportion of people join externally into engineering management roles. It was only when we got bigger that we, well it was through acquisition really, that we got senior leaders. I think our success in hiring engineering managers from the market when we were small was just very very very low and poor. We couldn’t offer enough money. Where we were located, it was hard to get people to also want to almost reverse commute outside of the capital, where they had people with the experience to come down to a small town to work with us. So really, we hired like one external engineering manager who was great. Who was someone looking to get more autonomy to learn more things. To be exposed to more of the stuff at a startup and where you can learn rather than necessarily earn. Yet most of our managers came from within following the same path that I did. You look for people with potential and you go, hey, give it a go I mean.
I trust you. You trust me. If you want to do it for a while, if it doesn’t work out, there’s a safety net of you just going back to what you’re doing before. There’s no hard feelings. So we always offered that get out clause of, hey, try it for six months. See how it works out. If it doesn’t work out, you’re not exiting the company. You just go back to being an IC again. It’s cool.
Patrick Kua: Love it. I Love that reversibility and that experimentation and it really fits that startup learning experience. Of if you like, it continue. Otherwise, yeah, go back to being an individual contributor and that’s perfectly fine too. I heard you say spotting potential. What would you look for for potential managers?
James Stanier: You often observe it in potential managers where there’s a real pragmatism between engineering quality, speed to market, how you talk to people, interact with people who are technical, non-technical. There’s a lot of the soft skill side. Which I think if you’re if you’re progressing people from within you get a lot of opportunity to observe. And that’s why hiring managers is really hard because often in the interview process, you can’t observe all of that. You can maybe see where somebody’s worked and maybe get some references. But if you’re progressing ICs from within into management roles, you already have built trust. You understand that they’re respectful, good people, who you could give them a team and you know that those people will be treated well and and they’ll be coached and progressed well. You’re also looking for people who are in it for the right reason and I think the career tracks by the time that I left the company were in a good place where we really did have dual career tracks that compensated pretty much the same. Almost I think the same for for that journey. But in the early days, there was still that stigma, in a lot of the industry, and especially more in Europe as well than America, where beyond a certain amount of seniority, the only way that if you really wanted to earn more money, was you become a manager. I think that forced people into that role sometimes for the wrong reasons so going back to your question which was spotting potential, you get to observe people doing that for the right reasons even as part of their IC role. And then if they say that they want to move into management, it’s like well, yeah, I can see that you can already do this.
Patrick Kua: Ye amazing. That’s really great. You’re right with that touch point. You get more of those experiences and observations that you can see if they’re moving in that direction of what you think they need to be to be a good manager. Absolutely. You talked about correcting the career ladder. That feels like a good to-do for somebody who’s not just a manager of a team. So can you explain what triggered that and what you had before what you ended up with?
James Stanier: Yeah, so I think in the early days. Well, to begin, with we, didn’t really have one which was part of the problem. So I think going through the exercise of trying to define your career ladder because I think when you’re growing really really quickly as a startup even though you’re aware that at a very big tech company, you’ll have things like Principal Engineers or Distinguished Engineers or these types really exist when there are many many thousands of people. It’s good to take that and have it as a blueprint because getting it right early on is super important. In order to ensure that you can hire people at the right level. You compensate people at the right level. That it’s very clear how you progress. Which is often, if anyone’s ever been a manager and never had career tracks and they’re staff are like, “How do I get to the next level? I don’t even know what the levels are?” Having all of that early and in place for something I was very fond of. I think the Brandwatch career tracks are still on http://progression.fyi. I think they’re still attributed to me. Getting that early on where you can really see how the management progression works and how the IC progression works and also in a way visually where both of them are side by side so you can say okay, an IC at this level of seniority is equivalent to a manager at this level of seniority. That also helps you set that compensation equality as well, which is dead important. What’s also nice about that as well, is that the reality is, as you progress in management and you progressing individual contributor, there’s a huge amount of overlap in the responsibilities and also the way you expect somebody to work and present themselves and interact with the company. So being able to really see that that’s expected of everybody regardless of what your role is, it was really good ahead of time.
Patrick Kua: Amazing! And this building a career ladder or growth ladder, that’s something that a lot of Directors or Heads Of end up doing, particularly startup land, where, as you say, having something is better than nothing. If you were to think about the timeline, when you thought, okay, we need this, and by the time you ended up with version one what was that timeframe for you and how did you go about approaching it?
James Stanier: So it was round about when I moved into the Managing Manager’s role, and as you as you indicated in our in our prep, I had this job title of Head of Analytics, for a while which I remember getting that job title. I don’t like that job title. Why don’t I like that? And there’s a couple of reasons, I was like, one, analytics was the name of our product, but presenting that externally it makes it feel like I’m a data engineer type person or or marketing type person. That was not true and then also the the Head Of which was more of a european flavour job title, didn’t really map to the kinds of companies that I looked at for inspiration where it went the usual Engineering Manager, Senior Engineering Manager, Director, VP. I just looked at that went why, what’s happened here, and I think that was when it was an indicator that we hadn’t really thought about it properly. I think the way that I also observe that was I was thinking that there’s lots of up and coming people in our industry that were were joining Brandwatch and accelerating their careers and I was always thinking of what’s next for them. If we don’t get things like progression and job titles correct then when these folks go out onto the market, in hopefully many years from when they joined, people are going to look at their CVs and almost misclassify what they’re doing before they’ve even got a chance to get in the door to an interview. So, that’s when I was starting to look at what what did Google do? What did Facebook do at the time? What were Twitter doing? And seeing that, yes, there was some commonality in how they did IC progression and management progression and we should probably do that as well because I want the interface between our job titles and industry job titles to be the same and also there’s already a lot of material out there in that format, that we can then bring in and copy.
Patrick Kua: Yeah, amazing. And then time frame wise, how long did it take you as a project if you think about it?
James Stanier: I think I wrote it in like a Google sheet in maybe a few days and then it was one of those things where we you know we were still small enough at the time where I just sent it around my my seniors and and my peers and said, “Does this seem reasonable?” and it was like, “Yeah, actually that does seem a lot more reasonable,” and then I think we didn’t change everybody’s job title immediately. But once we got to see that this was a really useful reference and people keep opening it and we specified it in similar to how it is online at the moment where for every level you have the the role, the seniority on one axis and then you have the skill sets on the other axis. So things like communication, leadership and technical contribution and then you can create a matrix and go, ok, so if someone is a VP of engineering what does that mean for their communication skills? What does it mean for their influence? You can map that grid out and people found that super useful and people just picked it up. They would go into conversations with their managers and go, “Where am I on this thing?” and they’d point, and it would help people frame the the next steps. So it became quite organic after that. It was like this thing just started existing and by the time that we went into the next funding round and we did the next reorg for larger size we apply the new job titles.
Patrick Kua: Amazing. So it sounds like the usefulness people could see it immediately and therefore there wasn’t really that much of a debate around what exactly goes where and which level.
James Stanier: It takes the pressure off managers to have to come up with all of this themselves because if you have a very high growth, and very persuasive direct report, who’s always like, “What’s next? What’s next? How do I get to the next level?” And you don’t have these tools, as a manager it can just become incredibly stressful for you because you don’t have any answers but having some templates like that. Also do it in such a way that people can discuss and debate and you can add revisions and you can go to new versions of it I think opens up that career progression discussion to everybody because they can all contribute in as well.
Patrick Kua: Amazing. So speaking of high-growth you’ve jumped to another high-growth company. Shopify. So let’s understand a little bit of a snapshot about what your current role looks like so can you describe a little bit about your current scope and maybe what’s similar or different from your experience of managing other managers?
James Stanier: Yeah, good question. So I’ve been at Shopify almost two years now. Just coming up to 2 years anniversary.
Patrick Kua: Congratulations.
James Stanier: Thanks very much. Still here. So the area that I lead is called core engage. Tthere’s an area of Shopify called core which is about one a half thousand engineers which is really the whole core of Shopify. It’s Shopify. Then this is broken up into 10 different areas which have different names. Our area is called engage and what engages all about it’s based on the engagement of customers to merchants. So we do the whole marketing tools and measurement stuff. It’s a broad span between lots of data ingests. So events that are happening on storefronts and linking them to customers and understanding and giving merchants the tools to see how people are interacting with their stores but also built on top of all the the data and the identity graph that we build. There’s a lot of smaller products which are finding their product market fit at different sizes which is what makes it quite interesting. As well as with the data to do with marketing and ad spend and attribution built on top of that, we also have our marketing tools suite. So Shopify email which is like Mailchimp but internal. Shopify inbox which is like Intercom but internal and each of these products is at different phases of growth. With lots of different UX and and lots of different challenges in terms of how we scale them, how we get revenue from them and how we fundamentally help merchants go from acquiring customers to getting repeat sales. It’s a really nice lifecycle and it it’s a lot of different engineering disciplines which makes you quite fun.
Patrick Kua: Amazing. So it sounds like a very large group and you know, probably a small part of Shopify still considering how big the overall organization is. How do you keep on track of all the things going on within your teams and then with your peers because even within the core I understood there was 10 different groups. So that’s like 10 different peers then right?
James Stanier: Yeah, it’s hard, is the short answer. So I think in terms of our group it fluctuates with time. I mean we do quite proactively reallocate people, maybe once a year, sometimes twice a year. To make sure we’ve got the right people working on the strategic things that Shopify wants. So the group has fluctuated between 140 to 200 engineers around about the last year or so. In terms of keeping track of what’s going on, it’s a lot of asynchronous work that goes on behind the scenes. I’ve shown screenshots of this at talks before but we have like an internal wiki+ I’d call it, called the vault. That’s Shopify’s internal knowledge base. Everyone has access to it regardless of your role. All of our projects, our projects updates, all of our artifacts like design documents and decision logs are all kept in the system. For example I can go into this. I can click on engage which is my area and it will show me all the projects that are different stages from proposal to prototype and so on. It builds a dashboard for me to to work off of which is incredibly useful. That’s the administrative side. There’s also the harder side which is the connection with peers connection with direct reports, skip levels. That’s where there’s less prescriptive action as how to do it.
Personally? 1-1s weekly with my directs. The seniority of my directs varies. I’ve got one person who’s a director as well. I’ve got senior engineering managers. I’ve also got senior ICs like a principal engineer and staff engineers. We meet once a week. In terms of general chat we have Slack channels for all ourselves where I try and keep interesting discussions going, to some level of success. Then within my own peers, who are all directors or VPs, who have similarish sized areas, we meet once a week as well. But we also have a slack channel where we share things. But as you rightly pointed out the sheer breadth of things that is going on makes it very very difficult to really focus in on what’s important. So I think I don’t have any concrete tips as to how to deal with that. But I think you have to, in my mind, operate with my department in mind, as what should I input an output that would be beneficial to my department. Try my best to filter the things out that I don’t want to listen to because they’re not super important and then overindex on the things that I think are super important. Those are either based on the KPIs that we’re tracking towards the mission that we’re on or things I think that will be really important in the future or for next year.
Patrick Kua: Amazing. You talked about 1-1s and that’s actually a topic that you spent quite a bit of time in your book about. Do you have any reflections on are there differences about 1-1s with managers versus 1-1s with individual contributors that you manage? Do the topics differ or how would you describe the differences if there are any between 1-1s?
James Stanier: Yeah, they are different. I mean the the format’s the same. The general practice of doing them is the same. But I think that the the content is very varied. This is where I try and tune it to the individual as much as possible. For example, some of my reports are always super interested in strategy discussions like where we’re going in the next six months to a year, to bring their ideas to the table to, debate them. I make sure that I spend time with those people talking about those things I mean it’s super beneficial for me as well. But then I also know I have other directs who aren’t as interested in that so I tend to underindex on that, focus more on what they’re working on. What are some of the technical challenges? Screen share me a demo of what you’re working on. Let’s have a look at some of the code. It depends on the person. I think really where it gets trickier with managing managers as every manager knows, for themselves, because it’s almost like a recursive thing here, there is no right way to do your job. I don’t really have any particular direction to give anybody so you do put your coaching hat on quite a lot.
You just probe. Ask questions. Try and expose what are some of the things that you’re thinking about? What are some of the problems that you’re digesting? Can I get you to surface them to me? So then we can talk through them together and maybe that can help unblocks some thinking. I think none of my 1-1s now are at all status updatey. I think that’s partially because of the seniority of the people that report to me. But I think also because so much of is available async at Shopify, like all the project tracking, all the information is just there, we don’t really need to spend a lot of time talking about it. It depends on the person. Tailor it to the person. Really, I think, that it’s mostly about me every week having an opportunity to increase the trust that I have between me and that person, as opposed to necessarily needing to have that time to make a decision or tell them to do something.
Patrick Kua: Yeah, absolutely. I love that you talk about putting your coaching hat on. Because these are highly empowered managers who are dealing with things. Do you have any managers that are managing areas where you have no background in that technology or field?
James Stanier: Yeah. So that that’s been quite interesting. So earlier I was describing the different parts of engage. The areas where we are building products like Shopify inbox and email and forms. That’s where I feel fairly comfortable. I’ve done Product Engineering type stuff before. We’ve launched products to market my previous company. Product market fit. Scaling. I’m cool with that. I have done that. There’s an area that reports to me which is all to do with ad attribution, identity matching, customer behavior, events, data. I’d never done anything like that before. So, really the first year or so managing that area, it was more about I want to spend time with you to really understand it better. Because fundamentally if I’m responsible for what is happening in this area and I’m accountable, I have to really understand it. Because if there’s some tiebreaker decision that then escalates to me I have to really have the tools to to make that tiebreaker decision or to even disagree with you because it’s just very very hard. So I spent a lot of time with that team understanding what they did.
One of the techniques I used for doing that. Wwhich was a technique I used for every team really was that in our team documentation, there wasn’t a huge amount of of specific onboarding material. So selfishly when I onboarded and started to learn all these different teams, I said, hey, can you take me through? We’ll record a video. Half an hour. You share your screen. We’ll start with the product. We’ll look at it the product itself. We’ll click through it and then go deeper. Do an architecture diagram. Show me what’s happening as you’re clicking around and doing these things and seeing these charts or doing that action. And then I’ll record it and I’ll embed it into each team page as to our little Safari around your area and learning what you do. Even though that was a way of potentially giving back to everybody else who was onboarding that there’s a video actually it was completely for me and and that was my shortcut.
Patrick Kua: It was a win win.
James Stanier
Yeah. Win win. That was that was my secret source for getting to know what people did. That area I still am not an expert. I still rely very heavily on my products and engineering counterparts there to help. Sometimes help me understand the nuances but I’m getting much better.
Patrick Kua: Yeah, no I mean it’s completely understandable with the number of teams and scope that you’re dealing with. There’s going to be those areas. What it sounds like it’s like you know what you don’t know, and you spent more time there trying to get comfortable with those unknowns. To ask the right questions and to be able to understand where that risk profile is through the onboarding and spending more time with the teams.
James Stanier: Yeah, absolutely. I think you know it’s good to be able to go deep when you need to go deep. I try my best to build up enough of the fundamentals where hopefully if I had to review a pull request or I had to make an architectural decision I would be able to do that with some amount of competence.
Patrick Kua: Yeah, do you actually write any code in your role?
James Stanier: Not anything that goes into production. I do mess about with things for prototyping for myself. I mean last week we had our our hack days which is something we do twice a year. So we have the Shopify editions launch which is like our big splash of feature updates. Then the three days after that are called hack days where everyone joins a hack project and either build something or explore something. So I did actually do three days of programming last week which was quite fun.
Patrick Kua: Amazing
James Stanier: But that’s not =a regular recurrence.
Patrick Kua: Special times of the year. Amazing. One of the other things you talked about with 1-1s were skip 1-1s. How do you like to run them? Do you have times where people do things or do you reach out specifically? What’s your general philosophy or approach to skip 1-1s?
James Stanier: I do them monthly and I try my best not to move them. I do get around everybody. I mean the nice thing is that everyone who is a skip level is still a fairly experienced manager or individual contributor. In terms of needing to really prepare or steer I don’t have to. I pretty much just, we have time booked in every month and I’ll just turn up and pretty much say, “Hey, how you doing? What’ve you been working on. Let’s talk about it,” and just open the floor really for letting them talk about anything that’s on their mind to discuss. Anthing that they’re worried about. Maybe they want some input on. Because I find that you know sometimes if you come into skips with too much of an agenda or too much of a steer, even though I don’t feel like it that the seniority can overwhelm someone at a skip level sometimes like I’ve got the director or the VP having a meeting with me. And it’s like they’re just a human being. They’re just trying to get to know me a bit more.
Patrick Kua: But what do they want?
James Stanier: Yeah, exactly. What are they trying to find out that I don’t know about? So I just leave it very very open. Just take a healthy interest in what they’re doing, what they’re building. Some of the things that are on their mind. Sometimes bring up some of the future roadmap or future strategic thinking that we’re thinking about, just to get opinions and just to say, really, you can trust me. I’m here. My door’s open. In theory. Remotely. I’m always just a slack message away. I think that’s the outcome really.
Patrick Kua: Got it. So if I understand right then you have a regular cadence with the same people for skips. How big is that circle of skip people that you keep?
James Stanier: It’s about 15, or 15 to 20, I think. But I just do half hours.
Patrick Kua: Got it. And then do you do any other ad hoc skips.
James Stanier: Occasionally. Occasionally. Like if anyone suggests that someone might benefit from my time and I do ask. Then I’ll happily reach out. I do have to be mindful though that sometimes if I haven’t spent a lot of time talking to somebody who isn’t a skip, and all of a sudden, a meeting turns up in the calendar, that’s not a cool thing. People find that scary sometimes. The flip side of that is we are a fairly asynchronous company and I do hang out in as many stack channels as I can and you know once a week just peel through and and just get involved in the conversation. So I’m not unavailable unless you have a meeting with me. I try and turn up in as many places in a open and and lighthearted way as I can. Because then I think it’s less about needing lots of meetings with people and it’s more that they know that I’m there if they need me.
Patrick Kua: Amazing. Let’s turn to some of your more recent writings because you’ve also started to publish on the engineeringmanager.com more things about managing managers. One of the things that you touched upon was managing through interfaces. So we use this metaphor in code interfaces. So what does that look like for you as a director?
James Stanier: Yeah, so the the code interface idea was really just defining what is it that you really need from people that report to you? What do they need from you? And then you can obfuscate away all the things that you don’t need to worry about and just focus on what’s important. As somebody managing managers, there’s a few parts of that interface that are really important. Like number one it is really about building trust. Fortunately everyone who reports to me is really good, pretty senior, so I don’t have to worry about the fundamentals too much. So it’s really just building that trust every week and and making sure that there’s never any surprises. Both in terms of things that are happening that I don’t know about but also projects being late.
I really like the culture of no surprises. It’s like, let’s just tell each other what’s going on all the time. So that’s number one. I think the other part is just making sure that you know I am accountable, as are pretty much all the directors for a bunch of business metrics that drive Shopify and and drive success for merchants. So making sure that everything that we are doing in terms of our prioritization, what we’re saying no to, is always in a line with that. So I always like to be able to talk about what we’re doing now. What we’re doing next. Being able to healthily debate whether that is the right thing to do or isn’t the right thing to do. I think that’s something I really benefit from as well. I always like someone trying to pick holes in what I’m thinking about because sometimes it’s easy to convince yourself that something is right but harder to convince other people and and that extra level of scrutiny is good.
And senior ICs as well. My interface with them is that, look, I’m not here to tell you what to do. You know what you’re doing. You’re a self-directed person but really I’m here to help leverage any ideas that you have. To get consensus around where we should be going. To make sure that we are not overlapping other areas of the company when we’re proposing new things. Because there is a lot of overlap at Shopify and sometimes some areas could easily belong to 3 different parts of the company. Often you have to catch things as they’re coming along. Go, hey, we should definitely do this, but we should definitely also talk to these people and I think that’s something I can bring to the table there.
Patrick Kua: Amazing. Excellent. Another article that you recently wrote was the don’t make yourself redundant. So why? not as a manager or manager and what are the dangers?
James Stanier: Um, yeah. So it’s not like literally redundant. But it came originally from Andy Grove’s High Output Management. Where you’ve got one team. The team grows really big. Say you’ve got ICs. You keep hiring. You end up with like 15 ICs or something. Now you want to split the team. Makes sense. Too many people. And maybe you’re working on multiple things. So let’s say the company is growing. They’ve got some headcount. You might think, okay, we should divide this team into 2 teams and then what do you do? I think sometimes, some people think this is a great opportunity for me to manage managers. I will get 2 leads underneath me. Each of those leads runs one of the teams. But then the question is what do you actually do? And I think keeping busy enough in the details of what’s going on underneath you is not a bug. It’s actually really really healthy. In the book he suggests that if you’re going to split the team get one manager reporting to you managing one of the teams and have the other team report to you because then you are still less in the weeds. But you’re still just as busy and just as useful. I think, we have seen an industry over the last year, especially as there’s been lots of reductions in force that the amount of management layers has been something that’s been reported on quite a lot. I think sometimes during growth phases, you’re trying to shape an org for a future state and then you end up with lots of layers. Lots of managers. And very easily and without any bad intentions. You can just end up with people, who, it’s not even very clear what they do, other than just a layer. A translation layer in the org chart between some area and another area. I think it’s just really important that people aren’t striving to become as detached from the ground as possible as they progress. You always want to make sure that you’ve got enough skin in the game of what your org is doing before you detach. If you think about it when you’re hiring and you bring on 3 or 4 managers underneath you for the future, you then need to hire like 50 people to become completely saturated. So I think in the past over the growth phases, we have made too many managers almost redundant in their roles by growing too quickly.
Patrick Kua: Yeah, absolutely I can definitely recount that. And that idea of maybe not the manager first but maybe a bigger team. Okay, you’re going to overwhelm a manager but the reverse problem is often a lot more questionable about a manager about what are they actually doing right?
James Stanier: Yeah, and it’s a dangerous position. You have to also hedge against, well what happens in the future if the company that you work for is going to decrease in size? Well you look at all the individual contributors. You’re like, well everyone is really busy and then you look at this management layer and you go well, there’s 5 layers of management here. What are these people doing? So I think you also you know in your own growth have to watch out for any any traps of falling into that because you want to make sure that you’ve always got really clear things to do. That you’re hands on enough and that you’ve always got a chance to be impactful. bBecause as soon as you are just a management interface between 2 parts of the org there’s usually a bug there.
Patrick Kua: Absolutely. Too many levels of abstraction, right?
James Stanier: Yeah, exactly.
Patrick Kua: What are maybe some new skills or activities of managers of managers that they would need to build that they maybe haven’t done as a manager of individual contributors before?
James Stanier: I think you have to work harder at managing upwards. I think the more senior levels that you report to in a company you may, maybe, have found in your previous role, running 1 team that your lead had lots and lots of time for you. The more senior that you get, you find out that your manager is exceptionally busy. Especially if they’re on the exec. And maybe you get a very limited opportunity to meet with them once every two weeks or three weeks just because of their their schedule. So you have to work out what works for you in how best to get what you need out of them. Sometimes this can almost just be using them as an imaginary avatar where you are interacting with them in a way that actually benefits you the most. That sounds really nebulous. What I mean is, for example, if you have an incredibly busy manager, it could actually be really helpful for you to drive your accountability to write them a really detailed asynchronous update once a week. Like, here’s all the things that I’ve done this week. Here’s what the team have been doing. Because even if they don’t read it, you’ve gone through that process of really clarifying the progress that you’ve made this week and what works for you. So I think managing upwards and providing your manager what they need to make sure that they know that you’re doing a good job but also that you feel that you’re getting the time that you need is super important.
Patrick Kua: Yeah, and other responsibilities are activities that might be a surprise for first time managers managers? What would be some other examples?
James Stanier: I Think as I moved into manager of managers, it’s where I felt the tension a lot more between this is the thing that’s right for the team and this is the thing that’s right for the business. Sometimes those aren’t the same. Managing one team, I think there’s a lot out there about really trying to cultivate the culture of a team. Make it super healthy. You know you’ve always got the back of your your teammates. You may find that when you’re a manager of managers you’re forced with a hard decision of like, no actually, we have to get this out next week and there’s nothing else we can do about it and even though I know that’s not cool I have to stand up behind it. And I have to tell you that.
James Stanier: And I have to I have to embody that decision. I think that’s where you’re more exposed to the executive and the business side and you have to understand that you’re probably going to be the bad guy sometimes. It’s just how it is. That’s where all of the trust foundation is so important because occasionally when there is something that people won’t be happy about or changes that are disruptive that you have to bring about you’ve got that trust underneath to support it.
Patrick Kua: I can definitely see that and I’ve definitely been in those places as well. Those awkward conversations where you go, oh you’re definitely not going to like this, but it does need to be done, right?
James Stanier: Yeah, it’s like we are. We are just stopping this project. Yep. Sorry about that.
Patrick Kua: Is there anything that’s helped you get through those conversations easier?
James Stanier: I think you just have to always be completely transparent. If you have decisions that are being made that people aren’t going to be happy about you just have to stand behind them. Be transparent. Always have the space around those decisions for people to vent at you if they have to. Always create the space for people to talk but fundamentally you do have to believe them. Every difficult decision to change the size of a team based on priorities or to stop a project or to pivot or to do any of these things, you can’t come into them as a leader not believing that they’re right because people will see straight through you.
Patrick Kua: Yeah, absolutelyly. Maybe coming to a bit of a close as we come up to our hour what, advice or tips would you give for people thinking about transitioning into a manager or managers role?
James Stanier: Good question. So I think things that come to mind are… I mean one, there really isn’t any correct way to do your job. That’s the first thing you learn. No one’s telling you how to do it. You may not know how to do it. So you just have to do your best. As time goes on you build up your intuition as to how you should act in that role. It’s almost like you start with a machine learning model that’s just untrained. You have no data. You don’t know what the output should be. So it’s a process of continually being exposed to new situations. Doing your best. Sometimes getting it right. Sometimes failing. And just adapting as you go on. It’s just a new gig. It really is a new gig that you have to you have to work it out. I think the other thing, which we touched upon earlier about, sometimes not getting much time from your own manager. You just have to build a muscle of self resiliency. Being able to set your own direction. To understand that no one’s telling you what to do. You’re on your own. That may not be true everywhere. But it is true if you’re you know in a large company or you have a manager on a very different time zone which can happen. So you just need to be confident in what you’re doing. Believe in yourself. And also build up a a good network of peers. I think that’s sometimes where people fail a lot in managing managers roles. They forget that often they have maybe 6, 7, 8 amazing peers, who are all in exactly the same boat as them but they never talk. And they never just go, hey, we should just chat once a week. Or just hang out. No reason.
And never lean into that peer group. But that peer group is amazing. If you think that you’re good, well there’s loads of others of like you. They’re right there. Why not? Why not lean on them and talk to them? I think the other thing is just visibility. We’ve all worked for managers where you just never see what they’re doing, ever. You wonder what they’re up to. Especially if you’re remote, you’re, like, what are they even doing? I don’t know, Something I try and I think because it helps also keep me accountable to other people is I try and be as visible as I can. For example in the channel with my direct reports, I’m always writing something in there every day, or every other day. Either a conversation topic. Or hey, I’ve just seen this this document which is a tech design for this area. This is really interesting. What do you think? Really turn the dial up on on sharing and visibility and being around so that no one has the question of what you’re doing because it should be very self-evident by your output.
Patrick Kua: Amazing. Some really really great advice and tips. I definitely could have used this a lot earlier in my career as well. So thank you.
James Stanier: No worries.
Patrick Kua: Where can people find more about you or reach out to you on the internet?
James Stanier: Yeah, good question. So the http://engineeringmanager.com is my blog. You can find all my links through there in the about section. I’m jstanier pretty much everywhere. So J from James, and Stanier, my surname. That’s on Twitter or x or whatever we are in the middle of the transition of now. And other places as well. I’m always open for a chat. Just let me know.
Patrick Kua: Amazing. Thank you very much for spending the the time with me. I feel we could spend hours talking about so many other topics but really want to appreciate you sharing your time and advice and your experience on the podcast today.
James Stanier: No you’re welcome. It’s been great. Thanks.
Patrick Kua: Thanks for listening to this episode of the Managing Manager’s podcast. You can find the transcript and the show notes at www dot managing managers dot tech. If you enjoyed the content please be sure to rate and subscribe, to be informed about new episodes. Also consider sharing this podcast with another person who might benefit. Until next time.