‘Driving Success with Dev Autonomy’ with James Samuel, Software Engineering Manager at Reddit

Kovid Batra: Hi everyone! This is Kovid, your host, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who has 12 years of engineering and management experience. He is the author of the ‘Effective Software Leads’ blog, which totally focuses on the difficulties of building and leading software teams in the 21st century. He is currently working as an Engineering Manager at Reddit. He’s also been ex-Head of Technology at TIER Mobility. Welcome to the show, James. Great to have you here. 

James Samuel: Thank you so much for having me today. 

Kovid Batra: So James, today, I think we’ll have a lot of questions to ask from you, a lot of things to learn from you, but before we get into that, I would love to know more about you, the audience would love to know more about you. So, we have this ritual of a quick fireside chat where we ask questions from our guests which are outside the scope of the work that they do so that we know you more. Are you ready for that? 

James Samuel: Yeah, absolutely. 

Kovid Batra: Great. Thank you so much. So, let’s get started. Let’s start with a very simple question. Tell us about your hobbies that you really like to pursue. 

James Samuel: It’s an interesting question. I enjoy a variety of sports ranging from tennis, badminton, and sometimes volleyball. But one thing that I really like so much is playing tennis. In my free time, you either see me playing tennis or badminton, you know, either of the two. 

Kovid Batra: Perfect. And tennis is a fit man’s game, I’m sure. I have tried it multiple times, but I’ve never been able to hit the ball inside the court, either it’s outside. Cool, cool, cool. So, do you play like state-level or something, or it’s just a hobby? 

James Samuel: No, it is just a hobby. Something that I spend time with friends, I kind of like play, in my free time. Not really a professional level. 

Kovid Batra: Okay. Got it. Got it. Got it. Cool. Perfect. I think this, this another thing, which probably is a passion for a lot of techies, like, you get started at an early age. Most of them whom I am talking to on these podcasts that they start early-age, coding or early-age interaction with computers. What was your first experience? When was your first time with the coding and the technology? 

James Samuel: Yeah. great question. How I moved into programming or coding was really an interesting story. And it began around 14 to 15 years ago during my second year at the university. I was studying industrial chemistry. So, a friend of mine was also studying computer science at the same university. So one day, he came to my hostel and was writing some code on his computer. Later, I knew what my friend was writing was C++ and around this code and I saw the output and that piqued my interest. And I started to ask questions. How did you do it? Like, because it was just so, it was magic, you know, writing something that doesn’t make sense and then you could compile it and run it and then you see the output. And that day, I picked my computer, installed everything that I needed, and a week later, I bought a programming book and started practising. And I discovered that I really enjoy writing code and seeing the output of the code that I wrote than actually studying chemistry that I was doing at the university. So.. 

Kovid Batra: That’s quite a transition actually, from chemistry to actually coding, I mean. But, I think for a lot of techies, this early-age experience with coding has always been magical, right? I mean, which was your first code that you wrote, if you remember? 

James Samuel: Yeah, so it was a game. I was trying to write a game where you kind of like guess a number. So it’s going to give you a box where you can input something and then you put the number and then it will tell you how far away you are from the number, how, how many. And if you get the exact number, you win. So, that was a very simple game that I programmed. 

Kovid Batra: But back in that day, I’m sure this would have been another magic trick for people. 

James Samuel: Exactly! 

Kovid Batra: Cool. Cool. Cool. How old were you at that point in time? 

James Samuel: So I, I think I was around 18-19 years old at that point in time. 

Kovid Batra: Cool. 

James Samuel: Yeah. 

Kovid Batra: Perfect. All right. Moving on to my, my next question. What is that one quality about you that you really feel proud of or you think that this is something that you have really accomplished?

James Samuel: Yeah. If I’m going to look back, I’ll say kind of like pushing myself outside of my comfort zone. I’m kind of like, I tend to, I can, I get bored easily. And one of the things that excites me is trying something that I’ve never done before and kind of like pushing myself outside of what I’m comfortable with and kind of like testing new things, taking new challenges, and all that. And this has really been an interesting one. It has really helped me right from the beginning, even from pushing myself outside of, you know doing chemistry and moving into programming and finishing programming, trying to create software and moving from one school to another school to sell the software that I built. And at the same time, also kind of like pushing myself from, from one city to another and ultimately from Nigeria to Germany. So kind of like trying to, you know, find a new challenge and pushing myself outside of the comfort zone. 

