the replatforming odyssey: guidance from a tech leader

🌐 join us on an enlightening journey through the world of software development with a seasoned tech executive as your guide and uncover exciting insights from a cloud-based SaaS engineering leader.

🛠️ explore the complexities of startup dev environments, navigate tech debt, and optimize resources for success.

🚀 debunk myths about software engineering, understand VC-backed pressures, and the critical path (and often misstep) of replatforming in startups.

🌟 discover why confirmation bias stifles innovation,  how to eliminate biases in replatforming, and avoid pitfalls and dangers.

🤖 gain strategies for successful replatforming, including customer support's vital role and the importance of choosing the right first customer for migration.

🔍 don't miss this deep dive into the fascinating world of software engineering and replatforming! 🎧💡

transcript

josh: 0:07

on this episode we're diving deep into dev, we're examining and exploring engineering and we're excavating exciting insights from a cloud-based sass engineering leader. that's right. we've explored sales, product marketing, product marketing and more on this show. but none of those functions could do what they do without the power of software engineers. but the dev environment at a start-up could sometimes be tricky and political, from tech debt to scalability issues. developing and maintaining software is hard. there's too much to do and not enough time or people or money to get it all done. and it's even harder when the pressures and expectations of a vc-backed company are not being met. we spend a good amount of time discussing replatforming and what that typically means for a start-up. our guest is an experienced tech executive across a number of businesses with over a decade of experience. he's worked on software serving restaurants, government, automotive manufactured and more, and he's consistently overseeing the change from on-premise solutions to cloud-based solutions. he's founded teams and has grown those teams and organizations to be well over 100 people, so he knows how to scale engineering. he's been a part of a number of replatforming efforts and is typically brought in when a company is looking to optimize their engineering time and talent to better meet the needs of the market and the demands of customers. i've experienced replatforming and had i known the insights our guest shares with us today, i would have been well better prepared, to say the least. before we get on to the show, a quick call-out. the stories shared on the diSaaSter recovery podcast are based on anonymous, individual experiences at real companies. the goal in sharing these stories and perspectives is to help fellow sassles learn from each other, get a much needed sanity check and build empathy along the way. no specific company or person is mentioned, so if a story that one of our guest shares feels like an attack on you or an attack on your company. we really encourage you to reflect on your guilty conscience. and with that, let's get on to the show. welcome to the diSaaSter recovery podcast. it's so great to have you here and one of the things i'm excited about besides the entire conversation that we're about to have i had never heard this about this gig before that you have you called it a fractional cto. tell us about what a fractional cto is. yeah, fractional.

guest: 3:36

cto is a role that allows professionals in the technology space to help out various size businesses on a part-time basis. the role of a chief technology officer is pretty vague at this point. it has a lot of different meanings across different industries, regardless of your sass, focus, and what it enables me to do is parachute into organizations, whether it's helping to figure out organizational structure, hard technical problems, cloud spend, reducing technical debt, all of those things. it's a new adventure every day. that's at an hourly rate and usually comes without any board approval, so a lot of ceos who might be listening out there you can hire on. you can bring on a professional to help you out and coach your existing vp of engineering, your existing cto and really get the most out of your engineering product compliance all those organizations that fall underneath the responsibilities of a chief technology officer.

josh: 4:39

so you're the guy that they call it. come in and assess. okay, what are your goals? let's take a look at what you have. here's the gaps. here's how i recommend solving it. by the way, i can help develop and motivate your team, as long as you're willing to take the hourly rate on. it's sort of like pulp.

guest: 4:53

fiction. i'm the wolf. you recall me in when you have a really bad problem, potentially when somebody's head's exploded on the open streets of south la and i come in and clean up.

josh: 5:06

clean it up. clean up crew. i love that fractional cto. i'm going to have to try to find something like fractional product marketer, fractional podcast host. i bet there's a market for that. if anyone's listening to the show and needs a host of their very own podcast, you can call this guy. i'm really excited to talk with you because we've covered on the show so far topics related to marketing, to sales, to business development, to product management as well. really, none of this is able to happen without a product to take to the market. the team behind making that product is a development team the software engineers. really excited to explore this topic with you. i want to start off with just understanding how do you define software engineering?

guest: 5:59

it's a great question. i think software engineering is understanding what the customer needs. it's working across discipline, from product to sales engineering to customer success, to figure out the best way to deliver delight to the customers at the lowest cost with the highest degree of scalability. it's our role to understand how things will work in production and how to really engineer not just develop solutions that delight everybody and make sense for both the short, the mid and the long term.

josh: 6:40

i like that you use the term delight. i feel like that was a very intentional word choice. why do you say delight as opposed to delivering on pain points or anything like that?

guest: 6:55

in software development. there are a few methodologies. you hear about agile, you hear about kanban. in my experience, there's this term mvp minimum viable product. it's all well and good, but it's really the v where you get some controversy. it's what's viable. in my experience, looking across all of the different stakeholders from sales to customer success to product management to customer support you all have a different view of what that v is because you're motivated by different pieces. when i say delight, really what i try to focus on delivering from a unified r&d team is what's that minimum lovable product? what's that minimum delightful product? when you look at a lovability, a delight index, and not just what viable is, where it's too black and white, i think that delight gets us into some emotional quotient. i think that when you look at it through that lens, it's a lot easier to find common ground across all of those different pieces, because delight is a degree. viability is very black and white.

