Becoming a Great Engineering Manager and Balancing Synchronous and Asynchronous Work

Transcript:

Shane Hastie: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down across about 13 time zones with James Stanier. James, welcome. Thanks for taking the time to talk to us today.

James Stanier: No, no worries. Just before we started recording, talking about time zone difference and how you are in a beautiful mid-summer weather at 9:00 PM and I'm 8:00 AM in the morning in freezing cold. So, the magic of the internet, huh?

Shane Hastie: It is indeed. We can be together remotely and I can experience my summer. You are the Director of Engineering at Shopify. You were also the track host at the recent QCon San Francisco conference, looking at what's next in terms of remote and hybrid work. But before we delve into either of those, I'd like to just explore who's James?

Introductions 01:04

James Stanier: That's a very good question. I asked myself that on a regular basis. So, you've said my job title already. I work for Shopify. I'm Director of Engineering. I run a bunch of initiatives there in engineering. Also, I guess I could call myself an author. I've written a couple of books. The first one was called Become an Effective Software Engineering Manager and it's with Pragmatic Programmers and that book's done really well.

And it's all about getting into leading a team for the first time and what are the tools that you need to do so. And then I wrote a follow-up to that book about a year ago now called Effective Remote Work, which is very similar template of how do you get into something for the first time and what are the tools that you need. But this time turning towards remote work as the thing that people are learning. And really both of those, I wanted to be field guides to that particular area.

It's super practical, super hands-on. And I guess moving away from work even further, leave the work at the side, I'm a pretty normal human being. I like music, I like playing music, I like taking photos, I like being outside. I like going on hikes and runs and cycles and all those nice things.

Shane Hastie: Thank you very much. So, let's start by maybe exploring the two books. What does it take to be an effective software engineering manager?

What it takes to be an effective software engineering manager 02:09

James Stanier: It's a good question. And I think where I went with the book, where did it come from? That's probably a better question to ask myself. So, I probably in about 2013, a while ago now, became a team lead for the first time, engineering manager, whatever you want to call it. The landscape for material is better now for sure. There's other authors as well as myself that has written really good field guides. But back then there wasn't a huge amount of really good material as to how to run teams practically in a modern way for software engineering folks.

So, when I started that and I was part of the startup at the time, I joined at the seed round and then we did a few venture rounds and we grew very, very quickly. I had the opportunity to step up and lead the team, great opportunity and I just didn't know how to do it. And I think I found myself surrounded by lots of startuppy people who had never done it either. So, I didn't have good mentors and I didn't have lots of people in my network who were great managers, because I was fairly fresh out my PhD at the time. So, I just wrote a blog and I wrote every week on my blog stuff that I was learning, things that I was thinking about on that management topic.

And I wrote that blog for four years and that kind of manifested into the book. And really what the book was, to come back to your initial question as to what does it take? It really was writing every single week my thoughts and then those thoughts coalescing over a longer period of time into what I thought were really good tools for people to use. And I use the word tools very specifically there, because I think there's a lot of advice out there for managers, programmers, authors, whatever, any kind of industry, that's extremely prescriptive.

There's lots of articles that say, "Here are the top five things you need to do to do this thing." And often that's very shallow. So, I was very careful to write the book in such a way that was super practical and hands-on, but didn't prescribe too much. Instead it introduced techniques, tools, frameworks, and then kind of gave that to the reader to say, "Hey, go try this out. It could go this way, it could go that way, but here's like the core of what I think the job is and here's the scaffolding you should build it upon." And as a follow on to that, I think that's very much the framework I went with with effective remote work too.

It's not, "You have to do this, because this is the way you do remote work." Instead it was, "Here's the toolbox. Go and learn how to become a carpenter with the tools," rather than here's how to do it.

Shane Hastie: What's a piece of practical advice for a new software engineering manager, a new team lead in that space?

Practical advice for new managers 04:35

James Stanier: There's a couple of things. So, one of them, which I think is probably the core principle, is that it's fundamentally a different job and you have to get into that mindset very quickly in that it's a new set of skills, your output is defined differently. And the quicker you can get into that mindset, the better that you will do. What I mean by that is when you're leading a team, when you're managing a team, your output is the output of the team for the first time. Whereas when you're an individual contributor, you are very much focused on your output. So, how can you be as efficient as possible? How can you ship the most code or build the best architecture? But you're very much judged by your own personal output in the context of the team. But when you are a manager, your output is the output of the team.