Kovid Batra: So, is it the curiosity in you that pushes you outside of your comfort zone? Or is it something like that when in needy situations, you push yourself out of your comfort zone, you get great rewards, and now you are trained, your brain is trained in a way that every time you have pushed yourself out of the comfort zone, you achieve something. What is it actually? Is it like innate curiosity or is it the reward mechanism that actually made you move in this direction of moving yourself out of that comfort zone?

James Samuel: Yeah, I think it’s a mix of both. At first we start with curiosity, being curious. How does this thing work? And what would this thing feel like? And then when I become curious, I tend to venture a little bit. And, when I get there, I’m challenged. I want to see this to the end. I want to do this. And half of that, the rewards that come kind of like something that helps me to keep doing that over and over again. So I would say a mixture of both, curiosity is there and also the rewards you get when you try something new and then you can say, “Oh, I’ve done that.” Yeah. 

Kovid Batra: I think that’s amazing. And having a mix of both is actually cool because if that innate curiosity is missing, there are more chances of not letting you move out of that comfort zone for a very long period of time. So if you have both the things in place, probably it plays a much stronger role and then can take you even farther than compared to somebody who has either of those. So, cool. Cool. I think that’s nice. It was great knowing you, James, and thanks for sharing all this with us. 

And now I think, we, the audience are eagerly waiting to talk to you about what you have done in your career, take some learnings from there. So, you have been an EM in Reddit, right? And you have been into this role and responsibility for, for quite some time now. So tell us about, let’s start with this. Like, tell us about your daily routine. What are your core responsibilities? And then you can tell us about the challenges that you see. 

James Samuel: That’s a great question. Yeah. One of the things that I do at Reddit as an Engineering Manager, it depends a lot on the day and the challenges of the day or what my team is trying to achieve. I work on the core consumer product at Reddit and a typical day for me at Reddit could be hiring and interviews, for example, trying to fill the open positions that I have for my team. And, it could also, after I work also spend, I spend a fraction of my time sourcing candidates for those roles as well. And also reviewing a couple of codes sometimes, and also the experiment my team is running. At Reddit, we have a culture of experimentation, how do you kind of like build something and see how users react to it. So, we experiment a lot. And sometimes, it requires digging deep into code, looking at the data and see, the output, the impact of that feature we’re building. And, it could also be meeting with managers of other teams to sync on what we need from them, or what they need from my team as well. And also, partnering with stakeholders like Product Managers on defining the strategy, the road map for the team as well. And a huge percentage of my time is also spent in 1-on-1s, trying to kind of like, you know, coach the engineers, my team partner with them, support them as well, and also kind of like growing them because one of my roles is to make sure that I grow every one of my teams and understanding their strength and also leveraging their strength as much as possible and also helping them to level up where they need to improve as well. 

Kovid Batra: Cool. I think there are quite some responsibilities that you have here in this role, but I’m very curious about one question here. A lot of EMs remain in this dilemma of, uh, taking up that technical lead kind of a role also, responsibility also in the team, while also managing people and taking care of the project deliverables. In your case, how do you manage or how do you keep this balance in place? Or do you even think that you should be moving in the technical direction where you are taking the decisions, the technical decisions for the team? So, you just gave me an example that sometimes you are reviewing the code. Is it something that you think the EMs should be doing on a regular basis and how do you do it? So can you just tell us about that? 

James Samuel: That’s a great question. And it’s also something that I struggled a lot when I ventured into engineering management early. So one thing that I, I think that I used to assess myself that I think managers also assess themselves is whenever there is a technical task, ask yourself, “Is this the most important and the most impactful thing I could be spending my time on right now?” And this question, if the answer is yes, then go for it. Most of the time you might find that the answer is no. And the couple of reasons why it could be no, for example, there might be a strategy problem that your team might be having, the direction where the team is moving, the technical direction, that could be the most impactful thing an Engineering Manager could be spending his time on. And depending on the state of the team, it could be filling a critical position in the team. So if you kind of like line all of those things up, with reviewing code with, you know, making technical decisions, most of the time you might find that there might be something that is (more) impactful than doing that. And the second thing that I also try to do is if you are the sole decision maker for your team, technical decisions, then you are not growing the people on the team. So, you want to make sure you build a team that is able to function without you. Let’s say, you are only there for a month, the team should be able to run and still drive you back. 

Kovid Batra: Right. 

James Samuel: And by, by empowering them, you allow them to take decisions and support them from behind, from the back. 