josh: 8:07

i like how you put that there is different perspectives on what is actually viable. now, i'm very much a big fan of minimally viable products because i tend to be a perfectionist and that doesn't go well, particularly in saas startups. right, i have learned the hard way to focus on what's that minimum level of quality that i need to get to to feel good about whatever this work is that i'm doing and deliver it, and that quality depends on a number of different factors, like you're talking about. who is ultimately going to be impacted by this and what are they really representing with their concerns? what they're looking to accomplish with the work that you're doing? i like that you're reframing it from minimally viable to minimally lovable or minimally delightful. my own notion that i came up with well, in my head at least, prior to this conversation was the idea of a minimally adoptable product, because it's similar to what you described sometimes, that that debate of viability doesn't always end in something that can be actually used and implemented by the customer in a way that the customer wants to do it, because sometimes you can argue that well, it does this thing, you can use it, and they're like i don't wanna do it that way, that makes it not adoptable at that point. so i love how you broke that down. i we talked about the idea of delight. i like how you broke down software engineering as more than just coding or more than just infrastructure support for the product. i like how you really established that kind of this responsibility that everyone needs to know and understand the customer and why you're doing what you're doing and collaborate to get that in goal. so i can only imagine the impact you have as the fractional cto, because that's such a great perspective to bring.

guest: 10:12

i've had some opportunity to learn from board members and see folks that are much smarter and more senior than me, and one of the pieces that i've learned in those experiences and in those exchanges is in modern software development the engineer has an opportunity to be a 10x multiplier by empathizing with the customer, by putting them first that sales, product marketing, product management in some ways and it's not to be derogatory, but they are overhead to that product creation process so that you can be customer first and you can understand their pain points and you can come up with great ideas and rapidly push them out to production through things like continuous integration, things like continuous delivery. what an opportunity to rapidly feel that up into the right product market fit and do some really fun things.

josh: 11:06

absolutely, and that sounds like a unique take that i haven't heard before on it. and that leads me to my next question. i really wanna understand from your perspective what have you found that people typically get wrong about software engineering?

guest: 11:23

i think that there's this and you touched on it a little bit that hey, go code it, nerd, right. i think that that's an important piece that let the folks in a dark room in their parent's basement and our covid work from home lives. just let them go figure out. hey, we need to micromanage them because they cost a lot. we don't understand what they're doing. we have to have all of these stories in all of this process to micromanage a creative process, because we aren't really sure about what the outcomes are. we don't know how to measure, we don't know if we're getting the true value, and i think that not enabling them to solve problems. and it comes down, in a lot of ways, to the difference, in my opinion, between what is a developer and what is an engineer. and as you're building up your software engineering capability, you can hire developers and they are robotic. they will do whatever you tell them with and they have no connection or accountability, responsibility to the outcome. they will put out whatever you ask and if you say that you want to have a button that does nothing on the page because it's gonna help with a sales cycle, they will do it, even if they think it's done, and while an engineer will get more into the ethos, they'll understand the why and they may build a series of buttons that connect and provide that value. and as you're building your organization and you're thinking about what people get wrong and how to avoid that in saas or any organization it's, which do you want and are you willing to abstain some of that control for a potential larger payoff, by allowing them to be creative and deliver and engineer amazing solutions that are potentially beyond what we ever thought of? when you think about some of the investments that have happened, it would chat to you with all of these really creative pieces those that have happened from developers, that happened from open green field engineering, that defined markets and built whole new product categories.

josh: 13:29

i like how you started it out with a quote hey, go code it, nerd. i immediately thought of a sales rep there like just go build it. i'm trying to close this deal. i'm wondering if that's what you're quoting, but i will press you on that topic. you know one of the things you called out. you talked about that idea of micromanage and it sounded like it was coming from a place of maybe fear or uncertainty, because you followed that up with this idea that well, they don't know how to measure, they don't know if they're getting the true value out of the engineering team. can you talk to us a little bit more about that? what are the difficulties in measuring and determining the true value?

guest: 14:12

yeah, i've gotten a lot more exposure to this via the fractional cto role, coming into various organizations and interfacing with ceos. you know a lot of chief executive officers, a lot of chief operating officers. they're coming from the sales and the business side and there's this interesting dichotomy between the chief technology officer or the head of engineering and that sales side, where they don't really speak the same language. if you're on the accounting, you're trying to run an fpna or a budgeting process, you're just looking at the black and white, the dollars and cents that you're spending and the outcomes, which should be story points they should be valued to customers without understanding the process and some of that creativity that goes into it. but what i try and do is bring actual data. i think that on the sales side, great sales leaders who i've had the pleasure to work with are all data-driven. they understand what their inputs are and for their sales cycles, how to motivate their sales reps with quotas and other things to get the best out of them. so when we're able to look at engineers, we're able to look at some amazing tools out there, like linear b is a favorite of mine at the moment but what is the output? where are we spending our time? if the time that an engineer is spent is in too many meetings, how do we work on that? if the engineer is seeing too many bugs get kicked back or features that are misunderstood or not completed, is that due to bad requirements? is that due to poor focus on quality and not testing their own things? there are all these steps along the way that, if you measure, you're able to show the value and the lack of value. as you're having those discussions across the organization. i think we have to highlight it and it goes away from that hate encoded nerd sort of mentality of we're all in this together. what are the quarters that we can cut and how do we get the best out of highly focused time in order to deliver these features?

