ScreamingBox Technology & Business Rundown

Dave Erickson 0:00
You and your buddy built an app MVP that will change the world, and then you found an investor who gave you the money to make it a true SaaS product. But how are you going to scale it for production? On this ScreamingBox podcast, we're going to look at how to scale up SaaS product development and engineering. Please like our podcast and subscribe to our channel to get notified when the next podcast is released.

Dave Erickson 0:50
Once you got your app MVP, earning some revenue, things started ramping up quickly. So how do you scale your SaaS product development and engineering to meet the needs of your new customers? Welcome to the ScreamingBox technology and business rundown podcast. In this podcast, Botond Seres and I, Dave Erickson, are examining techniques to grow SaaS product development and engineering with Drew Harris, fractional chief technology and product officer of theonedrewharris.com. As a former SaaS CEO and seasoned technology leader, Drew has built scaled and optimized SaaS products that have powered businesses, from startups to $100 million products, from pioneering subscription based video training to scaling an event management company, his company, Quantum Delta helped customers unlock new revenue streams and achieve massive growth, like taking A single location franchise to over 100 locations nationwide now as a fractional product and technology leader, Drew helps SaaS companies avoid common pitfalls and build high performance engineering teams. He brings years of hands-on experience, Agile development, performance testing and strategic product roadmaps to create software that delivers stability, efficiency and growth Drew welcome to the podcast.

Drew Harris 2:02
Thanks for having me y'all appreciate it.

Dave Erickson 2:06
Well, to begin with, how did you first work with a SaaS product or company?

Drew Harris 2:12
That's a great question. You know, when I started out, SaaS wasn't a thing, and I didn't even, wasn't even familiar with the terminology. You know, in the early days, we developed products and shipped them to clients or they installed them on your computer. But borrowing from different industries that were subscription based, SaaS came into play. So I guess my first experience with that was when I was running my own business, was started out as a custom development shop, and to deciding I didn't want to have to write the same software over and over again, and I wanted to be able to update it real time as I incorporated new features and new functionality into the software to provide the most value to my customers. So in doing so, my custom development shop quickly became a SaaS shop, and that's how I first got into it.

Dave Erickson 3:20 You know, SaaS is a very interesting avenue. We have several clients who are SaaS based, and SaaS development has its own kind of things that need to be taken into consideration. When you were developing a product that was basically a software product that was packaged software, and as you started moving into, kind of SaaS development, what were the differences you saw in how the software had to be engineered of a product base versus a SaaS base? What were some of the differences in how you had to develop that software?

Drew Harris 3:53
Yeah, so when I was packaging software, I was developing software specifically for one customer where it was very, in my case, it was very custom. This is focused just specifically on their needs. Whereas, as I became a SaaS business, I had to make it more applicable to my audience as a whole, and make sure that the features and the things that I was developing into the software was feature rich for my ideal clientele, which was more than just one company. I think a lot of times a SaaS companies get started in the space, or business leaders get started in the space, and they're unfamiliar with this challenge, one of the things that they can fall into, one of the common pitfalls that I see, is they have one customer that pays more of their revenue than any other customer, and there's this temptation to really cater your product just to them, to make it, ust provide for their needs. And sometimes, when you do that, you alienate other customers. So in my opinion, that's the biggest difference in, you know, package software versus SaaS software. Another sort of secondary difference is with SaaS software, you have the opportunity to incorporate new features, to provide new value to customers, versus, say, this is installed locally, and you're limited to what you have and you know, if you want the latest and greatest, you have to pay, like, a yearly subscription fee, which is not unlike a SaaS, but with SaaS, it gives you the ability to provide those new features and or bug updates immediately. Just as soon as they're ready for production, you ship them to production, and your customer benefits from those immediately.

Botond Seres 5:53
He did mention that it often happens that companies fall into this trap of having one big customer and that it is good to make features more applicable to a wide customer base. But I do wonder how, how do you, do companies actually do that? How do they put this theory into practice? Maybe through an example?

Drew Harris 6:22
Yeah, how do they, how do they make their product applicable to a larger audience, versus just one customer? And that's a great question. I think it's really important. And this was a significant change in my own business when I was developing, uh, and I ran my own SaaS business, was to see the product and to see the software through the customer eyes, to really experience their pains and their pleasures with your software, and you have to account for what is your bullseye? Who is that target market versus the edge cases, as we call them, for those specific clients. I worked with a big, bigger SaaS business, and one of our, one of our big clients, was really, really big, and I can't mention names unfortunately, but they threw their weight around a lot, and they demanded a lot. They, in fact, wanted us to have a specific team just dedicated to their implementation. So they were constantly pushing us to customize the software specifically for their needs. That can be good in some ways, because those customers oftentimes will have you push the envelope a little bit will have you exposed to some situations and some things that your larger customer base may not have encountered yet because they're bigger and larger and they have more revenue, they have more sway, and your customers will benefit from some of those features later on, but at the same time, you really have to balance that with seeing the product through the customer's eyes, and not just the big customer, but all your customers. And what is your, what is your ICP? What is your primary persona that you're developing your product for? Do these features provide value to them versus just that one customer that's having you push the envelope.

