Tackling bottlenecks at scale-ups

Full transcript

Zhamak Dehghani: Hi, everyone. Welcome to Thoughtworks Technology Podcast. I'm Zhamak, one of your regular co-hosts, and I'm here today with Alexey, my other co-host. Hi, Alexey.

Alexey Boas: Hello, Zhamak, and hello, everyone. Pleasure to be here with you.

Zhamak: Great. We are joined by two of our colleagues, Martin Fowler, and Tim Cochran, today to talk about bottlenecks of scaleups, the challenges that organizations that go through hypergrowth phase that slows them down in their growth and in their journey. Welcome, Martin. Welcome, Tim.

Tim Cochran: Thank you.

Martin Fowler: Thank you.

Zhamak: All right. Let's just start with you, Tim. What has brought you to this point to talk about and write about scaleups' bottlenecks?

Tim: Sure. Essentially at Thoughtworks, we have been doing a lot of this work. Over my journey, I've been with Thoughtworks for over 15 years. Through that, I worked through a number of different enterprises, but also a number of different companies that are scaling quite significantly. They're moving from being a startup up to becoming a larger company going through their IPO. We've noticed obviously with working with enterprises and scaleups that there's very different approaches that you might apply. Some of the techniques may be similar, but they may be applied in different ways to different extents.

Within Thoughtworks, we have a number of different scaleup teams that are currently working with these companies in the different phases and they do work differently. What we tended to find at Thoughtworks is a lot of these companies would come to us when they have a problem. We would do some initial ‘five whys’ root-cause analysis. We realized that there's a common set of themes around these problems. Some of this writing is about sharing that knowledge. Obviously, we looked at those themes and thought about what are the common solutions and how did we detect those themes. That's what we'll talk about a little bit later about what we're defining as the bottleneck of scaleups.

Zhamak: I guess it's a similar story. A lot of us come and write and share our perspective after having gone through many challenging scenarios or experiences with our clients. We think there are patterns that can be generalized and put forward. I'm curious to go through those patterns of bottlenecks, but Martin, you're hosting these articles on scaleup bottlenecks, so I'm curious from your perspective, what's interesting? What interests you to host this topic and write-ups?

Martin: A lot of it has to do with the fact that it's something that we are seeing exactly, as you said, a common pattern amongst our clients. I know that Tim has worked with quite a few of these over the years. I'm very interested in capturing material that captures this kind of common knowledge. If you look at the themes of a number of the articles that I've been posting on similar things, the distributed systems stuff with Unmesh, the legacy displacement work with James, Ian, and Rob, indeed, stuff with your stuff on data mesh where I did some of your earlier writings on that.

It's all about the fact of people in the field noticing some common threads across multiple clients, which is what I did when I did real work or the closest I ever got to really work which was being the consultant. I would again see those common threads and that's what led to a lot of my writing. Now, I'm much more detached because I tend to be focused much more on this publication side of things, but I still very much try to have the ear and the nose for something that I think, has this kind of quality of interest, and then help to provide what experience I can to help people get that through, both in providing the platform from the website. Then just supplying stuff from my own experience as a writer and being able to try and set things up.

These issues around scale-ups is also something we're actually experiencing in Thoughtworks ourselves at the moment. We're a scale-up. We've been growing at a ridiculous rate now for 10-20 years. It's not the same as perhaps a product company scale-up where you've got a core product that you're experiencing this kind of hypergrowth with, but the level of growth that we've gone through over these last 20 years has been pretty remarkable.

When I started with Thoughtworks, we were a couple of 100 people in a couple of offices in the US, and now we're over 10,000 people worldwide. That puts a lot of stresses upon any organization's information systems.

Zhamak: That's really interesting. First of all, thank you for hosting these timeless patterns. I know that one of the criteria that you put on the articles is that you can come back to these write-ups maybe in a few years, and they're still relevant. It looks like this one is also one of those age-old, timeless problems that we see over and over again. It's great to share some solutions around that.

Martin: Indeed, they are because a number of the things that Tim is talking about are things I remember from places I saw back in the late '90s in the pre-dot-com boom and crash, for those of you who can remember all the way back into the last century, and it's very similar topics.

Zhamak: Okay, let's just step back for a minute and discuss what's a scale-up. How do you describe and identify one when you see one in the wild?