josh: 16:20

because we always need more resources and it's always a constant battle of how can you, how can you get the biggest bang for your buck, how can you focus on what truly needs to be prioritized? because you're not gonna have enough people, you're not gonna have enough time, you're not gonna have all the talent that you want, you're never gonna be operating what you would consider ideal conditions. i like how you were really talking about establishing what is the reality, because these perceptions and opinions get developed especially coming from a place of ignorance, because there's no other word for it, it's just a lack of knowledge. on the particular topic, you mentioned certain executives who come from the sales and the business and the go-to-market side. i mean, that's a totally different perspective than someone coming up from a more technical path and understanding what's happening, what needs to happen, et cetera, but really being able to identify when you are having this preconceived notion and taking it out of something that's in your head or an echo chamber of your team or your peers, and really bringing in the data, like you talked about. certainly, critical data can be kind of difficult and sounds like some of the problem is well, what data do we capture? how do we capture that data? how do we then determine if this data even matters, that type of thing? so i imagine there's a handful of challenges just tackling that topic alone.

guest: 17:46

and there's some terms or phrases that my colleagues and i own the engineering side use. you have to be really careful when you're talking to the other side, when you bring data to a narrative fight or vice versa. right, if people don't like the story that the data is telling, if it doesn't match some of their experience, what a customer is really mad and they're threatening to churn out. but everything that you see in amplitude, everything that you see in datadog from their usage is still up into the right, even though they say they're gonna pull the plug. how do you resolve that the feeling versus the data that you're seeing? and those are some of the toughest conversations that you have within an organization that trying to align perception versus reality.

josh: 18:32

and context is critical, right. the data can sometimes be just as subjective if you're not providing the right context with it. if you're already making assumptions and looking to use that data to confirm a particular bias that you may not even be aware of, then the data is kind of the same situation where now it's fitting a narrative as opposed to really exploring. what is it trying to tell us? what are the clues? how do we really understand what's going on here? now i'd have to imagine that, especially in the experience that you have and the leadership roles that you had, you're encountering strong opinions constantly about software engineering and from software engineers and engineering leaders. i'm curious what is a strongly held opinion that you've encountered frequently within software engineering or about software engineering that you just completely disagree with?

guest: 19:32

you know, i think one of the pieces when i come into an organization i've been lucky enough to enter with some fairly well-established engineering and product and design teams with pretty well-established r&d squads i think the biggest misconception when i come in as a new engineering leader that i think people really latch onto is the idea of that everything that was done from a zero to one or a one to 10 as an organization, as a business grows, that somehow it has reached a point where it will no longer scale, where it is wholly unviable, and that a rebuild, some massive migration, is the only path forward onto a more modern tech stack, onto, you know, in the service of security, in the service of being able to move a lot faster, to leave the old behind and do a big bang migration to what is next. i think that i've seen it so many times in my career. i've seen so many organizations have appetite for it, only to have their eyes sort of be bigger than their stomach and have a lot of lessons learned and scar tissue and experiences with how that can go well and how it really does not.

josh: 20:58

that's an interesting topic, that idea of replatforming, somebody coming in and being like, well, out with old, in with the new, and i'm curious what do you think some of the drivers for that is because i've already found my mind going to certain assumptions, but i'd love to hear from you why do you think that this idea of replatforming or this popularity of replatforming, especially by newer engineering leaders, is something that you've encountered on a frequent basis?

guest: 21:27

so i don't know if it's engineering alone. i think there's some human nature that ultimately comes into this too. think about the last time you took a new job as you came in and you found what has been happening. you're there to make change. things aren't going well for you to be brought in, and as you're looking at those changes, the first thing that you're going to notice as you dig in are the corners. if you're accomplished and you were experienced in your role, you're going to see the corners that other people have cut in order to get where they are. it's going to stand out like a sore thumb, and if you're trying to show value early on and that you are an expert, it's really easy to poke holes in and highlight those. it's the poor job that somebody else has done. you're also trying to not make it about the team. you're trying to make it about your predecessor and give yourself ability to shift and pivot in your first 90 days. and so whether you're a sales leader coming in and saying that your funnel isn't real, whether you're an engineer leader coming in saying your platform sucks, that you don't have the right icp, like, we all do this same stuff. i think that for engineering. when you come in and say it's time to replatform. number one, there's often bias because you might not know the length as you're going and being hired. you aren't really the expertise in java or python or php or java like those aren't necessarily important from a leadership perspective. it's how do you get the most out of your engineers and you aren't necessarily in the code every day. so there's some bias to the familiarity you have with what you built before. same thing with microservices, same thing with a certain cloud provider and you can see a path because it's more familiar on how to move faster. there's often bias within the executive suite as well to say, well, things aren't really going well, we are getting as much out. maybe it's because we don't have the best talent, maybe it's because we're writing in cobalt, we're writing in something that we can't find the right resources at a reasonable price. who can help us? and everybody's looking for the easy button or the silver bullet that's going to solve all of your organization problems. and replatforming is a popular one because you can come in and say, oh, we could easily do this in three months and you leave out all the things that would lead up to that, because that's a nice round number. it's about a quarter, maybe it's two, and it's all too easy to be able to show your value and solidify that. you're in the middle of this replatforming and you can make it as a cto for 12 to 18 months.