Kovid Batra: That really answered the question well. Realizing the impact of your involvement in the technical decisions would be the answer to take it up or not take it up. So, I think code reviews on a daily basis would be something that I wouldn’t do as an Engineering Manager, but if that particular code review is so important that it is going to impact, let’s say, or it can create a lot of technical debt or it is misaligned from that particular technical strategy that you have decided for the team, then probably reviewing in that particular week or in that particular month for the things that people are working on would be important for sure.

And apart from that, how do you, like as an Engineering Manager, I know that my team, like the business counterparts, basically the product team, right, they have certain expectations from me if I’m an Engineering Manager. What do you feel as an Engineering Manager is your core responsibility? Are they looking into this technical decision-making quality of yours at all the time, or are they relying on you to give them clear timelines, keeping the team happy, delivering projects with quality? What exactly is there in, in their mind as an expectation from you?

James Samuel: Yeah, that’s an interesting question as well. And before I answer it, one thing that I have seen in the past having worked with different Product Managers is expectations of Product Managers can be different, depending on where you are, depending on the team, depending on the company. And one thing that I try to do is to get together in the same room. Hey, what do you expect from me? How can I support you? Sometimes I see a little bit of differences between what the Product Manager might expect from another one, but overall it’s usually, there are usually some key things that I see across the board. And one of them is they also want to know the timeline. When is the project going to be ready? And sometimes they want to know how complex, should we build it or should we not? Usually there are a lot of computing priorities with different costs, engineering costs. So, they want to know these ideas that I’m thinking of how expensive is it going to be to build? And they also want to know how the project is going, regular updates. And at the same time, they also want input. Usually engineering would know how, uh, maybe if it’s expensive to build, if it’s not expensive. So they want to be able to know, get input from the Engineering Manager, like how expensive it is. Is this something that we can do? How feasible it is. And usually, these are things that I see across all Product Managers that I’ve worked with, in terms of expectation, what aligns. 

Kovid Batra: Makes sense. Cool. So, I think here automatically there is a certain expectation from you in terms of timelines and to have those timelines, obviously, you cannot have clear timelines every time but to even have a tentative idea of what things look like you have to have a good understanding of what’s going on in the team, how this module which you would be working on could impact the other module which is already running, right? So, you have to have a good context of the code being written, how it is being written, where things are moving. My question to you is though both the things are required, creating that balance, taking out time to read about different technologies and to that depth where you are able to guide the people in the right direction, how much time do you attribute to this in a week or in a month? 

James Samuel: That’s a good question. If I’m going to put a time on it, I think a huge chunk of my time is also trying to figure out what is happening across my team. And this goes around how the engagement of the team, what is the adrenaline, and also understanding what is happening in the code base that we are working in. All of these impact the timeline of what we’re building, like you mentioned as well. If it is very difficult to deploy, or maybe there is a bottleneck elsewhere, it will also impact the lead time delivery. So, most of my time in 1-on-1s, I try to understand how is the person in front of me feeling. Are they feeling engaged? And what are the bottlenecks, they are having right now? What are the technical challenges? What is wrong with the environment they are working on? And all of this kind of like, help me to be able to know how early is this team and at the same time, helping to know our throughput basically. Yeah, and I could go for that in terms of how I actually measure these, the dimension things that I look at.

Kovid Batra: I think we’ll, we’ll definitely come to that as well. My thought behind asking this question that how much time you attribute to learning new technologies is probably to find out how much a team needs from an Engineering Manager in terms of those decisions, right? So let’s say, you know, that your responsibility is to have 1-on-1s because that is very important to have a connection with the team to understand their problems, as you said. So you are allocating a certain amount of your time in that particular month or week for these activities. Do you dedicate time to such technical reading that really helps in taking those decisions, adopting new technologies? Maybe you are not building something from scratch, you are adopting something which is already existing, or it could be you’re building something on set, but the thought of bringing that piece into the architecture, into the code, into the day-to-day technical strategy, how does that work for you? 

James Samuel: Yeah, that’s interesting. I think as engineers and Engineering Managers, I think technology evolves a lot and we need to constantly keep ourselves up to date. For me specifically, I spend a huge chunk of my weekends and maybe after work reading technology blogs, reading books, and also reading about emerging technologies. And it’s a little bit complicated because when you are a full stack Engineering Manager, you also have to read about mobile, iOS, what is happening in the Android world and what is happening backend infrastructure-wise. So there’s a lot, I spend a huge chunk of my time learning this and I also actively encourage my team members to kind of like go for conferences, buy books, even recommend books and things just to kind of like, you know improve, and then how can we apply new ways of doing things to how we work. 