Dave Erickson 8:26
One of the things I've noticed, because we do a lot of SaaS businesses, we help them with either doing all of their development or working with their internal teams to augment their development. And we've built several MVPs and then taken them into production. There's kind of this window where people build an MVP, or we build an MVP, and they got the MVP, and they use that for, you know, getting some funding or getting some initial business or revenue flow. And we may have built the MVP for them, or it may have been two developers who just built it themselves, and then they got to start producing an actual production ready app. That, that window of going from MVP to production, that seems to me to be one of the biggest challenges in scaling a SaaS business. Maybe you can kind of talk a little bit about, from your experience, what are those challenges that businesses are going to have to think about and deal with when going from basically their MVP to production?

Drew Harris 9:38
That's a, that's a great analogy there, I'll tell a story to help illustrate this. And this is not my own story. I'm borrowing this from somebody that I've worked with recently, so I can't take credit for this analogy, but I thought it was really good. So what I see is a lot of times are CEOs and executive leadership, maybe even investment teams that are working with these SaaS, as SaaS companies, they want to get in the race as quickly as possible. So they have them build something that can compete. And, you know, it gets them funding, it gets them, let's, let's call it on the race track. But oftentimes what they're building is a bicycle, and they're, they're really competing among people who are on foot. So, yeah, you're gonna be faster than the people who are on foot, and it's gonna get you the, get you the funding that you need. But to go to that next scale where it's more production ready. What the business really needs is a car to compete in like a Formula One race, and that's that competitive market that's out there in the industry. So you're not trying to take the bicycle and make it a car. In many cases, you almost have to start over with a more proven sort of foundation. You have to have a frame, you have to have four tires on the ground versus two, you know, you have to have an engine versus pedals. You know, sure you can augment that bicycle with, you know, electric, make it an electric bike. Make it go faster, make it so you don't have to pedal as much, but are you going to be able to compete against a race car? Probably not very well. So it's really important to note the difference there, and that's just the sort of story analogy, like I said, I borrowed that from somebody else, and it's almost like you have to start over. You have to really understand the competitive landscape of what you're engineering with those systems, those systems themselves. They don't scare, scale very good and if we want to get technical with it, you know, you look at your, your data platform, or your even the way that you develop products, it needs to change. It needs to be able to scale. You need to be able to accommodate more users. You need to know where the fail points are. You need to make things more accessible, handle a bigger load, oftentimes a big problem that I see with, with that transition when they're still trying to ride the bicycle on the racetrack, with the, with the race cars, if it comes to, comes to crashing. So they're crashing their bike all over their place, and they're wondering what the heck is going on? Because, you know, they're pushing that bike just as hard as it can go, but things aren't holding together very good. And then they wonder, why is it not competing? Why am I having so many struggles? Oh, that's because you're competing on a bicycle versus a race car. So you need somebody with some experience to come along in the race car industry to help you go to that next level. I hope that helps illustrate what the question was.

Botond Seres 13:03
I do believe it does. That's a great analogy. Personally, I would be tempted to go in a different direction with this analogy, like if we built a bike, which is fine when one person is using it, but we really might need something bigger if we get a lot more users.

Drew Harris 13:26
Yeah, that's true. That

Botond Seres 13:28
That does need a complete change of foundations and mechanics to be able to carry that many more people. We can deploy many, many instances, more and more bikes, but it may not be sufficient. I would love to hear what your opinion is on scaling up the development side of things. How does a team go from 2 to 20 people? How? How does leadership keep their vision and the team aligned with that vision? How do the teams stay healthy?