Tim: Yes, we have a definition. There is also a technical definition. The way that we've defined it is via what we're describing as these four phases of a scale-up, but if you look at the Wikipedia entry, there's a definition from the Organisation for Economic Co-operation and Development where they define a scale-up as of having an annualized return of 20% in the last three years with at least 10 employees.

We're a bit more fuzzy on it. Our four phases of a startup's journey actually are beginning with experimentation. This is where the company may have an idea, but they're trying to prove that there's a market for that idea. They're trying lots of different ideas, lots of different experiments focused on getting those on ideas out quickly and validating them, and very little care about a scalable platform at all. It's actually an anti-patent if you're focusing at that point on it, it should be throwaway ideas.

Then we're saying there's this second phase which is gaining traction, which is where we are actually getting some early indicators, some early adopters, maybe you start to get a passionate community of customers that like your product and are contributing. It's when you realize, "Oh, actually, there's something here," and perhaps you're narrowing on one of your ideas. That's the point where you really are starting to capitalize on it.

Also, maybe in the beginning, you could apologize to your early customers if the site went down or something like that, but at this point, we really have to start building a product that's reliable on performance and having all the features that a customer needs to actually use the product day-to-day, use it for real.

Maybe towards the end of this phase is where we are thinking about the scale-up begins. Then we move into this growth period, and we put in parentheses, hyper. This hypergrowth is this desired goal, which is defined as 40% compound annual growth. Of course, anybody that's rapidly growing or growing significantly is going to have scaling challenges.

At that point, and this is where a lot of our material's about, this is where the stress and the demands really come in. You have such a lot of stresses, external stresses coming in. What will be apparent is your constraints and your bottlenecks. How you quickly notice those bottlenecks, ideally, before they constrain your business, this is one of the key points is we want to notice, it's okay to have these bottlenecks in place, but we want to fix them before our business growth is affected by it.

That's actually a lot of what we're talking about is how to spot those things. Hypergrowth obviously, a lot of times, it's like, "Can we keep the site up? Can we deal with peaks and troughs in traffic? Can we deal with fast followers like competitors quickly?" We also may be dealing with things like we have to hire a lot. In order to build the products, keep the traction going.

Then the other thing at this point, we probably have taken on a lot more funding. We have this other group of demanding customers, I suppose, which is your investors. There's that piece as well. Making your company look good to investors to your next funding round is an important aspect, it's purely about the number of users and those kinds of things.

Assuming we can keep the product up, keep the traction going, and we can get through hypergrowth, we have this phase, I don't have a technical definition for it, but it's what we're calling is optimizing, which is yes, we're still growing and actually could be quite rapidly, but we're no longer firefighting and we're really looking at the economies of scale and trying to utilize that just to make it easier and more efficient.

At this point, we might be looking at applying the platform approach; reducing the amount of fragmentation, I might be looking at product delivery speed. I might be looking at reducing the amount of technical debt, the amount of developer friction, making the company into a well-oiled machine, where I'm able to make a profit. That's one of the important things to maximize that margin and that profit. That's really that optimization.

Buy versus build is an important aspect here, other things that may be a few years ago we quickly built, and it turned into a [chuckles] capability that we rely on, but we realized that there's a cloud service or a third-party package out there that we can utilize. Those are the four phases; experimenting, getting traction, hypergrowth, or just growth, and optimizing and scale-up really is for us towards the end of getting traction through to optimizing and the IPO.

Alexey: I find it very interesting in these phases. I mean, they seem very simple, but also a very solid way to think about the moments for scale-up because then it shows how the concerns and the focus changes from experimenting to validating a business model, but then how to get market and grow fast and handle the competition and then reach an inflection point in the market and a presence in the market, in which you need a fast growth and then it concerns change to optimize itself. The whole mindset of the company changes over these phases, not only from a technology perspective but also from a culture, product, and processes perspective. It's really powerful and has a broad impact on the organization itself.

Tim: If you take that as an example, Carl Nygard and I just wrote about accumulation of technical debt as a bottleneck for Martin’s site, and the take that is often thought of being bad, but actually, it's very valuable and we say very healthy for scale-up in the early phases and experimenting and getting traction, and to be taking on technical debt because we're making experiments, were building products where we don't know if we have an audience yet. Therefore, we shouldn't be building a scalable platform, we should be doing whatever we can to get that product out quickly in front of a safe user audience and validating that it's valuable.

