‘Bridging the Gap between Business and Engineering’ with Chris Bee, Startup Tech Advisor

Kovid Batra: Hi everyone, this is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing special guest who is a seasoned startup CTO/CPO. He has seen a startup journey from a 20 million valuation to a 2 billion dollar valuation with Lessen as a CTO. He has 17+ years of experience in leading software teams and building applications. Currently, he’s working as a technical advisor and consultant with multiple startups. 

Welcome to the show, Chris. Great to have you here. 

Chris Bee: Thanks for having me, Kovid. Great to be here. 

Kovid Batra: Pleasure. All right, Chris. So, we’ll be starting off with a cool fireside chat with you, where I and the audience would love to know more about you through different questions.

Are you ready for the fireside chat? 

Chris Bee: Yeah, absolutely! Let’s do it. 

Kovid Batra: All right. So, here’s the first question for you. Tell us about the most important event of your life, like that defines you. 

Chris Bee: Yeah. Yeah. There’s lots of things I could, I could probably reference. It’s kind of hard to narrow it down to one event necessarily.

But one significant event that I would, I would typically talk about is, moving out west and, you know, took a pretty big leap of faith and left behind a lot of my family and friends back east and really jumped out here without really knowing anyone or much about the area, frankly. But in retrospect, it was a great decision and, it was a huge boost for my career. And, got to work for some amazing companies out here that really didn’t have offices back east where I was from. And, you know, being away also let me focus a little bit. You know I originally worked for Microsoft and then Amazon, Uber and Zillow and, you know, being out here allowed me to have a little bit less distractions, a little more of kind of a blank slate and kind of carve out a new path in life. And, I, that path has been focused around tech and the outdoors and meeting new people, Met some great friends out here that I otherwise wouldn’t have met if I didn’t make the move and actually met my wife out here and started my family out here as well. 

So, it’s been quite a kind of pivotal point in my life as I reflect back a little bit when I actually made the decision to come here, but definitely a good one. And, I miss a lot of my friends and family back east very dearly, but, all in it’s been great living on the West Coast. 

Kovid Batra: What do you love most about the East that you don’t find here in the West? I mean, I, I’m sure you would have spent your childhood and growing up teenage over there, right? 

Chris Bee: That’s right. Yeah. Yeah, I moved out here kind of in my late 20s. So, I had a pretty significant chunk of my life that was, that was on the East Coast. Well, I mean, the family and friends are the main thing and a lot of the people I knew back there. You know, there’s sometimes a bit of a directness about the East Coast that I appreciate. Yeah, there’s a little bit different, food, culture there and kind of cuisine options, although cities have homogenized a little bit over, over the years. But, you know, I think there’s, there’s different food options.

And, I don’t know, I think the main differences are really just around, you know, kind of the general attitude of folks. I think people are a little more laid back here, a little more reserved. They get a little more of that directness on the East Coast, which I appreciate. I think I carry that with me. It actually helps me at times. But, broadly speaking, you know, it’s, it’s the same country. It’s not a wild difference between the two coasts really these days. 

Kovid Batra: Cool. Amazing. So, tell us about, uh, your first experience; how did you get into tech actually? 

Chris Bee: Yeah. So, I was always inspired by what technology can do. I was an early adopter of the internet back in the 90s, kind of really date myself here. But I studied programming and management in school and more specifically, I got really into software in my grad school years. And, I was actually a DJ during that time, just kind of a source of income when I was, when I was in school and that led me to learning graphic design and then promoting a lot of my events and led me to building a production company that had a pretty comprehensive website of event listings, forced me into learning technology. So I learned, you know, PHP and HTML, CSS, a little bit of JavaScript, and, you know, web servers and analytics and, you know, kind of the, everything I needed to do to basically promote events and keep the website maintained. And I just really became fascinated with what technology can do at that point. 