Drew Harris 14:08
Yeah, that's great. Yeah, there's usually two pieces that I encounter with scaling a SaaS and one is the systems, which we've talked a little bit about that, and the other is the teams, or oftentimes even the culture. I think that's the underlying issue here, is that the culture of the company changes. When you go from a small development team where everybody can tap each other on the shoulder and everybody knows what everybody's doing with a team of 2 or 3, to a larger team of 10 or 12 or even 20. You know each time you take a next step in that, scaling processes with your, with your team, the culture changes, changes significantly. What worked with a team of 2 doesn't work at the same level with a team of 12. Particularly if one, I see a lot with SaaS companies, and this may just be my, my own personal experience is a lot of times those engineers in the early stages, they're working shoulder to shoulder. They're working side by side. Maybe they have an existing relationship with each other, and they're not in the same town. They're working remotely, but they already have this rapport with one another. They already have a relationship, and they have this level of trust, almost shorthand, with one another and the way that they communicate. Whereas, you know now you've got a team of 12, and maybe half or more of that team is offshore, and they have a whole different culture. Well, how do you bring that in and incorporate that into your, into your existing company culture without completely destroying it? How do you optimize the successes that you've had and build on the future? So those are some of the challenges that I see. How do you do that? You know, there's a, there's a whole alignment process that I go through with teams, and that really starts at the executive level, where I talk about values. What are your values for the company? Why do you believe these things? What is your vision for the company? And then from those values, we talk about expectations. And what are the expectations that you have of your company, your team, and not yesterday, not when there were two people, but now that there's going to be 20 people working on this product. What are those expectations? How have those things changed? And for one, I have to make sure that the executive team is all in alignment with one another, because sometimes they're not, and that causes more problems than others, because those executives are the ones that are communicating their vision, and if they're communicating different visions, different roadmaps, if you will, then the product and engineering team is completely lost. If product and engineering aren't on the same page as the executives and they're all in alignment with one another, that creates a lot of problems. So then that takes us into that next piece is communication. How are you communicating your values and your expectation, your vision, to the team and the team that is executing on it? How well are you executing on that? So one of the tools that I use is I go through this interview process with the leadership team and with the ICs to evaluate where they are in those different aspects that we discussed. And then I'll plug data analytics tools into their code, into their GitHub, into their Jira, their project management, and I'll pull data, and then I'll take what I learned in the interviews and send it to my data analytics, the analytics engine, and it'll analyze whether they're on alignment or not, and identify like, Hey, these are the these are the things that you're doing really well, here's the things that you're really doing really bad, and that's really insightful. A lot of times, executives don't understand how misaligned they are. Again, going back to the bicycle analogy, they think, hey, well, we can just continue on this path and it's just going to work, because what we've done so far has worked, so why not just continue that same path?

Dave Erickson 18:48
Yeah, I find that's a big, big challenge, especially when you're dealing with, you know, a startup of, you know, one or two developers, they got their MVP, they're ready to kind of scale. They got a little bit of money. And when you approach them and say, Okay, your MVP is nice, but it's not going to be your product. Some of the theories, some of the logic you've worked out that stuff is applicable, but you really have to start a re-engineering process. And that re-engineering process should be done by the developers who are going to work on the project, versus you re-engineering what you already engineered. That seems to be a challenge for a lot of startups who have their MVP to convert into production. What are some of the things that you can say or do to help those people kind of release from their old product and start this new engineering development.

Drew Harris 19:50
Yeah, that's, that's the biggest challenge, right? That change management, I started to have a conversation with a larger company. Company than what I normally work with, and they're in a more traditional, legacy software space, and they're wanting to move into the SaaS space. And their biggest challenge is, I did my initial analysis with them was the, the thing that really stuck out was that change management, we've got a lot of people that are stuck in their ways. We've got a lot of people who are, you know, resistance to innovation, and we need your help to navigate that and to, you know, help us create a better culture that's focused more around innovation than it is about keeping the lights on. So in that case, when you have some, well, I guess it works for any case, even if you're going from MVP to, you know, production, is you've got to keep the lights on with your existing product. You have to keep that going. But at the same time, you have to innovate, and you have to almost start over re-engineer, like we've said. So what I like to do is, rather than isolate those efforts, you incorporate those efforts together. So you've got people who are still keeping the lights on as part of their job gets in, getting them familiar with the existing systems, the pains of that system, how that system works, and then also looking towards the future, looking towards that next roadmap, or that next place on the roadmap that the product needs to go and innovating at the same time. Because if you have half of your team doing one thing and half of your team doing the other then that's really not sustainable, because your people who are doing the innovation, they're not experiencing the pains. They're not experiencing the product as it is. They're not getting familiar with that product and in the means that it exists today, and seeing and feeling that pain a little bit to motivate them to go to that next level, and then, you know, vice versa. If you've got people that are just keeping the lights on and they're not innovating, they're not thinking about the future. So if you can incorporate those two things together, not saying that's a silver bullet that's going to solve all your problems, but I think that that's a good starting point in regards to, how do you deal with that change management. You get people working on both things, and you basically tell them, to like, Hey, if you're too resistant to change, this may not be the best place for you, because we have to innovate. We have to build a race car now, and that race car is going to operate differently than that bicycle that we have in the past. We gotta keep that bicycle on the track until we can pull that race car on alongside of it and start making the transition or or like your analogy earlier, with multiple bicycles, multiple instances of the same. You know, we gotta start getting people into the race cars. You know, that's a process too. How do you transform and move from one thing on the track to or and there's never a time where or there eventually becomes a time where you just have one thing on the track, but there's real awkwardness where you have two things on the track and that, that's where a lot of that challenge is, hey, I've got two things going. How in the world do I support things? And there's so much chaos around that, usually, and just being calm in the chaos. And, you know, having teams experience the pain of the legacy system and the fun, if you will, of the innovation in the new system, I've experienced that. That's good way to do it.