Kovid Batra: I think when, when you want to empower your team to like perform, deliver, right, they, they look up to someone, they need that figure in the team. So, probably when you have the context of how the business has to run, how things have to be delivered on that end along with the technological understanding, I think that inspires the developers the most probably.

And, I was recently, like reading this article and then I shared it through my LinkedIn post also. It was about that most of the high-performing teams are those where developers actually are able to think like Product Managers. They don’t have to do that exact role, but at least if they have empathy, if they have an understanding of what value they are delivering through their code, I think that’s the best scenario to be in. So as an EM, you can actually inspire your team to do that. And with that, I want to know, like how you actually bring in this practice into your team, into the developers and how do you, what’s your style of building that high-performing great teams at Reddit?

James Samuel: That’s a good question. So, there are two things here. For example, how do I enable engineers to think like Product Managers? Kind of like reason about the impact of the code, right? And how do I build high-performing teams? Those are really great topics that are actually very close to my heart. 

So, one of the things that I do when I onboard a new engineer to my team, I start to let them know this is not about the code you write, it’s about the impact you are going to create. So when you assign a task or you are to do something, don’t think about the end goal, me writing the code and deploying, that it doesn’t end there. It is me writing the code, what is the assumed impact that this is going to bring to the company, and also seeing it through to how customers are using it and also tracking the metric to see if it’s actually bringing that in part. And one way that I try to build this is through performance reviews and all that. Rather than looking at output, we look at the impact you’ve created. And also enabling the team to kind of like if you are going to pick these tasks, what impact will they bring to the team? What impact will they bring? Will they kind of like maybe move us closer to our KPI or the goals that we’ve set? 

And to the second question around building high performance, how performant is the team, I think there are four critical pieces that I think are crucial to build a team that is high-performing. One of them is something that I call ‘synergy’. And, one thing if you see a team that doesn’t have this, you see people moving in different directions. I like to use an analogy of a football, if you are a soccer fan. So one thing you see everyone’s playing, the goalkeeper knows his role. The striker or whatever, they all, everyone playing on the field, you know, supporting each other. And at the peak performance, one of the things that you see is that everyone is in sync. They all know their role. And this is where the peak performance happens. In software as well, synergy has to be there. It has to be working towards a common goal. Everyone has to know their role, what role they have to play in getting that. There has to be a clear direction. 

And then the second one that I think is crucial is a culture of continuous learning and improvement. So, one thing is no matter how performant your team is, there’s always going to be a time when they will drop the ball. Something will happen. So, for them to continue to perform is to learn from that mistake. Can they reflect on things that didn’t really go away, improve on those things and keep moving? I think these are, these two key things are very crucial in building high-performing teams. 

And another one is also ‘autonomy’. Something that I call empowering engineering teams, kind of like similar to what I mentioned. If you are leading a team that cannot exist, they can’t do anything unless they have their leader, then that is not a team that is empowered. You want to make sure that you take yourself outside of the job. Can you empower them, allow them to be able to own things end-to-end in such a way that if you are not there, the team is still working and working? And this is about allowing them, empowering them, supporting them from behind and not being a sole decision maker. Help them even to come to you, help them to reason how they can, help them to arrive at the decision, not to make the decision for them and this, I think is very crucial in building high-performing teams. 

Kovid Batra: Cool. I think these are very good points. Having that synergy, autonomy in teams is very crucial. And I think, engineers themselves are, I believe intelligent species, right? They, they like that autonomy. They like to question things. So automatically, if you are imbibing that feeling of questioning things, what is the impact of what you are doing, if you’re just reinforcing it time-to-time, bringing synergy amongst them to deliver towards a similar goal, I think that really really works well for the team. So great piece of advice, James. And I think you are driving some great teams at Reddit right now. 

Cool. With that, I think one last question I have. So, I’m sure there would be people who are directly reporting to you, right? Then there could be some indirect reportees too, right? So, in those scenarios where you have indirect reportees and you don’t have direct visibility, you can bring in that culture, give them goals, do the right hiring, right, set great examples. But I feel on a day-to-day basis when you’re running your sprints, right, when you’re seeing the performance over quarters, you just have to make sure that teams are being efficient, right? You don’t want to, like stress them out with too much work, but you want to see them being efficient. And of course, you have to take care of their wellbeing. How exactly do you gain that visibility when you are not talking to those five folks, there are indirect people also working along with you whom you’re responsible for, what are your ways of looking at and measuring that efficiency for them?

