Anil Beniwal: Preparing to scale your engineering team

Summary

In a recent podcast episode, Anil Beniwal, the Head of Engineering at Arcadia, shared invaluable insights on preparing to scale engineering teams, especially for companies experiencing high growth. He outlined key prerequisites for successful scaling, including well-defined team structures, a focus on diversity, and a clear hiring process. Anil emphasized the importance of addressing tech debt and having a semblance of product-market fit before scaling to avoid potential pitfalls. His insights serve as a crucial guide for tech leaders navigating the complexities of scaling their teams for future growth.

Highlights

• Anil discusses prerequisites for scaling engineering teams, emphasizing the need for clear structures and roles. 📊
• Diverse teams are not just a bonus but a necessity for robust scaling. 🎉
• Tech debt should be identified and managed meticulously. 🔧
• A stringent hiring process helps ensure the right fit during scaling. 👥
• Flexibility in engineering roles, especially full-stack capabilities, aids in smoother scaling. 🚀

Key Takeaways

• Plan meticulously before scaling to avoid chaos later. 🎯
• Diverse and inclusive teams are stronger and more innovative. 🌍
• Clear team structures and well-defined roles streamline growth. 🚀
• Address tech debt proactively to avoid future bottlenecks. 🛠️
• A solid hiring process is crucial for successful scaling. 🔍

Overview

Anil Beniwal, the Head of Engineering at Arcadia, joined The Tech Trek podcast to delve into the myriad challenges and strategies surrounding the scaling of engineering teams. As Arcadia pushes for a 100% renewable energy future, Anil draws on his experiences to outline the prerequisites for successful team expansion in a growing company.

Central to the discussion was the importance of having a diverse and inclusive team, equipped with flexible and full-stack capabilities to handle various roles and responsibilities. Anil highlights that although diversity should never take a backseat, it unfortunately gets deprioritized at times, and he warns against this common but detrimental oversight.

Anil also delves into the concept of tech debt and its implications on scaling. While some tech debt arises naturally with business evolution, others are due to ill-conceived shortcuts. He suggests a proactive approach to tech debt management and stresses the need for a robust hiring process, noting that while the market remains competitive, strategic planning and thorough preparation can significantly alleviate growing pains.

Chapters

• 00:00 - 00:30: Introduction to the Podcast In this episode, the host talks with Anil Benal, the head of engineering at Arcadia, about the essentials of scaling a business. They explore the prerequisites for scaling and the potential drawbacks of scaling without adequate preparation.
• 00:30 - 02:30: Anil Beniwal's Role and Arcadia's Mission In the podcast episode, the guest Anil Beniwal discusses his role and the mission of his company Arcadia. He begins by explaining that Arcadia is focused on promoting the adoption of renewable energy, with the ultimate goal of achieving a 100% renewable future. Anil and many of his colleagues are passionate about this mission, reflecting a strong commitment to environmental sustainability.
• 02:30 - 04:00: Defining Scaling in Business This chapter discusses the concept of scaling in a business, particularly in the context of renewable energy initiatives. It highlights the role of Arcadia in addressing climate change by providing platforms for consumers and developers. The consumer platform allows individuals to align their energy usage with renewable sources like wind or solar, while the developer platform enables enterprises to create their own renewable energy solutions using Arcadia's technology. The chapter also delves into the responsibilities of the head of engineering at Arcadia, emphasizing the management of engineering builds for consumer-facing products and backend systems.
• 04:00 - 08:00: Prerequisites for Scaling The chapter titled 'Prerequisites for Scaling' discusses the concept of scaling within businesses, particularly in high-growth companies. The discussion features insights from SRE (Site Reliability Engineering) teams and others, highlighting their varied roles (many hats) in the scaling process. The chapter aims to set a context for what scaling means in different scenarios, particularly emphasizing that scaling can take many forms, such as increasing customer base.
• 10:00 - 12:00: Full Stack vs Specialized Engineers The chapter discusses the concept of scaling teams within a company, focusing on transitions from mid-sized teams (around 40-50 people) to larger teams (100 or more). The most interesting changes and challenges arise during this stage of growth.
• 14:00 - 16:00: Art and Science of Scaling The chapter titled 'Art and Science of Scaling' discusses the key elements necessary for successfully scaling a business. It begins by recognizing the initial stage where a business is performing well, leading to the need for scaling to meet its potential. The discussion includes identifying foundational aspects to assess readiness for scaling and outlines basic criteria that should be considered. These considerations are vital for overcoming limitations in delivering business potential.
• 19:00 - 22:00: Acceptable Level of Technical Debt The speaker discusses the importance of being prepared for the acceptance of technical debt when scaling a project or a company. They emphasize the need for groundwork, ensuring resources and support are ready to accommodate rapid growth. The narrative draws from personal experiences at Arcadia and previous workplaces, highlighting the necessity of forethought before ramping up development efforts.
• 25:00 - 30:00: Consequences of Poor Scaling Preparation This chapter discusses the consequences of poor scaling preparation, emphasizing the importance of team structure. It highlights the need for autonomous, cross-functional teams capable of delivering value independently. This involves team members who can navigate the codebase as needed and includes embedding cross-functional partners like product managers, designers, marketers, and analysts to ensure all necessary perspectives are included.
• 30:30 - 35:00: Current Hiring Environment The chapter discusses the current hiring environment with a focus on building successful teams. It emphasizes the importance of hiring full-stack developers who are versatile and can work on both the front-end and back-end aspects of a project. This approach helps to prevent bottlenecks, ensuring that one part of the team isn't overburdened while another has excess capacity. The goal is to have a fully staffed team capable of independently delivering features without dependencies. It also briefly touches on architectural opinions relevant to this context.
• 35:00 - 37:00: Conclusion and Contact Information The chapter emphasizes the importance of having well-defined guidelines, even if they're not set in stone, to ensure that a team doesn't operate chaotically. While smaller or early-stage companies might benefit from flexible operations, allowing everyone to choose their own technology, patterns, or principles can result in an inconsistent codebase. This inconsistency can complicate the onboarding process and slow down new team members, especially when a feature requires knowledge across multiple domains.

