How to Plan for 10x Growth Without Over Engineering with Marcus Fontoura

So, let's make this a happy day. Let's imagine your startup is growing. Fast. Users are signing up, revenues are climbing, everyone's happy. But behind the scenes, your team is drowning in bugs. Hotfixes every day, or at least couple of times a week. Your systems weren't built for such demand. Everything is being held with workaround solutions or duct tape solutions. That's a nightmare scenario for any founder. You are scaling your technical debt instead of scaling your success. The fix? Well, it starts with the platform mindset. Hey, what's going on everybody? I'm Mike Sirius and this is Mastering Tech Growth. Every week we sit down with industry leaders to bring you no-fluff tips on how to grow. If you enjoy the show, make sure to subscribe and send me your biggest growth challenge at masteringtechgrowth.com. I really wanna know what you're building and I really wanna know what keeps you up at night. Today I've got Marcos Fontoura on the show. Marcos was a CTO and currently an advisor at Stone, one of Brazil's largest fintech companies. He as well in his second tenure as a technical fellow at Microsoft, where he works as a CTO and a lead architect for Azure Core. Over his 20+ year career, Markus worked at Google and Yahoo, helping shape some of the planet's most scalable systems. He as well holds 50 patents and is the author of a new book, A Platform Mindset. If anyone knows how to scale tech without breaking it, it's Markus. Markus, welcome to the show.

Mike, thank you so much for having me. Super excited to be here with you.

We got a lot to talk about, so let's jump right in. So here's what we got today. Your book is a thick book, right? There's so much value in that book. And of course, in 60 seconds, we can't cover all of that value. So I've got a couple of takeaways. Which I'm sure our listeners will enjoy. We'll kick off with the biggest mistakes founders make when scaling. We're gonna look at how to plan for a 10x growth from the gecko without over-engineering. We'll discuss why disconnected systems slow you down more than missing features, and we'll finish off with high-performing team culture and how that can multiply everything you build. We love to kick off the show with this question, Marcus. When I say mastering tech growth, what comes to mind?

Tech growth means to me scaling. And of course, like, if you are building a startup and validating a new idea, you don't yet know if it will scale. But at some point when you go to market to validate your idea with customers and you found out that incredible idea that customers love At that point, like, you have to think, like, how my company grow, how will we scale, how do we attract more customers? And that's the point that I think a lot of founders miss the, the boat, right? Like, they, they really don't think about that next step that is like building the foundation that prepares the company for the, for the next phase, the, the 10x growth of the, the company. And I think a lot of my, my book talks a lot about that phase, that like once, once you validate your idea, it's— you have a success, successful company that, that, um, is at the startup phase. What do you need to do to grow and to, to be like a 10x, 100x company?

Okay, so, so for you, tech growth equals preparing for scaling. Makes perfect sense. Um, let me do this, let me make this more difficult. So from all the things you can choose which has direct influence towards the growth, and you can choose only one, what would you choose?

I think, um, the uniform— having a uniform, um, platform and set of tools that developers can build upon.

Okay.

I think what I see that it's probably a very common mistake is that when you start building a company, you let developers pick and choose whatever they want to use as tools, how they want to build the systems.

Yeah.

That works for a while, but very soon it will start causing problems and accruing technical debt. Like, because if you want to build like a shopping app and then you build it, you hire a team to start building that shopping app and then you soon you realize I need a new module for that shopping app to work and you hire another team and they started building that second module completely different technology, using completely different technology than the first team. At that point you start having problems and what happens normally is that Once the company starts growing, you hire more and more people and you amplify this problem. Because like with 10 people you can control and, you know, the founders normally know exactly what's running the company. But once you go beyond 10, 15 people, 20 people, then 100 people, it's really hard to, to establish that standardization process that you need to have in your company. If you don't set that from the get-go and then if you don't intentionally think about that.

Yeah, I love you actually calling this out, that, that picture. I, I'm seeing that picture everywhere, like literally everywhere. People don't think about the next step. And I love how you put it. Once you validate your idea and you know you have a market for it, at that point in time, you need to start thinking from platform perspective and start thinking about how you're gonna 10x. So the question I have is How do you know that you validated your idea and you should be thinking about scaling? It's like, what's a good signal that you should start thinking about the next phase, which will be the scaling?

Yeah, we are very fortunate to live in this day and age that most of the software that we build and most of the ideas that we build can be readily validated with users because we are building services and not box products anymore, right?

Yeah.

When you think a long time ago, companies like Microsoft, they work on products and they build the product in a box and you had to go to the store and go buy that box and then go home and use the CD or diskette to install it. And then you see if you like it or not. And then it's very hard for the companies to get the signals if users are loving it or not. Yeah, like now, like, we are in the web services era and in the AI era, and data is everywhere. So it's very easy for us to start collecting signals and have a sense that, that customers are really engaging and loving that idea. If you're doing a consumer thing, that is very direct, right? Like, you can readily get consumer input. And if you're doing a business, business to business, a B2B, you can still measure like if people are using your APIs and which parts of your APIs people are interacting, interacting the most and which parts of your APIs people are not calling or maybe it's too complicated to use. And then you see that you have that unit economics, right? That's like, okay, I have an idea that I could package. Users are loving it, and I can see that the cost to produce the goods is low enough that if, if I had a 100x or a 1000x scale at that point, I'll be profitable. And I think this is the point, that when you find— we find that idea that has the, the right unit economics, that the idea is producing value to users and you can produce it at scale without cost that is overbearing for you, right? So, and that's the, the thing that is the hardest to find in a startup.

Okay, I love that. So I'll throw in this quote, uh, from, from Startup Genome: 75% of high-growth startups fail due to, due to premature scaling. In other words, growing too fast without a solid foundation can be a startup killer, which effectively is what you were saying. So why, why those early workarounds and accumulation of technical debt end up causing so much pain when it comes to scaling?