josh: 24:08

that's an interesting idea that someone would think completely starting from scratch and building a new is easier than running with what's already been created. now, i'm sure there are plenty of situations in which it was just an absolute shit show to start with, in which case, sure, replatforming is a great idea. but i like how you really brought it back to the human nature side of things, because if we take saas and development out of it, we just think about how people tend to act with certain things like diet trends, for example, keto. no, don't get me wrong, i like keto, i've tried it. but that's a dramatic change coming in and being like no more carbs, out with the carbs, in with the fats, and my body will be replatformed. you see really rapid results, right, until you go to the third. really rapid results. that joke's good. yeah, three months, three months, nothing but bacon and cheese on that. and i like how you brought it to that idea of bias that's coming in. there's some credit that needs to be there. you called out that idea that you're brought in because something does need to change. they need help with something, something has to change. so it certainly makes sense that you're gonna come in and look for where are the gaps and how do i think it's gonna be best to fix them, and best is gonna go back to our conversation on the minimally viable right, the minimally lovable approach, which everybody's gonna have a different opinion on. so it sounds like this perspective is very much consistent with human behavior that we see in other examples. i think it's such an interesting take. now you've got some diSaaSters under your belt and you have one ready to share today. i'd love to get into the story time. talk to us about your diSaaSter that you experienced.

guest: 26:01

yeah, i think it follows that same line of replatforming and it's not one specific experience, it's across all of these different businesses about what happens when you go through replatforming and at various stages in my career, sort of entering as a naive sort of engineering leader who thinks that it's just a engineering problem, who doesn't necessarily understand how to build and get the collaboration and the buy-in across all the other pieces. and there are a couple of different ways that i've seen a replatforming happen. there's engineering going at it alone. there's the ceo is looking for it and backs up the engineering leader. there's everything is on fire and we're under duress because we're reaching a scaling point that we were unprepared for. and i think that those are the challenges that i've seen and as i look at the stories, i wanna walk through how this normally happens. so when i take it and i come into an organization, most often they've just taken and raised some funds. as they've raised those funds, they have capital and, while it's not necessarily in the series b, in the series c, they are trying to pour some gasoline on their go-to-market, but they're reaching the limits and as part of that fundraise they think that they have to reap. so they bring in a new engineering leader because product and engineering design are not working efficiently and they need vision for where it can go to. and most often that is a ceo who has had probably directors, maybe some vps who have gone zero to one or one to 10 that they are frustrated with because things aren't moving quickly enough and they know what those changes are and they've been told either they're advisors or from their past experience they need somebody with different perspective in order to execute on this new vision. so they bring in somebody like myself and we find these same things that i was talking about. how do we immediately show that value? oh, it's antiquated, it's not gonna scale. we talk about the cloud, we talk about the cost savings, we talk about the security, and they love that. they say, yes, let's go forth and do it, and oftentimes with that charter. after you've investigated what's currently there, josh, when i were talking about the first piece, that happens and what i've seen more often than not is that engineering r&d understand that they have to replatform and what do they do? they go into a back room, they close the door and they'll disappear for a month. i've seen it go up to a quarter, which is crazy and they are going to get into this echo chamber about what the perfect vision is of a new platform, one that will solve all the problems that are immediately in the front. they'll take and have in mind who the loudest customers are. where things are falling over, where they can get into the back room, they'll get things over. where they get distracted with bugs today, where performance issues and bottlenecks are, and they'll go in and they'll brainstorm and they'll use various techniques to figure out what to do with what the ultimate solution made completely on their own, just no input from, let's say, customer success or the product team or sales and marketing. maybe the product team would be in there, because they are meant to be a voice of the customer. they are sort of if i think about the raci they are consulted, right, but they are not accountable or responsible for any of this, and they will figure out the technical pieces. sometimes the ceo or the coo, cto, of whoever is taking the spot sometimes they will also have a consultant in there in order to think through the viability and really, out of that exercise, the ceo has sent this team away with two questions in mind what is it going to cost and how long is it going to take? they are already sold on the vision that you need to replatform, but you're sending engineers into a room to think through those two things.

josh: 30:53

you know, one of the things that sticks out to me is how much of an opportunity there is to go down the wrong path in that example, because, really, when we're talking about a product that fits a market need, the focus has to be on what is the problem that the customer is experiencing and what is the best technological solution, the ideal technological solution, just the ideal solution to that particular problem. and when that's not top of mind, when the distraction comes on. well, what are we seeing the most bug reports on? or where are we hearing one particular customer scream the loudest about? or ai is the biggest buzz, and our executive team and our vcs want to see ai in the product. that all gets away from the true purpose of the entire company, which is to fill these specific needs experienced by these specific people.

guest: 32:05