Botond Seres 23:43
And to to achieve that goal of getting everyone on board and taking some risk with supporting both the new development and the existing code base. I'm not sure, it's, it's no easy task, and even to just convince people that it is beneficial as to require a great deal of trust. And I do wonder if, if you could share some key strategies to use to build up that trust.

Drew Harris 24:19
Yeah, I think that's, that's a good way to note it like that is that is the biggest challenge. How do you build trust? And you build it incrementally over time. It's, it's not an overnight process that doesn't, things don't just fix themselves. You don't automatically start in a new relationship with a product or a person, where you trust them 100% or you trust the process 100% on day one. It takes time and, and, you know, a mentor of mine once told me the best way to eat an elephant is one bite at a time. So I think you've got to break it down into small, incremental pieces, just like we do with. Uh, taking a large epic of work, a feature, and breaking it down into user stories that are bite sized chunks. It's the same process that, you know, we've, we've done for years as engineers, and breaking big problems down into small executable things. You've got to do that on the people level. So, so, how can I start building trust with people, what are the steps that I can take and if you don't have a plan for that, then you don't have a project plan. And just like, just like with code, you don't, you don't know where you're going. You don't have a road map to get there. You're going to get lost along the way. So having a road map of how to build trust, and then breaking it down to those incremental steps, those user stories, if you will, in engineering speak, is the same way that you do it. In the cultural aspect, is what are some incremental ways, and an experienced leader can help you with that. There's no magic one size fits all. thing. It's going to vary from company to company. One of the things that I did that was unexpectedly successful with a team that I was working with globally, across multiple countries and continents, was we were all remote, different time zones as I started having a virtual happy hour with the team, you know, just just to have that sort of water cooler, sort of experience where we would get online, and it was only once a month, so it wasn't too disruptive and it was on a Friday afternoon, which was challenging for some people in some countries, because Friday afternoon in one place is a totally different time for people in a different place. So that presents its challenges, but having those virtual happy hours, having those places where it's safe to just kind of unwind and to talk and providing that vulnerability yourself as a leader is huge. You know, hey, I don't have all this figured out. I don't know all the answers, but we're going to attack this together. Being vulnerable, sharing your challenges, that goes a long way in starting to build trust with your team and your teams. But in one of those, one of those happy hours that we had, I started to go to the team and say, Well, I want you to participate and bring ideas, I want you to host one, and you give people ownership that way, which starts to develop trust too. So you give them the apps, the ability to plan something and schedule something. Well, we had, we had one lady on our team who had the idea of doing a virtual version of Iron Chef, where we had several people on the team that liked to cook, and so she came up with a secret ingredient, and just like Iron Chef, we did it virtually. And you know, we did it over confluence, where we documented what we made and people's responses. There were some guidelines there, but you know, having just some fun sort of experiences that you can share goes a long way in starting to build that trust versus, Hey, it's all work all the time, and it's 24/7 that can burn people out really quickly, and that diminishes trust.

Dave Erickson 28:19
Yeah, the other side of the trust equation is the leadership and management. And one of the things that I've kind of found with dealing with leadership and management is to help build that trust. They like, I guess, data, they like metrics, they like KPIs. So in dealing with software teams and management, how would you use data and KPIs to help build that trust between management and teams and vice versa?