Yeah, that is technical debt is like the, the nerdy version of debt in our financial lives, right? So the sooner you pay debt, the better you are off. And the reason is, for instance, like let's say you're starting building a system and it scale up. And then eventually you were very, very successful and it scaled beyond the point that your servers can contain and you start seeing like slowdown of the system. You want the best engineers in your company to go and tackle and make that system more scalable, thinking about re-architecting or doing better capacity planning for your system. However, let's say that your infrastructure is very fragmented. 10, 10 of your engineers are working on Azure, another 10 are working on AWS, the first 10 are using Java, the other 10 are using C#. They don't talk to each other. They don't know which databases are running. So at that point, it's really hard to get the best minds in your company and ask them to work together. Of course, they will work together, but there is so much context that they will have to learn about the new project that is really hard to build this SWAT team to go and fix a problem, for instance. And this is just one of the problems, right? Like, it manifests itself everywhere, right? We cannot plan. It's very hard to take dependencies if things are not planned to use, like, for instance, the same communication protocols between the systems. If you don't have, like, a same monitoring platform for the system. So If you don't have like proper alerting and all these things that are like platforms of scale, right? These are the building blocks that you need to have to have like a professional system. And what a lot of startups do wrong, and even big companies sometimes get that wrong, Mike, is the fact that you validate an idea and it's very successful commercially And then you just get that idea and scale it without making the investment to make it more professional.

Yeah.

And that's, I think, what people miss, that point. And that's a crucial point because it will bite you down the road. It will not bite you in the— for the first 100 or 10 or 100 customers. It will bite you down the road.

Yeah. So we're basically saying that accumulation of technical debt. And just like any debt, it is gonna, it's gonna have interest on it. So, so it's gonna compound and it will become a bigger and bigger problem over time. So if you have a, a solution which is effectively a workaround, or you're missing stepping stones or building blocks that you put it within having a matured and scalable system, all of that area of issue, it's not like it's gonna remain contained, being small, it's just gonna grow as a problem, right? It's either gonna be process debt, where things are slowing down because they need to go through that system, or it's going to be an actual development debt, where code is so out of date that it's becoming, you know, buggy, or no one wants to work on it, and things like that. It's just going to be basically a problem which continues growing, right? And the higher the scale, the bigger the problem that will be.

Yeah, when I joined Storm, for instance, The company was very successful, IPO in 2018, hyper growth, and it went like from a startup to a company of 10,000 engineers very quickly. And in this hyper growth phase, right, especially after the IPO, you have an influx of money and you can hire like new employees and you build new areas because you want to invest and you want to find the next big thing for the company, right? So And time to market is very valuable. So when you're trying to find the next big thing for the company, you want to try many new ideas. So I joined Stone as CTO. The company had already 10,000 employees and 2,000 on technology. When I look at the number of programming languages, for instance, they had 63 programming languages. I didn't even exist, knew that there were like 63 programming languages available.

I wouldn't, yeah. 63 different languages. That's insane.

Yeah. And what happened is that, like, if I had an incident, for instance, if I had a live site, just to get the context of that part of the system that I had to address at that moment was so hard because it could be using one of many databases, one of many programming languages, one of the many hosting environments. And driving commonality is like actually like providing us like the substrate, right? Like that's computing substrate that should be for free and out of the box for you so that you really can free up your resources to invest in the innovation areas that you want to create and add value to your customers. But if you don't create that substrate and that platform, Soon enough, what will happen is that over time, that toil, right? That I was just talking to Satya Nadella, our Microsoft CEO, the other day, and he called this toil, right? And that toil accumulates and accumulates and is really hard for us to make progress at that point because a lot of your resources will be devoted to firefighting and fixing problems instead of like really adding, adding value to your customers.

Yeah, I love you calling that out. I actually have a quote exactly about that, which is— I know exactly who made that study, but it was, it was discovered that developers waste 23% of time on technical debt or reworking the past bad solutions like workarounds or hot fixes. So basically meaning that within any team, one day out of their week will be spent on, on that, on technical debts or reworking. That's a lot of time. That's one-fifth of the time which could be put into innovation and building new features. So I love you calling that out. Let me ask this, uh, Marcus, in practical terms, what does, uh, what, what does adopting a platform mindset, uh, from day one look like for a startup? Let's say they are at that point which you said, they validated, they believe they have something there, and the business is there and they need to start thinking from that day about the platform mindset, like how that looks like in practical terms?

Yeah, I think this is a great question and there is two components to it. And then the two words are very important, the platform side and the mindset side. The platform side is at that point you start to defining, to define, and what are the foundations that you want to have to build your house, right? Like, think about at that point you didn't build the house, you build a blueprint for the house and you validated the blueprint. Like, you found that unit economics that, that you know that you can scale, that customers know and love. And then you have that blueprint, but, but you didn't really think like, what are the materials I'm going to use? What is like the tools that I'm going to use, the foundation? So at that point, you have to— the platform side of this is defining, defining this foundation. And defining the foundation involves a cultural change, right? Because up to that point, the engineers are trying to spend sleepless nights and endless nights validating that idea. And then they are really not thinking about like, oh, I'm building like a robust software that is going to scale, I'm building commonality, I'm driving standardization on how we use databases and how we use communication systems. I'm thinking about how to deploy features in production so if they have problems, I can roll back. So that they don't impact my customers. So building that foundation is the platform piece. But for the developers and the people that are in your company, they need to have a cultural transformation, right? That's where the word mindset comes about, right? Because then you're saying, Mike, I know you are doing this using Lisp and you love Lisp, but unfortunately we decided that you cannot use Lisp. And I know you are like on AWS, decided to standardize on Azure. I know that you're like shipping things from your, your dev box, but now we have a professional CI/CD pipeline. And you might see all these things that I'm imposing now, like as the CTO or the company leader, as restrictions that I'm imposing on you, right? And saying like, oh, I used to have fun working here, I had like my liberties, I could do whatever I wanted, and now this guy is coming, you know, telling me like that I should do this and that. And it's true, right? Like, for the people that are there early on, before you adopted the platforms, this platform mindset, I'm imposing more restrictions on you. But for all the other employees, right, because at that point you didn't start scaling yet, right? So for all the other employees that will come next, they will not view this as restrictions. They will view this as, okay, this is the, the In Mike's company, that's how things work. Everybody uses C#, everybody uses the CI/CD pipeline, so they will love it because then they will not need to think about these things. They will take those things for granted and then they use their brain cells to think about innovating. As opposed to them spending part of their dev cycles thinking about, oh, what should I use for an RPC mechanism? Oh, I want to write tests. What is the mocking framework that they use for writing tests? Oh, what is the best CI/CD platform that I need to have? Like, how do I implement the policy for rollbacks to be easy? So you want all these things not to be there, right? Like, as a main thing that the developers want to think, you want to platformize and build these tools and tooling And infrastructure that it's just there, right? It's a fact of life, right? So then everyone else joining the company will just benefit from that.