and i think there is an important piece of product vision that comes into this. where are we going? what is the vision and what could be the next bit of innovation? and that can come from product, it can come from engineering, but, to your point, you have to be really careful that you don't get into a mindset of having far more customers in front of us than behind us and forgetting about those customers that you currently serve and how to expand and continue to service them, while opening up and welcoming more.

josh: 32:39

yeah, because a dramatic change like that, like a rip and replace, may not be the best customer experience which leads to some conflicts.

guest: 32:50

so, as the engineering comes out of this, it's time to go and they say it'll take a quarter, it'll take four years, whatever it is. they have an estimate on time and on materials and now it's on the cto, with some of the backing of the ceo, to go in and shop this to the other leaders in the other departments in the company and you get some interesting conflict there. that sales right. the new sales reps are excited. they're going to have something brand new and shiny to talk about all the possibilities that's going to help them close deals. customer support gets really worried. they're like oh my god, i'm going to support two different platforms. how am i going to learn it? it's totally different technology. we have all this documentation on the old. what's it going to do? it's trying to narrow and bring in the scope of what it's going to be, which means that they're thinking about mvp, not minimal, lovable product. so how can we get the smallest bits out there to exercise this new platform and show some value? and the biggest point of friction comes with customer success, because in order to go and replatform and think about all the new capabilities, you're pulling resources. no matter how much you raised. you're pulling resources from focusing on the features and the bugs and things that each customer care about and we're asking for and every csn who i know. they have their own google spreadsheet or their own list of wants that come from customers and their view is very narrow. all that they care about is nrrgr. they care about their paychecks and keeping their customers happy versus the universal customer, a client for the organization and if you're focused more on everybody versus those specific pieces, they're not going to see the expansion and they're going to feel neglected, which is going to cause a schism within the organization where you're going to begin to not disagree and commit. it may last for a little bit, but you're going to start to undercut and the rumor bill is going to start with what is going on over there why aren't we focused on our existing customers and you start to get a pretty segmented organization, which can be dangerous.

josh: 35:15

yeah, you know, i've heard that term disagree and commit before, but you bring up a good point. sometimes the commit is not there and instead of commit, it's the undercut, it's the sabotage, it's the let's politics and get this change, or let's lobby and get this included into the first initial release. it's a tough situation to really examine, because you absolutely must have those people who are representing the customer and advocating for their customer and you also have to have that broader perspective of what's going to be forward-looking, what's going to serve us the best in the future. what are the ideal customers that we want to work with and that we want to serve? does that include the customers that we already have? are we willing to sacrifice some sort of revenue or expansion revenue in order to achieve whatever this goal is, whatever this vision is that we have? i get it. it's tough, it's a tough thing to navigate and i don't know how you do it.

guest: 36:23

going through a multiple line. this is my diSaaSter at multiple companies is i think they're my advice to anybody listening. and the piece that i've learned is there are two really dirty words. there are two things to be aware of as you're thinking about replatforming and you're thinking about this strain between the different parts of the organization. the first one is migration. that is an awful word and i think that we constantly under scope and under appreciate how painful migration can and will be and what it means for our customers and our ability to manage organizational change internally and externally. and the second piece is parity. to any engineering product r&d leaders, parity is such a loaded and dangerous word. it assumes that we understand how our product is being used and why it's being used, the vast amount of professional services and things that have been put into a legacy platform that are from yesteryear of generations of engineers and product folks that have moved on. the idea of parity being a requirement is something that can never be successful in my opinion and in my experience, and you have to watch out for both of those pitfalls if you ever have any opportunity to migrate either partially to new technology or wholesale in some sort of a replat.

josh: 37:53

those are interesting points. i'd like to define it just a little bit further, because you talked about how migration is going to be a painful topic, but what do you actually mean?

guest: 38:06

so migration is moving between generations of these platforms, and how frictionless is it supposed to be? our friends over at salesforce, who are not a client, not associated anyway with lightning and some of their replatforming they've been at this for about a decade to various levels of success, to integrate their platforms together and to various levels of paying for their customers. i think that when we talk about migrations and we talk about that scope of coming out of that room and selling this from engineering to other parts of the organization, is that migration will be seamless, that through the ui, the customer will be interacting with new technology without having to move any of their data. everything will work exactly the same. it'll just be scalable and everybody will be happy, and oftentimes, because we don't know how the customers are using it, that never factors into those estimates. that never factors into those costs. really, what you're talking about is it bringing up a feature lacking or a feature light version of the software that can bring on new customers that we can learn from. that? we can scale out where you're running two things for a little while, but ultimately you're asking customers, while the data may be moved, you're asking customers to enter things into two places and to interact with different experiences and setting the expectations that there's variability between the two and those expectations are often hard to manage.

josh: 39:40

the image that i'm struck with in how you describe migration is the scene from indiana jones, where it's one of the first scenes, and he's got the little bag of sand and he's trying to seamlessly switch the treasure out for the sand and he takes them out, he gets rid of some of the features of the sand, so to speak, and he does it in a big boulder just coming right at you, the big boulder of adding customers to adopt it.

guest: 40:10

