ºÚÁÏÃÅ

Ìý

[Music]

Ìý

[Rebecca Parsons] Hello, everyone. My name is Rebecca Parsons and I am one of the recurring co-hosts of the ºÚÁÏÃÅ Technology Podcast series. And I'm joined by my colleague Prem.

Ìý

[Premanand Chandrasekaran] Hello, everyone. Thank you, Rebecca. Glad to be here. I'm also one of the regular co-hosts and looking forward to a wonderful episode as usual.

Ìý

[Rebecca] And I'm joined by two other colleagues from ºÚÁÏÃÅ, Sofia Tania, would you like to introduce yourself, please?

Ìý

[Sofia Tania] Yes, thank you for having me. I'm Sofia Tania, but I go by Tania. I'm a tech principal at ºÚÁÏÃÅ and have been at ºÚÁÏÃÅ for about 10 years now. And I'm also part of the Digital scale-up Group, which is relevant to the topic at hand we are going to talk about soon.

Ìý

[Rebecca]...and Stefania?

Ìý

[Stefania Stefansdottir] Hi, thank you for having me. I'm Stefania Stefansdottir. I'm also a technical principal at ºÚÁÏÃÅ and I have worked here for about 10 years and I work as a general architect and technical principal for ºÚÁÏÃÅ’ clients in the East market and in North America.

Ìý

[Rebecca] OK, so Tania, you mentioned the Digital Scale-up Studio. So why don't one of the two of you tell me a little bit about what this unit does, and why it's different?

Ìý

[Tania] Yeah. So through the many years of ºÚÁÏÃÅ’ history, we have actually even before the scale-up Group has been created as an independent unit, we have been partnering with start-ups and scale-ups to help them grow and reach their next milestones and a few years ago we started thinking, well, we should probably sort of formalize and codify the lessons that we are seeing that the patterns are we are seeing into something a bit more coherent to partner with these organizations better. And so the group was created.

And part of what we aim to do, as a group, is also to share the lessons that we've learned. I guess I kind of alluded to before, and that led us to publishing a series about bottlenecks, aliasing and scale-ups, which one of them is the one that Stefania and I wrote about cost efficiencies.

Ìý

[Rebecca] Okay, so why don't you introduce this cost efficiency topic to me? And Stefania, I'll start with you. Why was this something that was interesting enough for you to, you know, invest the effort into writing an article and now doing this podcast?

Ìý

[Stefania] I have kind of maybe a little bit of a different background from a lot of technical principles, but I actually also used to work used to study something called financial engineering and something called operations research, which interestingly enough both focus on cost and finances.

And the other side of it actually are on optimization and operational efficiency. But I end up working in software engine engineering and architecture. And I ended up working with a client of ours here in North America, and they were on the beginning of their kind of digital journey. And we had worked with them from scratch, we had built their holistic platform. And as they were growing very fast, we started seeing kind of the costs starting to build up faster than we anticipated because we've got a spurt of growth. And all of a sudden the costs started growing. And that kind of wasn't an expected growth nor expected cost.

And then all of a sudden we had to start thinking a little differently about how do we operate these platforms and how do we make costs associated with our our holistic thinking, both from architecture perspective, operational perspective, and just in a forecasting expectation for the client and this kind of led us to an initiative where we started looking into these operational cost efficiencies, which I thought were really intriguing.

And you had a lot of good learned lessons that we thought were applicable to other clients and actually also to scale-ups in particular.

Ìý

[Rebecca] And Tania, what about this topic is interesting to you?

Ìý

[Tania] For me, it was kind of a convergence of two things. The first one is, as a tech principal of one of our accounts before, I kind of got sucked into a cost savings engagement because the client that I was working with had a cost balloon and we had to spin up a team to look into it to resolve both the technical, how do we reduce cost right away and how do we maintain it going forward?

So that of course, made me think about the topic. And then the other factor that was converging at around the same time as I was starting to get pretty involved in the Scale-up Group that I mentioned earlier and of course the Scale-up Group was thinking about these bottlenecks.

These things are starting to… the patterns that we are seeing, they are typically starting to constrain start-ups growth at a certain point and cost was one of them. And so those two things came together and then I also wanted to look at both… share what I've learned and also learn more about the topic from the other authors.

Ìý

[Rebecca] And so we very often hear that in the early stages of a start-up, what you're really trying to do is just figure out what it is the market wants. And cost is certainly less of a factor there. So what are the signs that you've reached the point where cost becomes this more significant factor?