Yeah. I love you put that, a fact of life. That's a very nice saying. I mean, that's definitely a fact of life for someone who's a developer, hands-on person, and there's so much pain. And you mentioned developers doing what they want and coding with the tools they want. And just sort of feeling that freedom, you know, as they say. And then you come in and you're going like, look, everything will have a structure. We're going to become, you know, a scalable platform. And then, oh, I'm getting restricted. I usually get that, and this is my experience, is that from what I called MacGyver developers, you know, they usually like a high-performing rockstar type of coders and they just love things to get done. And then when you bring the rules for standardization or commonality, They always get, you know, they feel restricted because they just, you know, MacGyver type of person. They just want to go in straight into production, you know, fix the bug or something like that. And then you go like, no, no, it's going to be a release process. Like you're going to create a release ticket. Someone will approve that. Like you can't just go in there. They always feel restricted, but it is for a better good. It is for a better good because all of these processes meant to help the business to actually go 10x. Otherwise you're looking for some problems.

And this is great because there is always this MacGyver developers, right? So like the other day I had a conversation with this guy that's saying like, Marcus, why do I cannot have this database open to the internet? You're complicating my life. I said, for privacy, security, you cannot do that. That's an internal database. Like let's close it down. And people might think like you are just creating bureaucracy, but you are not creating bureaucracy. This will bite you down the road, and it's much better for you to fix these things now when you are building the foundation of the house, right? You don't want to build the whole house and then you say, oh, I have a shaky foundation, right? Like, exactly, because then you cannot rebuild the foundation of the house. You can, but it will take forever. It really takes you forever. It will be very painful investment. Yeah, the metaphor that people have is like changing the wheels of the car with the car running. It's better to change the wheels of the car before the car is running.

Yeah, I love you, uh, I love you putting this. And for the founders listening, I feel like they really don't understand that when they have the tech product, their house is the tech. Like, you know, you might not be sending APIs But you might be selling a mobile app which solves some problems, but the mobile app is the tech, right? So yes, your success will depend on your marketing and on your sales capabilities and timing and market fit and all of that. But ultimately the product is the tech. And somehow they ignore that that is their house and they think about, you know, better sales processes or better marketing partnerships and things like that. And they pull in all of that strength into these elements, which then increases the demand on the systems. And then the systems break and they go like, what's going on, guys? Like, why can't we release this today? Why do we need to wait 3 weeks? Well, it's because you didn't take care of your house, right? It's just like, that's it. It's crumbling down under pressure. So I have this one, Margot. So you mentioned the tactical ways people need to think and And the first thing which comes to my mind is the maturity of knowledge. Because when I was participating in a couple of startups way back in my career, I didn't really have those knowledges. You know, I didn't have a very strong understanding about commonalities and processes and why that's important. And I was head of engineering in some of these startups, right? So we definitely did things to get things out. The speed of just going out and releasing was the key element, which of course of course, accumulated technical debt. And I, I learned the hard way about many of these topics. And now being much later in my career, I fully understand that. And working as well for enterprises, I know exactly what that means. But how do startups think at that point in time? You know, let's imagine we have a startup with a couple of fellas, you know, they're like 25s, you know, they got great ideas, they went out, you know, maybe borrow money, maybe got some funding, they released something, they build something. They don't really have the knowledge around thinking about scaling in the first place. They just don't know what they don't know.

Yeah, I think this is a very key point, right? And, and I do believe, Mike, that the main objective of the early engineers and the founder is to validate the idea first, right? To find that scaling point, right? And then And then I think the point that people miss is the transition between like the initial phase that you're validating the idea and the professionalization phase. And, and a lot of the times it is even the fact that like we don't have the right people for the second phase. The founders might be very good in, in validating business ideas, but they might not be great in scaling the company once you found the idea. So then I think the key point is that like we have to, you really have to see like when do you need to bring more experienced people. And I talk a lot about that in the book, right? That at some point you need to have like a lot more experienced people in the team and bring that outside knowledge so that, and it's important for the founder to find that point and to understand their limits and not wait too long. It's the same thing. Like, think not even about software, think about like payroll. You have a startup, you have 3 people, you don't have to have a payroll system. And let's say you go and now you scale and now you have 1,000 people. Imagine with 1,000 people you don't have an automated payroll system. Yeah, you'd be dead, right? You'd spend like, yeah, all your time doing payroll and manually paying people, and nobody would think about that. But like, when it comes to software, it's the same thing. Like, at some point you need to, to think, oh, that's the professionalization phase, right? It's not, it's not the validation phase anymore. I, I think these are very two very distinct phases.

Okay, I actually love you calling that.

Just one, one key example of a company that's, that was very successful in this is that everybody knows is Google. Um, so think about early days of Google. The guys wanted to build a search engine. Yeah. But then, but then they don't only build the search engine. They realize that like, oh, to build a scalable search engine, I really need to invest in infrastructure. So they invest a lot. They hire the best engineers in the Silicon Valley area, and they ask them to not build directly a search engine. They build like a foundation for like deploying systems. They build They built a foundation for like communication library. They, they built like Google File System. They built the MapReduce platform. All these platforms that we all know and love. Everybody now uses protocol buffers and gRPC. Think about that Google was a startup and they were investing like their money to hire people to build like systems like gRPC and GFS, the Google File System. And based on those platforms that they built, they built a very successful search engine. But, but at that point, they, they didn't only have the search engine. They also had foundation that they can build YouTube, Google+, News, and all the other services that, uh, Gmail, all the other services that we know and love, right? Google Docs, everything is build on the same platform. So of course, like, we cannot compare anybody to Google. Was, uh, was 20 years ago, pre-cloud, but, but they had that vision that— and they could, could understand early on that, like, investing in the platform was a key factor that enabled their growth. And then this was— this is almost like a textbook example of, like, um, founders realizing that they build— they need to build that commonality.

