Ben Pearce (00:01.954)
Hi folks and welcome to the Tech World Human Skills Podcast. We've got another value packed episode for you today. We're thinking about what we can learn from startups. Now, whether you work in a small startup, a massive corporate, or anything in between, there's loads of lessons that we can take from startup culture. And to share.
His wisdom with us today. We have someone who has worked in many startups and worked in large corporates too. Not only that, he was the host of the Italian AWS podcast for four years. So please welcome to the show Alex Casalboni. Alex, it is brilliant to have you with us.
Alex (00:51.484)
Hey everybody, thank you for having me, Ben. Great to be here.
Ben Pearce (00:55.338)
No, the pleasure is all mine and really looking forward to getting into this conversation But before we do Could you introduce her into yeah, let me start again before we do could you introduce yourself for all our listeners?
Alex (01:10.852)
Of course. So I am a software engineer. I've done a lot of things in the last 10, 15 years. I started from web development, went into startups and cloud, then was at AWS for about six years. And today I'm back to the startup world. So I've done a bit of everything and really enjoyed it so far. So happy to share a bit about my startup journeys and also enterprise experience.
Ben Pearce (01:37.276)
And I think what's really interesting as well as your startup.
and your enterprise experience, which is one of the things we're going to be talking about today. You've also had a lot of experience with not just the technical side of life, but also the customer facing the influence. So you've been a keynote speaker, sorry, keynote preparer. I don't think that's a proper word, but and a host of a podcast. Could you sort of give a bit background on some of the things that you've done aside from those sort of core roles?
Alex (01:59.517)
You
Alex (02:08.218)
Of course, so I started with, you know...
full-time development kind of roles. And then I slowly transitioned into the DevRel developer relations. So developer advocacy space where you build content, you do blogging and podcasting and conferences, and you meet a lot of people, build relationships. And then I moved into something a bit more behind the scenes kind of content building and deck preparation and internal research at AWS where we built the executive
presentations that know C-levels do at large events. But what I really enjoy is diving into the technology, building great material for developers to help them and really what really always motivated me in the last 10 years is helping other developers succeed. That's what you know that's my mantra.
Ben Pearce (03:02.606)
Brilliant. And so what we're gonna dig into today is sort of five lessons that you've gleaned from startup culture, but.
I've had a bit of a sneaky peak of the sorts of things you're gonna say. And what's really interesting is they are so relevant, whether you're in a corporate, a mid-size, whether you're in developer, whether you're in customer success, whether you're in pre-sales, they are really useful lessons for all aspects of life, not just developers in startups. I think that's fair to say, isn't it?
Alex (03:33.326)
I think it is fair to say whether you are a manager, maybe you are in a non-tech role, I think some of these apply to everybody. Some are more tech-focused because that's where my experience is coming from. And some of my examples and anecdotes will come from the tech side of things, but I absolutely agree.
Ben Pearce (03:52.463)
Brilliant. And that's all right, because this is the Tech World Human Skills Podcast. So that's what this is all about. Well, I think enough preamble. Shall we get into it? Hit us with what is your first of the five lessons?
Alex (04:06.8)
Yes, so first one is one of my favorite, but also the hardest to put into practice. I like to call it complaining is not a strategy. And then I'll share where I found this and where is the quote. It's actually a quote from Jeff Bezos, but I didn't know back in time when I first discovered it. And the really core message is that...
When you're facing a challenge, an issue, a blocker, you know, it's not enough to talk about it. It's not enough to complain about it or just discuss it or find someone who can solve it in many situations. If not most, at least in my experience, you should take action. You should try to not delay action, not try and pass it to someone else who could fix it for you, not wait for approvals or political discussions. And there's the never ending tension between the
better safe than sorry people and they you know just do it don't wait for approvals kind of people I'm a you know better say sorry they now ask for permissions you know it's just faster you may get things done and this is really a mantra that stay with me over the years
Ben Pearce (05:17.326)
Okay, so complaining is not a strategy. So I really like this. Can I play devil's advocate for a second? So, know, complaining is not a strategy. So let's imagine I'm a leader, you know, and I'm talking to people, know, complaining is not a strategy in this org, you know, let's get this stuff done. Can that not lead to a culture where people don't express?
Alex (05:25.02)
Peace.
Ben Pearce (05:44.085)
reality. There's a phrase in English like yes men or yes men and women where we just say yes. The leader says yes, we don't complain, we just do it. Even if it's a rubbish idea, if it's a bad place to go and the leader's got no idea what they're doing, how do you balance?
Alex (06:04.816)
Yeah, so it's not a, I don't think it's not a replacement for having backbone and raising issues when there is an issue. So that's, should still happen. It's more to me about, you're facing a problem.
Ben Pearce (06:12.6)
Okay.
Alex (06:18.48)
You have no idea how to solve it. Nobody has any idea how to solve it. And you just sit there and wait for someone to do something about it. So that's the situation that needs to change in most places where, you know, I see problems just staying there forever and ever and nobody's trying, even trying to fix it. So I don't think it's about not bringing up criticism. It's not about not showing your opinion.
Instead, know, show your opinion, but also come up with a solution, a proposal, or even just the final solution already done and implemented so you can go and, hey, here is what I did last week. Nobody asked me to do it, but the problem is solved. Let's move on. See you, Amy.
Ben Pearce (06:58.188)
Yeah, yeah, yeah, I do and as I think it through I'm sort of thinking there are people in teams and I'm sure we've all seen these people in teams. There are people that pour energy in.
and there are people that scoop energy out, you know, and, you know, I've heard the term like hole drillers, you know, like there's people pouring energy in and they're like drilling holes and all the energy is just disappearing and complaining is often a big part of that. But I think it's getting that balance, isn't it, with...
Alex (07:12.804)
Hmm.
Ben Pearce (07:31.5)
complaining versus surfacing and having backbone like you talked about. Have you got any examples where you've sort of come across this, know, complaining is not a strategy?
Alex (07:45.659)
Yeah, so the reason I bring this forward as point one is because it helped me a lot during my career because it kind of helps you.
advance and it helps you show leadership, it helps you at a lot of different levels. And when I found this, I was in a startup accelerator in Silicon Valley and they had this kind of attached to every wall in all the meeting rooms and it kind of showed, you know, the startup attitude where you have to sit down and fix the problems, don't wait for somebody else to do it. And this was a Jeff Bezos quote from, I think, the late 90s. I didn't even know at the time.
Um, but so it happened a few times during my career where I applied this and it really helped me and it's still helping me over the years. So for example, um, back in 2017, so, you know, uh, almost 10 years ago, um, I was working in a startup. We were facing some, you know, code or system optimization issues. were using it as Lambda at the time. And so I was spending hours and hours and hours every day or every week to
to of fine tune the functions, to try and optimize the system to find the right balance. So what I did was like, okay, I was coming back home via train on a Friday night, I started coding something to try and automate this, right? And then I spent the entire weekend, because I was super into it. And I didn't have a wife or a family or anything. So I could afford it, right? And so...
Ben Pearce (09:14.043)
You
Alex (09:15.564)
I spent the entire weekend on it. I created this project that became what people now call AWS Lambda power tuning. So it's an open source project. I pushed it on GitHub. And so nobody asked me to build this. The company was not even aware of the problem. It was just a problem I was having. And so my team was having. And so we were all wasting a lot of hours. And so...
I could have just been sitting there and complaining that AWS wasn't giving me enough functionalities or optimization. I was wasting so much time. And so I just built this, pushed it, and got a lot of attention very quickly. So if you look at the GitHub, the stars in history kind of spiked after a few days. But also today it has over 5,000 stars. It's being quoted by most of the AWS well-architected
documentation for how to optimize your system on AWS Lambda. And so over the years it helped thousands and thousands of customers to, you know, improve their AWS bill or improve the performance of their systems running on Lambda. So that's not what I wanted to do. I just wanted to fix my problem. I could have not pushed it on GitHub and nobody would have never known.
Ben Pearce (10:25.134)
Mmm.
Yeah. Yeah.
Alex (10:33.852)
But it definitely paid off over the years. It helped me eventually even get hired at AWS because I was not working at AWS at the time. And so the idea of sit down, fix the problem, even talk about how you fix the problem and share it so that you can solve not just your problem, but a lot of other people's problem too. It really helped me. And every time I do it, it pays off and everybody kind of ends up.
Ben Pearce (10:58.382)
Mmm.
Alex (11:00.752)
thanking you or making sure it was a great investment of your time.
And it also helped the company, it the startup to gain some visibility and so on. It was already aligned to my idea of getting into DevRel and creating content and helping other developers, not just myself or my team. So that was a good experience overall. Not easy because then it creates more work, right? The trade-off is the more initiatives and projects and solutions that you propose, the more work will come on your table, right? If you just sit down and wait, everybody else is doing the work.
you just sit and wait. But you know, I think that's a good problem to have in tech. You know, if people trust you and want your help, that's a good end result in my opinion.
Ben Pearce (11:41.324)
Yeah.
Ben Pearce (11:46.735)
Yeah, great lesson. Complaining, not a strategy. Got it. Should we move on? Lesson number two. What's your second lesson for everyone?
Alex (11:54.96)
Let's move on. Let's move on.
Alex (11:59.983)
So this is something that's very, very valuable in a startup and if you do any startup acceleration or incubation program, that's almost the first thing they tell you. And that's the idea of iterating quickly. Whenever you have an idea, whenever you have a new feature, a new product, a new something that you want to try and do, don't wait for 12 months to...
you know, release it out and get some feedback about it. I think the hardest lesson, especially if you are a perfectionist, especially if you are, if you have a like software engineering background with all the best practices and all the, you know, the engineering mindset is that
you need to accept that your version zero, like I like to call it, your initial version, should look pretty bad. It should not be perfect. It should kind of shame you a little bit, meaning that if it doesn't shame you a little bit, you probably waited too long to release it, right? So, and it's not because, you you need to release crop into production, right? The idea is that...
Ben Pearce (12:48.28)
Okay. Okay.
Ben Pearce (12:55.054)
You
Ben Pearce (13:01.61)
Bye. Okay.
Alex (13:09.626)
You want to get feedback as quickly and as fast as possible. Why? Because if you build for 12 months without...
even looking for feedback without showing this thing to anybody, maybe you are iterating very quickly but in the wrong direction. So that's the key. Like getting feedback early and often helps you iterate not only quickly and fast with the right people, you know, and everything, but also in the right direction. Otherwise, you're you know, swimming as fast as possible, but going to the wrong side of the...
Ben Pearce (13:43.895)
So so what so this idea this version zero, I love this idea like so you should be ashamed of version zero That that's how bad it should be. I love that now what about How far would you release that how how does that damage your credibility? You know, how how can that so if i'm just releasing rubbish all the time and people are like
Alex (13:48.06)
Mm-hmm.
Ben Pearce (14:10.152)
my goodness Ben, know like you've got no skills. This is just rubbish. Are you saying do that or how widely are you saying you release to public with version zero or is it to a close set of confidants that are going to give you feedback, your team? What do you mean about that?
Alex (14:31.046)
Yeah, it's bit counterintuitive because you want people to trust you and see your skills and see how great the product you released is, right? And that's the tension, right? It's not a, or nothing like total rubbish versus perfection. is a good somewhere in between that you need to find depending, you know, if you're doing software for healthcare, you maybe stay towards the second half of the, you know.
Ben Pearce (14:37.912)
Yeah.
Alex (14:54.324)
more closer to perfection. But if you're building software for web developers, if you're building cloud services, if you're building something that's not critical infrastructure for affecting the life of thousands of people like healthcare or stuff like that, banking, what you'd learn in the start up life is that most of the time you can just get away with a version zero that is not perfect because you're adding immediate value to the people that are using the product.
And you get feedback about what the version 1 and the version 2 should look like instead of kind of randomly guessing So the idea is not so much about pushing out rubbish But about pushing out something useful for the people who already use the product people who already know you and trust you So that they can get value immediately and give you back Valuable feedback immediately so everybody is kind of happy and then you also need to be clear about hey this version 0 This is not you know the final product
If you're afraid about brand reputation and things like that, maybe you can do a beta program. Maybe you can find ways to do, know, selected to work with a selected group of beta testers or pioneers who are used to this idea of version zero and, you know, then find your balance there.
Ben Pearce (16:13.158)
Yeah, do you know what? There's a great little analogy. I remember hearing this years ago and it's got an Italian theme. So as you're from Italy, Alex, I'm going to throw it out there. But it's this idea of the idea was, you you need to design a device that's going to get people places quicker.
Alex (16:22.076)
You
Ben Pearce (16:30.738)
and one person sets out to design a Ferrari. The ultimate machine, it looks beautiful, performs brilliantly, the engineering is perfection but it takes five years to build. Somebody else built a skateboard.
And now we've got 10 000 people on skateboards then somebody adds a little little handle on the top and we've got a scooter and now that's up to 20 000 now somebody wax a little electric motor on the bottom and you know now we've got an electric e-scooter and that's taken us up to 100 000 we still haven't released the ferrari yet we released the ferrari it costs 100 000 euros the little e-scooter's costing a thousand euros and you've got a massive user base it's filling its purpose it's not a ferrari
but it gets you where you're going and it's got massive adoption. So I think that's the sort of thing you're talking about, isn't it?
Alex (17:24.092)
Yes, and that also tells you about product evolution because iterating doesn't mean, okay, we need to build a Ferrari. That's our vision for the next five years. But if you start iterating like in a more traditional, you know, waterfall approach. So how do we build a Ferrari? You start with the wheels or you start with the body of the car, but that's not releasable.
That's not a product. Nobody would ever use just a car wheel. You need the full car. So how do you make that vision evolve in the next five years? Like you said, start with a scooter, start with something small that is immediately useful without waiting for the next five years, right? That's how you think with a product mindset about evolving towards the final product that you think people need.
Ben Pearce (17:48.397)
Yeah.
Ben Pearce (18:06.05)
Yeah, brilliant. Start with version zero, you should almost be ashamed of it. Love it, love it. Let's move on, shall we? Lesson number three, what's your third lesson from startups?
Alex (18:19.718)
So this might be the hardest to put into practice and this can apply to a lot of different things. I like to call it kind of focus and prioritize, know, try to avoid distractions. And in today's world and in today's, know, social media, a heavy kind of landscape, it's not super easy to do. So, but not just about personal distractions, it's also about business distractions and things that you think you need to build,
not really and you end up wasting a lot of time. So there are hard lessons for me here is learning how to say no to a lot of things that seem important, maybe seem fun to do or interesting technically, but they don't really provide a lot of value to the team or to the business.
Especially if you come from the technical or maybe are an engineering manager or developer or someone managing a team of people who build stuff. It's super important. And so it's hard lesson number two in my head is that.
If you build something in the technical world, you often have to maintain it over a very long period of time, almost forever. And so the idea, you know, bringing this startup attitude, the startup mindset is only focused on the things that really differentiate you. I can give you an example. You are a startup in the first 12 months of the company.
Ben Pearce (19:44.726)
Okay. Yeah.
Alex (19:48.847)
And so I've seen so many startups waste months and months and months on building a custom web framework or re-implementing authentication and single sign-on from scratch because it's complex and fun and cool. But in practice, everybody has those. You're not differentiating your business. You're not...
telling your customers, hey, we're special because we have this. Or you have single sign-on. Who cares? Everybody has single sign-on. Why did you waste three months building that from scratch? Why you could have used a SaaS product or something ready to use, right? So focus on the important thing that differentiates you as a business. So especially in the startup world, but you can reapply that to a lot of other scenarios.
Ben Pearce (20:36.92)
So focus on the things, so focus and prioritise the things that differentiate you.
and buy off a shelf the things that I guess get you to parity. So like single sign-on, you just need it because everybody wants to use it, but don't reinvent the wheel. So get off the shelf the things that get you to parity, but then focus on the bits that really bring value, that really differentiate.
So how do you think about that? So if we start to combine your lessons, so you've got your, you start with zero. So we've done version zero, right? We've got a load of feedback. Now you're getting feedback from everybody that's saying, you need this, you need this, you need this, you need this. How do you go from all of those potential ideas and go, this, this is the thing that we're gonna focus on?
Alex (21:34.173)
Yeah, that's one of the tricky parts where you need to understand, know, spend time on understanding what people actually need. Not only when they ask you, you know, it's the typical, uh, you know, people back then ask for a faster horse is not for a car. know, people still build cars and they understood the problem was, you know, moving people around, not, uh, getting a faster horse. And when you get a lot of feedback, that's where you should spend most of the time understanding and figuring out is there a big.
idea that you can really work on that will solve most of these seemingly unrelated problems. And back to the idea of iterating quickly and thinking about iterating. Often you do find the great super complex idea that will solve all your problems, but they will take five years. know, back to the we should build a Ferrari use case.
I think in this case what you should try and do is to kind of break it down because every amazing idea that would take forever is composed by many smaller things that you can probably do today or next week or next month.
and they will add value right now instead of in 12 months or next year. So that's the work and it's the weapon, the prioritization, the analysis, the strategic analysis of what you work on. And it's tricky. I don't have a special recipe for that. It's something that really applies to your field and your expertise and your experience as a product or as a leader kind of person in the company.
Ben Pearce (23:00.937)
Hahaha
Ben Pearce (23:11.97)
Yeah and it's fascinating isn't it because we're thinking about this from a startup mentality.
Certainly from my perspective, when I started this business that I run now, the Elevated U business, and I left the big corporate world and started my own business, what was really interesting was I only had so much money, right? And I needed to be making revenue quickly because if I, once I run out of runway, then it's game over.
And I've always found that that gives me tremendous clarity, I will say, on do I think this is going to be something that is going to help me generate revenue? And if it does, brilliant, this is a way to go. And if I don't, maybe it's a nice to have something that you can do later. So that really helps kind of do that. But then on the flip side.
of this, and so this would be interesting to get your perspective from a startup, is then you chase the revenue and you almost lack the focus because you're going, I could make some money here that gives us runway. I could make some money here that gives us, we can pivot to this. There's a revenue. And so you end up chasing the money, which means that you're not focused. What's your experience of that in a startup world?
Alex (24:31.584)
So what I've seen smart people do is work on categorizing the things they want to do based on not only does it relate, know, does it provide impact like revenue, for example, but also how long does it take for this to happen? So you have like a four kind of quadrant. And so what smart people tell you to do is to
Ben Pearce (24:48.718)
Okay.
Ben Pearce (24:53.313)
Okay.
Alex (24:57.916)
You know, the bottom side of the quadrant is small impact. The top is high impact and the left is very slow to build and the right is very fast to build. Right? So if you categorize all the things on your table like that, you have a good, um, method to understand, you know, what you should really focus on. Cause something maybe has very high impact, but it will take you a year to build. So maybe that's, you know, possibly a distraction.
Ben Pearce (25:03.79)
Okay.
Ben Pearce (25:10.67)
Okay.
Alex (25:27.566)
Everything that's quick to build and slow and low impact, just ignore it. It's just wasting your time.
Ben Pearce (25:32.333)
Yeah.
And the problem is often they might be the exciting things. They might be the shiny things. They're the things you really want to do.
Alex (25:39.005)
Exactly, Yeah, yeah, like building a web framework that will give you a lot of satisfaction as an engineer. I can give you an example back in my first startup days. We ended up building a MongoDB mapper for Python. It didn't exist. It was exciting. It was pushing the frontier of technology back in 2014. But then, you know...
like two years later or one year later, you know, an official driver for Python and MongoDB existed and it was, you know, contributed by thousands of people. And it was so much better than what we came up with. But what we built back to the idea of if you build something, you have to own it and maintain it forever. It was so much part of the core of the product that we couldn't get rid of it. We couldn't just move to something else. It would have taken months. so, SDK technical depth.
Ben Pearce (26:18.85)
Ha ha ha ha.
Ben Pearce (26:25.048)
Yeah, yeah.
Ben Pearce (26:32.558)
Okay, so it became technical debt for you.
Alex (26:36.792)
And so I think if I go back, I would tell my folks, this is wasting our time. We are actually building something that will kind of stay with us forever and hold us back forever. that I think it took them after I left the company, after five years, it took them five or six years to get rid of that core component of the product. So I'm not saying, a lot of people do this. I'm not saying this is bad always.
But our customers didn't care. had that. It didn't provide any business value at all. It was just fun and cool to do technically. yeah, if I go back, I wouldn't do it.
Ben Pearce (27:12.492)
Yeah, you would do that. Brilliant. And so I really like that idea of your quadrant that you've gone through there. So, you you've got those four quadrants, everything on the negative side of the scale, everything at the bottom is basically, don't do it unless you're twiddling your thumbs, don't do it. And then on the top half of that scale, you've got the what's the what's going to take you a long time to do and what can you do quickly. And so, of course, those things that you can do quickly that are the most impact.
Brilliant, get them nailed and then get on with those longer term things.
Alex (27:45.093)
Exactly, and the long-term things again can often be breaking down into smaller, faster and slower things that you can re-prioritize again. So it's a time-consuming exercise. You don't have to do it every day. It would be too slow and too time-consuming. But if you do it once a quarter, once a year, at different levels of strategic planning, I think that would be useful.
Ben Pearce (27:54.499)
Yeah.
Ben Pearce (28:02.733)
Yeah.
Ben Pearce (28:10.636)
Yeah, brilliant. Love it. Well, that's lesson three. Lesson four. What's lesson four, Alex?
Alex (28:19.164)
So this is similarly related to the idea of taking decisions. And so I like to call it, it's a typical Amazonian thing that I bring with me since I joined Amazon. And so at Amazon, they immediately teach you to think in terms of one way decisions, like one way doors that are really hard to revert or go back or change your mind. And two way doors and two way decisions that.
Ben Pearce (28:42.626)
Okay.
Alex (28:45.774)
you can easily revert or change, or maybe it's cheap to do or fast to do. And so the hard lesson, and we're back to the idea of prioritizing and focusing on what's really important here, is that not every decision has the same weight or the same importance. Some decisions are very important and you should spend time on picking the right choice. But most, I would say the largest majority of decisions are very easy or cheap and fast.
Ben Pearce (28:50.209)
Okay.
Alex (29:15.494)
to change and revert. And so those you should take quickly, all right? What I see, you know, in the business, in the technical, or even in life world, is that people treat decisions as they were the same, right? Whether you're buying a new car or buying a new t-shirt, as you know, the life changing decision, you should sit down and think for an hour before you take it, right? And you know, intuitively it's not.
Ben Pearce (29:38.678)
Okay.
Alex (29:41.307)
Like if you ask anybody, know, you should never think about a t-shirt for an hour. But what actually happens in practice, if you look at how you spend your time, is that people waste way too long on decisions that should have taken quickly. And often you end up that you don't have enough time to spend time on the very important decisions that you should take, you know, a little bit more slowly, I would dare to say, or carefully. So...
I think it's really important. This is something you can apply to everyday life and the hard part is not the decision. The hard part is deciding if that decision is a one way or a two way door.
Ben Pearce (30:24.11)
Okay, any tips on how you make that call on whether it's a one-way or a two-way door?
Alex (30:31.324)
I mean, most people think in terms of cost. if there's like the car versus T-shirt, intuitively a car is cost a lot more money and it's harder to sell or to throw away after you don't need it anymore. So intuitively you should take a bit more consideration and time to take that decision. But it's also about how easy it is to revert. Imagine you're doing like a business decision or picking a vendor. Like do you use AWS or Azure or, you know, do you...
go this way or that way, how hard it is if you change the season in six months, you know, down the path to do something different, to go back and rebuild everything for another cloud vendor, for example. This is a typical, you know, vendor looking kind of scenario. I don't think there is an easy way to figure it out. It is very subjective. But the really important part is to focus on what's important. So I go back to the previous three points.
and try to prioritize and focus on what's differentiating you, focus on iterating fast. And so if you can take 80 % of your decisions today instead of next month, you're going fast, you're iterating quickly and you're doing all the things we've been talking about so far. So that really enabling all the other things we talked about because otherwise if you take two weeks to take any decision, you're kind of stuck and you're not moving fast enough.
Ben Pearce (31:57.796)
Yeah.
Yeah, and it's interesting because it's not like you said, it's not just cost, but you know, I was just reflecting then on you were talking about that little tool that you made that integrates Python with MongoDB. And actually you made that decision that turned out to be a very one way, yeah, a one way door because now it was the core part of everything that you had and you were laden with all this technical debt because of that one way decision. So it might've been cheaper than buying something else or something like that, but it
was very costly because now it was at the foundation of your architecture for everything else and was hard hard so it's not just cost it's all of those other things that you've got
Alex (32:33.67)
Exactly.
Alex (32:37.62)
And sometimes if you spend enough time, you know, categorizing the decision, you can turn a one way decision into a two way one. Like for example, with this project, we could have thought a bit longer and decided, okay, this is possibly a one way decision, but if we do it right, we turn it into two way decision. And so we are ready in one year to switch to something else, but we were not because we're going too fast. And we thought we didn't even think about it.
Ben Pearce (33:03.182)
Yeah. Yeah.
Alex (33:07.63)
So that's how a lot of companies think in terms of picking the right hosting provider or the right cloud provider. That's why a lot of people choose Kubernetes because they can run in theory on any vendor without being locked in. That's driving a lot of decisions with the idea of not locking yourself into a one way door that you can't revert. It doesn't always work. Sometimes the solution you choose
Ben Pearce (33:31.756)
Yeah. Yeah.
Alex (33:36.454)
to turn that into a two-way door is the actual lock-in. Like, you know, some people go to Kubernetes and now they're locked into Kubernetes. They can't do anything else. But that's another discussion for another podcast. I don't have a super strong opinion on that part.
Ben Pearce (33:44.974)
Yeah. Yeah.
Ben Pearce (33:51.405)
Well, with that said, I think let's move on to our fifth and final lesson. So what's your final lesson for us, Alex?
Alex (34:00.432)
Yes, all of this brings you... Sorry, all of this doesn't really work if you are scared of failing, right? Back to the version zero, you know, could be scary. If you are afraid that, you know, by doing all these things, by moving fast, by building iteratively, by prioritizing ruthlessly, you can't do all of these things.
unless you are okay with failing or with at some level, know, failing. I think for us Europeans, it's a bit tough because it's cultural. All of this is cultural. There is this idea that if you fail once, you're a failure for life forever in some cultures. And that's part of, you know, how people grow up and how you think about these concepts. One of my best memories about doing the acceleration program in Silicon Valley was that
Our mentor was a 19 year old guy who had built five startups in the last five years and failed all of them. He had so much to teach us because he failed so many times in so little time. And so if you are not even 20 year old person in, I'm talking about Italy, for example, and you failed already so many times at 20, people will look at you and say, oh, you're already a failure at 20, right?
You couldn't do anything so far. And so it's cultural. I think you need to embrace failure. need to embrace that the only way to succeed, the only way to learn, the only way to know what's good for the business or for technology is to get some failure in your hands. I would even say that if you meet someone who has never failed before, they probably never even tried to do something.
Ben Pearce (35:33.751)
Yeah.
Alex (35:56.955)
meaningful or challenging or exciting. so that's also a strong opinion. Somebody will tell you about job security and there are other considerations, not just moving fast and learning everything you can learn. But I think culturally accepting failure is a big part of making all the other lessons work. Otherwise you'd be too scared to move forward or you are too concerned about brand reputation or too concerned about
protecting your job security. And so it's a good lesson to bring and like everything else there is a good balance that you need to find depending on your own situations and career path and company culture and so on. But I think it's a very important one to wrap up with.
Ben Pearce (36:45.356)
Yeah, no, I think you're right and a couple of thoughts spring to my mind as you sort of talk about that and the cultural piece and the reluctance to fail.
first thing I think is you know so I remember I used to do performance reviews for people in the team and one of the questions you know would be like oh well where have you have you failed over the last couple of of months you know with this idea of trying to promote this we want you to fail because we want you to learn we want you but there is also that piece of hold on if I'm failing they're gonna sack me so you kind of had this kind of
You know these two this tension that was going on there and the way I always used to like to think about it And and you've already done it actually during this podcast was to say, okay You haven't failed right? Everything's good but if you were to time travel back to your former self before you started this project and you were about to give yourself some advice from what you've learned what would you do differently and
And then they go, well, I do this differently. do this differently. I do this different. And so my point was, well, there's an argument that you kind of failed in all of those decisions that you made. And they'd be like, well, yeah, but based on the information I had at the time, it was the right decision to make. So it wasn't a failure. And my point was, it doesn't matter on, you know, whether it was that type of failure, whether it was the best decision given. The point is you've learned something better now and therefore you could think of this as I failed and I've learned something better. And maybe that was a
a way that people sort stomached this idea of being a failure of failing, that it was okay.
Alex (38:27.1)
I mean, experience means stacking up failures over failures or bad decisions over bad decisions. So, you know, next time you'll do the right one. It's just a different way to look at it. But especially if you're leading a team or especially if you need to show by example, I think it's important, like you said, to think and reason and analyze the past to do better in the future. That's the whole point, right? It's not about everybody should fail just for the sake of failing. You should try not to.
Ben Pearce (38:35.779)
Yeah.
Alex (38:56.438)
but not be scared to possibly fail because that's part of how things work and so it should give you the motivation.
Ben Pearce (39:02.874)
And the other thing I think when you add that to your version zero that we talked about.
you almost get this idea that I quite like of micro failing so if you fail little and often and course correct little and often then that means you don't have the big failure that gets you sacked you haven't built the Ferrari that nobody wants you've course corrected with your electric skateboard or whatever it is and you know so you've failed along the way but it's been fast and you started at version zero
you've iterated on it as opposed to we've done this in isolation built this big thing then it is a massive failure and that is where it turns up in your performance review it turns up you know because so taking those other lessons together means that this works really nicely
Alex (39:56.733)
Yeah, so fail fast, fail often, but to instruct you on where the next version should go. Yeah, that's exactly the idea. It's not about trying to build a big failure, but try to build small micro failures that allow you to iterate into the right direction. There is no way you always go to the right direction, but if you do it quickly, you can find and turn and make it right.
Ben Pearce (40:21.932)
Yeah. Brilliant. Well, I think that's all five lessons. I think we're coming to the end of the podcast. So shall we just do a quick wrap up summary, key takeaways? Could you wrap up from your perspective, Alex?
Alex (40:35.448)
Absolutely. So I've talked mostly about my startup experience, but I did apply most of these or even learned some of these into an enterprise context. So I understand you might have a different perspective or a different company culture, but I think if you apply these, you know, trying to build solutions instead of just complaining.
iterate quickly so you can move fast and you can get feedback from people as soon as possible and go into the right direction. Try to prioritize. It's rough because you have to say no to a lot of things, but if you avoid the distractions, you are moving quickly and focusing on the high impact items. Try to categorize your decisions into one way and two way doors. That's crazy useful and it really helps you in everyday life as
well, in my opinion, and then try to embrace the idea of failing quickly or fast and early, you know, with micro failures to be able to move even faster and into the right direction. think this will improve your teams, your career, your company. think there are maybe like a 1 % cases where it doesn't really work. It could be because of the culture, but especially if you are, if you have the possibility to
influence the culture. If you are a leader in your organization, try to apply this and you will see more commitment, more ownership, more speed, more quality and more business value. So I think it's, I hope it was useful and I think it has the potential to improve a lot of companies and a lot of teams and organizational cultures.
Ben Pearce (42:17.294)
Yeah, brilliant. Thank you so much for that Alex. I'm gonna just list off the five. I've got a list in front of me I'm gonna cheat. number one, complaining is not a strategy. Number two, iterate quickly. Number three, focus on high impact activities and avoid those distractions. Number four, take two way decisions quickly and one way decisions slowly. And number five, failing is okay.
brilliant brilliant set of lessons. So thank you so much Alex for bringing that to life for us. I think you showed some really good examples of how you can apply those things whether you're in a startup or whether you're in a in a big corporate or a middle corporate whatever whatever it might be. Now if people have loved what you've been talking about how can people get in touch with you or find out more Alex?
Alex (43:08.508)
Feel free to connect on LinkedIn. I'm Alex Casalboni. I'm happy to have a quick chat or maybe you're struggling in your job. I know the job market is still a bit unstable and so a lot of people reach out in the last 6 to 12 months. I've taken some tough decisions myself so I know it can be tricky to make the jump sometimes. So again, feel free to reach out. I'm happy to talk and share some personal stories or hear about yours.
Ben Pearce (43:37.198)
Brilliant. And I will put your link to your LinkedIn, put that in the show notes if people want to make sure they got the right person. So the final thing for me to do is to say Alex, thank you so much. I appreciate you're a busy man with life, with children, with work, with everything that's going on. So to take the time to give us these pearls of wisdom has been really good. So Alex, thank you so much for coming on the show.
Alex (44:06.374)
Thank you man for having me and enjoy the postcast everybody. Cheers.