i love that visual and, as i'm thinking about it, there is this perfect moment that wraps it up, where, indy, he puts on the sand and he gets a smile and he's holding the idol and he thinks that he's done it, he thinks that he's okay and in the background you see it lower down and you're like, oh my god, it's my diSaaSter, this is not going to work. that's right. that's not going to work. having launched these and launched these platforms and things that are on the side, or these new platforms, it's wonderful to get the organizational buy-in to celebrate and say we did it, but that is only the start of the work. and then you're running from this boulder and you're getting through all these booby traps and it's only part of the way.

josh: 40:52

yeah, such a good, applicable moment. who would have thought, indiana jones, the lessons being applicable to sas and to software development, so okay. so the terms migration and parity comes up. parity meaning okay, whatever you deliver, it has to do everything that we were already capable of doing in order to migrate, to even start, to even start, that's right. and then that goes back to that idea of minimum viable, minimum lovable, all that stuff. so, certainly in a tricky situation when it comes to replatforming, what tends to happen next?

guest: 41:32

so i think that let's say that we got to launch, so everybody bought in. we've spent three months probably turned into nine months in order to build this thing. we have a feature light product out there and nobody wants to use it. customer success will not migrate into their customers because it doesn't have parity. they're already sort of undercutting why we made this investment. the ceo is getting heat from customer success because nrr and grr are lower because we aren't. there may be some churn because we aren't focused on the features and things that customers need, because it's going into the new platform that nobody will touch. and so you come to this crossroads where you engineering the cto and often the ceo say let's just pick one, let's find somebody to move over, and you may say all right, let's take whomever the newest customer is. sales has already been talking about all this great stuff. let's take a new customer and put them on it and that's all fine and good, but it doesn't begin to really bind everybody together. often there's little revenue that goes along with it. there are long implementation cycles and saas, so it's more of a token celebration that somebody's on it, but usually you're taking say let's pick one of these existing customers. let's do the hard work of going through a migrate and maybe not surprisingly, it's always easy to stick your biggest, hardest customer, one that is fraught with risk. but by moving them you will have understood all of the challenges and there's hopefully in your icp there's enough liken data points that you would feel really confident in how it would be able to move the other 25%, 50% once you did that. so you may pick somebody that's a medium customer, but you have to sort of hunt the whale on some of this and i think we also get into trouble in that whale that they're. often they've been neglected, they are a cash cow. they want all of these features, they want all the promise of this platform and they may be seen and they may say in ebrs and in calls with your csm that they want to be part of the development process, they want to engage this, they understand how software is built, they want to give features, they want to give feedback, they have time to test, move us over. we're going to engage, be a great customer, and i think that for myself, being a large purchaser of saas products across a number of organizations, what i will tell everybody is that nobody wants to help their vendors. nobody wants to spend time testing their software for them. you may say that because you want to have your finger on whatever you care most on the scale of features and be able to give them feedback on how web hooks work or the sap integration, like whatever you care most about. you say that you'll do it, but nobody wants to talk to your saas vendors. nobody wants to give feedback, nobody wants to give them. the cycles and the stakes are too high. you have a day job and so it always falls down there that you think that you have this sympathetic customer who's going to be a great partner in it and you're left pushing them on to things that they haven't had time to vet, that they don't really want. that has far too sharp of edges and it comes out a bit fraught and you end up having to do some damage control and hopefully you come out the other side, but more often than not it's far too easy for them to stay on the legacy.

josh: 45:26

you bring up a good point with nobody really wants to help develop the tool, and it's really. i'm sure the intention is there or the goal of getting exactly what you want out of the software. solution is certainly there within customers, but it's the fact that you got a day job and this tool is there to help you do your day job. but the tool is not your day job, or at least it shouldn't be, because that sounds like a complex tool if that's the case. now you mentioned that somebody decides we should go for the biggest customer, because that's what's really going to prove that we're on the right track and if we can do it with them, we can do it with anyone on kind of like new york, new york type stuff. if you can make it there, you can make it anywhere, which i don't think is true, because texas heat will destroy you by far.

guest: 46:18

by group factors, for sure.

josh: 46:19

different factors? yes, just because there's a lot of variables that come into play. that's really what it is all these different variables, that you understand them, you understand how you're impacted by them, etc. totally different topic. we can get into frank sinatra and the philosophy of his music some other time, but i think it's kind of crazy that that's the jump of let's go with our biggest customer and not only are we making this dramatic change to our solution, but we're making a dramatic implementation decision like these big, big, like extreme examples.

guest: 46:56

well, i think, politically, you've raised money. you're in for a penny sort of in for a pound. let's say that you're 12 months in and you've spent millions and millions of dollars. your board is getting exhausted. they're wanting to see progress you're starting to fight for. is this thing going to go toe up? are we going to revert back? are we going to have to to sure up the legacy thing that this cto has sold and said was non viable? like what does that mean? cto is going to be fired. so what they're saying is let's get the biggest customer onto it so that we can't go back and there is some security that comes into it. that, hey, this new thing, it's viable, it's working, it can meet all the needs. anybody who wants to stay on the old it's not going to work. we have critical mass. you have to move.

josh: 47:52

got it, to put it, in a situation where there's no way back, the only path is forward. and sure, i think that that can be a very motivating situation to be in, for sure, but it's a scary one. it's a life or death type one. well, to a degree, right, it's not life or death, but it's life or death for the company, i should say.