And that led me to go a lot deeper in my studies. I did a lot of like continuing education and you know, kind of nights and weekends programs and got my first job as a Product Manager back in Philly and at a technical company. And I just really kept progressing from there. Every company I joined, I would take on little side coding projects. I still kind of do projects for fun on the side today. And, it’s really a never-ending pursuit. There’s always something new to learn. And, you know, obviously with AI now there’s like a whole new era of things to understand and learn and dive into, which is exciting. 

So yeah, it’s been, it’s been quite a journey. But, way back in the day, believe it or not, it was, it was being a DJ and promoting events that initially got me started in actually hands-on kind of coding and building applications.

Kovid Batra: I like that. That’s one hell of a transition. I mean, a DJ turning into a tech leader, if you look at it, I think that’s amazing. I’m sure that that would have definitely brought a lot of different aspect and perspective of how you look at things when you lead teams, when you do your work on day-to-day. I’m not sure how it impacts, but, that’s a different transition that I’ve heard very lately. 

Chris Bee: Yeah. Yeah. Yeah. No, it was a lot of fun when I was in college. It was a great job, a lot of the other jobs that my friends were working at the time. And, you know, I did internships in the summer, more professional internships. But, yeah, it was a lot of fun and it led me down the very beginning of this path is kind of where it started when I really think about it. But quickly, the professional world took over and I, a lot of that type of work just really focused on that once I finished grad school and started working professionally. 

Kovid Batra: What about now? Do you, do you still play sometimes? 

Chris Bee: On occasion. Yeah. Yeah. I’ll dabble here and there just for fun. You know, just at the house, you know, no desire to go play gigs or anything like that anymore. It’s purely just a hobby at this point. 

Kovid Batra: So, how do you usually unwind your day? Like how, and there, there is a lot of work, hectic day, then you come back home, what’s your go-to then? 

Chris Bee: Yeah. Yeah, it’s varies by the day a little bit, and depending on family activities, you know, can, can change a little bit. But, I guess I tend to be a night owl a little bit more by default. You know, I’ve become more of a morning person with kids, but, I generally like to put some closure to the end of my day. And I actually kind of find it relaxing to work a lot of times when there really aren’t other folks online. And you know, as a busy professional, you can either carve out early mornings or late nights, essentially to focus. I feel like you kind of have to pick one when you’re sandwiched between meetings all day, and you know, usually just bouncing around from conversation to conversation. Um, so I usually find that that time of night and I really like to carve out my next day as much as possible. Kind of prep call notes, set up any meetings that are needed, catch up on the email I might’ve missed, and sometimes do some deeper work, or at least, at least frame it out for the next day is usually what I like to try and do. And what I find that does sometimes is it will sort of allow things to sit in my subconscious a little bit while I sleep and let my mind kind of solve some problems while I’m sleeping. A lot of times I’ll wake up, you know, with the insights or you know, kind of thoughtful approaches to what I was ruminating on.

But I try and stop working at least an hour before bed just to, you know, wind down and you know, usually read before I actually go to sleep is typically my pattern. But that’s based on my routine. You know, it varies a little bit like everybody and I try not to get, you know, super dogmatic about, you know, how I, how I handle it. I think, you know, not putting too much pressure on yourself is also important. But yeah, that’s, that’s the basics, I think. 

Kovid Batra: Cool. Cool. Cool. I think it was, it was great knowing you and thanks a lot for being honest here and telling us from where you came, what you did, what you like. 

Now, I think I would love to, and the audience would also love to know more about what you did in your career, maybe some successes, some failures, your experiences as a CTO. So, I think let’s get started with the main section where we talk to the new-age CTO. 

Chris Bee: Ah, sounds good. 

Kovid Batra: All right. So, my first question. So, as a CTO at Lessen, and probably you have been wearing this hat now multiple times, there have been multiple challenges that would have come across when you are into this responsibility and this role. Tell us about some of the major challenges that you have seen as a CTO, and how did you overcome those, and share some hands-on advice there.

Chris Bee: Yeah, absolutely. You know, I think big picture, if you zoom out, you know, the job of a CTO, or any technical leader really is to translate the business strategy into engineering strategy, right? And how you actually do that, I think depends a little bit on the company size and the stage of the company.