Because clearly, you don't want too cost optimized too soon when you're trying to explore and figure out fits. So how do you start to recognize, we're really getting into trouble here now and we've got to take this forward? What are those signs?

Ìý

[Stefania] There are multiple ones that we can see. But one big one is actually, just visibility is the first one, meaning that if the person who is mainly handling the invoice is the first one who starts saying something or the forecasting becomes really nowhere close to where the actuals are, that is often the first bell that starts ringing because there's actual, a person who manages it that it gets concerned and worried.

And that's kind of the first alert of it. But there are other more subtle signs that you can see.

For example, that the cost starts growing faster per unit of change, meaning either customer that uses your platform, or what you're selling. And you are seeing that growth keeps the cost keeps increasing more per this individual unit.

But then there's other signs that you can see that your contracts that you're expecting, your fraction of third party services, or maybe your observability tools, or your cloud costs, you had certain expectations of how the cost would go through on the month. But it completely changes from an engineering perspective. You might have the visibility. But the changes are really fast.

Those are times that you start looking into it a bit more. Something starts ringing internally that you feel like, hey, we really need to start looking into this. But also another aspect of it is that when you go through funding rounds in the scale-up culture, you might need to be showing that the cost of goods sold is actually good. And then also it's a time when people start actually looking really deeply into this because it can affect how you're getting what kind of funding you're getting.

Ìý

[Prem] So I do have a question for you because maybe a lot of listeners do have this as well. So are we saying that it's not necessary to be cost conscious right from the outset?

Ìý

[Tania] No. You don't need to. There are different kinds of phases when you're, especially, coming from a start-up a thought process. Then in the beginning, you are just being scrappy. You don't have that much money. And you're trying to find a product market fit.

And you're going to just try to figure out how to get to what you need to do with that financial runway path you have. That is different cost consideration. If you don't have a lot of it, you'll be using it up to a maximum advantage. But you're trying to do it to actually reach a certain conclusion in a time frame that you have.

That's not when you should be thinking about packing your resources and things like that. You might do it just because you don't want to waste the penny because of where you are in your phase. But it is not something you should, necessarily, need to think about from an operational efficiency for a long term. It's not where your effort should be put in. You should be focusing on the product market fit. That is not, necessarily, a phase that you should be looking at.

And then when you get into the, ‘Hey, I found some product market fit, and I'm growing’, you're starting to still try to capture customers. So you're not necessarily trying to focus on this cost efficiency even at that point in time. It is actually only when you start moving a little bit further up when you have to start, ‘hey, now we've reached a certain amount of maturity. And I want to continue growing’.

That's where your slope starts to get, you see it happen. And you want to be like, hey, now we need to start thinking more about operational efficiencies. And this actually starts applying to more than just this bottleneck cost. We can see it's also happening in technical depth at a similar point in that growth curve.

Ìý

[Prem] So what you seem to be saying is it might not matter until you hit a cusp of popularity?

Ìý

[Tania] It's not that they doesn't matter at all. Obviously, if you're really bleeding money from your architecture, it is going to affect your runway. But realistically, when you are very early, the chances of that happening is much lower compared to when you have started hitting product market fit and you are scaling in terms of the number of customers that you have to serve.

Typically, the risk of cost ballooning is larger when you are at that stage. And that is where it can materially impact your runway. So again, I think cost matters in all phases. But in the earlier phases, it's not a top priority.

It's maybe something that you're just watching on the sidelines to make sure that it's not going crazy in terms of the numbers. But your priorities for the first few stages are just getting that pilot market fit. And when you've gotten it, then you go to then cost becomes a bigger potential risk to your--

And we're thinking about this from two different terms. There's a cost in terms of cost of people and investment in your product. And then there's the operational cost of running your product. And I think we should make that distinction here because that's why we're saying that you think about cost all the time.

But like we said, in the beginning it's more around the investment I'm putting into this company, am I getting enough out of it to be able to reach some kind of popularity to make my company work? It is not necessarily tied to what we focus more on the article, which is operational cost more than anything.

Like, how am I running this product and moving that forward? And that's the different distinction that we are making in this article. And we don't really focus on things like labor costs, or marketing costs, or anything like that. We focus more on just infrastructure, operational costs, and ties to technology.

Ìý

[Stefania]So the cost of your architecture, the architecture that you're using to serve your customers, that's what our focus is for the article.

Ìý

[Rebecca] And let's briefly look at this from the other end of the spectrum before we get into the specifics of the recommendations.