So, what that might mean is that from one week writing some code might be the most impactful thing that you could do for the team, because it may move them forward. But on another week, coaching people for most of your time and not writing any code whatsoever might be the thing that makes the output of the team the best. So, getting into that mindset early, and I guess as a follow on from that, being very mindful that most people who get into technology and become individual contributors have spent an awful lot of time practicing that thing. So, maybe they went to university, they went to college, maybe they hacked around with programming languages as a teenager growing up, they've had a lot of hours of practice into becoming the craftsmen. And often when people step into a management role for the first time at work, they've never really done any formal training whatsoever.

Taking a management role should not be a one-way door 06:06

So, they might not even know if they're going to be good at it. And this isn't necessarily just for the individual, but for the person who is the new manager and the contract that they have with their manager to know that, "Hey, you've never done this before." Obviously that person doing that job for the first time should get some training, some support, some continual coaching, yes. But also having a safety net I think is super important to say, "Hey, can I do this for a certain period of time with a two-way gate where I can go backwards and go back to individual contributor if it doesn't work out?" And that being a perfectly acceptable outcome.

And I think that's something that I've done a lot with my reports over time who wanted to become managers, is try and give a safe environment to say, "Hey, this is totally new in terms of a job. So, if you want to try it for a bit and then go back, that's cool. Not a problem whatsoever," because there is no formal training.

Shane Hastie: Thank you very much. And let's jump to the effective remote. Obviously that's become so much a thing since COVID, but it was around before, but when we were chatting earlier you made the point, it's a hygiene factor now. Organizations don't have a choice. People want to work remotely or have a hybrid work environment. There's still a lot of, I would say leaders in organizations, who are struggling with this.

The ability to work remotely work is a hygiene factor in technology organisations now 07:39

James Stanier: It's true, it's true. I mean one thing before I start talking about this that I have to catch myself or my own biases. I work in technology, you work in technology. So, when we talk about everybody, we usually mean everybody in technology. And I'm going to scope my answer to that to begin with, because often it can get a little bit tricky to answer, but there is a lot of inertia. Why I don't know. Now I'm biased in my opinions towards remote work, because I work for a fully remote company and that was a choice of mine. It was a culture that I wanted. In terms of those that are struggling, I can't answer why people may want to go back to the office. There are many reasons. Community, some people really like that home life separation in the physical space, all of that's great.

Hybrid is hard and should be avoided 08:24

But the thing that's hard is hybrid. And I think hybrid is way harder than being one or the other. Being in office, being remote, you are just doing one thing and you can focus on doing that one thing well. So, if you want to go all in on the office, have great offices, make sure that they're always filled with people so that when you go into work, there's lots of people to talk to and interact with, you get that office environment and that's great. If you want to go fully remote, then that's also great because you can focus all of your time, your effort and your money into making the remote experience really good. So, if you're not paying for any offices which are very expensive, then you can probably afford to have a stipend that kits everyone's home office out really well.

So, it works if you're doing one or the other. But if you're doing hybrid, it's hard because how do you do two things well? And that's not just in terms of allocation of time and money, i.e. how do you have amazing offices that are full of people, because it really sucks going into an office when there's only three people in out of a potential 250. It just feels dead. It's not the same. But how do you provide a world-class office experience and a world-class remote experience? And laid on top of that is that the environment that you're in, whether you like it or not, and even if you are the most disciplined practitioner of asynchronous working and using all the tools that we have primarily rather than synchronous in person stuff, you just can't fight the office when you're in it.

It's so easy to have conversations with people in the physical space and then forget that three quarters of the team just haven't heard what you've talked about because you've just done it in person. So, it's that layer of hybrid that's super hard. And personally I am curious to see over the next say five years how it works out. Will those on the fence drift back to their preference and choose one only, or will we still be in this middle ground? It's really tricky actually at the moment, isn't it, with the economy and the recession and certainly the layoffs that we've seen in tech. Companies are trying to save money, and doing hybrid well and saving money at the same time is even harder. So, I'm curious as to what you think as well. Is hybrid something that you can see happening forever, or will people choose?