I think if you’re in the earliest stages, you know, you’re really going to be operating as a lead developer and a system architect and maybe managing a small team to execute. When you get to that next phase of a growth stage company, you’ll typically be more focused on hiring and guiding the team to follow best practices and, you know, taking on more of a leadership role. And then, as you get to the later stages, I think, you know, it shifts again where, you know, you’re really working with your peers to make sure you’re investing in the right areas, studying the culture, keeping teams aligned, and really working towards achieving business goals in the broader sense. I think you’re delegating a lot more as you know, you get to kind of manage your managers and, you know, department managers and this sort of thing. 

But in any of those phases, I think it really breaks down to three primary aspects. The way I think about it is people, process and product. So, ‘people’ is really the most important part, right? The company’s kind of nothing without their people and it can be easy to forget this as a tech leader, especially as you’re deep in the technology. But aligning your team’s passion to the growth objectives with the company is super important. I mean, there’s really no more important job than that. And, you know, focusing on helping people find satisfaction in their work and in their career and really helping people grow in their career is really one of the most important jobs. And I think focusing on that is super important. You know, work is such a huge part of our life. I think you really have to love this part of the job as a manager, and if you don’t, or that’s not appealing to you, then, you know, maybe management work isn’t really the right profession, and that’s okay. And there’s lots of, you know, technical leaders that can lead in other ways that aren’t people managers, but the ‘people’ is really one of the biggest parts. And I talk about that a lot when I’m reflecting on what it means to be a technical leader. 

I think the next thing is ‘process’ and kind of setting up the rhythm of the technical organization, you know, aligning the tech team with the broader company objectives, you know, creating a process to set expectations and hold folks accountable. And this can come in the form of goals and OKRs or managing to a delivery schedule that needs to be published by the team or kind of a variety of other ways. But, I do think having a system by which people understand kind of how they’re being evaluated and you know, what the expectations are is really important. And, you know, as a, as a leader, as a CTO, you know, you’re ultimately going to be responsible for kind of setting up, you know, what those expectations are and what the rhythm of the business should be and how you’re going to drive performance in your teams. And, what I found is that high performers, you know, want to be held accountable. They want to know, you know, what the rules of the game are, so to speak. I think there’s nothing worse than, you know, being surprised or not really understanding what your expectations were and having a miss. And, you know, then you’re in a whole, you know, kind of people management debacle that you don’t want to be in. So, I think it’s important to be clear about that and set up a process that works for people to grow within and know what the is expected of them. 

And then lastly it’s ‘product’. You know, really leaning into prioritization and having a business lens with it is, is sometimes a new area for, for folks that have really come up from the technical side. But, you have to really be thinking broadly about the organization and the company to help make good prioritization decisions inside your team and what your team’s working on. It’s a lot about architecture and, you know, building the right foundational pieces so that, you know, the platform can grow and, you know, flourish. I think ensuring you have the right investments in infrastructure and DevOps to create a great developer experience so, you know, you’re able to move fast and people feel like they’re working in a system that is modern and doesn’t get in their way. And then, I think just weighing on priorities and making sure that tech debt, architecture projects are fairly represented. And, you know, having that kind of broader view of the product, I think it’s really important as a leader, when you’re thinking about the product part of all this. 

And then, there’s some challenges I could probably talk through as well, if that’s interesting or up to you, where you want to take it from here. 

Kovid Batra: No, I think the two points that you have touched upon, one is translating the business strategy into a technical strategy and then dealing with people, process and product. Like, these are like quite in itself, quite broad domains to talk about. I’ll try to take them one by one because I have some things to really understand there. And I have been hearing this from a lot of CTOs now, like translating the business strategy into tech strategies, one of the biggest challenges they see. 

Just throw, throw some light on how you as a CTO, let’s say, at Lessen or other companies have done that. Can you just give us some example where we could, like the CTOs who are listening to you could relate to that, “Okay. Yeah, this is the scenario we are exactly into. And this is how we can translate some of the business goal and vision into the technical strategy that we are looking at right now.”? 