Okay, I love that professionalism being another phase. Um, so you need to recognize what you don't know and effectively just pull in people who actually knows and can help you. So you're playing into your strength and then you, you know what your blinders are or what your weak spots are and you're getting some advice, potentially, you know, advisory for someone who actually knows about the next phase, or you're hiring someone who knows so you actually can scale and not make these mistakes. So it's not about you building everything, right? It's about bringing the right people at the right time, which leads me to this question. Let's say, what is the, what would be some core architectural principles you would want to see in an early stage startup, which is just at the, you know, at that phase where they need to start thinking as a platform mindset But what can they instill there from like the beginning as core architectural principles which will pay them off later?

The main thing is the common infrastructure that you have to monitor the services online, monitor the scale and take care of incidents and mitigate incidents fast enough. So this is the biggest thing for scale. When you start scaling, people say, people don't think about that things will fail, right? Like they build the happy path. And then like that very soon leads people into trouble because there are like tens of engineers that can build you a happy path system. But a real system is one that has the principles that will handle, of course, the happy path, but also will handle the scale, the complexities of managing the dependencies. That if the cloud, the dependencies you have on the cloud providers fail, how would you fail back? How do you take care of your customers so that the system doesn't degrade for them? And this is the foundation that you need to build, people that have this mentality of scalability, resiliency, that are the key attributes for scalable platforms. And even if you're talking about an app, right, so you need to, to build the app considering that it, it has X users now, but you want it to have 1,000x. So all the calls to the backend need to be throttled. Sometimes you need to have monitoring to see when you need to do auto scaling for the, for the backends and all these things come into play. So, and that's not the mindset at all when you are just trying to validate the idea, right? So that's like the shift that needs to happen at some point.

Okay. So this for me feels like we're entering into that proper engineering phase, right? Where we have better skills than what we had initially when we were validating and sort of growing. We hired potentially a top talent to some of the areas, maybe We have technical architects which will look at getting that platform in place. The question I have right now is, what's, you know, what's the secret formula to not over-engineer stuff? Because I've seen a lot where people maybe hire a little bit too soon and too strong of a people, and these strong people tend to look at everything as a huge problem and they they tend to over-engineer the solutions, you know, for the future, of course. But at that given point in time, it feels it's just too big, like something lighter would be enough. So it doesn't, you know, make us move slower, right? We don't lose momentum. But at the same time, you cannot under-engineer. So it actually becomes too small and then eventually it becomes another technical debt. It's like, how do you balance that timing for these solutions?

Yeah, this is a brilliant point, Mike. And thanks for asking this because this, you cannot overemphasize how this is important because not deciding to professionalize, right, like it's a problem, but also going too far in the other extreme is another problem, right? So let's say if you have like, if you have a system that should just work for Europe and then you want to build a database that is global scale, right, like you're wasting a lot more money than you need, right, at that point. And I think what people don't realize is that if the solutions that we have now and that, that support us scaling, they can be used very incrementally. It's not that now that we need to build our own data centers and you need to provision data centers for the long run. Most, for most companies, they can rely on cloud providers for most companies, they can use the solutions that are provided to them by third-party companies that, that are in the infrastructure space that will allow them to, to, to navigate that growth curve gradually. So this, this used to be much more problematic in the past when before cloud computing, for instance, if you had an app And if you had to host your own app, like, then how many servers do you get? Like, it's a question because if you buy 100 servers and it really takes, takes off, maybe you need to buy 100 more, and that takes time. But, but now you can just scale it linearly and then even have solutions that you can have, like hybrid solutions that you have, like something, some things on-premise that fall back to cloud. At peak times. So, so an experienced leader now can use a lot of tools that are at their disposal to, to avoid this over-engineering and overspending. And another point that I also bring in the book that is, that is important is make sure that the tech team pays for itself, right? Like, what, what I mean by that, right? So like, you have a solution and you have a startup and you start selling and you're making profit, you're making a good profit. So part of this profit should be reinvesting in tech so that you can scale more and more. But make sure that you don't invest more than you are making, right? Because then you go bankrupt. But so for you to be— to have like a solid business that you keep growing and growing and growing, you— your— the complexity of your platforms will always increase with scale. So you keep have to reinvest more and more, but you don't want to, to reinvest like arbitrarily in platforms, right? You want to, to build efficiencies, and the gap between your profit and what you can save by building efficiencies in the system, you can reinvest. So, so this is like for the— even for the CTO, like for founders that are looking for CTOs, the CTOs have to have that mentality, right? That I want to keep my organization profitable. If you think about the engineering organization, it should be profitable because it creates efficiencies to self-fund it. So that like, and then by self-funding, you can take care of technical debt, scale, and all the architectural needs that you have.

This is brilliant. This is first time someone gave it like this, Markus. It just, uh, just connected a few dots in my mind which I never had before. That's a, that's an excellent explanation when it comes to how you need to think about overspending and over-engineering. I'll need to come back to your book and dig into that one. That was excellent. So I got good example, which I, it's from my experience where I believe over-engineering took place. So I joined this small startup. It was like 20 people or so. And for no reason, they started to migrate into microservices. And that was about like 7 years ago. Microservices were just sort of beginning, you know, very hot in the market. And there was literally no reason. There was no load, there was no demand challenges. You could have just lived fine with a monolith application and having a little bit of scaling when it comes to your server infrastructure, right? So I couldn't understand that decision at all, and apparently it was made because it was just cool, right? And they walked into this complexity of all of it, which just crippled pretty much the whole team, right? And they just needed to deal with that without no business value whatsoever happening, because the clients don't care if you're microservice or you're monolith. As long as the service is available, they don't give a shit, right? So they were spending all of their time and cost. So that's a very good example for, you know, from my experience, from over-engineering Which leads me to this question is, should the team be thinking about things like that, like microservices, distributed systems? And when do you think that conversation should start taking place?