How is this different? Or is there a difference in thinking about this operational efficiency for a scale-up versus an established organization? Is your approach to operational efficiency going to be different because of your scale-up as opposed to some Fortune 100 company?

Ìý

[Tania] So certainly, Fortune 100 companies can also get into a situation where cost balloon in some part of the organization. Now, I think we do see that typically. These bigger companies tend to have more rigor around cost controls. But that's not always the case, or not always uniform across different parts of the organization, or different technology workloads.

So for example, one of these organizations can be maybe a little less mature in terms of how they control costs for data workloads because they are still building that capability. But again, the problem can occur.

I think, the higher level approach that we cover in the article, the reduce and sustain a lot of those apply to both. The main difference that I see is apart from that tendency that Fortune 100 companies tend to have a little more control already, is the effect on the sustainability of the company is very different because scale-ups have, well, limited funding.

They are still very dependent on investor funding, typically, whereas Fortune 100 companies, they are a little bit more have more cushion, so to say, financially. And so the impact of the ballooning costs can be a bit more manageable ones.

Ìý

[Stefania] But there's also another aspect of it is that when you're the approaches are similar. But when it comes to the Fortune 100 companies or bigger enterprises, one aspect of it is that you have more players that you have to coordinate between.

We often talk about in our approach like, ‘hey, you should look at it from different aspects of these FinOps teams or these financial operations teams’. They come from different parts of the organization. In a scale-up, you might not have that many employees. Maybe you're 100 people. Everybody knows each other by name. You can work across barriers or walls.

But when you become part of this into those bigger, bigger companies, it is often multiple walls between different departments or people who are never really necessarily work together that closely, that need to come together to actually make this work.

You would maybe have vendor management groups that have to deal with your contracts and third party contracts and a third party managed services.

But at the same time, the technology people also need to have that relationship because they actually help them manage the solutions. They give them their recommendations. And they also do not have collaboration has to be a lot tighter than maybe normally it is.

Or for example, you start to work with your finance department a lot more closely because maybe how you guys were structuring your budgets doesn't make sense for with new cloud ecosystem versus how it worked when you were on-prem. And there is different kind of ways of handling your bookkeeping.

There are things that in a big, big enterprises that have a lot more legacy, that there's just more basically, more things around it. And it's a little bit more lift to move everybody in the same direction. The good thing about it is that you have a lot of people with different kind of specialization.

But it's just about getting this group of people who normally never talk to each other together to come towards a goal. And that often can be maybe a little bit more of a difficult sale following in the scale-ups group because everybody is so tight. You can just move these things forward maybe a little faster. But again, you have more cushion on that the price, than necessarily in the scale-up group. So it balances this out. But it does change it a little bit.

Ìý

[Prem] I do have a related question there in terms of the recommendations that you make in your article or the signs that you point out. So are those more universally applicable for, I know you've directed it specifically or addressed it specifically to scale-ups. But can this be applied a bit more universally to larger organizations as well?

Ìý

[Stefania] Yes, you can most of them can.

Ìý

[Tania] I would say, yes. I was going to think of a longer answer than just yes. So basically, the approach that we propose in the article are to first is, this is assuming that the company, or I guess a Fortune 100, or a big enterprise in the States are already seeing that their costs and maybe one part of the organization has increased dramatically beyond their projection, or beyond their budget, or something like that.

The first approach that we propose is, basically, reducing that cost no brainer. Of course, everybody will be like, OK. Of course, we have to reduce that.

And how do we reduce that? And it's really I think it's a pretty general framework that can definitely be applied in all types of companies.

And it's really, OK, let's look at that part of the organization where cost is increasing dramatically. And let's look at what part of the cost is ballooning? Let's look at the drivers for that cost. And what I mean by driver is sometimes it's specific applications, or it's a specific managed service, or it's certain environments.

When you tease apart the cost report you have, you can see, which factors are playing into the cost more? And then once we do that, we have a few levers to control that class. And I think this is, again, something that definitely applies to all types of organizations.

Of course, the exact lever will depend on the drivers, like, whether it be let's say it's just your observability service. Like, a managed service for observability is ballooning. What are the levers? What are the cost factors for that?

And then from there, we just prioritize, which ones are the low hanging fruits versus,

so basically, prioritize across effort and impact. And we just start executing in collaboration with teams that are the product teams that actually work on those areas.

But that said, we also made a comment in the article that often because we need to move fast to reduce costs at this point. And that sometimes, you need a team that is focused on that initiative to just reduce cost in collaboration, of course, with the different teams.Ìý