Chris Bee: Yeah. Yeah. And I, I think it really it requires you to kind of take a little bit different view of maybe work than you have in the past if you were previously an Engineering Manager or Engineering Director, and you know, now you’re in this CTO role. And I think there’s, there’s two aspects. One is, you know, looking at it from a business lens that may be a little bit different. I think the other is just really understanding the impact of your leadership and your words and your communication to your organization. On the business side, I think the big change really is that you have to think about the company holistically. You know, it’s no longer just about the technology. And sometimes that can be at odds with how you may have thought about things in the past, because what is the best thing for the overall business may not align with really what you would like to do as a technology leader, or, you know, what you’d like to prioritize or the projects you think, you know, would be kind of fun to work on that no longer is the right lens to really look at things. So, I think keeping the business on block, helping fuel in growth, making sure you make the right investments. And you end up having to look at things from a little bit of an ROI perspective, which I think is a new lens for people, like truly, like how many dollars did we spend to deliver this part of functionality or this part of the platform? And you know, that, that generally isn’t the way in a lot of organizations anyway, how you look at things. It’s more headcount, I’ve got projects and I’m, you know, using Agile, I’m running through my sprints and I need to deliver things by certain dates. But, when you start looking at things from an ROI perspective, and you ultimately own the budget, you know, that’s where I think, you know, your view will start to change a little bit.

So, you know, it comes back to really understanding the business well, like you have to be much more of a business person, I think, than you were before. 

Kovid Batra: Right. I think that that’s very true. And I don’t think a strategy, a technical strategy would just come out of two days of thinking and you are through with it; there are a lot of aspects that you need to look into to really say that, okay, we, we have to come up with this strategy and this would work. But, one most important part I feel is the understanding of the business. 

So, what kind of questions a technical leader should ask themselves and their business counterparts when they’re thinking on those lines of building a strategy for the team? So, can you just highlight those few questions probably which you would be asking? 

Chris Bee: Yeah. I think as you’re trying to kind of make that translation, you know, I’m a big believer in starting with goals, right? And having goals at the company level that are aligned across your peer groups. And that means with marketing, with sales, with your CEO, with, you know, other departments, operations, if you’ve got an operations-heavy style company. And those become kind of the backbone for how you empower your teams. The way I like to operate is to then allow my teams from the bottoms-up to create their goals that, you know, have a level review, but are owned and kind of independent by each team. And then, the projects within should, you know, not be surprises, but generally should be things that are coming from the bottoms-up. So, the teams are figuring out how to get to those goals and how to achieve what you’ve laid out as the objectives for the company. And that framework, I think is the best way to sort of break down the strategy. And then, there’s usually a review process that’s in there, right? If getting into the specifics a little bit, you know, if you’re going on a quarterly cadence and you’ve got quarterly OKRs you’re setting, having teams come up with their objectives, their OKRs at, at the team-level along with the projects they’d like to prioritize, having a review session with leadership, maybe making some tweaks, maybe making some prioritization changes, making sure that the dots are connected between the different teams, because, oftentimes the theme becomes sort of the glue that, that pulls together a lot of teams. 

So, I think it’s goals and themes really, I should have mentioned that themes are the other really big part and, and that’s like at the level of leadership you probably want to stop, you know, you don’t want to get down into the weeds of individual projects and, you know, individual work that you want to see done. Sometimes that’s okay. It’s inevitable. You know, if you’re using the product, you know, you’re thinking about all the time, it’s inevitable. 

Kovid Batra: Yeah. You gain some context, like you have to understand some of the initiatives that have been taken up. But yeah, I get your point, what you’re saying. Yeah. 

Chris Bee: Yeah, you really want the teams to come up with it because I think that that empowers them and gets them excited and gets folks, you know, really eager to work on what they’ve they’ve concocted and what they’ve trimmed up. So, I think that’s important. Yeah. 