This is a great question. And I think one of the failures of engineering leaders is when they are so in love with some technology concept that they will say, I learned this in the textbook this morning and I want my team to apply it in the afternoon without reason.

Yep, seen that, seen that.

And I think like, just think about it, like, uh, if you're a tech leader and then you are talking with your marketing counterpart and your marketing counterpart for your startup says, oh, I want to advertise in the Super Bowl for a company. And I said, but we don't have money to advertise in the Super Bowl, we're too small. No, no, it would be great because everybody advertises in the Super Bowl. So we, we also should advertise in this, but, but like, come on, we should understand the phase that we are in, right? Or, or if you have like an HR leader that say, and you have an organization with 20 people and say, oh, I want to build like all the HR systems in SAP and do our integration, and said like, why you're going to spend millions of dollars doing integration when you have a company of 20 people, right? So when you look, these examples are in other areas, and then you draw the parallel to our area, right? So we cannot do the same, right? So like, we normally criticize when people want to overinvest in marketing, overinvest in HR systems, overinvest in like, uh, even in the facilities for the company, right? So like, and then we, we also shouldn't overinvest when you don't need to invest. And, and then a key point here is also that that people forget that we are not in the Stone Age of computers anymore, that refactoring code is impossible, right? Like, when I went to school, I'll reveal my age, right? I'm 50, 52, right? So I went to school in the '90s, and then at that point, like, writing software was so complex that people would— my professors taught me, oh, you have to do a specification then you validate the specification, then you have to do the design and validate the design, and then you talk to customers and making sure that they really want this, and then you implement. Because, because if you start implementing and they don't want, it's very costly. But all this is not the case anymore, right? Because the programming languages are so good now, especially AI. So if you have the right platform investments, you are not really investing in platform, you're investing in the innovation for your company normally, right? That is a new app, a service model, a new, a new, like, service that, uh, that you are automating, like, the lives of your customers and so on. So you really want to innovate here, and you're leveraging a lot of foundation that makes your life so much easier. So this is where the platforms come into play, right? You should realize that you are leveraging all these platforms, and if you need to rewrite your application on top, it will be much easier. So you don't need to write a very complex application on top to begin with. Like, wait to see the feedback from users, wait to see the demand for scale, and keep re-engineering over and over and over. At some point, you should have the foresight that say, oh, the monolith might not work anymore, but you don't need to rush into that. That can be a late-binding decision.

Okay, I love, I love you. You said understand the phase you are in. I think that, that for me, that was the key. There's different phases to business, you know. You have less money, more money, you raised money, you know, maybe the economy is different, but you need to really understand the phase you are in, in your business maturity cycle, and act accordingly. Uh, because if you just start, you know, prematurely scale, as the statistics we mentioned before, it's probably not going to end up well. So let's shift to something which I really loved in your book, where you said that the having non-integrated systems, or systems which are siloed and not talking with each other, is actually worse and will slow you down more than actually lacking on the features. And I got this quote from Salesforce Companies today use an average over 1,000 different apps, but less than 30% of them are integrated, which means silos, duplicated work, and very clear bottlenecks when you need to jump from one system to another. So the question is, why, Markus, do you believe integrated systems matter more than constantly adding new features?

Constantly adding new features sometimes is in some situations might be good to add new features, right? I'll give an example of Azure. When we started Azure in Microsoft, we are like 6 years behind AWS. And then at some point, like AWS had more features than Azure. So at that point, we had to catch up. And then like, if this happens and you're in this situation, like then adding features is the right thing to do. But eventually you catch up in adding features, and I think the magic that the customers want to see is really when you have many platforms that work together and bring magic to life, right? Like when I was at Storm, for instance, we had the banking system and we had our credit system and you had our payment systems that were originally not super well integrated. And then we realized that, oh, while it's great for the company to have like a payment system, it would be really magical for, for customers if, for instance, when they get payment coming in the system, they all could automatically pay the interest in their loans. And then like, and then that would be so good because like it's very frictionless for the, for the, for the customers, and also can reduce the amount that they pay. Because like, as soon as the payment come in, if they have extra money, they could define a rule that every time you come in, part goes to my bank account and part pays the interest on my loan. So that's the type of integration that I think, uh, that brings the synergies between the, the platforms. And then Sometimes, like, people don't realize that you cannot develop the synergies if the platforms and backends are so disparate, right? So if one of the systems is running in one cloud provider, the other one is running in another one, they don't have clear paths of communication. They are in different code repositories that you cannot easily build a module to integrate them, to test, to validate. So it's really hard to make these scenarios work. So I think like this quote from Salesforce is really relevant, right? And then many areas like thinking about what is that scenario that like you will really bring a wow factor or a delight for your customer is really important. And sometimes this is by creating new flows and new composition of services that you haven't foreseen before.

Okay. So how do you, I then go as a startup and let's say I'm a CTO for a startup. How do I assess our healthiness when it comes to being integrated? It's like, is, you know, like how do you, how do you go like, okay, we need to unify our systems, you know, or eventually it's going to go out of hand. It's like, is there like some type of terms of rules like where you, where you go like, okay, we are integrating. That well and enough, and we were thinking about this, maybe thought pattern behind this, or, you know, on, on the flip side, okay, we're very siloed, we need to fix that.

I think there are some metrics, and of course there is not a lot of standards for developer metrics. Like, we have like DORA metrics, we have a few things, but let's say if the two teams want to work together But when you look at the productivity, like number of check-ins and number of like codes, coding to production from idea to production is a good metric to have, right? So if you have a new idea that two teams should work together, how long does it take for them to get that idea into production? A lot of the times you see that it's very complicated because there isn't an easy way for these two teams to take dependency on one another in terms of like even the software dependencies and also the team dependencies. Like they really cannot work together. So if you see that like these projects take a long time, it's all about agility, right? So if the projects take a long time, like then you probably could be a lot more integrated and that's I observed quite a few of those things in some of the companies that I worked for. Let's say we wanted to do a project between two organizations that normally didn't work together. The code repositories were completely separated. The infrastructures that they use for RPC were completely different. Like, the teams didn't talk. They didn't trust each other. There was no way There was discussions like, are we using inner source? Can I check into your code? And said, no, I don't want you to check into my code base because if you cause a problem, I might have an outage because of that. So all these things, like, I think that you need to remove those frictions. And then the sooner you think about like standardization of some of these platforms, the better you are when you think about which projects you want teams to work together in the future.