Now, the problem comes-- when it becomes a bottleneck is once I've actually validated that that product is successful, have I gone back and made it higher quality? What can happen in hypergrowth is these shortcuts can become apparent. It can become apparent in some of the customer experience metrics such as the performance of the site or the availability, it may be causing bugs.

Then longer term, especially as you scale and maybe those products have become core components of your system, it's really about when new different people have to look at it or new users, new employees have to work, maybe the teams have changed, can they actually maintain this code? Can they understand it? If they can't, you're going to see either drops in productivity or increases in bugs. Yes, your tech strategy has to change across the growth across the four phases that we have. That's in this article that I wrote with Carl.

Martin: One of the things this really brings home is whenever you're trying to give advice about patterns or practices to apply to what you are doing, it's always very context-specific. What a model like this does is highlight those different contexts that an approach that works really well in the experimenting stage may not work so well when you are dealing with heavy levels of growth. This is also something that people are pointing out.

Kent Beck has this 3X model that he talks about; explore, expand, extract, and of course, as an old gamer., I'd always throw in, there's the exterminate stage as well, which is what you want to do to your competition, but that's always left out. Again, as context shifts, then your approaches and what you're trying to do has to shift. It's good to have some model like this that gives you anchoring to sense, "Okay, where are these different stages? Where do you get these inflection points?" The key thing about this bottleneck is it's identifying a particular inflection point as you shift from that getting traction stage to the hypergrowth stage.

Alexey: It's interesting because it also removes guilt. Tim mentioned technical debt, it's usually associated with the guilt. Something you might be doing in one context that might be the perfect right thing for you to do at that moment, but the completely wrong thing to do in a different moment, and you have to shift mindset as you move from one phase to another and it's great to have a product like that. It helps.

Martin: That's something we put into the structure of the articles themselves. We're following a somewhat structured approach to how we lay out these, where we begin by describing how did you get into this bottleneck? That is really part of saying a lot of people are being perfectly rational, doing perfectly reasonable things that lead them to the bottleneck position. They're not bad things. They're the things that were right in that earlier context.

Then the next section is, we talk about what are the signs that you're approaching? What are the little indicators that you should be looking out for, to say, "Oh, I'm coming up against this bottleneck, I should start thinking about doing something different"? Then the last section, and the largest section of each of the pieces that's been written so far is, "Now that you're in the bottleneck, how do you make progress? How do you get out of it?"

I think it's important, that structure is useful because it helps reinforce people's minds on, it wasn't by being stupid that we got into this, it was actually by being very sensible that we got into this. Maybe by writing this down and telling you what the signs are, you can spot earlier before you've actually dug yourself into a hole.

Zhamak: I find this whole S-curve that we use in so many different scenarios, the S-curve of Roger Everett's diffusion of innovations and Kent Beck with the exploration and expansion and extractions, and the scale-ups that Tim just introduced here, it's adopted in so many scenarios, and it's just such a wonderful tool to structure our thinking and decision-making and optimizing for the right thing.

What we're talking about is this-- I see that as well, we come across technology companies-- even within a large company with a smaller group starting up a new initiative and they start with the most sophisticated architecture that is optimized for when you are skilled. It's not optimized when you are even within a large organization. They're still experimenting in smaller groups.

I think not only is what we're going to discuss is relevant to scale-ups, but it's also perhaps relevant to initiatives or startups within a larger organization. Shall we talk about a few real case studies and use cases if we can?

Tim: Certainly. Maybe I can talk through a couple of scale-ups and startups we're working with. I may not always be able to mention the name. We're actually working with a company that is very much in hypergrowth. This company called Voyager, they're a crypto app. Very successful. For them, they made the right decision actually, that at the beginning that they were they were building a monolith.

What they saw was that they were seeing reasons to change that strategy. The main problems were the teams were clashing with each other too much. They had too many dependencies on each other. Then they were perhaps not seeing outages, but seeing that could be on the horizon if they kept growing. They wanted to be able to really scale, grow, build more features, have more teams, and then address these problems.

What we're working with them on is creating decoupled microservices in Go lang and building that scalable architecture. This is not an example of a bottleneck. They're an example of them avoiding a bottleneck, but the interesting thing is how did-- and we should actually get them on another podcast to talk to them about how they found those indicators, but a lot of it is its trends because probably once you've got that bottleneck, you have that problem.

Those trends of performance trends, traffic trends, availability, and noticing it, some of it actually comes down to the ability to observe because what we find sometimes is either the information isn't being tracked or it isn't being exposed. Quite often what's common is, through good intentions, an engineer or group of engineers may be solving the availability problem by just firefighting, by doing a lot of quick fixes.