You know, you kind of also have to understand your impact a little bit as a CTO. I think, you know, one of the biggest changes from kind of the managerial level to the executive level is you have to be a little more thoughtful about some of your decisions and some of your statements. You know, the more senior you get, the more weight your messages will carry. And, it’s important that you’re consistent, right? You need to be a carrier of the vision for the organization. You need to be aligned with your peers and your CEO and how you describe strategy and priorities. I think it’s, you know, a situation where you have to be a little careful about half-baked comments or things that, you know, you haven’t really thought through because people sometimes will take that as direction and as, you know, sort of guidance of what they should be working on. And then, that can cause problems in your organization, especially if you’re misaligned with, say something the CEO said or something the sales team’s talking about, and, you know, that can create confusion and a lot of churn inside the team. 

So, you know, it’s, you want to be approachable, you want to be transparent, but you also want to be thoughtful about, you know, sort of giving guidance and direction. And I think sometimes, you know, you even need to specify to say, you know, “This is just a suggestion or a random observation. This isn’t a go-do.” I think actually clarifying that when you’re talking to people from a leadership level, I think is, is actually really important. 

Kovid Batra: Totally. That makes sense. Cool. I think that’s, that’s on the, on the technical strategy being formulated. When it comes to like leading teams actually, you have to enable your dev teams, you have to enable your Engineering Managers, your, like senior managers to actually lead their, their teams better. So how, how do you exactly do that? What kind of leadership style do you take up or what process of framework do you have in mind to actually lead and enable teams? 

Chris Bee: Yeah. Yeah, absolutely. You know, I’ve been talking about it a little bit already, but I, I really like to lead with the theme of accountability and autonomy.

I think in order to empower teams, there’s really 3 things you have to have. You’ve got to have a system for accountability, you’ve got to have team autonomy and you’ve got to be able to articulate and make sure everybody understands ‘why’, the ‘why’ behind what we’re doing. And I’ll just talk about that last one first, since I haven’t talked about it much. And I think as a leader, you know, that’s one of the most important jobs is to repeat the ‘why’ and really make sure that it lands with people. I think when people really understand the ‘why’, they can work through almost any ‘how’. And that’s, that’s part of your job as a leader so that people feel inspired, so they’re excited about what they’re working on. They understand how their work ties the bigger picture to business goals to hopefully the impact the company’s making out there in the world. And I think you have to deliver that with some passion and conviction. And you need to, need to legitimately feel that way about what you’re working on and what you’re doing. And, and I think when you are able to articulate that and put that out into your organization, you know, people are going to perform at their best and be the most excited. And it’s just a lot more of a fun work environment when everybody’s aligned, you feel like you’re working towards a little bit of the greater good and something that is beyond just the scope of the specific, you know, task or, you know, bug that somebody’s fixing. So I think that ‘why’ part is really important. 

And I talked a little bit about, about the autonomy and kind of how to break that down and how to set clear goals at the top and have teams kind of build that from the bottom up. I think, you know, there’s a little bit of, like, just the right amount of pressure in there, that’s important. I think periodically, you know, usually on a quarterly basis, doing some level of sort of public review of our accomplishments from the previous quarter, and what the plan is for the upcoming quarter, I think does add a layer of, kind of a healthy pressure, right? To sort of discuss things in kind of a more public forum. I think demos are another really big piece as well, when you talk about accountability. I think allowing frontline engineers to show off their work, whether it’s weekly or bi-weekly basis to the broader organization. I think that can create, you know, a little bit of a healthy, you know, situation where people feel ownership and feel like they need to deliver something by a certain time. 

Yeah, exactly. Exactly. So, yeah, those are some of the big things I think but autonomy and accountability are kind of the themes.

Kovid Batra: Perfect. And now, moving on to the product part. Like, when you are moving down, building the product, there has to be a development process for that. And that has to not only work for the customers, for the consumers, but also for every stakeholder that is there in the system, and that includes your dev teams also, that probably includes investors also. There are a lot of things when we talk about stakeholders there. So, how do you create that product development process that falls in line with each and every stakeholder in the system? 