So effectively, the integrations is API layers, right? That's what we're saying, is that any system you build, you should have an inbound and outbound APIs capabilities.

Yeah, this is like a great solution. That's what, um, Jeff Bezos wrote a famous memo in Amazon that wants everybody to use APIs and to be two-pizza teams, right? Like, you, you build a system that have like at the most like, um, 16 engineers because that's enough that can be fed with 2 pizza boxes. And, um, the systems communicate through APIs and web services. Yeah, that's the standard practice.

Okay, well, you brought up the 2 pizzas rule, so let's talk about teams and high-performing culture then. Um, we know if you have a good, uh, good culture There's so much value when it comes to speed. And I have this Harvard review which effectively did a study on it and found that companies with a strong culture experience 4 times more revenue growth compared to the ones with a weak culture, right? So it doesn't become this like a good feel type of situation, you know, oh, I'm working on a culture I really love here. It actually has business outcomes, which is 4 times more revenue. That's a big number, right? So if you're making a million, you could be making 4, theoretically, if your culture is weak. Which leads me to this question. You've seen all the teams, Marcus. I mean, you were at Google and you did Yahoo. Now, you know, you have second year tenure with Microsoft. It's like, what, like, how do you go about building a high-performing engineering culture in the first place?

A lot of it, it's building trust across teams and having the right people and making sure that they trust each other and that they can work together. And collaboration is really key here. Um, well, there's— in Microsoft is great, right? So like when Satya Nadella became CEO, uh, maybe 10, 12 years ago, I don't remember exactly, most teams didn't really work a lot together, right? So we have been— I was working on Azure at that point and there were other parts of Microsoft that they had their own computing infrastructure that were not taking dependency on Azure and they were not even considering moving to Azure. Of course, part of that is because we needed to evolve the platform to support some of our first-party scenarios, which we did over the years. But also a lot of that is because leaders were not incented to work together. They were incented to ship features and to do like whatever they needed to do to make their products successful. When Satya came on board as a CEO, he completely changed the culture and he said, not only you need to make your product successful, but you need to make others in Microsoft successful and was part of everybody review how you're contributing to this success of others. And this was a huge change for us, right? So then suddenly we started collaborating a lot more. And my one thing that is super important to me is that it doesn't matter if you and I are super smart and we consider ourselves like great engineers, like there is nothing that we can do together by ourselves. Like nothing relevant I can do by myself. Like I need a team and then I need the teams to take dependency on one another.

Okay.

Sometimes people don't want to take these dependencies because they simply don't trust, right? So like you say, Mike, is leading a team and say, oh, Marcus is building the database layer, but I don't really like Marcus, so I'll build my own database layer here. So that's where the culture comes into play. And if the culture enables a lot of efficiency, because once the teams trust each other, all this building duplicated systems goes out of the door, right? Like, you are now forced to, almost forced to collaborate, but not forced in a bad way because you really want to collaborate. You like working with people, you like, you trust that they will deliver on time. So, so this is, this is really the key to, to build high-performance teams.

What are some practical tips for that one, Marcos? So let's say you work in a business and you see that the trust is not there and teams are not talking, or teams are not talking and you decide that they're not talking because, you know, they don't trust each other. It's like, how do you begin to fix that?

I think like the first thing is like understanding why leaders don't want to take those dependencies, why leaders don't want to collaborate. And a lot of This is you being a role model and forcing people to do things, but, uh, but people don't change if they don't have the right incentive. So it needs to be a cultural transformation of you, Seth, being a role model and you, uh, trying to dictate how you want the company to operate. But also combined to that, you have to have like the incentive change too, so that people understand that their promotions, bonuses, salary will also be tied to the cultural change, right? So this is super important because people really optimize for their careers. And then if they, they think that they will be very successful locking themselves in the, in the office and just writing a bunch of code, they will do that. If they realize that that's not going to take them anywhere then they won't do that, right? Okay, so, so it's, um, it's a whole company effort. Like, HR is super important to be a partner with the CTO or the CEO leading the change. And the CEO really needs to be a model, right? So like, it doesn't matter if they say, oh, I want people to collaborate, if him himself is a micromanager, if him or her, herself, is like, um, not taking dependencies and, and not trusting people. So it starts from the top, and, and people demonstrating that you trust, you have trust on them, and then once they feel that you trust them, they will not want to disappoint you.

I get exactly what you're saying over here, and I love how you put about the incentive. So effectively, we're saying There's cultural values which are being set by the business, and we're talking about the apex of leadership, CEOs and all the CXOs, which says that communication is one of our cultural values. And then we actually have incentives being tied to it, meaning that employees being looked at performance evaluations a yearly or half a year, maybe they have their goals, personal goals, or maybe team OKRs, and all of that is driving that want of more communication to take place. So everybody just falls in line with that. And then it's a cultural transformation shift which happens. Otherwise it's just, it's just wants, like just dreams, right? It's nothing tactical which will not yield the result, right?

And everything, yeah, your point is super valid, right? So it doesn't matter that you say, oh, I want to do a cultural transformation, but you are are not a driving force behind it. If you don't show the values, if you don't show that you take accountability and you trust people, people would simply not follow. Okay, so, and then, and the other point is that all this is tied together, right? The platforms and the cultural transformation and all this, this, um, not two separate concepts that you're talking about, but this really tie together here because once people start collaborating, it's much more possible for them to depend on other teams and leverage the work of other teams, right?

Yeah.