So this is what we're proposing in the reduce approach. And I think that that definitely applies to the others.

Sustain, maybe we'll talk about this later is a completely different approach because it's all about the cultural change that you need to infuse to the organization to make sure that cost stays at that level, or that lower level, or a more sustainable level. And I think, again, that the larger points there still apply to both scale-ups and enterprises.

Ìý

[Rebecca] So tell me a little bit more about this ‘sustain phase’. Because when we talk about things, for example, like technical debt, one of the questions I very often get asked is, I'm going to give you x period of time and x amount of resources to fix this problem. How do I know that you're not going to be back in 6 or 12 months asking me to do it again?

And I suspect that's a lot of what the sustain phase is about. So how do you go about making sure that you don't get yourself back to the same kind of a problem? What are some of the strategies that scale-ups can use during the sustain phase?

Ìý

[Tania] Maybe before we get into that, just to paint a bit of a story. So let's say there's a scale-up or a company that has gotten into a bit of a mess in terms of their architectural cost. Let's say it's because, initially and this is pretty common too in start-ups, scale-ups.

It's a bit of a free for all, especially, say, in pre-production environments. Free for all, as in, anybody can create any infrastructure. And let's say that they are also doing that because they are not aware of, not very well aware of the cost impact that the things that they are creating in those reproduction environments are costing the company.

I think a lot of people will have intuition that, of course, if we created an infrastructure component on some cloud provider and we don't turn it off, for example, when they're not using for sale, it costs something that we don't have such strong intuition to the level of numbers for those.

So let's say, it's something like that. Well, in that situation, after we reduce the cost reducing the cost can be as simple as turning off things. Of course, we cover more of the strategies for reduce in the article. But let's say in that situation, we just reduce by turning off things.

If that's all we do and we don't fix, for example, that empowering the engineers and the product teams with, hey, here is how your actions are impacting cost, or your product team, or your part of the company. Then they're going to operate without that signal in mind.

Even with this contrived scenario, that's the thinking behind the sustain phase is that once we reduce the cost, there are certain things that we need to change in the company in terms of, again, the culture and the operating model to make sure that people are operating now with more cost control naturally. So without really policing them, policing their every action, we want some cost awareness to be embedded in their mindset. So maybe I'll let Stefania cover the sustain phase.

Ìý

[Stefania] When we think about some of these sustain phases, it is different aspects that you have to consider. But the main one that we see often lacking in a lot of companies, both scale-ups and enterprises, is actually the visibility of cost in a way that makes sense to people either tied to product, or tied to teams.

There's no way for them to see like, hey did my cost actually increase with these new product changes that we put in place? Or did our revenue increase and our cost increase more than we expected? And a lot of that is missing from the view of engineers or architects. So they can't really understand the impact of the decisions that they were making. That is one big thing that we think can really help is just changing a little bit organizational thinking and consideration around cost.

But there's, of course, side effects to some of that. We don't want people to become frugal to a fault. This has to happen with a good product management and leadership because we don't want people to be pinching pennies on the cost of necessarily product evolution. But we want them to think about this because actually, technical decision can impact cost immensely.

There's other aspects of it as well that we also see often lacking, which is tied to platform engineering, meaning, thinking about how to make it easy for people to do the right thing and difficult to do the wrong thing. So thinking about, for example, tagging infrastructure in a way that makes sense. Can you limit how people can tag their infrastructure, so it is tied to what makes sense to you?

So as a team, if I create infrastructure through my pipelines, is it do I have only specific values that I can choose from, so that it makes sense from a perspective of the visibility of the cost? Or it could be as simple as, have you considered cost when you're coming up with solution?

Some people have architectural decision records that they make decision. Is there a question in the ATR that says, was cost considerations thought about? Or is that an impact tied to the solution? It is sometimes, really, simple nudges that are needed to change how we think about cost as an organization.

Those are the main ones that we can see from an organizational culture perspective, from a sustain phase.Ìý

But then there's another aspect of it, which is actually partnership with people that you work with from a third party vendor perspective managed solutions.

Almost all managed services providers, most of your tools, your cloud infrastructure have account managers that help you. Having those relationships and building those, actually, can help you be more sustainable when it comes to cost.

It's their job to help you navigate their contract structure and figure out how to deal with the scale as you move forward. Having that relationship really helps you understand the product you're using, and how that can affect your overall cost, and forecasting.