Drew Harris 28:57
Wow, that's a, that's a great question. So you know, I would start with, what are the, what are the key results that you want, what are the OKRs that you want out of this that are realistic? And then, then let's build KPIs around that, around the trust itself, just like we do with software. So you know that's going to look different for different people. A lot of times, trust has to do with communication. One of the ways to measure, to measure building trust is something as simple that you can measure really well is prs. And who is doing the PRS, and are they providing the right feedback? So, So one of the indicators that I've seen that indicates that people don't trust each other is they're just passing each other's PRs without, without providing any comments, without providing any difficult feedback. If you're not seeing any difficult feedback on your PRs, then that that could be an indicator that people don't trust each other, whereas you might think it would go the other way, whereas, if you're seeing people provide very harsh criticism, you know, on on PRs and just you might think that that's not trusting, but if you think about it, it really is trusting, because I trust you enough to tell you the truth. I trust you enough to give you the hard truths. So as a leader, you have to manage, you have to manage that, and you have to create that culture where it's okay to make mistakes, and we encourage mistakes, and we encourage feedback. Hey, when somebody makes a mistake, call them out, and they're going to do the same to you, providing the sort of accountability feedback loop, you know, if to use a different bicycle and car story, I was, I was riding my bicycle on a country road a while back, and I was on the bicycle, and this car passed me, and they were acting a little funny. I thought it was a little strange, but I was, I was kind of in the middle of nowhere. They were being extra careful. And I looked in the back of the car, and it said, student driver. And it was, it was, it got me thinking about, culturally, it's important to provide those rural roads, if you will, the the places, those playgrounds out there, where a student driver can get behind the wheel of the new car, of the race car, even, and give it a go. And you know, you've got the instructor, the mentor, there in the, in the passenger seat with them, coaching them, helping them, and, you know, allowing them to make some mistakes, allowing them to actually drive the car. And I think by doing that, that's a really good indicator of trust, and you can use that even as a KPI. Are you doing that on a regular basis with your team? Are you providing them with opportunities to take ownership, to be a part of the process, to be on different teams, to look at different code bases, and you know, you don't want to get people to isolated where they're just driving the bicycle all the time. That's, that's an indicator that you don't trust people and that people don't trust themselves. So that's one way.

Dave Erickson 32:35
What kind of, what kind of KPIs would you say are the most important to use and I assume you can build some kind of KPI dashboard, but I you know, dashboards really it. Part of that is also the communication of those who are looking at the dashboard. What are they actually seeing? And what are they you? What do they do with the information? Maybe you can talk a little bit about that.

Drew Harris 32:57
Sure. I mean, there's, there's all different KPIs that you can build as you're scaling your team, and you've got to be careful about what you're measuring, because what you're measuring is going to directly affect what your team is focused on. So for instance, if you're just develop, if you're just measuring, we see a lot of positioning in this industry to focus on speed of development. How quickly are you getting new features out the door? How quickly is your team producing? Are you, are you performing as a team by delivering new code into production and what rates do people do that? How long do things sit in? QA? How long do things sit in, you know, waiting for a PR in these different states, and then what is the life cycle look like of how quickly are you getting a new feature into production? So the temptation is to use these sort of metrics exclusively as your KPIs and the health of the team, and even sometimes the health of the culture. And that's not always the best thing, because that doesn't necessarily say, how well are you serving clients needs? How, how responsive are your customers to the new features that you're producing? You know, I think it needs to go back to the ROI for the business. And oftentimes product and engineering is a black box to leadership, and they don't have clear visibility and what, what is the ROI, and that's one of the biggest things that I help companies find, is what is the ROI for product and engineering itself. If you think about the other parts of the business, they all have their own KPIs, their own metrics, you know, sales teams are evaluated. By how many sales they land, you know? And it's really clear, but product and engineering is sometimes that black box of unknowns, so they just kind of grab at straws of like, oh well, you know, we just need to measure how quickly are you getting stuff to production, which isn't necessarily the best measurement.

Dave Erickson 35:19
Yeah, in that sense, I had a client, and we had a big development team, and you know, the client would say to the development team, I want you to go faster on the development of these things. You're taking too long. Your KPI shows that you're taking too long to develop something. And then the developers came to me and said, well, we need a new KPI, and that KPI is, how often has the client changed the requirements of the software? How often has the client said, Well, I like what you did, but I want something else that should be a KPI, because that's what's kind of taking the time to develop something and making it much longer, so that the KPIs are more balanced so it's not just KPIs measuring the performance of the team, but also the performance of management to lead the team and to give them something as well. And obviously they would want to know how that affects ROI, because you're spending money every time you make a change, or you say, oh, I want to do something different, you know, you're affecting the ROI balance, right?

Drew Harris 36:28
Yeah, absolutely, absolutely. And likewise with, with customer care, you know, I think it's really important to incorporate customer care into those KPIs for engineering, for instance. You know, because if your customer care team is burdened by customers being unhappy because there's bugs in the code that you're releasing, sure you're releasing a lot of stuff to production, you're doing it really fast. But is it killing your customers? Is it killing your customer care department? Because, you know, they're having to fight all the fires because, hey, you've got bugs, you've got issues. And maybe it's not even bugs or issues, maybe your customers are just unhappy with, with the results. So I think it's important to, to measure like, Hey, we've got a new feature that we're going to develop. We think our clients are going to love it, but you need to measure the love, if you will, of the feature once it's in the wild. How much did our clients really love this feature, or did they hate it? And why did, if they hate, hated it, why did they hate it? And asking like the five whys to really drill down and figure out why did they hate this feature that will help identify some of the red zones that are holding you back in your scaling.