That information may not be known by management. They may not know that actually the way that we're surviving right now is by-- I'm not talking about a client at this point, I'm talking more abstractly, they may not know that the way they're surviving is via by the customer service team or by maybe tenured developers that know the code really, really well, and can fix things, spot things really, really quickly. That does not scare them.

When you add the next group of people or the next group of users, suddenly that's not going to work. In that situation, it's like maybe if we'd had more observability into our capacity, we could have spotted that. That is one of the articles that we'll be writing as part of the bottleneck on an overcomplicated, distributed architecture. We're going to describe the anti-patent, but then the question comes like, well, when do we make a more complex architecture?

This is obviously a big topic with microservices, but how do we make that decision? What are the NFRs? What are the cross-functional requirements that mean that I need something more complex? A lot of times we see, and I think you mentioned it, Zhamak, a lot of times a lot of our clients come to us and it's an incredibly complex architecture and not a fit for what their business or technical metrics are demanding actually.

Alexey: Yes, I was just going to say how interesting I find, not just from a technical perspective but also from a cultural and a process perspective, because you reach a point at which you need to change the way you work. You're not doing more of the same things you have been doing. You have to do it differently. Just realizing that, looking at the meta-level and observing the process and what you're doing, that's really hard to do. Building in observability, the culture of, "All right, what's happening here? What speed? Are we getting what we need," and banking that into the culture early on. That helps a lot with that because it is a difficult process from a human perspective, I guess.

Tim: It is because when we talk about observability, people often think about the technical aspects of it, right? Like charts and things, but a lot of it's actually the vulnerability to be transparent and to tell your manager, "I think this site is going to fall over if we add 20% more users." It requires that safe environment, that vulnerability to actually expose those problems if you are the manager of the infrastructure department, right? There's a lot of cultural aspects to this. It isn't purely technical.

Zhamak: The process of observability as well, as you're talking about, the signals that are telling you and the trends, "Okay, we are reaching that pivotal point that we need to shift, and now we are a scale-up. Let's get serious. Things have to change." Some of them seem to be around people and processes like how long it takes to build a feature or how quickly backlogs are growing.

Tim: Yes. There's an example of a plan. Actually for, I think, a number of years, we're working with Etsy, and there we worked with them to improve their product delivery processes, and they were scaling and they saw that they have a really good culture about continuous improvement and autonomous teams, but they were seeing that as they were scaling people, they would benefit from having some amount of common blueprints and standardizations.

We did a fair amount of deep analysis into what could improve them. We focused on some sort of basic stuff around some of the product imaging practices, but also improving the ability to discover quicker, to try more ideas and to discover using a mixture of experimental techniques, a mixture of using-- they have an amazing data platform at Etsy, but also mixing it with prototypes and interacting with users and that.

That's one example of product delivery. Some of the antipatterns and we see, and when I talk about antipatterns, I won't mention too many clients, but we've seen places where it's been hard to add people to the organization because initially there was a close-knit team that-- I said it was a good thing earlier, but it can become a problem. You've got this initial team, the founders' teams, and the people that would hire there, but can the next set of people come in and actually gel and actually feel welcome in that culture and feel productive and empowered?

We've seen problems of founders micromanaging too much. The product was their baby, but now they've hired maybe a product leader and they have to be able to let go of that and to empower enough to-- also, they will get overworked, they themselves will become a bottleneck if they don't do that. A lot of different aspects there around accountability and decision-making practices that may change as you grow.

Zhamak: Martin, you mentioned earlier that Thoughtworks is a scale-up or has gone through that hypergrowth. I wonder these people-process type bottlenecks, as Tim mentioned the onboarding or hiring, is there something that you have seen within our own organization or the clients that you had worked, you said from the '90s, some of these patterns are repeating themselves, that you think you would want to point the audience to the article and the solutions proposed by the article?

Martin: Yes. They are common kinds of issues, particularly when we again look at bringing people into the organization. I remember back when we were just a few hundred people in the early 2000s, some people were saying, "Oh, the company culture is being totally destroyed. We can't possibly grow to 1,000 people and remain like that," and what happens is there has to be some change in the culture.