So now instead of me, Marco, saying, oh, I cannot depend on Mike, so then I'll build my own AI system and then I'll hire like a bunch of people and duplicate the work that Mike is building on his on his team, like that doesn't happen anymore because I can, I really trust you. And then when I go to you and say, Mike, your system is not working, and you really take the feedback and you try to improve it, right? So that, that, that's where like a key pillar for Microsoft cultural transformation was this idea of the growth mindset, that for people to be able to collaborate, they need to be open to, to take feedback And they need to take— to act upon this feedback, right? They understand their blind spots and then say, oh, I want to change and I want to do better for the company. And people shouldn't take these things too personal, right? So if I turn to you and say, Mike, I don't like your system, I'm not saying I didn't like you, right? I just didn't like your system. And probably I didn't even like the, the entire system. I just didn't like some aspect of it. And then we go Marcus, what, what didn't you like? Let's just go and improve that, that aspect and work on it together. And sometimes I feel that like people really don't like having feedback, right? So I joke that some people prefer to go to the dentist than to, to, to receive a feedback session. But, but that is kind of unfortunate because if you are part of the same company and want the company to succeed, we want to be able to tell each other like what we can do better together.

100%. There's something innately with us humans when it comes to receiving feedback, which makes us sort of defensive and shut down and become almost like, you know, oh, it's not me, it's this and that or something like that. Yeah, I get feedback is definitely a skill to give and receive. 100%. So I have this question, Marcus. Let's say we transforming our culture and it's going well, but at the same time we are hypergrowth, so we're adding more people. And you bring in more people, you diluting an existing culture with whatever is the average of these new people coming in. How do you protect the, the culture values when, when you hyper, hyperscaling?

This is super important, Mike, because it's at some point, right, like, um when the company scales to a factor, like, it becomes a reflection of society, right? What I mean by that is if you have a company of 10 people, you can interview the 10 people yourself, and you know that they adhere to the values you want to impose in your company. And the— but, but then you have a company of 1,000 people, you cannot do the same, and you cannot interview them yourself. And, and then it really becomes a reflection of society. In society, you have like good people, bad people, hard workers, lazy people. Who knows, you might have even spies in your company that are trying to steal data. Like, it's— and then it's really hard to protect against that. All you can do is like to not only do technical interviews but make sure that the cultural component is also part of the interview. And like when you're trying to bring people in and really look for the attributes. If the person is a good team player, you don't want— and in tech there is this thing about the brilliant jerk, right? You don't want to have this brilliant jerk saying, oh, Mike is great, but like he's a jerk. He doesn't work well with anybody, but he's brilliant. So let's just have him. I don't think that is acceptable anymore in our day and age. Like, I, I would rather get somebody that is not as bright and that but can do things together and can work together, because at the end of the day, you want to bring these synergies, right? So where like two people do more than, than the work of two people if they're really working together, they, they they produce like 3, 4 people. You have this multiplier effect if people work well together, and if you have the right foundation and the right platform, you want to have a people of 100 team producing like 500 and not a team of 100 people producing like 50. Yeah, so you have to have team players, and that's a key. So interviewing for that and asking questions like, um, What was like the situation that you, you participated in a project and you contributed to the success of others, for instance? Yeah, that's a good question to ask. And people say, oh, and you can really understand if people are just like BSing or if they are telling the truth.

Yeah, there's a book called The Ideal Team Player, which is written by the same guy who wrote The Five Dysfunctions of a Team, which is, which is one of the bestsellers. Can't remember his name. But the book goes literally about what you're just talking about, because that the importance of what team player capabilities for the team is a lot more, a lot more important than, than ability to be a solo, solo driver. Because if you have teams and someone is not a team player, you have a dysfunctional team. Have dysfunctional team, they're not going to perform that well compared to other team which might have a less skill on average but actually work as a proper team. That's 100%. So how do you assess this? Like, let's say, you know, I have a team, maybe, you know, I'm listening to this episode and I'm someone like a team lead, so not a CTO, you know, not a head of engineering, but I have my team and I think I have a suspicion that we might not be working well as a team. Like, any frameworks or any advices you could give? Like, how can you assess Are you a good team or you could be doing better as a team?

You can, there is some concrete metrics that you can see, right? So you can see like, does your team take dependencies on other teams? Like when the team works with other teams, what is the feedback that they get? You can seek, proactively seek feedback from partner teams to see how your teams are interacting. You can observe those interactions in meetings. You can see that your team is lean in terms— is not building like duplicated things when existing platforms or existing solutions exist outside your team. So there is not this not invented here factor in your team. So a few of these things is things that you have to take and keep an eye on. I love a book called, I don't know exactly the title of the book, is one of the references that I cite a lot, a lot of times in my book, is the Multipliers book by Liz. You talk about multipliers and diminishers. Yeah. And there it is that multiplier leaders are the ones who empower the team. They don't micromanage. They empower the team to do more, to achieve more. They welcome new ideas. And diminishers are the ones who are like trying to micromanage all the time. They always like, um, antagonistic to, to, to, to new ideas. They interfere, like they don't give praise, they intervene, interfere in bad ways in meetings. They don't, uh, so, so you can observe those things. And then you should not only observe, but you should act if you, if you see one of these things in play in your organization.

I, I love you calling that book out. I love that book. I did the Diminishing Qualities. Usually people don't even know that they do that, you know. They don't have a hostile behavior of like, oh, I'm going to be diminishing to everyone around me. They just are who they are, and, but they have these tendencies which effectively diminish others around them. So the team can really come together. I love you calling that book out. I want to share this module which I used multiple times, and I feel like it's a great one. It's called Spotify Health Assessment Module. It's a very simple team comes together, and it's almost like a, you know, it's almost like a Scrum poker sizing type of situation where you have different topics like collaboration, technical debt, processes, you know, and other things the team care about. And you just basically go across the room and you just take votes, you know, like 1 to 5, why, things like that. And it just allows to see how the team feels on average around certain areas, which makes the team work together and then gives as well some visibility to team leads to potentially have some one-to-ones or, you know, drive some initiatives around change. It worked quite well for me. Right. So, yep.

One thing that I also did is like the Five Dysfunctions of a Team that the book you mentioned. Patrick Lencioni, they have some workshops that are quite effective too, that they can go to your organization and apply the framework to analyze how dysfunctional or non-dysfunctional your team is. And I did this couple of times with some organizations that I work on, and people love taking that workshop and is actually quite effective.