Shane Hastie: Hoisted on my own petard. My personal feeling, and I will confess a bias as well, I’ve worked remotely for the last seven years and loved it. And I find the opportunity to get together in person occasionally very valuable, but I wouldn't particularly want the once a week. I would want this to be once a month, maybe every couple of months, and then have that together time, very, very focused on collaboration and building relationships and so forth. But going into an office to spend seven hours on Zoom calls with people who are not there just doesn't work.

James Stanier: Yeah. And I think that's the taste that people got during the pandemic that I think almost lifted the curtain on what was happening, so I can fully understand it. And I have been part of companies where everyone is in the office and there's nobody else anywhere else around the world. I've been part of a small startup just in one building, one room, and that is a nice magical experience. But the reality is that most companies will grow, they'll be successful and someone will be remote in some way. You'll have another office in another location. It might even be on the same time zone. But you certainly, as you say, begin to find that each meeting that you're having in a physical space starts to get more and more people who are on the end of a video call.

And the normalizing effect of the pandemic, which was that everyone started to experience those meetings with their own camera, their own microphone. Okay, we can't fix time zones, that's still a difficult thing, but when that communication playing field was completely leveled and everyone experienced what was a form of digital equality in some way, that the whole office thing seems like a bit of a strange charade after that, didn't it? I mean I agree with you, at Shopify we do a few times a year have teams meet up very intentionally for things that are just easier to do in person. If you're going to try and think about your next six-month roadmap and just jam loads of ideas together for a couple of days, yeah, it's way easier to do that if you're in the same room. But a couple of times a year is enough for me. Meet people, get the energy from that, but then bring it back and then focus on building things at home.

Shane Hastie: So, let's talk about Shopify. You mentioned to me earlier 14,000 people fully remote. How do you build a great culture with 14,000 people in 14,000 locations?

Building a great culture with 14000 remote workers 12:41

James Stanier: That's a good question. So, obviously I can't take personal credit for everything they've done now. I joined in 2021, Shopify, so I've been there for a year and a quarter now. I think the first thing that comes to mind is intentionality. So, when Shopify went fully remote, it didn't do so half-heartedly. It was very much, we are now fully remote, and that is how everyone is all the way from the CEO down to the individual contributor in every team. There is no physical center of gravity of the company anymore. Everyone is remote completely. And the money that was being spent on offices, a few of them remained open but were converted to meeting spaces. And I can always talk to that a bit more in a sec.

There was no office desk for anybody anymore. There was nowhere to go. You had to work from home and the money was reinvested into making sure that people had remote setups that work for them, being able to get super good quality standing desks, chairs, monitors, all the computer set up at home that you need. So, one was definitely intentionality. And then two was the tools. So, really shifting everything so that it was async friendly. And I think this was before Shopify went remote, but centralizing all the company documentation in a place that's effectively an internal wiki and there's a newsfeed where everything important flows by, making sure that all important meetings are streamed in such a way that you can play them back later async if they're outside of your time zone, that they're rebroadcast in different time zones for the important town halls so that different communities of people in different time zones can watch them together.

So, really just going all in I think was the main thing. And embracing it, seeing is exciting. And I think also mapping the experience of working there to the experience of the people that we are serving as well. So, it's an eCommerce company, we have millions of merchants that use us around the world of all sizes of business and they are globally distributed and we are able to serve them. So, surely we can also work together collaboratively to build that product while not being in an office also.

Shane Hastie: Where does Conway's law come into play?

Structure teams deliberately to take advantage of Conway’s law 14:38

James Stanier: I would say that in my experience, I guess for listeners that aren't familiar with Conway's law, it's that the shape of the organization or the way the organization's communication is structured reflects the way in which the software is organized and shipped. The classic sort of siloing thing. I think Conway's law, in my experience, I mean one, it still happens when you're remote but not so much from geographical clustering, more so on the way you organize your teams for sure. You see teams organized around a particular product and they focus completely building on that product and maybe they haven't had the chance to stick their head up above where they're working to go, "Oh, actually we could maybe reuse this piece of work over here that this other team's doing." So, the problems I think are the same whether you are remote or not remote.

And I think good team structure is the first thing you try and solve. And that's not just individual teams, but also good group structures that are not necessarily siloed around building particular products, but instead have important metrics and missions that they contribute towards. That's the way that we try to break it. So, we are very intentional with each team having KPIs that are meaningful. And the nice thing about working for an e-Commerce company is that everything that happens with our product is people running their business and using it to make money and to be successful. And that does make KPIs easier to ladder up because you can look at user adoption, you can look at the GMV, you can look at revenue of our merchants. So, we make sure that every team has a north star that they can go towards fairly autonomously in a way that doesn't solve the problem by building things in a silo, and then structuring those groups so that everything ladders up to larger goals and encourages collaboration.