Chris Bee: Yeah. Yeah, I think there’s a couple of aspects to it. You know, and I’ve talked a little about this, but there’s, there’s a combination of tops-down and bottoms-up that I think really needs to be, you know, clearly defined as you’re figuring out how to set up a product development process.

As I mentioned, I think top-level company goals and themes are what leadership should really be responsible for, communicating that clearly,  making sure that’s aligned across functions. And from a bottoms-up perspective, I think team goals and timelines for delivery are really, like the responsibilities of the individual teams. And then, as you kick-off individual projects, you know, a system that I’ve developed with some others over the years that I’ve found to be really successful is what I call “the 4 Ds” and, it’s discovery, design, development, and distribution. And for kind of epic-level projects, you know, these aren’t task-level items, but, you know, bigger projects that, you know, usually measured in, you know, one to three months, having projects go through those phases, I think is really important. 

And, that point between design and development, I think, is 1 of the ones that needs to be kind of clear and you want engineering involved in the front half of the process and you obviously want product involved in the back half when development’s actually happening. But, there is a little bit of a point there of need to have things clear enough and requirements specified well enough, and technical design figured out well enough before you go off and start coding and building something in the wrong direction. And that isn’t to say that, you know, you shouldn’t experiment or build things quick and kind of get things out and fail fast, like that mindset needs to be there as well. But, I think even in those scenarios, you want to have sort of an abbreviated version of that, where, you know, what you’re building has enough alignment, enough agreement, you know, and that can be done in the course of a day or two potentially. But, there is a clear kind of handoff there where it’s like, okay, this thing’s ready to actually be, be built and ready to be coded. 

So that’s like in the weeds a little bit with like the product development process. I guess the other thing I’d mentioned are ‘principles’. I think having principles for decision-making is really important. You know, Amazon is very famous for this and it’s very baked into their culture. But, cultural values are important. I helped create the cultural values for Lessen. And, I think those are really great frameworks to have conversations with people on your team and, you know, as you’re, as you’re considering priorities. And then, I think the other set of principles that’s useful is a set of product principles that help you make decisions and help you make trade-offs because often you’ll be faced with something that has some ambiguity and there’s a lot of different ways you could decide to do something. But, if you’ve got a clear set of principles that help you make trade-offs between potentially opposing forces or different considerations, those can be used as a framework a lot of times to help accelerate decision-making and really push decision-making down.

Kovid Batra: So, you talked about making people in place who are taking the decisions; that’s what I understood from what you said right now. 

Chris Bee: Mm-Hmm. 

Kovid Batra: How do you prefer that happening? Like, should it be a collaborative effort or should it be an individual person assigned who is gonna be the decision maker taking all the calls there? Probably they’re the Product Managers. How does it work out well and what according to you, you have seen working out well for the teams? 

Chris Bee: I actually think that’s a pretty important piece and what I found to be successful is really defining who the ultimate decision-maker is for a given area. I think breaking that down by area is important. You can’t go feature-by-feature or project-by-project, but if you look at a given section of the product, a given group of features, I think it is important, and often as a Product Manager that ultimately owns the decision there.

Another framework I’ve used or have described in the past is sort of this concept of a 49:51. And if you’ve got a, say, an engineering leader and a product leader who own a given area, for certain types of decisions, it’s going to be 51% engineering, 49% product; for other types of decision, vice versa. And, you know, broadly, it’s usually the more technical-oriented platform decisions live with engineering, but you want product involved and vice versa. The more product-oriented customer-faced decisions, ultimately somebody needs to be the decision maker. And that’s usually on the product side. But engineering leadership should be right there. 49 is, you know, not zero. It’s, you know, equal partner, but if it comes down to like, there’s a disagreement, you know, there’s gotta be a clear owner, I think. And that just helps teams stay unblocked and, and move fast and continue to iterate because without that, you can just end up a kind of, you know, analysis paralysis and decision fatigue and a lot of wasted time.