guest: 48:18

i think back to some of the ethos and processes. i know that amazon have. they talk a lot about one-way door decisions versus two-way door decisions, that if something is reversible, you want to push it down into the organization, you want to enable managers and folks to make the best decision as rapidly as you possibly can, and if something is a one-way door decision, it needs a lot of analysis, needs a lot of focus, and i think what you're trying to do is, given that you've sent all of these engineers away, that you've garnered all of this support whether it be genuine or not for replatforming to try and make that as much of a one-way door decision as you can. the idea that you can still go back. it means that you were unsuccessful in moving really rapidly and spinning something up. that it's sort of the worst of both worlds, where it took you a really long time, you invested a lot, only to go back and it will sink a company.

josh: 49:19

so you have to commit 100%. in these types of topics, it's a decision. if we're going to do this, there's no going back, and i understand that you don't want to do this, whichever team i'm talking to at the time. i understand that this customer doesn't want to do this, but there does have to be that. let me make it clear we, as a company, this is the way we're going, and the option is to be on board or to get off the ship. yep, in extreme terms. okay. so somebody comes up with the idea let's pick the biggest customer, let's force a hand here. there's no way out, no way back. when we go down this route, what do you see that typically happens next?

guest: 50:03

i think either that customer who gets really frustrated, they come over and they are okay with some of the limitations. they straddle both of the platforms. oftentimes you learn things and in engineering maybe you end up doing what was called like a split brain implementation, where you're trying to sync data between the two, you're trying to offer both experiences, but ultimately they come over and now you have your largest customer and maybe some new customers on this platform. things are going okay, it's starting to stabilize, but you're still hearing all of that frustration from the legacy platform and now your cfo and your board are asking why you're still spending money in maintaining that thing, because they were expecting, with the investment, that everybody would be migrated over, that they would be onto the new thing. and you start to look at your engineering investment and you're not seeing the savings in the promise. on your bottom line and that's where you take in you have to make some really tough decisions about either accelerating migration, which means spending more potentially, and or taking and trying to offshore or find other savings to continue to maintain these things.

josh: 51:25

find a way to move faster to get to whatever the original milestone or goalpost was. i think you had mentioned earlier that you said specifically. you know three months turns into nine months and i imagine that that timeframe may continue to expand, especially the more pushback you receive internally or the more legacy issues pop up and the limited resources then have to go to maintenance, like you said, i would imagine. i mean, this is not all on the engineering team. there's, there's got to be responsibility at the executive level to really really drop the hammer and say get it together and identify which orgs are not working together and then make them work together, because, again, this is the way we're going, if you don't like it you can leave.

guest: 52:18

i think that that does happen. it usually takes longer than you expect. i think you know, having overseen a lot of different parts of the organization that are outside of just engineering, i have some some empathy, i think. where we're who i think gets the shortest end of the stick out of all of this is customer support. like, how is customer support supposed to maintain and be able to troubleshoot these two things? how are they, if customer support not customer success, but customer support often have an nps that they're trying to drive? how do you marry that with the folks that are happy with the new platform but really angry about the old, when all they have to do is migrate and their numbers would go up? they are stuck in the middle and the leaders of customer support are often seen as ineffective and like they're they're. they're not on board because they're totally trapped in the middle between all of these organizations, and i've seen it play out too many times either where they get burnt out, they quit and they leave, or they're putting the you know, impossible position that they have to pick a side and there's no winning.

josh: 53:32

it doesn't sound like there's much of winning so far. in this entire scenario, i'm curious is this how the story plays out? is it just something that's typically doomed from the start, or is there a possibility for success?

guest: 53:47

i think that there are potentially some possibilities for success in some ways maybe to blow the ending in the summation i don't think that wholesale replatforming ever worked. what i have seen take it work and what i think has promise is if you use technologies and better implementations and more modern practices in order to offer things like new product lines, if you're able to offer new features and integrate better ways to do things. in engineering, we have patterns for legacy systems called strangling the model. that's a practice that we take where we try and peel away parts of the old with parts that are new. it takes longer, you have to have really great testing. you have to have a good understanding of how the application works. those are the things that are often much more successful because there's less customer pain. it takes longer and it potentially costs more. you don't get the big bang of having a press release of a shiny new platform. if you take this approach and you're able to offer a new module or a new product, like something that's a product led, a light version of the application. if you're able to offer something that is a new module, that is ai insights, that's all built on new technology, those are the ways that you can find success where you don't have to go wholesale and where you can talk to your customer success team because it's additive and get them to opt in, get them to buy in, use their data, to show them the viability and the value without any of the customer's pain. those are the ways that you find success, in my opinion, where you can unite the organization. it's not just an engineering behind closed doors then, it's taking in service of the business, in service of a number of customers via product. how do you build these things that you can get beta customers on, you can get testimonials and other things you can go out to the market with and things can get critical mass and you can begin to see the realization and the benefit of that investment at a much more rapid pace.

josh: 56:07