So, if you have a wider group which contains say eight or nine teams and they're all working towards the same metrics, that naturally facilitates collaboration because you find the teams look to each other to go, "Hey, how can we all work together? Maybe if we are building this thing in this quarter, you could then fast follow in your team next quarter using what we've built so that it's a multiplicative effect." So, Conway's law does happen, but I think you can fix it with metrics and team structure. And to address the siloing thing, I think communication is key there. So, this is something that we are still trying lots of different ways, trying to get better at. I don't think there's one solution to it, but how do you have teams communicate in such a way that you just naturally in your day-to-day get the sort of smell and the sight of other things that are interesting to you in your area?

The impact of removing all meetings from everyone’s calendars 16:39

And one thing we've been trying in the last few weeks was in the news that we had this kind of Shopify refactor thing in January where we had what was called the chaos monkey that was an automated script that went round and killed all the meetings in everyone's calendar that were over three people. And this isn't us saying that you should never have meetings, but I think there's a leadership aspect of Shopify that says fight against silos, fight against wasting time, make sure you are spending your time on building things and then sharing what you're building. And our teams over the last few weeks have been trying out, they're not sprints, I'm not a huge fan of the word sprints, but sort of weekly heartbeats of teams where on Monday the teams really think about what they'd like to achieve in that week and then they think about how could that be demonstrated on Friday by recording a demo and sharing it more widely asynchronously.

And then that kind of bubbles up in the internal systems that we are using in order to share information. So, you sort of fight it by team structure, good metrics and then also just lots and lots of sharing. I can't say that we've solved it, I'm not going to say that we've solved, it will always exist, but we're fighting it.

Shane Hastie: So, asynchronous and your example there of removing all the meetings that are more than three people, pushing much more towards that asynchronous work. How do we keep relationships and bonds while still working very asynchronously?

Balancing synchronous and asynchronous work 17:54

James Stanier: I guess I'll append onto your description of the meeting killing thing there, that we again haven't said that you can't ever have a meeting ever again, but I think there is great power in maybe once a year just setting fire to your calendar because it just accumulates cruft and you accumulate status meetings or group meetings that maybe once were relevant, but then you've just kept doing them forever because they're just in your calendar. So, meetings are being booked back in, but we are asking people to be very, very intentional as to why they exist and also to just kill them when that importance does diminish and just kill them. The asynchronous meaning collaboration is difficult and personal bonds is difficult, is just truth. You can't change that. And when we work asynchronously, typically the unit that is synchronous is still the team at Shopify.

So, we do, at least in my area, in the areas around me, we do structure teams so that they have a lot of time zone overlap. So, if you are on a team, your manager, your peers, usually only one to two hours difference. So, if you're thinking about that in terms of continents, East Coast, West Coast of the US and Canada, Europe shares a fairly wide overlap in time zone. So, we still have teams so that they can be online at the same time most of the day. And that's great, because there's things that we do a lot of like pair programming, collaborative design, all the general facilitated group activities. It's just way easier synchronous. But within a larger division of many teams, the boundaries between those synchronous teams is asynchronous, and that's where it comes in as to sort of the information sharing between teams. If you are a manager, you don't need as much overlap as your own manager or the other peer managers and your team, because you're mostly writing to each other anyway. So, within teams is synchronous, between teams, those edges that the communication flows along are asynchronous.

Shane Hastie: How do you tackle re-teaming? How often do you reform teams? How do you move people around?

Be deliberate about reteaming 19:49

James Stanier:There's a few things there. So, typically we find that people don't want to move team too much themselves. And I can go onto my reasoning behind that in a second. Usually, and this isn't actually a Shopify thing, this is now my own personal opinion. I think that reorgs are healthy because the business changes, the business needs change and you want to align teams to the business needs. So, you have to change the teams. It happens. Making sure that every team and area has clear metrics makes re-teaming way easier, because the purpose of changing the teams then is self-evident. Where I've optimized in the past at previous companies is the managers of teams stay fairly solid. So, if there's some particular product, we try and keep the same manager if they want to be on it for a long period of time, but optimize so that people can self-select onto different teams if they want to over time.