Then I think a lot of people forget about that. They are like, I've built the contract. I have the tool. I don't need to talk to the people again, which is not the right way of thinking about it. You want to actually have a pretty crucial relationship. If you're not meeting with your account manager, probably, at least once every couple of months, you may be missing out on opportunities.

And we actually cover that in our article. So there are things that you can ask for or, especially, if you are OK with advertising that you're using a tool, you might be getting discounts. There are things that you can do to make that relationship more beneficial in the future because you want to be able to be cost efficient with the tools that you actually use.

Ìý

[Rebecca] One of the things too that occurs to me is if you focus too much on cost and this is what one of you mentioned earlier. If you go into too much of a frugality mindset, you might compromise your product strategy or something like that. But do you have ideas or strategies for how you find that balance?

You can't completely minimize the cost because, again, you might be doing the wrong thing by your customers and your product. But you also want to be operationally effective. So can you talk to me a little bit about how we find that sweet spot of, OK, we're not spending too much, but we're actually spending enough?

Ìý

[Stefania] Oh. There's one aspect of thinking about it. We think about something called unit cost sometimes. And there's thinking about we had talked about this, like, either unit of cost. It could be a person your customer who uses your digital product. Or it could be the cost operational cost tied to supporting a physical product. Or it could even be, actually, requests going into your system that could be the cost of unit.

And you can actually look at the cost per unit. And you want to actually think about that cost is that it can be good for you based on your business. And that's cooperation with your business stakeholders, or your product managers, and saying, we have that cost. If you're adding more product capability or you're charging more for the product, increasing the cost is fine. It's actually, you're thinking about that margin.

But for example, if you're not either increasing your revenue either the number of people, or within the cost, and you are still increasing continuously on that unit cost, you need to start looking into it. Because that means that you're taking away money that you can use in the future for your product evolution.

And I think, often looking at that cost structure often helps you make certain amount of those kind of decisions. And so you have to think about all this holistically, but that actually becomes really difficult when you're looking at company level capabilities.

So think about when you're making decisions about tools that you're going to be tool that you’re going to be with contracting this that are going to be used across the company.

You might have multiple product teams. And they're all using the tool. There might be usages that actually affect how much each one of these teams are having cost. But everybody's using it. And you have to have a contract structure associated with it. But you're making this decision. And then the question becomes, are you going to go for the cheapest solution? Or are you going to go for the solution that's best for you? And you have to make those kind of compromises just like anything in architecture.

There's always pros and cons to everything. But you have to think about it holistically. And that's actually when your partners become really useful. You have to think about your forecast for your company, especially if you're using third-party tools that affect how you use it.

And you're looking into forecasting. You're looking at the capabilities, and your growth, and where do you see yourself going in the next year, two years, three years? Does this tool seem to match what I am moving towards?

But then you have to think, I'm making this investment. There might be either a contract investment, or a money investment. And then you have to think about the usage. How does it help you? What will it do for you? And then you have to make that return on investment calculation.

And that's where that team mentality becomes super important. You need to bring in your finance. People you need to bring in your product people to think about, where are we going? And then you have to think about the architectural mindset of like, what is this tool?

Or what is this managed service doing for me? What does it actually provide me? And what is the actual monetary value versus what is value that is going to bring us future growth? And then you have to do all those calculations.

This is not a simple calculation by any means. And that's why you have this group of people all working together to do these things together.

But those become really important. And so thinking about ROI analysis is actually, really like a group sport because you don't want to get stuck on one frugal mindset. Everybody has to think about it together with those kind of different dimensions that are coming together.

Ìý

[Rebecca] So, Tanya, earlier you mentioned that a lot of this is a cultural change in the developers if you just, OK, they created too many environments. So we're going to shut down the extra environments. Well, if you don't change their mindset, they're just going to recreate the environments because they didn't create them just because they could.

What is the strategy for getting people who are primarily software developers, my job is to get this product, this feature out as quickly as possible. What's the strategy for helping them understand this cultural awareness of growth at any cost is not where we’re going. How do we make these individuals aware of these issues, and their responsibility, and helping to control this?

Ìý

[Tania] I think of it in a few dimensions. I guess, one side is that visibility that Stephanie talked giving teams visibility. That's a part of it, and then not just visibility, but some level of accountability for teams.

But there is some nuance here because when I say accountability, we talked about not wanting teams to go to the extreme and be so frugal that that's all they focus on either. So the way I think of that is either via processes, for example, keeping a cadence of some kind of review with the engineering manager of the team just making sure that cost isn't going in the wrong direction dramatically.