Botond Seres 37:53
Oh, absolutely. My personal experience, it might also be a great idea to add some instrumentation to see if anyone is actually using the new feature that we spent so much money developing. There's really no return if it goes unnoticed. And that note, one of the things when developing new features is trying to keep up with the quality that has been established in the past. And the more people are on the team, I suppose, and the more a project grows, the more different it is to maintain that same level of quality. And I wonder if there are some best practices that can ensure reliable liability and just high performance of software at a large scale.
Drew Harris 38:54
Yeah, that's a great question. I'm glad you brought up quality, because that is a big pain point as, come as companies scale as they take that bicycle and turn it into a race car. You know, it's the first time building a race car, and they're,

Botond Seres 39:10
They're great at building bicycles at that point.

Drew Harris 39:14
Yeah,yeah, yeah. Can have issues. So, yeah, you've gotta, you've gotta measure the quality. How do you incorporate quality into the product development life cycle? I say that's a part of the building, trust, going back to that previous thing, trust building is huge. Quality is huge. I think it's important to hold the team accountable for the quality and test along the way, because, like in the early stages, when you're building a POC or a POV and you're just even an MVP, and you're getting it to market, you know you're you're getting it out there as quickly as you can. And you might take some shortcuts. We don't need a lot of times, what I hear is companies that are ready to scale the challenge culturally a lot of times is, well, we don't need a lot of testing. We've never had a lot of testing. So you know, what we've done has worked. Our customers are using our product, and so I have to take, get them to take a step back and say, Yes, but now you're, you're scaling this, and you need to have testing frameworks in place. You hold your team accountable for testing, and QA is a huge part of that. So, so one of the ways to do that is to for certain portions of it, you make the engineering team themselves accountable, like I was talking about earlier in building a team that focuses both on a bicycle, keeping the lights on and building the race car. I think it's important to have the product and engineering team, each team individually responsible for the QA as well as the development. So you have these cross functional teams where it's, you know, everybody suffers together, you know, through the quality assurance process, and if it's not quality enough, it doesn't go to production period, and you've gotta, you've gotta start doing performance testing. That's where I see a lot of companies skip, try to skip that step. And a lot of companies build these race cars, and they haven't done any performance testing, and they put it in their race and it breaks down because they didn't know where the break points were. They didn't know how fast or hard they could push it, and then it fails, and it fails in front of customers. And now you've got customers, and you've got outages, and you've got all sorts of problems. Now the team's fighting fires, and they're like, well, and they're frustrated, because it's like, you've pushed me so hard to get this on the racetrack, I didn't have time to test it, and now it's on fire. And now I've gotta go out there on the track with the other race cars and try to put the fire out. And it burns people out really quickly, rather than like, Okay, we're going to scale. So guess what? We're going to slow down, and we're gonna, we're gonna do some performance testing, and we're really gonna push this car as hard as it can go and find out where it breaks down before we put it on the racetrack. I think that that's kind of key to baking quality into that release process.

Botond Seres 42:37
That's a great point, especially about suffering together through the QA process, I do find that extremely helpful in, in the development life cycle. Speaking of life cycle, I think you already mentioned that it is good to break down issues into small steps, or we might say, iterations, and that brings Agile into discussion, speaking of iterations in a way, and that is typically the go to strategy when teams and companies try to scale in software development. And one of the original sins of Agile I suppose, is trying to balance speed with stability. And the roadmap is being developed. So I, what do you think is the best way to, to manage this imbalance, or maybe bring balance to it? If, if that's even a good way to think about it.

Drew Harris 43:55
Yeah, so speed and stability. I think it can be done well within the Agile framework where you'd just you'd be realistic about your expectations. Going back to that expectations conversation

Dave Erickson 44:14
And management is always realistic about expectations, I'm sure.