Anil Beniwal: Preparing to scale your engineering team Transcription

• 00:00 - 00:30 on this episode of the podcast I have with me Anil benal he is the head of engineering at Arcadia we're going to be talking about a really interesting topic probably relevant to a lot of startups a lot of companies and growth and it's about preparing to scale uh Heil was going to talk to us about some of the prerequisites that you should have in place and also some of the consequences of what happens when you're not ready because obviously when you're trying to scale your team and you're trying to set all those dominoes up you have to have a lot of planning to make sure it all
• 00:30 - 01:00 works really well Anil thanks for being on the podcast yeah thanks for having me absolutely so head engineering uh two things I always ask for is if you could give us a sense of what your responsibilities are and what does Arcadia do and we'll Jump Right In yeah totally so I'll start with Arcadia Arcadia is a company that is trying to essentially help Drive the adoption of renewable energy basically our our mission is to drive towards a 100% renewable future a lot of people at the company are actually very passionate about the topic including myself and you
• 01:00 - 01:30 know being here and being a part of the solution towards fighting climate change is obviously very exciting for all of us we offer consumers a platform that they can sign up for to help match their energy usage with wind or solar energy and we also offer a developer platform to Enterprises that want to utilize our technology to build their own renewable energy offerings as well I am the head of engineering at Arcadia so I largely focus on basically anything around our engineering bills for our products so that includes our consumer facing products our backend systems our
• 01:30 - 02:00 infrastructure through our SRE teams and uh you know anything along those lines we're lot many many hats and uh with many hats obviously um you're in a high Growth Company you guys are doing some exciting things so I know the topic here is talking about preparing to scale and I think maybe we can kind of set some context of um what scale means to you so that uh we use that as a jumping off point yeah totally yeah scale comes in many forms and scaling can be customers
• 02:00 - 02:30 or traffic it can be going from a tiny team to a slightly larger team it can be going from a massive team to you know a massive team plus 10% for me when I talk about scaling I'm talking about the stage of company that's operating at let's say a midsize team like the 40 to 50 range trying to go to a big team so 100 or more because that's where I find actually the most interesting change happens and probably where most of the the challenges start to arise so that's relatively the scale that I'm talking about awesome so I guess when you're trying to put yourself in a position to
• 02:30 - 03:00 be successful and helping the team scale what are some of the I guess things you're looking for to know all right well we have the groundwork to scale right so there's some basic things that you should be looking at and maybe outline what a couple of those are for us I mean usually you're you're thinking about scaling because your business is doing well and in fact you feel limited by your ability to actually deliver for the business and so in order to meet all the potential that you have you need
• 03:00 - 03:30 additional resources for maybe more builds or more support or anything along those lines and so there are a few things once you get to that stage that you don't want to be caught off guard by and so when I joined Arcadia and when I've joined previous companies before I've thought about these prerequisites because I wanted to lay the groundwork such that when that moment came where we quickly wanted to put our foot on the gas we had all of these things in place and it was quickly a matter of just hiring more people as if it's that easy but that that basically boiled down to that and so a few things that I've
• 03:30 - 04:00 thought about even as I joined Arcadia is things like team structure making sure you have autonomous kind of cross functional teams that can be focused on delivering value as independently as possible so this means people who are comfortable kind of diving in across the code base where they need to in order to deliver on the Mandate as a team but it also includes kind of embedding cross functional Partners like product managers product designers maybe marketers maybe analysts to help make sure that they have all the voices they
• 04:00 - 04:30 need in order to be successful as a team it also means from a technology standpoint not focusing too much on front-end specialized people versus backend specialized people I actually try to focus more on full stack developers who can actually jump in on both sides so you don't have any sort of bottlenecks that for example your front end team is completely stacked but your back end team is is wide open you have lots of capacity there and so thinking of a fully staffed team that can independently deliver on most of their features without having to wait on someone else is I think definitely a priority architectural opinions are
• 04:30 - 05:00 something I also like to have relatively well defined not necessarily set in stone because that type of thing will change over time but you don't really want your team to operate in the wild west you don't want to be in a situation where anyone can do anything they want to solve a problem sometimes that's necessary at the earlier stage companies of the companies that are smaller but if everyone is choosing their own Tech their own patterns their own principles your codebase is just bound to get inconsistent and it's just going to be hard to onboard new folks and have them running quickly especially if a feature requires spanning multiple domains at
• 05:00 - 05:30 once with disperate patterns different Tech choices just bound to cause issues and that's something you want to probably get ahead of the other one I call like kind of the Leaky bucket problem so if you have for example a lot of tech debt that's causing a lot of on call burden and it's distracting your team from just delivering value as their primary mandate you won't really be able to have Engineers focus on making sure they're hiring the right people that they're onboarding those people effectively that they're code reviewing with the right level of rigor and compassion as is necessary obviously for new employees but really all employees
• 05:30 - 06:00 that you can enforce patterns of best practices and that at the end of the day you can innovate and you can push your kind of industry forward this one is challenging especially because it's actually sometimes hard to convince stakeholders that you should be investing in in this leaky bucket problem because it doesn't it's not a clear straight line towards business impact but there are ways to get around that you can talk about the operational burden you can talk about what I refer to as R&D potency for the team so your ability to actually innovate and research and develop effectively and in some cases there's Direct business impact actually and you just have to
• 06:00 - 06:30 show that to the business stakeholders for example if you have as part of your Tech debt it's actually resulting in data that you can't fully rely on or fully trust then obviously then you can't rely on the Strategic business analytics that you're doing and that actually does affect the business you know I've spoken to actually several orgs that felt overburdened by debt and they thought the only solution was actually hiring faster which is I think not the problem and this is actually why I like to call it the Leaky bucket you know if a team is on fire with outages and emergencies they're not going to pay attention to the things that you want to
• 06:30 - 07:00 be paying attention to and so I think it's super important to actually solve this problem before you decide you want to put your foot on the gas in terms of hiring then obviously you need like you know a fairly standard and consistent hiring process in place to make sure interviewers are trained to assess for qualifications that really matter you know you do that through the standardized questions and evaluation criteria that actually reflects the needs of the role otherwise you know you end up allowing for more bias and subjectivity that you don't really want in your in your hiring process which could lead to actually poor hes and people who might turn out after 60 or 90
• 07:00 - 07:30 days which is not great the other thing I like to focus on actually at all times at all stages of a company but certainly before you try to scale is diversity we all know this is important but we also all know that as an industry we could be doing much more and it's really easy to devalue this or de prioritize this as you're trying to scale your team quickly because it's sometimes just easier to get the first candidate you see without realizing the knock on effects of having a team right there's having a diverse
• 07:30 - 08:00 team actually leads to many benefits including actually greater Revenue there's lots of studies and proof points to that statement and you know you can't necessarily deprioritize this because you end up having a bigger hole that you have to dig yourself out of which is just not an effective way to be spending your time as as a organization that's trying to scale quickly the last thing I'll say which is hard to get right every company struggles with this but there's a semblance of product Market fit that's in my opinion ever elusive that you probably want to have in place before you scale Engineers very quickly
• 08:00 - 08:30 or else you might end up in a situation where you've hired a whole bunch of Engineers but don't know exactly how to utilize them because the product is Shifting so quickly under their feet so yeah I would I would classify all those in my mind as prerequisites before you decide you want to start hiring quickly awesome those are some good pointers to keep an eye on and I guess when you're when you're trying to prepare to scale obviously you mentioned having a good hiring process on the flip side when you're looking at actually having people start the onboarding process how critical is that like if you're trying
• 08:30 - 09:00 to assimilate multiple people on to the team obviously the team might take a hit in a particular Sprint bringing those people on anything that you've seen work well in trying to make sure that onboarding component is less costly to the team there's a few ways that you can probably minimize the impact there one is you should be thoughtful actually about pacing and making sure that you're spreading out the hires on different teams or you potentially can go faster on teams that might have more senior members because there might be more mentorship capacity on that specific spefic team but I think a lot of what I
• 09:00 - 09:30 mentioned as prerequisits actually setting you up to onboard and engineer effectively for example having well established patterns and Frameworks and engineering principles is actually a really effective way to you know accelerate onboarding essentially because people will join they will know exactly what to expect when they jump into a code base they will know the long-term vision of that architecture and can build towards it and that will result in a lot less churn when people are are putting a poll request and trying to make changes to the code base and actually require also less
• 09:30 - 10:00 involvement from my mentor because they can actually rely on some of the documentation that might exist or some of the packages or libraries or Frameworks that might be already built into the code base but that is certainly something you do want to take into account you know you can't drive it all the way down to zero but you certainly can help make onboarding much more efficient let me ask you this question because I'm always curious so obviously in a team where there's going to be high growth having flexibility and staff's really helpful you mentioned full stack people who can handle a little bit more than being you know special specialized
• 10:00 - 10:30 resources in particular areas so if you're kind of thinking about that and then you're trying to think about you know the scaling even further down the road potentially do you see like there being an issue of having those people and now having to specialize into specific teams and being reallocated or you know is it a case where listen like we know we need you know 20 30 Engineers we want this approach of more you know full stack people focusing on that next iterations just too far out I will say
• 10:30 - 11:00 similar to product Market fit a true fullstack engineer also happens to be pretty elusive in my opinion and my experience even when you go to hire at fullstack engineer what you actually end up finding is that every engineer will naturally lean in one way or the other some people love uis they love react as a technology they love animations they love just the Paradigm of how State Management happens in Out World and some people hate it and some people just want to be in the back end they love interfacing with you know making database queries much more more efficient or what have you and you know
• 11:00 - 11:30 when we hire full Engineers we naturally find that everyone has a lean but what we do is when we bring them on we place them on teams we try to balance that lean but we also very clearly set the expectation that when the time comes and we have backend work to happen and the only person who's free is someone who might lean front end that they have to be comfortable and capable of actually diving in on the back end when necessary over time you might actually want to lean in and like Embrace that specialization as your organization gets larger you may want to front end Architects for example or
• 11:30 - 12:00 principal Engineers who can come in and actually stud a long-term vision for your front-end architecture or help Mentor engineers and get them more up to speed if they're not familiar with FR Technologies same goes for back end that's kind of a natural progression that I see but the value you get about resource flexibility by going towards a full stack model especially for the smaller sized organizations I think is massive I guess when you're looking at your relationship with product anticipating what they see as features road map you're talking in interface facing with sales anticipating sales
• 12:00 - 12:30 growth and demand how much ART versus science I mean I'm curious I've asked the question before different perspectives but how much ART versus science to this you know ability to kind of start planning for the scale that's tough that's tough there's definitely some art here for sure you know I found in my experience that oftentimes it's a business decision when you decide okay we're going to go for it we fit the traction we've seen the green shoots we want to accelerate in this direction and actually take a bet on what our traction has happened so far in
• 12:30 - 13:00 the past quarter or two and see if we can actually have that stick and accelerate so there's certainly an art there as well and then also you know as you know and I think a lot of your listeners will know road maps as hard obviously to get a road map right especially some organizations will think a full year out some even think longer out and you know your certainty for those later quarters ends up being very low so it's hard to predict for hiring for next year's road map because it's likely that next year's road map will definitely change before you get there so there's certain amount of art to how
• 13:00 - 13:30 you think about that the science part I think actually comes into making sure you're actually just expecting and embracing that change in the sense that you know you know that things are going to change you know you're going to have to have some flexibility and coding and designing for that change expecting to need to be nimble is actually a big part of how you should be thinking about writing software and building teams interesting I've read about you know Warren Buffett's investment you know philosophy in I think someone asks him do you know if stocks are going up
• 13:30 - 14:00 or down and he says I don't know and you see a guy who's really well skilled in making a lot of money in the market and um he's not you know living his life based on the decision of it's going up or down because his Horizon's longer in a cycle where you're a startup and you're in growth that Vision that cycle is definitely a smaller window because obviously you have Milestones as you're in growth mode I think the tricky part like sometimes when you're looking at the technical deck component that you mentioned is those tradeoffs of speed
• 14:00 - 14:30 scale come back fix but then there's always more and gets buried when you're looking at let's say a two to four year window and you're thinking about scaling your team is there an acceptable amount of technical debt you're willing to take to help facilitate some of that growth versus having to go hey we have to come back to fix this I have over time gotten very comfortable with the fact that I will be wrong I won't say how often I'm wrong but it happens and I think every
• 14:30 - 15:00 engineer ends up being in that situation every business leader ends up being in that situation you know we can design the perfect solution for how we understand our business today and two years later our business will have evolved and any perfect decision we made two years ago now suddenly gets classified as techical debt and I think that's totally acceptable and it's totally fine it's just the nature of how businesses move your competitive landscape moves the industry moves and so you're going to have code and technology that no longer matches it's not necessarily fully in line with how
• 15:00 - 15:30 you think about your business to me that's considered Tech de to me that's actually totally healthy and you don't want to have it acrw because the longer it acrs the stickier it gets inside your codebase and the harder it is to extract so you have to have a certain amount of throughput and paying that down over time you have to have dedicated focus on it as well or you might actually end up being buried underneath it you know it's kind of funny is I think um the concept of tech debt and I mean you're an engineering you maybe you can break it down for me I almost think that there should be two categories of it you know
• 15:30 - 16:00 Tech debt where poor decisions are made and Tech debt where the business shifted and you have to go back and address just some of the growth that you can anticipate I mean we can only look forward so much and whatnot I mean is it categorized in that way is are you doing it should it be done I actually think there's a third category in there so I agree with the first category which is poor decisions were made and that sometimes it's just like someone didn't think through something fully or didn't anticipate a future change or something I actually don't know that that happens
• 16:00 - 16:30 as frequently as people might think I think more often what ends up happening is a corner is cut in order to meet a timeline because either it's a very important timeline to meet it's a sales cycle or something or a corner is cut because someone underestimates the impact of cutting that corner and then people build on top of that cut corner so to speak and you end up with this problem that is a category of tech debt I think that is actually more likely in terms of making a conscious choice not to do something or do the wrong thing you think it's just temporary you'll come back and fix it and you never do to me that's got to be like a major
• 16:30 - 17:00 chunk of the debt that exists in people's code bases the other side about the business shifting I think is also definitely true but also understandable and almost probably unavoidable and potentially unpredictable it really depends on the stage of your company the first one is the one that you know you intuitively think you should be avoiding you should be identifying you should make that decision but in practice you kind of have to and I think that's just like a fact of engineering and it's going to end up happening to you I guess the flip side to this when you're maybe ill-prepared or maybe best
• 17:00 - 17:30 uh late plans don't go the way you think and maybe you missed something before your team's about to scale what are some of the I guess immediate consequences right obviously it's got to affect the current team right all of a sudden you have much more demand for what you need to produce and all of a sudden your team short-handed maybe you just missed seeing the timeline I don't know it could be a dozen things but when you're looking at some of the consequences of just missing the window of having things lined up what are some of those
• 17:30 - 18:00 things so there's multiple windows you could miss you could miss the window of opportunity to scale before you absolutely need those resources and then 100% you'll be under resourced at a time where you need the resources and then you will be further under resourced because you have to interview and onboard people and so that's certainly a challenge that can happen I think the other challenge that can happen is not focusing enough as I mentioned on the prerequisites and deciding that it's actually the right time to scale scaling and then hitting problems because your code base now has dispar patterns you don't have good structure in place to
• 18:00 - 18:30 set expectations for each level of your growth ladder for engineers so they don't know actually how they should be engaging with the rest of the team how they should be leveling up other Engineers you may end up bringing engineers in at the wrong level all of which by the way causes friction as you think about your team design you end up actually zapping productivity the whole reason you decide to scale is actually to get more done with your team that's the whole reason the budget gets green lit that's the whole reason you actually run it that and the answer to getting more throughput is both to various
• 18:30 - 19:00 degrees quality and quantity like we're not out here building Empires we're out here hiring people to get more done for the business and if you just hire a whole bunch of people that actually aren't perfect fits as a role because you didn't have a good interview process or a good way to evaluate them or you hired the right people but they don't know how to properly engage with your code base because the code isn't well structured and well thought through you're not going to get the quality out of these Engineers you actually will just have a whole bunch more people but not actually a kind of appropriate amount of additional throughput as a result so those are kind of the con consquences you want to watch out for you really have to pay attention to
• 19:00 - 19:30 those prerequisites or you end up in a situation with more people but not a lot more happening yeah and I guess you know curious what you think about this but I mean right now we're in a real tight hiring environment I mean I think in 2019 it was tight I think right now it's potentially as tight as I've ever seen it and when you're starting to plan you know you're looking at the prerequisites and you're trying to anticipate hiring you know two four 10 people whatever it is and then you start realizing that just the sheer time it's going to take
• 19:30 - 20:00 for your team to spend to hire to find the right resource you know make offers and have to worry about them being accepted how much of that impacts your I guess your preparation for this it's definitely something you consider I mean the Market's really interesting right now I wouldn't I wouldn't expect it to be the way that it's actually turning out to be for whatever reason I think I assumed it would be a lot easier to find candidates but it certainly is challenging to find the types of people you'd want to to bring on it's a business optimization
• 20:00 - 20:30 you can decide that now it's not the right time to hire but then you're also making the decision that you're not going to get all the things done that you want to get done and that may or may not be acceptable for your business when you think about the long-term road map or or trajectory or Revenue projections or whatever and so it timately comes out your business you want to invest in hiring to scale up the team be realistic about how much that will cost you and other leaders in the OR and just generally the engineers on the team and how much you know you're looking to get done in the next you know 6 12 18 absolutely I mean it's definitely uh in
• 20:30 - 21:00 your position balancing all this executing the team health of the team Lots goes into it I appreciate you coming on and kind of sharing um I know you guys are in a great growth mode so I'm sure you're kind of going through this real time and it's it's great to kind of share with everyone out there thanks for having me I appreciate it absolutely if someone wants to reach out LinkedIn is a good area to to hit up if they want to talk about something you mentioned on the podcast yep totally awesome I uh appreciate you being on it's been great and hopefully we'll have
• 21:00 - 21:30 you back on you know maybe six months a year down and kind of see how uh we can evaluate uh how growth and scaling has been happening at Arcada and uh check back in with you yeah I'd love to awesome that's it for this episode of the podcast we'll be back again with a different guest different topic and I always ask for two things one if there's a topic you want me to cover actually Anil brought this one preparing to scale to the table and I thought it was fantastic but if you want to message me about something you want me to find a guest to speak about out always looking for that and second you know keep
• 21:30 - 22:00 sharing the podcast I I love the fact that it's just kind of growing organically and it's exciting to to be part of the journey so thank you for listening and we'll be back again [Applause] thanks