Kovid Batra: One more important thing; I have been thinking about this lately. So, this is an ideal thought process where we say when the engineers are getting down to thinking about product as a Product Manager, then that’s when the best products come out, right? But honestly, I mean, I have definitely talked to a lot of engineering leaders and I have been listening to this a lot. What do you think, what kind of trades are there in those leaders or in those team members who actually exhibit this kind of a feeling where they’re really connected with the product, they’re actually involved in the product development process from the point where requirements are getting defined and then they’re feeling accountable for whatever they are delivering? They’re not just stopping after delivering a feature, they’re looking at what product metrics are moving after they have delivered something. So, just, just let me know. Yeah. 

Chris Bee: Yeah. I mean I think it really comes down to the culture that you build in your team and as an engineering leader or as a product leader for that matter.

Again, it goes back to empowerment, I think, you know, making sure that your teams have the, the safety, psychological safety, if you will, to be able to discuss, whatever it is that they think is important for the product, for prioritization that should be worked on. But, also understand the broader business context of what the goals are for the company, what the goals are for the team. And you know, I think there, there is a need for management in some of these cases to kind of be the filter and to be sort of the decision maker in some cases when things need to get escalated. But, you really want folks and engineers specifically to understand enough of the business context to where they can kind of almost make the decisions themselves if they, you know, are able to.

So, my experience has been if teams are moving kind of in their optimal cadence and moving well, the pace of iteration is really fast when teams, you know, are able to make decisions and kind of run on their own. And I think if you can build that kind of culture, and I saw it really at a couple of places that I worked, but specifically at Uber. When I was at Uber, there was really, you know, a lot of empowerment inside the teams and teams were moving super fast, and there’s a lot of freedom to run and build features and create new experiences. And sometimes they worked and sometimes they didn’t. And I think you have to build in that experimentation culture and that ability to test the ideas in kind of the lowest cost way to get it out to customers to get feedback and be able to, you know, make an informed decision with some data.

And then, you know, I think sometimes there is a little bit of subjectivity that comes into play, which isn’t necessarily bad. I think, you know, at some point in the process, you know, it does come down to a decision and there is a little bit of, you know, you could call it bias, but just, you know, kind of subjectivity in somebody’s experience or what they believe to be the most important, you know, direction to go in that comes in. And that’s, that’s okay. You know, not everything can be completely data-driven and completely metrics-driven. You want that as much as possible and you want the anecdotes to match the data is really the key. 

Kovid Batra: Absolutely. It’s probably, it has to originate from the kind of culture the leaders, the management pulls in. But, I also feel that when we talk about accountability and giving them autonomy, defining their success as we do for a product team, if we do it similarly for the engineering team would really help. So, I mean, from that, I would like to like, understand from you, how you define the success of an engineering team and how you have seen the best of the teams thriving with what kind of goals and what kind of success metrics, I would say, in the industry. 

Chris Bee: Yeah. And I think, you know, again, it goes back to goals, and are we focused on outcomes over output, right? And if we’re moving the core metrics for the organization, for the team, like those are going to be the ultimate measure of success. 

And then I think there’s, you know, specific things for the engineering team, you know, the DORA metrics. I think the SPACE framework has, you know, added a more of a qualitative aspect to some of that, which I think is really important. And, you know, a lot of those things, deployment frequency, cycle time, time to restore, failure rate, like those all do matter, I think are worth measuring. I think there’s context that needs to be added to that as well. So, that it’s not just a pure A to B. And you know, if it’s up, it’s good. I think it needs to be considered with everything else that’s happening in the team. And you know, maybe some of the nuances of your deployment cycle or release cycle or what have you. 

But at the end of the day, I think, you know, are you meeting your commitments to stakeholders and customers, right? Is what you should ultimately be evaluated on. And if you’ve got good goals in place, you should be able to align the work the team’s doing with the goals that the company has, and the team has, and you should be able to pretty clearly understand if things are moving in the right direction.