Drew Harris 44:19
Well, yeah, and I know that was sarcasm, like they're not always the most realistic about expectations. So what I try to do is make sure that, and you'll notice this with the big, successful SaaS companies too, is that they're more bottom up that the, the engineers have more say, so more engagement into the process, rather than a top down strategy. It's not always the best fit, but depending on your team, depending on its maturity, depending on the members of. The team. But if you look at a company like meta, let's say, well, meta is a huge, successful software company. They are very, very, very bottom up. The lead engineers on the engineering teams at Meta are the ones that are saying what needs to happen. They're in the trenches with their fellow engineers executing, getting things done, but they're the ones who say even, even to so much to say, this is we need a new hire, or we need to work on putting this person on a performance plan. A lot of times it's the, it's the engineers themselves. And so that's just one model. There's lots of different organizational models that you can look at. But if, if leadership is, got its head in the clouds and they have this expectation that's way out of line with what reality is. And, you know, the data just purely says that's not reality. They have to come to reality at some point, and that's where they have to Hey, sometimes you've got to slow down the speed up. Sometimes you have to have the engineers tell you what's realistic now that ca,n can go, you know, in a bad way too, depending on the culture. Sometimes I think the fear of leadership is, well, my engineers are always going to say it takes way more time than it really takes, and they just want it easy, they just want to sit back and watch Netflix and not write code. And you know, that's not the case. And you know, engineers like to solve problems. They want to be working and executing, getting things done. So that's, that goes back to that whole trust situation where leadership has to trust their engineers, and the engineers has to trust leadership, and the way you do that is through alignment and communication. And you know, communicating what the expectation is, and you have to have that same culture that you would have that we talked about earlier on, the development team. How do you build trust within a development team? Well, you create a safe space. You create a place where it's okay for people to push back. Well, you have to do that with leadership too. You have leadership people, if you're listening, you have to be willing and able to listen to your team and the engineers on the team about realistic expectations. And if people are telling you, then you need to listen, and you need to let them tell you, versus telling them they're wrong all of the time, because you're not creating a culture of trust. And what's going to happen with that, if it goes too far down that line is your engineers are just going to tell you what you think you want, what they think you want to hear, because you're argumentative, and they don't want to put up with that. So they're just going to constantly tell you what you need, what they think you want to hear, and they're going to do their best to deliver that, and then you're both going to be disappointed, and that's going to degrade your trust. I'll get off my soapbox now on the trust.

Dave Erickson 48:35
Well, I think it's an important aspect that ,that trust relationship. Sometimes it goes a little bit in one direction, and sometimes it's balanced. One of the things that I found is that, you know, management kind of looks at the engineers in a narrower kind of viewpoint. These are the software engineers, they're writing the code. But there's a bunch of other aspects to SaaS software that fall on the role of management, but they may not plan for it with engineering. And then when it comes time to do something, the engineers are like, well, we don't do that. So I think a good example of that is they get ready to release this new code, this this Ferrari, this race car, and they haven't thought about their infrastructure or their servers, or their, you know, pipes, or any of the DevOps stuff that you know, they think is just part of what software engineers do, but are very separate from writing code, right? And then they, they, they go to the engineer and say, Well, why didn't you think of this? Or why are you asking me? You know, what have I done for DevOps? That's your job. You're the software engineer. So maybe you can talk a little bit about that aspect of scale. Selling that management has to kind of be aware of.

Drew Harris 50:03
Yeah, I mean, it's, it's, I think some of that falls on product and leadership as well. You know, leadership being both product leadership and engineering leadership to properly break it down, break down a project so that it, you know, you're thinking about all of those pieces and how those pieces go together. You know, a developer may just think that they write code, but we talked a little earlier about how we want them involved in the QA process. We want them accountable for that. So I think a good way to make that work for both management and the engineering team is to help them be involved in the DevOps process as well. You know, it's only going to help an engineer if they have more depth of knowledge. You know, if you're just, if you're just a front end engineer, and all you do is write, you know, front end code all day long, Yes, that's good for your specialty, but then you're only ever going to be a front end engineer. You're not going to have exposure and understanding of other things. So one of the things that I try to apply on the teams that I work with is, is this cross cross pollination, so cross training, if you will, where, okay, for this sprint you're going to do DevOps, for this sprint, you're going to do QA, and you rotate those roles. So, yeah, you're not an expert, and that's not all that I expect you to do, but you're going to do that occasionally, so that you're familiar with the process. So that helps the depth of knowledge on the team, and it also helps you, from a leadership standpoint, have people that can cover so my QA is out on my DevOps is out this week, or whatever. Well, John, you've done, you've done this before. Are you comfortable enough to take the reins while we do this release or while we do this? You know, do this week's worth of work. Hopefully that cross training will help provide more depth as you scale, and the bigger you scale, the more important that is. Sometimes people think that, you know, the bigger you scale, the more you should specialize. I think that that's wrong, and I think that the bigger you scale, the more you should generalize and still have specialties and strengths that you play to your strengths, but at the same time, you should generalize and have exposure to more than one thing. So I think that that's a, that's a big, important piece, but there is still that responsibility on product and engineering leadership to scope it correctly, to understand the different pieces that are going to come into play for the development of the project. It's not just writing the code, it's also testing the code. It's also developing those DevOps pieces that are going to support the code and, and, you know, you got to make sure that things are going to work before you put it on the racetrack so it doesn't catch on fire.

Botond Seres 53:18
Couldn't agree more on those points. I do, I do agree very much on the importance of generalization. For a very simple reason, one of the biggest pain points in projects in my personal and professional experience is the loss of tribal knowledge, and that can, well, if not, be prevented, but effectively mitigated by having multiple people being exposed to all different fields in the team?