Recently we went through an exercise where we sort of effectively just sent out a survey and said, "Are you happy on your current team? Would you prefer to work somewhere else?" And then we can get all that data in and then you can stack it up side by side with where is the business need for this year? And then you can take the overlap of those two and you go, "Okay, well, we need to rejig the teams a little bit, but also we have a whole bunch of people who would very willingly do something different," which just makes the whole thing a lot easier. And I say every 18 months or so, it's fairly healthy to re-team. And I think if you have structured your teams previously, by no means am I saying that we do things perfectly, but if you have structured teams well in the first place that they are very metrics driven rather than very siloed around particular parts of the architecture or particular products, then re-teaming is way easier.

Because I think people just naturally gravitate towards making an impact as opposed to naturally gravitating towards clinging onto their products. But I think a good mixture is every 18 months, try and do it intentionally, rip the bandaid off, be very clear in your communication, be bold, get it done. Do it in such a way that you think will last for at least 18 months, and also add in an element of self selection if you can, because I think that also has a really positive effect on people's retention is that if you have the ability to sort of say, "Hey, I'd love to go and work in a different team," and you can actually go and do it, is a net win for everybody.

Shane Hastie: And onboarding, this is one of the things that we hear of the horror stories about onboarding in person is tough, onboarding in remote is fraught with difficulty, or is it?

Onboarding new people in remote teams 22:13

James Stanier: It's still challenging for sure. Onboarding is just hard full stop. Remote onboarding is challenging, but I think it has some benefits in the sense that what you really want in a good onboarding experience is some structure and some space and to make it really clear what you need to learn, and then have a really good handoff with your team at the end. I think the Shopify onboarding that I did in the program that we still run is excellent. And I've written about this and spoken about it before, which means I can tell you about it. And effectively when people join the company, it's a four-week period of onboarding where we are very open and say, "Hey, this is your onboarding time." That removes the stress of thinking that on day one you're going to join the company and then we're going to throw you into a team, give you a hazing with a high priority bug and then you stress out.

Instead we realize that onboarding somebody well, you only get one chance and that chance is when they join. So, take advantage of it, design a really good program, think about the funnel of the general things you need to know about the company and the mission and the values and then taper it down to their role over time. And you said remote? Well, Shopify is reasonably large now and we do fortunately have the staff that can facilitate these things, and our program is facilitated by people in our knowledge management team and they start in week one with what is quite passive learning for the new joiner, where in your cohort because everyone joins at the same time every month. So, you'll have a cohort of people who are also new, which is quite nice because you can all be on Slack together, you can all be new together, you can sort of be protected together in a safe space.

And the first week is all about the company and the mission and the values, and you pretty much in your cohort receive information. So, you watch some videos together, you start using the product together, you start understanding what it is that we do. You start understand who are the people that use our software and what makes them successful. And then in your first week you also ship something into production, which is quite fun. You get to use our tooling and get something out there, but as the onboarding progresses, it becomes more active and it becomes more specialized. So, week one, you could have any employee whatsoever go through that week in any department.

So, you get to, if you think about sort of reuse that, that's a really good part of your program. So, for everyone that week one funnel is super relevant. The week two funnel is also super relevant for everybody, because week two is all about understanding what the periphery of the business looks like. So, answering support tickets paired up with support agents, listening in to support calls and understanding, "Okay, so when someone has a problem and when someone has a difficulty, what actually happens and what kind of things do they have problems with?" Also in week two you build your own store, like you're given a brief to pretend you are a merchant who is in Mexico selling beer and you have to work out how to sell it in different jurisdictions using different taxes and real life scenarios where you get to not just see the happy path through the product, but also the things that are really challenging for some people.

And you really get into a merchant's mindset in week two. So, the end of week two, you've understood the company in week one, week two, you know how to use the product at a high level when you've started to experience like what works really well, what's really challenging for merchants. Just in general, taxes is very challenging. And then we taper off in week three and four to more craft specific things. So, if you're in engineering, in week three you get access to a whole bunch of learning materials around our architecture, you do group work, you look through the code, you get more hands on and you understand how everything is put together. And then week four is purposefully light, because in week four we effectively have a whole bunch of self-serve learning that you can do.