that sounds like a strategy that i can get behind. instead of this big, huge, dramatic change. it's the incremental improvements, the small 1% improvement every single day and then eventually you're at 365% improvement, or something like that, if my math checks out. i'm struck by how similar back to part of our earlier conversation about how human behavior, in this tendency to really think these dramatic changes and shifts are going to be what bring us the biggest impact, when really it's the small, everyday, easy to sustain, easy to commit to changes that, yes, they take longer they absolutely do, and they probably will cost more because they take longer, but it sets you up to be the most successful. going back to that example of keto, getting rid of carbs look, that's going to work for some people, but it certainly didn't work for me. instead, what worked well, starting to count calories right, focus on how much protein you're getting just these small changes as opposed to i'm not going to eat any of this specific food. no, there are some foods i won't eat. hate carrots, hate them. anyway, that's a side note. when we're talking about that idea of stringling the monolith, that sounds like a lesson that you've learned firsthand. that's really a good strategy to ideate on when considering replatforming.

guest: 57:39

yeah, i think it's also about the outcomes and i really love your metaphor on the diet stuff. i think that you have to potentially get away from saying i went away 175 pounds versus. hey, my pits feel better, they fit better, the notch on my belt isn't as tight. i didn't have to put my own extra hole at the end, so i didn't have to buy any belt depending on the outcomes and what good enough ultimately looks like. because the thing for the religious opinion on how systems are built and you want to strangle the monolith the monolith doesn't exist. you wholesale replace it. but if you're a pragmatic leader and you figure out what good enough is and where that investment will take us, maybe that legacy system lives forever, maybe it's routing to other things, maybe customers never know, but all of this is stitched together in a way that it's a level of risk that is acceptable to the business. those are the things. what are we willing to accept? what is good enough? all of that comes back into the minimum lovable. how do we take and deliver those things and what are we willing to accept and what are we willing to accept and what are?

josh: 59:06

we willing to accept? how do we get that all together? coming back to not just on the diet side, but the entire conversation, coming back to that idea of what's good enough, what is minimally lovable are we focusing on the right goals from the example of the diet maybe it's not a specific number on the scale, maybe it's a specific feeling or some other way of noticing a gain or improvement and very much taking that same approach here in this situation, really getting clear on what is good enough. that comes back down to what is the actual problem that you're trying to solve. for most of the time, unless you're a wrestler or a fighter or a boxer or whatever, the number on the scale doesn't really matter. it's the look that people are really focusing on, i think. at least coming back to that idea of what is the customer pain that needs to be solved. what's our own internal company pain that we need to solve so that we can better solve the pains that customers are having? what's going to get us that minimally lovable solution both internally and externally? i love how you brought that together. any other lessons from your experience with replatforming?

guest: 1:00:21

i think i touched on everything. it takes longer than you expect. try and be pragmatic. bring in more people earlier. i think it's very hard for it to work for a one-legged stool to stand if it's just engineering. reach across the aisle to the leaders that are on the call, from ceos to cxos, cfos. planning needs to be really unified, and if you're all hearing and seeing the same vision and then you set up a goal that is not parity you actually have an opportunity to be successful.

josh: 1:01:00

this ties into something that i really believe in. you can't over communicate, you can't continually beat that drum and send that message out internally enough, because it's really about driving alignment and collaboration and really being it all together and being on the same page. i like how you made sure to bring that up. you got to bring people in earlier. you have to build it with them to a degree, and that's really going to be where internal and external adoption comes from.

guest: 1:01:32

yeah, disagree and commit, don't agree and sabotage. i think you said that earlier. i totally agree. it is absolutely critical. i've been thinking a lot about corporate values and culture and mission statements. you touched on it a little bit about some of the transparency and doing these hard things. choose reality, have the honest conversation, buy in and let the best ideas win and align on what's good enough, absolutely, look.

josh: 1:02:07

this has been a certainly an insightful conversation for me. i feel like i learned a ton during this conversation and listening to your experiences working through plenty of replatforming diSaaSter stories. really appreciate you taking the time to join us for this episode of the diSaaSter recovery podcast.

guest: 1:02:25

thank you, josh. i appreciate it. it's nice to see you. yeah, this will not be the last replatforming that i go through. i hope that my stories and success and challenges are helpful to the audience.

josh: 1:02:39

you know, it's always interesting to me to hear how an expert who has dedicated years to a specific discipline simply defines their path. and that's my first takeaway from this talk. software engineering is about understanding the customer need and collaborating cross-functionally to identify how to deliver a delight at the lowest cost while staying scalable. the keyword there delight focusing on more than just a minimally viable product. focus on delivering a minimally lovable or a minimally adoptable product, because there's a big difference and there's also way more to software engineering than software developing. it's not an org of nerds coding to infinity. it's a strategic arm of the company responsible for building and maintaining the foundation to the company's success. a good, reliable product. replatforming is not for everyone and it should be thoroughly examined and challenged, based on the needs of the customer and the company's ability to deliver consistently on those needs. and finally, there's a need to avoid the confirmation bias, the echo chamber of a team, of an org, of a company, even sometimes an industry. and the best way to do that is to collaborate internally and make sure it's cross-functional collaboration. but don't just stay internal. you have to go external as well. you have to connect directly with the people you seek to serve to understand how you can best serve them. now, what did you think of the diSaaSter stories shared by our guest? he's seen how the replatforming story repeats itself over and over, and now you have what you need to spot the warning signs and help course correct.