James Samuel: Yeah, that’s also a very good question. So when I was Head of Engineering at TIER, so I had this problem a lot. So I was managing 4 teams, engineering teams. And each team has an engineering lead directly working in this team. So, one of the challenges that I had is getting to know what is actually happening in all of these teams that I don’t directly manage and to be able to know how to support them as Head of Engineering. And there were four key frameworks that were really, really crucial in gaining this visibility. I do think for managers, leading teams that they are not directly managing, they need to get both quantitative and qualitative data that will help them to know or understand how these teams are building what they are building on time and within the budget they have. So, I call this ‘process’. And they also need to be able to get data that will help them understand if the things that these teams are building will continue to run at this higher level of performance and reliability, and they will continue to do so in foreseeable future. I call this ‘operation’. And they also need to be able to get quantitative and qualitative data that’ll also help them to understand the people building all of these things. Are they engaged? Are they happy to continue to build it? And they also need to get data that will also help them to understand if users they are building all of these things for, if those users are getting value and deriving satisfaction from them. And I call this ‘product’. So, these four pillars are very important to have visibility into teams that you don’t directly manage. You want people to know how are they approaching the software they are building right now. What is the process? How do they come across? How do they decide what to build and what to work on? How do they do prioritization? And you also want to be able to understand the state of the software they are building. Is it reliable? So what is the SLO like, and what is the infrastructure like? And then you also want to be able to understand the people that are building it. Are they engaged? Are they working on things they are interested in? Is someone about to leave the company? So, and you also need to be able to understand the people you are building for. If engineers are super happy, they are building that thing. And they are building it with all the reliability and performance you can think of. And at the same time, they have strong process. They can deliver, they deploy on time, and at the end of the day, users that you are building for are not getting value. They don’t like the product. You see no one. So, you need to be able to get data across all of these to know to be able to support the teams effectively.

Kovid Batra: Is there any specific tool or any specific method, any specific metrics that you are using to track all this? Like, some things are very qualitative, I’m sure those cannot be measured through objective numbers, right? 

James Samuel: Yeah. 

Kovid Batra: Like, how they’re prioritizing or how they’re making their decisions is something which you can understand through 1-on-1s or through pulse surveys where you can, like gather feedback from them on different questions, but is there anything else that you look at objectively when you look at the efficiency of the teams or the performance of the teams?

James Samuel: Yeah, that sounds good. When it comes to performance and productivity of the teams, one thing is certain, it cannot be measured through one single dimension. So, there are people who just look at, like how many times do you deploy in a day? And that’s it. How many pull requests? How many lines of code? It can be a tough one to measure, but one of the things that we’ve used or that we use a lot that I’ve used in the past is DORA metrics. And this can be very, very important because it allows you to get data from multiple dimensions to understand how the team is doing. And this is how a lead software engineer or software teams use to kind of like measure their performance. And one of them is the deployment frequency where you measure how frequent or how often do you release code to production. And this is about how fast can we get value to users. And when you see a team maybe deploying once a week, there’s a chance that the process is not right or something is wrong somewhere. And another one is the lead time, the amount of time it takes to get a code into production. How long does it take to deliver value to users? And there could be a lot of things responsible for this. It could be that the team is spending time, you know, not breaking the work into smaller, they are not doing rapid iterations, like small iterations. It could be a number of things that could be responsible. And another one too that I look at is what percentage of this value, of this change we are making is effective. And this is change failure rate. If we are trying to be as fast as possible, deploying as fast as possible, and at the same time it’s getting to production and it’s defective, then something is wrong with the process.

Kovid Batra: Right. 

James Samuel: And yeah, and the last one is the time to restore service. No matter how, how great a team is, there’s always going to be a time when something will not go right. You will have an incident. So, and what matters is how long does it take an organization to recover from the failure when it happens, how fast can we get back up running? 

Kovid Batra: That’s cool. I think that was a very detailed view of how you’re using DORA metrics and I’m happy to see that you’re using it to the fullest in terms of understanding not just one metric and looking at it from one dimension, but correlating a few things to actually understand the picture. So I think James, what I should call you, a ‘super EM’ then? No, actually this, this was really cool. I think, at your age, the level of experience you have, the kind of thoughts that you have of leading the teams, I feel are amazing.

So, thanks, James. I think this discussion was really amazing. There was a lot to learn from you and I think this 30 minutes of discussion is not sufficient for me to get all the things that you have experienced and implemented to make great teams at organizations, wherever you have worked. So, I would love to have you back on the show sometime again and talk about these topics in more detail, probably. 

James Samuel: Absolutely. Thank you so much for having me as well. 

Kovid Batra: Thank you. Thank you so much for your time. Have a great day, James. 

James Samuel: Yeah, you too. Bye.