We have to figure out how what is essential and what needs to alter. It also makes a big difference when you shift from a very visionary and sort of charismatic and forceful founder to an organization that's much more run by a leadership team. That's a big shift because we still have to be a bit more deliberate about stating what the vision of the company, what the core cultural qualities of that company are.

We're also trying to deliberately be more diverse. I mean, often, when you've got a small group that starts up, they end up being-- everybody knows each other, and they're naturally un-diverse because you're hiring from your own little network, but as you grow, that becomes a danger. Then you have to say, "How do we deliberately alter some aspects of our culture?"

Some people will talk about-- you hire for cultural fit and some people say, "Well, that's a bad thing because you're fitting into the culture." Well, it's neither good nor bad. Some elements of it are good because you need to try and keep that cultural quality, but you also need to stretch it and allow that greater diversity to fit in with what's already there. It's a balancing act, and these are always common features.

For us at Thoughtworks, a big aspect has been the international nature. As we shifted from a purely US organization to one that's really gone very deliberately and very aggressively worldwide into different cultures, that caused quite a number of notable shifts but also notable question marks. What aspects do you keep, what aspects do you not keep, becomes quite important.

There are parts of the world for instance where gender diversity was not necessarily welcomed, and we actually shied away from because we didn't get that and that was a factor. Again, you have to decide what is important to you in your culture, and what do you deliberately want to flex as part of the growth?

Alexey: On that point, there's one interesting thing about Thoughtworks, I guess, because of the organizational structure, nature, it's kind of fractal, we see the same patterns in different offices as they grow, and we see them happening repeatedly with very similar stories. The relationship people have to one another, the relationship you have to processes when the time comes to, "Well, now they need to process because we can't do that in an organic fashion anymore."

I don't know all the people in the office anymore. Then how do people react to that and learn to deal with that? We see that pattern in several different offices as the offices grow, it's the same company or sometimes even the same country, but in different cities, different offices, we see the patterns repeat themselves. It's interesting.

Tim: Yes. Just a quick advert for the article. I think the second article that we put out from myself and Rodney Smith, we talk a lot about what Thoughtworks did to grow and mention the story that Martin talked about, through some of the aspects, like how we achieved consistency across levels of co-op quality and how we did welcome more diverse people to the organization.

Then I think we'll have another article on onboarding. Our teams have done a lot of work around-- both within Thoughtworks, we have an interesting process and for our clients about different aspects of onboarding. It is not purely the technical aspects of, "Can I access the right systems?" It's, "How do I actually understand the mission, the goals, the culture of the company and feel like I'm able to contribute and potentially change it? How do I create that level of safety?" That's actually another article that we're working on at the moment that will be out pretty soon.

Zhamak: Make sure we put the link to the articles in the podcast show notes. I'm excited now to go and read these playbooks of [chuckles] identifying the bottlenecks and I guess identifying the signals, and then some solutions around them. Would you just perhaps go through maybe, Martin, Tim yourself, maybe a couple of more typical patterns of bottlenecks? We may not have time to go through all of them, we may have separate podcasts, but just to give an audience a sense of what is out there.

Tim: I won't read them all, but the first two, I talked about the first, the talent, which is essentially the bottleneck that the company's constrained by talent and I can't attract top technologists to my company. I'm sure, [laughs] everybody, that's the environment we're in at the minute, so I'm sure that-

Zhamak: Everyone will bookmark that one.

Tim: [chuckles] Yes. The first two we picked were the first reasons, the main reasons why we talk to clients which is the accumulation of technical debt, which is, a company will come to us and say they have technical debt, sometimes it isn't technically technical debt, but that's the words they might use. What it means is they've underinvested. There's been experiments or shortcuts that perhaps shouldn't have become a core component and now have and maybe only one or two people know how it works, and the code's not easy to read.

There are some interesting things in it. Actually, one of the debates we had was whether you would classify code that isn't used or code that has low value as technical debt. We think it is. There's something that you wouldn't normally think about, but this idea that any code that you accumulate, it is going to add friction. It's going to make software development harder.

If you have the observability to even know that the code is not offering any value or feature's not offering any value, then essentially it's a debt in a way. That's one point that we put there. Talk about some other ones. We talked about-- I think we are still working on the exact name of it, but it's about the organizational structure. How do you organize that? A lot of companies will pick a certain type, often the Spotify model or something like that.