So, we know that everyone that we hire might not have coded in Ruby, or maybe hasn't done a particular React framework before. So, we make it so that if you want, you can then spend half a day and go into a crash course in any of those things. And we have some internal materials, internal courses, so that really at the end of that fourth week you should be up to speed on what we do, our mission and values, our culture, understand what our merchants do, you understand the big box and arrow diagram of how things are put together, and you also managed to get your hands a little bit dirty in a crash course as to anything that you want to skill up on.

And then there's that manager handoff, and that's where you exit the formal program and your manager, and every team will be different here, will have put together here's the welcome to our team. Then you go into the Slack channels. And that's one thing that's worth noting, is that we purposefully make it so that our onboarding staff don't go into their teams Slack channels and emailing lists and rituals immediately. That's sort of a thing that happens in the fourth week gradually. So, yes, you'll meet your manager in the first week, you'll have a quick one-to-one, just to say hi. But really that one-to-one is all about, "Hey, I'm here, we can talk, let me know what you need at any time, but the most important thing is that you do the onboarding and you focus your attention there and you enjoy it."

Because it is a sort of a special fun time where the people who were in my onboarding cohort when I joined the company, I still talk to them every day. You make a really nice bond with that cohort that you go through in the first month, and that gives you some hooks into different parts of the business just by default as well, which is really nice.

Shane Hastie: It's a really, really important topic, and that's a great model. Thank you very much for sharing that. Reflecting back to Qcon San Francisco, you were the track host for the Hybrid and Remote: What Next track. What stood out for you from that track?

Where is hybrid and remote work heading in the future? 27:41

James Stanier: One is it's an area where there still is a huge amount of uncertainty, not just uncertainty about what the future holds for somebody as a worker in the industry to think where is this going? But I think also a huge amount of uncertainty from leaders as to what they should be doing. Not just how they implement remote or how they implement hybrid, but just where is this going. I think we've all seen how quick to react humans can be to different situations and I think it's extremely hard to predict what people are going to want in the next five years and also how to prepare. And as we said at the beginning of this conversation, it's so much easier going fully remote or fully office-based. You can imagine in the future that in the same way that remote was niche for a particular type of worker, say 15 years ago, and there was only a tiny handful of companies that did it, but those that did attracted a certain type of person who really thrived.

You wonder whether physical office-based work may become the niche of the future where there are just some people who love working in offices and companies may design themselves in such a way that actually in-person collaboration is all they really do. That's the most important thing. And if that's for you, then you will find one of these companies to work for. But I think the reality is that any company succeeding means growing geographically to a point where you have to deal with different locations, different time zones, different cultures, and you begin to butt up against the challenges of remote, whether you like it or not. So, I think also the other thing that people are trying to think about at the moment is what are the core principles of remote work that still also apply to office work, to hybrid work? And that that's partially what I got into with the book was like, yes, it was pitched as a book about doing remote work well, but I think what I did was write it in such a way that everyone is remote to each other in some way, even if you are in the same time zone, even if you're in the same building, you might be on a different floor.

And the primary way in which we are communicating with each other is digital in terms of digital artifacts, digital communication, and all of our code is in GitHub, isn't it? It's all asynchronously, contributable towards and work on-able. So, what are the core tenets of doing distributed work well? I think is what is on everyone's mind at the moment and whether or not that manifests in the future as remote, hybrid, not remote, I think we'll see where people vote with their feet. But maybe we can use remote as an opportunity to really think about the way in which we communicate intentionally in a way that's going to work now and into the future and just reset our habits a bit. Because I think doing remote well and using our tools well benefits you regardless of where you are working. And I think that's what we're trying to extract from it at the moment. What are the best practices that mean that we could be smarter and more efficient together in the future?

Shane Hastie: James, thank you very, very much for taking the time to talk to us. If people want to continue the conversation, where do they find you?

James Stanier: Twitter is probably the easiest way to contact me and it's @jstanier as one string. And if you want to read my blog, it's theengineeringmanager.com and that's a many year archive of thoughts about remote, management, software, so on. So, those two places are probably the two main vectors that you can get me on. And please let me know if you have any thoughts, opinions, if you disagree with me, I'd love to talk. So, do get in touch.

Shane Hastie: Thank you so much.

Mentioned

• Shopify
• QCon San Francisco
• Book: Become an Effective Software Engineering Manager
• Book: Effective Remote Work
• James on Twitter
• The Engineering Manager blog