Excellent. I didn't know that there's a— the book offers the, the workshops. I just remembered the book, but didn't, uh, so that's a good shout. Thanks, Marcus. So let's do some rapid round questions. Um, so first one, what's one early investment, say technology, process, team, anything else that pays off big when the startup hits hypergrowth?

Hiring key talented people.

Hiring key talented people. So basically when you're preparing or when you're getting ready for the hypergrowth, or maybe you're already in it, you want to prioritize hiring the best talent you can get on the market. That's what we're saying.

Yeah, I think this— we're talking about multiplier effect. Key people have this huge multiplier effect, right? Because not only they will build you the solutions that you need to scale, but also they will attract other key talented people.

Exactly.

This is all the time, right? 8 people hire 8 people. So the more that you have of this type of A people and the key leaders in your organization. This, the sooner that you can get them, the better.

Excellent. When hiring for growing tech team, what's more important, cultural fit or technical skill?

I think it's cultural fit because that is very hard to teach. Like, you can make changing somebody's mindset sometimes is hard, much harder to teach than than technical skills or technical gaps, right? Of course you want the person to have like good algorithmic understanding and good knowledge, but I do believe that technology is to a point now that if the person has a good algorithmic mind, algorithmic mind, like then they can really easily learn like new languages or new tools or new libraries But sometimes, like, making that cultural shift that if you are, if you are really a diminisher through and through, to make, to transform you to a multiplier might take years of coaching, and sometimes you cannot afford that.

I love you calling that out, and I subscribe to that belief very strongly, Marcus, as well. I think any hard skill can be taught in like 3 to 9 months, but when it comes to character traits If you, as you put it, a brilliant jerk, it's gonna take years for you to change that. And if that is diminishing to the team, you probably want to have someone who's a better team player and invest those 3 to 9 months to get them on that hard skill, whatever they need. I love that. Is there, is there a popular startup mantra or motto that you think does not work and actually cause harm to founders, and you would just want people to stop subscribing to it.

One thing that is hard to stop, but I would love people to stop, is the, the motto that people work 24/7 with no work-life balance. That's nice. It's hard to stop that in the startup because, especially because people are super excited and then they want to, to see the idea to fruition, but it bites them in the in the long run, if this, uh, if this continues for way too long, it bites them in the long run because it's hard for people to switch from that mode to a mode that, um, okay, I should have a balanced life. I really believe that people should have a balanced life and they will be more productive if once they realize that they can have a balanced life.

I'm learning that.

Who used to sleep in the office and, and And I tell everyone, like, the sooner that I realized that I could— if I had a balanced life, I would be more productive, I would be better off.

Yeah, I'm learning that the hard time myself. I mean, I honestly pushed myself to pure burnout couple of times in my life, and it didn't end well. First time I had like heart palpitations, ended up with like heart, you know, high blood pressure in the hospital. Second time had some digestive issues, and it's just all because, you know, lack of sleep, huge amount of stresses and things like that. Yeah, it doesn't really work in the long run. You want to have a sustainable pace and you just want to compound day in, day out towards your dreams, but not in the sense of I'm gonna sprint for 9 months. Like, no, just, just, just, just take a pace, you know, which gives you work and life balance. Love you saying that. Uh, which tech company's approach to scaling do you admire most and why, and you can't choose Microsoft?

I think I mentioned Google as a classical example of like some company— it's almost— Google is almost a black swan event in, in that, in that sense, because they, they got like top talent, that for me is the key factor, and they, they invested in the right platforms early on. And almost this combination of these two things is very rare, right, that you get top talent they will build the right platforms early on. So somehow they got that and that was like a key factor of the success that they had. And the rest is history, right? We all know Google now. Yeah. But I think that was almost a textbook example of like what to do early on.

And it still works. As in, you could take that textbook and you could try to, I mean, you still need great idea. Good timing. And execution, which is a lot of founders really like that, that execution element. But you could, you could take that as a textbook in the sense of what will, what you need to do in these phases moving forward. All right. So Google then, what's one habit or practice that you believe keeps an engineering team performing at its best?

Open communication. I feel, I feel that Trust and communication, it's super important. And I feel that especially now that people work remote, I am— I don't like when I think engineers are on their own without touching base and we don't have— it's hard for us to socialize now because everybody's remote and not everybody's in the same place. But I feel that engineering is a very creative art. Like, it's technical, but it's also a creative art. And, um, people do better if they, they understand the purpose of what they are doing, if they like their colleagues, if they, they are having fun. And, um, and I feel that, I feel that that is very hard when people don't have like that, uh, commodity built in, right? So I feel that without that, it's very hard to do things.

Love that. If you had 30 seconds to give a piece of advice to a new startup CTO, what would you tell them?

Find that unit economics that works and prepares you for scale, and then start investing early in the platforms and the culture that you want to see in the long run.

Excellent. Finally, in a few sentences, how would you define a platform mindset?

Encapsulating complexity in platforms and then having a growth mindset to build a culture that will leverage these platforms to really use technology to impact the world.

That's a— that's a— is that somewhere in your book, Marcos? That was a well-put sentence. I felt like you, you had that written somewhere, but that's excellent. Thanks for that. So, so this was an hour would just blitz through, and we actually an hour 15, fully packed with insights. Enjoyed every bit of it. Before we write up, Marcos, if people want to learn more about your book and about your approach to platform mindset, where they can find you and just get more information?

Oh, there is my website, fontoura.org. There is information about me there. I'm also very active on LinkedIn, like I post a lot there. I, I am not a huge social media, uh, po— uh, guy, but like I'm starting like now because of the book also to, to have, uh, Instagram so people can see like book events and all that on Instagram as well.

Okay, excellent. So, uh, we'll, we'll add all the links, uh, in the show notes, of course, for people not tuning in live. Just scroll down, check that out. And for everyone enjoying this episode, of course, hit that subscribe button. We love you showing us attention. And as well, if you have a founder, a CTO in your network which you believe should hear some of the tips discussed in this episode, please share that with them. Thanks again, Mark. That was brilliant.

Marcos, thank you so much, Mike. It was— I had a lot of time A great time being here with you. Thank you so much for all the insights and the great questions.

Cheers again, and as always to our listeners, until the next time, stay safe and see you online.