It's interesting. When we were writing it, and one of the problems we often go into these scale-ups is this is a kind of centralized decision-making, but you can't put centralized decision-making as a sign because no scale-up as a strategy goes, "All right, we really want centralized decision-making. This is how I think we're going to make our--" everyone knows that THEY want autonomous teams, but when you're in the midst of these hypergrowths, you don't realize that you have these bottlenecks of certain leaders that are making all the decisions that are spread too thin.

That's what we're actually gonna write about is, how do I know that I have this problem with my decision-making too centralized or something like that? It's about this idea that it wasn't-- not that it was intended to be like that, there's no point-- you can hire a consultancy like Thoughtworks to come in and say, "Oh, your problem is this," but it's it's how do we find those signs early, those indicators early?

Some of the other ones we've talked about, which are legacy, technology, there's going to be a crossover with technical debt, but we often see legacy coming through acquisitions, quite often as a company grows, like the technical strategies by other companies, and maybe you had a really good technical strategy, but perhaps the company board didn't. Now I have two perhaps similar capabilities that are of different qualities, and I have to reconcile that somehow, right?

That's a legacy technology which-- I need to think about that with startups, but it happens, and we work for scale-ups that have changed their ecosystem, their language choice after three years, or something like that. It may not be at the same scale as an enterprise company that's been around for 30 years or something, but we'll be writing about that.

Some of the other aspects, we've touched on it, which is about resilience and observability. A lot of times, the main problem is the site just doesn't stay up. [chuckles] It's a basic problem that we have to fix, and it's okay to degrade, but in a graceful way. Some of these markets that companies are in, a tweak can change the profile of your traffic, and of course, if you're a startup and you don't have any problems, then you probably overengineered and spent too much on your platform, but it's how do you degrade gracefully and have enough resilience and observability to quickly fix.

What else? Some of the things are how to find the next product evolution. What you find is after those first product-market fit, you build out your key features. It's a little bit of like, "How do I find that next 10% of users?" It can be a lot of opportunities at that point. Which way? Should we stick with a core product, and make it more sophisticated, or should we try different avenues, different ways that the company might grow in? Obviously, there's lots of histories of companies going in completely different angles. We're going to talk about ways of being more experimental, failing fast, finding that next product to evolution that will delight your customers.

Zhamak: Martin, you've seen these articles and it's fascinating, it's multifaceted, many different angles, technical people would take something away, managers would take something away. From your perspective, if you wanted to leave people with a few words of squinting at all of these patterns, what would that be?

Martin: Well, perhaps the most important thing, surprise surprise, is people, and the way they work together. Whenever you alter the size of an organization, you find that the habits that you've got in the past stretch. I've always had a rule of thumb that once you go up an order of magnitude, you've got to work differently. That's the case with all of these patterns.

I think the thing that's going to be most valuable to people is to look at these signs, the indications that you're approaching a bottleneck because if you keep an eye on those signs, hopefully, you can get there before you get into any deeper trouble. They correspond in many ways to the idea of code smells that we talk about, signs of problems of a codebase that you want to try and look and fix.

These are similar kinds of signs that come from bottlenecks. I think those are the things to most watch for. One of the things perhaps as we craft the article series is figuring out how to highlight those signs a bit more because one of the things that we're doing is we're evolving how to actually write about this stuff. As I said, we've gone for a fairly structured layout for each of these bottlenecks, which is risky because we're basing it on just the initial examples. We haven't written them all yet.

We want to evolve that and also evolve abilities, people's ability to consume the material. One of the nice things about having your own website is you've got a lot of flexibility as to how you lay things out and how you design things. We want to do that in order to make it easier for people to take hold of them.

Zhamak: Great. Well, we're coming to the top of the hour. Tim, is there anything else you want to leave the audience with?

Tim: I think it's just harking on what we've said a couple of times that everything you did during your scaling journey, you did for a reason, and it wasn't wrong, but with growth or pivots, different things happen, different practices come in place, and having that opportunity, having that ability to sort of like a step above it and to examine, I know it's hard when you're in the midst of actually doing the work and trying to keep up with stuff, but having that ability to actually look above it and figure out what your strategy might be, I think that's partly what we're trying to achieve, is trying to help people figure out their strategy and scale better.

Zhamak: Be kind to yourself as you're going through the pain. Well, thank you so much. This was great. I'm looking forward to the articles. We'll make sure we put the link for people to enjoy them. Thank you, Martin. Thank you, Tim. Thank you, Alexey.

Martin: Thank you. Bye-bye.

Tim: Thank you. Bye.