Or another way to think about it to complement the process is to think about cost as a guardrail metric. And what I mean by that is like a lot of teams are given metrics to measure how successful they are in what they do.

Cost can be part of that. But it should not be the top metric unless the company is really, really focused right now on that reduce waste and just reducing cost.

But if we are in the sustain phase, then I think cost can be there, or should be there, but not as a top one. It's just a guardrail. Like, we should not go beyond this. And also when I say we should not go beyond this, there is that devil's in the detail. Because if you're saying overall cost cannot go beyond this, then that's tricky because sometimes the overall some architecture costs for a product, if it's serving many more customers than it did before, of course, cost is going to go up. And that's why Stefania brought up unit costs.

And we can be very, very granular and very, very detailed in the way we measure unit costs. But we can start from something simpler. We can divide that overall cost for our team over a number of transactions, over a number of customers. A crude or back of the napkin calculation is a start. So that's one way I think about it.

The other way that I think about it is I also don't want cost to be necessarily mentioned in every single stand up or every single meeting that the team has. I think a big part of making the sustain successful is just embedding good practices that we expect people to follow as part of just a sensible default so, basically, making it easy for people to do the right thing.

And a way to do this, I think we have a few examples of… a way to do this is if we expect people to tag their resources, then let's make it easy for people to tag their resources. If we expect people to, let's say use spot instances for workloads that are ephemeral and then OK to disrupt in the middle, then let's make it easy for them to do that. So I think those are the two sides.

One is a level of accountability. And another one is let's just make it easy also for the engineers and the teams.

[Rebecca] It also sounds like there are, again, similarities with things like technical debt and code quality is that there is no absolute number. It cannot get over 42.

But trends are important. And you want to understand why something is trending a particular way. And even unit cost can trend upward if you're adding new features, and new capabilities, et cetera. But then it's still, OK, here's the trend. Is this increase what I expected it to be as a result of the functionality? Great.

Where do you go next with this? Or is there a next? Or is it just more and more sophistication around making the right thing the easy thing to do? Or how do we actually find that magic spot between cost and ability to deliver? I mean, where do you think of taking this work?

Ìý

[Stefania] I think for a lot of our clients, it's actually also tied to thinking about it from a platform perspective. Like for me, the tying together cost efficiency and operational efficiency to platform thinking, which ºÚÁÏÃÅ in general, is really a big fan of how to make things easy for people to do. And now that is the right thing to do.

Adding the cost dimension to all of it, actually, makes it more appealing to a lot of our clients because it shows more tangible results when you actually have other aspects or other dimensions tied to cost visibility and how you can track things.

So at least from my perspective, from my day-to-day, it just impacts how I talk about architecture and infrastructure on a day-to-day basis with this kind of cost dimension tied to it and when you're talking to people who also care about that actually, resonates a lot better with them.

Talking, sometimes, about ephemeral infrastructure doesn't necessarily resonate. But when you say, hey, here's the cost implications of using it or how much money you can save. It becomes a different conversation even as from some technologists' perspective, it doesn't seem as fun. But for me, it actually shows more value tied to it. And that was, at least, what I bring to it on day-to-day perspective.

Ìý

[Tania] I guess, for me, I'm part of the scale-up group. And we are actually, since we wrote the article, we've used some of these lessons learned and the framework that we are thinking to help some clients. So I think we'll continue to do that and to learn more from further execution of this framework in the wild. And then from a personal perspective, what also to do with this work? That's something for me to think about.

But for people who are interested in the other articles that we have in the bottleneck series so again, the patterns that we are seeing that are constraining or impeding growth in scale-ups, I would definitely recommend checking out the series in Martin Fowler's blog.

We've had, I think, five articles come out. Ours is the fourth one.

And it covers a bunch of topics. Already right now, it covers the tech debt bottleneck as, Rebecca, you also pointed out. It covers talent, friction between product and engineering, this one on cost, and it covers resilience as well. And again, we're working on an upcoming ones as well.

Ìý

[Rebecca] Great. Well, Tanya, Stephanie, thank you for that.

It's always great to see people who can be passionate about something like operational effectiveness and efficiency. So thank you, all for your observations. And thank you, Prem for joining me on this edition of The ºÚÁÏÃÅ Technology Podcast. Thanks to our listeners.

Ìý

[Prem] Thank you very much.

Ìý

[Stephania] Thank you.

Ìý

[Tania] Thank you.

[MUSIC PLAYING]

Ìý