I think some other indicators that, you know, or maybe not talked about as much in a business context are the team health. I think, you know, is the team well-being high? Do teams feel safe? Do they feel like they can communicate with one another and speak their mind and have an opinion about, you know, what’s happening in the company or the organization? I think, you know, happy teams are productive teams, right? And you can measure this through things like retention and attrition and, you know, internal NPS. There are ways to kind of measure this a little more quantitatively, but there’s a little bit of just a qualitative kind of feeling as a leader, you should have an understanding of how your team’s performing and how they’re feeling in general. You know, I think that, you know, building a culture where people feel like they can do the best work in their career and they’re growing and they’re having fun along the way, I think is ultimately what’s most important. We spend so much of our time at work and, you know, we should enjoy it. And I think that’s an element too that’s sometimes overlooked in some organizations. So.. 

Kovid Batra: I’ll just ask one last question that is related to defining the goalsfor the engineering teams. Can you just give us a few examples of those good goals which really seem to have worked for engineering teams?

Chris Bee: Yeah. I mean, I like to organize goals in two, buckets, company-level and team-level. And I think if you start veering into having department-level goals or group-level goals, I think it can get really messy really quick and you can end up with a lot of fatigue around, you know, which metric to pay attention to and who’s responsible for what. So, even as organizations scale, I mean, even, you know, multi-hundred person organizations, I think, you know, you want company-level goals and team, like, you know, atomic, you know, two-pizza team, you know, 10-person team goals. 

So, at the company level, you know, there are going to be the business drivers. They’re often going to be related to revenue and growth and retention and churn and, you know, onboarding of, you know, maybe one side of the marketplace or the other, depends on the business, obviously.

Kovid Batra: Right. 

Chris Bee: So, those, those are in place. But then, at the team level, the more atomic level, it’s like, okay, I think breaking those down into two buckets is really how I think about it. One is project and one is business. 

And, in an ideal world, you have mostly business goals and then the projects are sort of fitting underneath those to drive that metric. And you can get away with that in a lot of instances, but oftentimes, there is a big release, a big new set of functionality, some, you know, very clear customer-driven, you know, new set of features we need to add, and that becomes a project goal. And that’s okay. And having those set up in such a way that you’re trying to get something done in a given quarter or given time period, I think are important, but, you know, I think the business side, if you can break down one of the larger goals to something that your team can directly drive, I think is really important. So, you have to understand what drives, say, a revenue goal or a churn goal or a retention goal they may have at the company level; you have to kind of break that down to its granular parts. And if you’re working on the communications platform, you’re going to have a different goal than somebody who’s, you know, working on an infrastructure platform, than somebody who’s working on, you know, the front end client portal or what have you. Like, it depends a little bit on the team, I think, but being able to have that line of sight between what you’re doing at the team level and what’s happening at the company level, I think is super important because that ties everybody’s work directly up to what is important to the company. 

Kovid Batra: Perfect. I think, yeah, I think that’s a good way to define goals for any team and particularly for engineering team also, which most of the time is enabling some product or business metric. So, breaking down into a project and then to associating that with the business goal that is going to get enabled with that is a perfect way to look at it. 

Cool! I think Chris, this was a really interesting conversation and I think this is one of my longest podcasts that I’ve had. I would definitely love to have you back for another episode, talk on more topics with you. But for today, I’m really, really thankful, and so would our audience be. Anything that you would like to say as a parting advice to our audience? 

Chris Bee: I don’t know, nothing top of mind that we haven’t chatted about, other than to just say to not forget to have some fun at work. I think, you know, we, I mentioned earlier, but we spent a lot of time with our colleagues and with our coworkers, and I think when spirits are high and people are in a good mood and everybody sort of feel like they’re working towards the same mission, it’s just a lot more fun and you get the best work from people and it’s much more enjoyable. And that’s sometimes overlooked, you know, in business context. So don’t forget to have fun. 

Kovid Batra: Totally agree, man. Thank you so much. Thank you so much for this advice and for all the insights that you have shared today. Thank you, Chris. 

Chris Bee: Absolutely. Thanks for having me, Kovid.