Drew Harris 54:01
Yeah, you can see that too in your analytics of who's working on what code bases. So if you're watching that and you're seeing like, hey, these two people are the only two people in the organization of 20 that ever touched this code base, then that's a red flag, because now you've now you've isolated that code base, that not knowledge, and it's, it's a pain point, it's a it's a failure point where you need to, like we talked about early diversify. And you know, if you've got multiple different code bases, you should have relatively equal engagement of different members of the team engaged in those code bases, not just one or two people. And that helps with that you know, product knowledge that you know, hey, this is the only person. The person who knows where all the bodies are buried, and they're the person who touched it last so they're
going to get the code. They're going to if there's a bug with it, then you know, Dave is the one, and he's going to be the one that fixes this. And by George, if Dave is out, we're in a lot of trouble.

Dave Erickson 55:21
Well, that's one of the things we emphasize a lot, and it's more important than a lot of people realize. You know, documentation really helps with that. You know, if you're doing something and you're entering into whatever Agile framework or project management software you're working with and you write a, you know, five word sentence about what you did, it doesn't help anyone, right? But if you actually document it and say, This is what I did, and here's the challenges I found, and here's what I did to solve the problem, and you actually document what you're doing, that makes it much easier to transfer that knowledge and also to have, after a sprint or a piece of the software is done, to have the developers kind of document a little bit about how they did it, what are the aspects of that piece of software that are unique and that, you know, how do they communicate that, it's really important, and we emphasize that a lot in our teams, but I think a lot of companies don't emphasize that enough that that kind of documentation of the the engineering process is really important.

Drew Harris 56:29
Absolutely, I, I've tackled that problem a little differently in a couple different aspects. We talked about QA, and now we're talking about documentation, and this, this approach, I think, handles both of those is you do what I call a shift left, so you incorporate QA early on. So before the software is even written, you have QA writing test cases. What are the test cases that are going to prove that the software works? And then you know the engineer, the developer, is equipped with what those test cases are, so they know begin with the end in mind, sort of mentality, hey, I know what this needs to do. I'm ready. So you do the same thing with documentation before you start, I want to see a plan of how you're going to execute on this at a back end team for a large SaaS company that struggled with this, and the way that we overcame it was we had them write the because it was all back in we had them write API specs first and foremost before they wrote any code. So you're writing the documentation, and there's always changes, you know, because as you get into the code, and as you start engineering what you're developing. And you know, same thing with writing test cases ahead of time, you're going to have to make some adjustments, but that's usually more productive to do it up front than it is to wait until it's released, to go back, Oh, I got to write documentation. Oh, I gotta write test cases now. Oh, I have to test the software. If you're if you're shifting left, if you're putting that up front. It's a different mindset. It's a different mentality. But you have greater levels of success in my experience, when you do that and you put it at the forefront.

Botond Seres 58:17
So Drew, in your personal opinion, what is the future of SaaS?

Drew Harris 58:26
That's a great question. The future of SaaS, I hear a lot of business leaders say SaaS is dead. AI is the future, AI is everything. And I don't agree with that, I think that that's wrong. I think SaaS will still exist, and the future of the SaaS is incorporating AI as a part of it. Ai doesn't make SaaS go away. AI is just a new interface to access software, in my opinion. You know, back in the day we had, and again, this is borrowed from someone else. This isn't my original thought, but the interface was Command Line. That's how we interfaced with software. We had to get very specific commands to a command line, and we would get very specific information back. That was the first interface. Well, that interface changed, and we had the user interface, the graphical user interface, where you have buttons on a screen, a way to interact that way. Well, now I think that AI is the new user interface, where you can talk to it. You can chat with it, multiple different platforms, multiple different ways, where it interfaces back and with LLMs and and the different ways that you can retrieve information out of the data store, and the way technology has advanced, you can be more general about what you're asking, and it can give a lot more results than just a really, you know. So command line prompt response. So I think that AI is a big part of the future of SaaS, but it's not replacing SaaS. It just needs to be integrated as a part of SaaS.

Dave Erickson 1:00:16
Drew. Thank you so much for being on our podcast and discussing strategies and techniques for scaling SaaS product development and engineering.

Botond Seres 1:00:25
Well, we are at the end of the episode today, but before we go, we want you to think about this important question.

Dave Erickson 1:00:33
How are you going to grow your SaaS development team?

Botond Seres 1:00:38
For our listeners, please subscribe and click Notifications to join us for our next ScreamingBox technology and business rundown podcast. And until then, think about scaling up your SaaS.

Dave Erickson 1:00:51
Thank you very much for taking this journey with us. Join us for our next exciting exploration of technology and business in the first week of every month. Please help us by subscribing, liking and following us on whichever platform you're listening to or watching us on. We hope you enjoy this podcast, and please let us know any subjects or topics you would like us to discuss in our next podcast by leaving a message for us in the comment sections or sending us a Twitter DM till next month. Please stay happy and healthy.