Mastering Business Agility

Wiktor Żołnowski: Welcome to Pragmatic Talks, a podcast and video series where we discuss startups, contemporary digital product development, modern technologies, and product management. I am Wiktor Żołnowski, the CEO of Pragmatic Coders, the first-choice software development partner for founders. For today’s episode, we invited Tomasz Wykowski, the CEO and founder of ProCognita, one of the biggest Agile consulting companies in Poland. Aside from being an Agile coach and consultant, Tomasz is a Certified Scrum Trainer from Scrum Alliance and a LeSS Friendly Scrum Trainer accredited by the LeSS Company. Tomasz is an expert in modern software development management methods.

Some of you will sooner or later get to the point where you will start growing your team and scaling up your business, or maybe you are already there, but you have noticed that it could have been done better. In this episode, we’ll answer the question of how to grow your startup right. Listen to what mistakes you should avoid when growing your company and how to deal with their results if you haven’t avoided them in the past. We’ll also touch on the topic of company culture and its impact on effectiveness and results. You will also get a few tips on maintaining agility when growing your team.

Ladies and Gentlemen, please welcome Tomasz Wykowski. It’s a great pleasure to have you here today.

Tomasz Wykowski: Thanks for inviting me.

Wiktor Żołnowski: So, the first question: who is Tomasz Wykowski and what is your story?

Tomasz Wykowski: Okay, so the very short answer is: I’m helping leaders to build adaptive and learning organizations. The longer answer… I used to be a developer, turned into a quality engineer, turned into a product manager, and then turned into a Scrum Master and other roles.

Wiktor Żołnowski: So, a long story short, right now you are a consultant and a trainer?

Tomasz Wykowski: Yeah, let’s put it this way. And a founder and owner of ProCognita, a company that does coaching, consulting, and training–surprise, surprise.

Wiktor Żołnowski: Perfect. So as a consultant, you have an opportunity to work with various companies. Could you tell us a little bit more about those companies? Are those startups, scale-ups, or mainly corporates? How does it look?

Tomasz Wykowski: The answer is yes. So I, and we as ProCognita, work with companies starting from the super-small, few-people companies or even the founders trying to figure out how to do what they want to do, up to large international corporates in telecom and banking. The spectrum is broad, although my favorite kind of customer is a medium-sized company. And by medium-sized, I’m thinking about something like 60–100 people. And there are a pretty good number of reasons why.

Wiktor Żołnowski: And again, it’s not a magic number. So it’s not about, if you have 55, that’s bad, or if you have 120, that’s a bad idea. But there’s a different dynamic of working with these kinds of companies. So what’s the difference between working with smaller companies, like up to 60, let’s say 20–30 people, and what’s the difference with companies with more than 100 or 200 or even a thousand people? And what’s so special about this group of 60 to 100?

Tomasz Wykowski: So here’s the thing. If we are supposed to build a learning and adaptive organization, with 60 people in the organization, you don’t need to have a formal structure. You can basically have each person talk to everyone, and we can have lunch together, we can do something together. In most cases, if we need to do something, there is one person who will stand up and do something, otherwise, it’s not going to fly. Saying that, we had a situation where we had a call from the CEO of a company who said, “We have a problem because IT is not talking to business.” And we said, “How big are you as a company?” He said, “Five people.” Right? So I understand that that might be a problem, but basically, if you have five people and you have a problem with IT not talking to business people, then you probably need to have a conversation about the goal of your company and the people you have in the organization, not about building a better structure in an organization of five people. That’s one side.

Now, when you grow the company, they undergo growth to like 12 people, maybe 15 people, then you will figure out that you need to build sub-teams that are specializing in something. That changes the structure. Then you grow up and you have like 60 people and you see that the previous structure doesn’t work anymore. Now you will end up with having 100 people, 200 people, and the previous structure doesn’t work anymore. So why not 2,000 people? Because my observation is that if you are like 10,000 people and you want to have any change–and there is usually a lot of politics happening in these kinds of companies–my observation is that between the moment when I do something and there are some visible results in this organization, it takes ages. It takes years, it takes decades, if ever. I mean, most of those organizations change, but a little bit too slow for me because my life expectancy is usually shorter than their change implementation.

Again, saying that, I can see those changes in organizations like ING, though. I used to work with them. BNP Paribas here in Kraków. We did some changes, we had some results, but that was at a team level, so not a huge change on the organization level. Now, for different reasons, we had to stop this cooperation. Those are other business reasons; we still love each other. Although, I was not able to help them for the next few months, a few years–not even months. And like a year or two years ago, I’ve learned that they are doing a lot of great things inside the company with the help of other people. Although, for some reason, they still have good memories about what we did a decade ago. So it happens in those kinds of companies. It’s just, when I go to a company which has 100 people and I will do something, then I can see the results like a few weeks later, a few months later. So when we have a discussion like, “Hey, how about you change the structure of the organization?” then three months later, we figure out that they have changed the structure of the organization, not are still working on how to do this or how to approach the HR department and all this stuff.

Wiktor Żołnowski: I can imagine that many people who are watching this, especially startup founders, people who are growing their companies, they may start thinking, “Okay, should I hire an Agile consultant?” What’s the role of Agile consultants, and why hire someone from outside of the organization to help me? Help me in what? What’s your role? What’s your goal when you consult?

Tomasz Wykowski: Well, the answer is if you don’t know if you should hire an Agile consultant, then probably the answer is no, because you should not hire an Agile consultant to hire an Agile consultant. The first question is, what kind of challenges do you have in the organization? And is there anything in our portfolio that can help you solve those problems? So what we do is we try to help you build an adaptive organization. Now, if you are a startup organization, you most likely are working in a new, pretty dynamic market where a lot of things are changing, and there are a lot of things that you need to learn. It’s a pretty good idea to create an adaptive company. If you have a plan and you want to stick to this plan, as long as you have a lot of sponsors, that’s fine. But otherwise, the moment you will run out of budget, you will have a problem because you will discover that your idea is a pretty great idea, but the customer has a different way of thinking.

So basically, the moment you see that you’re not adaptive enough for your market, then it’s a pretty good idea to call someone to have a look at the organization.

What it means to be an adaptive company

Wiktor Żołnowski: What does it mean to be adaptive in terms of being a company?

Tomasz Wykowski: To make it super simple, we love to have a predictable world. We love to create a plan. You create a business plan, you go to the sponsors, they say, “Yeah, that’s an awesome plan,” you execute the plan, you make a lot of money, and you live happily ever after. Except that this doesn’t happen, except for the first result. You have a plan and you discover that the plan is wrong and you need to change it, you need to adapt it to reality. Now the question is, how quickly can you adapt to reality? And can you create a product and create a business that can earn money before you run out of your own money or your sponsor’s money? And this is the question. Now, the more innovative the product, the more of a new market it is, the more likely you need to be adaptive in this market.

Why? This is the question I’ve heard: if it is okay, why should I care about being adaptive? Why should I care about agility? Because you don’t know what you don’t know. So the challenge here is, you get some knowledge. You know the business, you know the market. You are creating the company, you’re creating the startup because you’ve seen the chance of building something on the market. Now you have some knowledge about this market. You have some knowledge about the technology, or maybe your friend has. You have some other knowledge about how to get money and all this stuff. That’s awesome. There are some risks. The risks are the things you know that you don’t know. So the question, for example, the risk is what the customer will do, or the risk is how the competitors will behave, and all this stuff. And there are things I call unknowns, which are the things you don’t know that you don’t know. Basically, it means they’re going to blow up in your face in the middle of development, and you have no idea why.

My favorite story here comes from NASA. In 1998, NASA sent a probe to Mars, and the probe approached Mars in 1999, and then with full speed, it hit Mars. Postmortem for the probe, they discovered that NASA was using the metric system, but the subcontractor decided to use the English system. Now, the learning cost was over 300 million USD. The trick is, we can say that those people were stupid. That’s a simple answer, but it’s a completely wrong answer, a wrong assumption. Or we can ask why they didn’t ask the question. And the reason why they didn’t ask the question is because they didn’t know that the subcontractor could use a different system. So they didn’t know that they don’t know, so they didn’t have a question. Now, because you don’t have a question, you cannot ask the question.

Sooner or later, you’re going to discover something you don’t know, and you either change the development of your product, or you’re going to stick to the plan you have created. There’s also a recording from Gojko Adzic, who’s been here in Kraków, and he has shown how he is building his own startup. The startup is called Narakeet, and he’s showing how Narakeet grew. He’s saying that at one moment, “I had a situation where I had plenty of platinum users coming from India.” He said, “Awesome, we have a huge growth in users,” except no one is paying for his product. So either they’re going to start paying, or he won’t have a business in a few days. And during the video–I’m not going to tell the story because I’m way worse at telling his story than he is–but during the video, he showed how he discovered why there were so many people coming from India to his system and what he did about this to make his company successful. So you need to either adapt, or you need to have plenty of money, or you need to be the only company on this market, and you have the monopoly on this market.

Wiktor Żołnowski: This is something that’s pretty important, especially for companies that are not having unlimited budgets.

Tomasz Wykowski: Most of them, most of them don’t. For large organizations, the cost of changing the organization from a predictive approach, where you have a plan and execute the plan, to a more adaptive organization is pretty high. And if you have an unlimited budget, then you just hire more people.

Wiktor Żołnowski: In some of the previous episodes with Michał Chalas about product management, we also discussed that too big a budget might be a problem for a product company.

Tomasz Wykowski: Yes. And because you hire more people. So you hire more people instead of solving the problem. You just… one of the smartest people from our organization, what he’s saying is, when you have problem X, you hire the X specialist, and you end up with having a lot of specialists, but you cannot do any work because you have a lot of specialists who need to cooperate, and you don’t know how to do it. So you hire more people, almost like you’re going to hire specialists on cooperation and call them whatever–product manager or whatever–and try to push the work to those people. So, getting back to your role as a consultant: you’re helping companies to become adaptive. How do you do that?

Wiktor Żołnowski: I’m helping leaders to create an adaptive organization. Great. So this is something else that I heard. Maybe I was discussing at some of the Agile conferences where we had this discussion about, if a CEO is hiring an Agile consultant to make his organization agile, he’s already failing, because he needs help to change the organization itself.

Tomasz Wykowski: So there is a great metaphor of when you change the organization: it’s like going to the gym. I mean, you can hire someone to do push-ups for you, but most likely, it’s not going to help you, for some reason. So this is the game with the Agile coach. The Agile coach is the annoying guy that stands over you in the gym and says, “How can you do more? You can do better.” And most likely, the government is going to say, “No, no, you don’t understand our context.” But in most cases, they can, because I’ve seen other companies doing better. They still don’t know they can.

Different approaches for startups vs. grown companies

Wiktor Żołnowski: From your perspective, what’s the difference when you are working with, or if there is any difference when you’re working with startups or with grown companies like a scale-up or corporate? Is there, do you have any different approach, or do you just use pretty much the same tools and methods for both?

Tomasz Wykowski: You asked two questions, and the answers for both are different. So the answer to “if I use the different tools” is no, but “is the approach different,” yes. So let me answer the second question first. Basically, if I’m being hired, my question is why I’m being hired. I don’t want to work with any company to do Agile for the sake of Agile. So if anyone is telling me, “We want to be Agile,” the question is why. What is the problem you’re trying to solve? There are different reasons. Some of the companies say, “We’re not innovative enough.” Some companies say, “People are leaving the company.” Some companies say, “Okay, our competitors are eating our market,” and so on and so on. And other companies are saying, “We cannot deliver on anything we promise.”

So what is the problem we’re trying to solve? Now, the second question is, how are we going to solve this problem? It’s like, what kind of experiment are we going to try in your organization–I’m going to say why “experiment” in a second–to solve this problem? So what is the potential root cause of the problem we have, and what are we going to try? Why experiment? Because your organization is a complex system, and I have no idea what is going to work in your organization. At the time when I was pretty sure I knew what the solution to your problem was, it wasn’t the solution to the problem. So right now, my assumption is I don’t know, but let’s do a cheap experiment and see what we can learn.

Now, coming back to the first question about the startups and the grow-ups, it’s like you have different kinds of problems. I mean, most likely, you don’t have a problem of the IT people not talking to business people if you have five people. Again, in some cases. Most likely, you haven’t built the silos yet. Most likely, you still have contact between the users and the developers. When you have 100 people to 200 people–and again, it’s not about a magic number, I’ve seen a huge company in Kraków, Codewise, and at their peak moment, there were like 400 people, and I would say they were like a small company because of the way they were working. And you can build a small company of 50 people and have a super-hierarchical structure and have a huge amount of politics inside, and I’m not going to call it a small company; that was a big company with a small number of people, let’s say. So in a startup, you’re going to have different solutions, different experiments, different problems, most likely, to solve. But still, your tool has to be experimenting with the organization, providing some data, experimenting, and learning. So what you do as a Scrum Master, an Agile coach, call it whatever, you basically observe the organization from the outside. That is basically the superpower the Scrum Master and Agile coaches have. We’re not involved in your politics, we’re not involved in your system. We’re trying to observe the system and see what the dynamics are, see what patterns we can discover. And because you’re inside this company and you’re involved in making this company happen and you’re involved in making this company make money and all the stuff and make the customer happy, then you may not see some patterns. And my goal is to see this pattern. Now, the second step is to show you those patterns. And most likely, I’m going to show you these patterns and you’re going to say, “Tomasz, you’re wrong. You don’t understand our context.” So it’s going to take a few months to understand that this is your context and this is the problem you’re trying to solve. This is why I prefer smaller companies because it takes a few years in the larger companies. And then finally, you say, “Okay, I agree we have the problem. Show me the solution.” And I say, “Okay, I don’t have a solution, but maybe this kind of experiment might help you because I’ve seen them working in others.”

Wiktor Żołnowski: You already mentioned the structure of growing companies. Even for a 50-person company, you can have a heavy structure or a heavily hierarchical organizational structure. But as you mentioned, for a 400-person company, you can still have a less hierarchical structure. What’s the impact of the company structure on its effectiveness or its ability to build innovative products?

Tomasz Wykowski: So, just to mention, you can have 10 people and have a structure in the organization. So here’s the thing. Because we don’t know what we don’t know, we want to put people who solve the problem close to the people who have problems. So basically, the crazy idea of adaptive or Agile development is to make sure that the users have a face-to-face interaction with the developers. And by “developers,” I don’t mean coders. By “developers,” I mean people who are responsible for developing the solution for the problem. So coders also, but if you have a marketing department and this marketing department doesn’t work, then the marketing people are the developers in this case. So at ProCognita, we have been with software development, which is most common because these are our main customers, but we’re doing hardware development, helping hardware development companies, we’re helping marketing, we’re helping sales, we’re helping customer support teams. So, how do you make sure that those people have close interaction with the users?

The second question is, how do you make sure that those people, that those developers, can solve the problems of those users? In many cases, what you discover in the organization is you build something we know from kindergarten, and it used to be called Chinese Whispers. When you have one person saying something to the next person, saying something to the next person, and so on. So at the end of the system, you have a developer who is supposed to solve the problem, except that he has no idea what to solve. And in many cases, he just gets the information, “Create a dropdown menu.” “Why?” “For what?” “What is the result?” “No, no, no, trust me.” That is one comment. And the second is, “Developers are too expensive to talk to users, so let’s have a cheaper analyst build a solution.” And you end up with a solution that is not solving the problem of the users.

You end up with a situation when we finally make those developers have a conversation with the users, they discover how painful it is for the user to use the product. Just recently, I had a situation about developers going to the customers, seeing how the users are using the application. And the user is using the application, and at one moment, he zooms out, he presses a button, and zooms in again. And they are thinking, “Why the hell is this happening?” And they go back to the office, and they discover that they have a different resolution on their screen. So it is fine on their screen because the button is there on their screen. But if the user has a different screen resolution, surprise, surprise. What you discover is that they don’t see the button, so they cannot click the button unless they zoom in or zoom out. And you want to have this happening, you want to have this conversation happening, which means, coming back to your question, you need to have a structure where you can have people who solve the problem deliver the solution. So either we build the teams that can understand the problem, create the solution, deliver the solution, and check if we really solved this problem. Or otherwise, you have Chinese Whispering, and people are creating a lot of documentation. Because at the end of the Chinese Whispering game, two years into the product development, when we go to production and we discover that the user is not using the product the way we thought they were going to use it, in most cases, it means them saying, “What is that? And why do I have this one? I wanted something else.”

What usually happens in an organization that has Chinese Whispering? They start looking for someone to blame. How do you blame people after two years of software development? Well, you open all the documentation, you open your Jira ticket, you open your PRD document, whatever, and you start looking for who made a fault. Now, how do you solve the problem of not being guilty? You create more documentation. So you end up with having a lot of random documentation but no software working in this company. So long story short, this is how the recovery usually looks. And what’s interesting is often when you figure out, you have a 50-person organization and you have a Java developer, a Java team in quotes–we can go to this one–you have tester teams, you have an analyst team, you have a front-end team, and so on. And you figure out that they have 20 people in an organization, and still, you have all this fancy Chinese Whispering system. One day, I was having exactly this conversation about the knowledge transfer in the organization, and we decided to draw on the wall–on a flip chart, of course, not on the physical wall–how the information goes through the system. And we ended up with having from the top of the wall to the bottom of the wall, the next wall in each row, and then another bit of information going from one person to another, from one person to another. And that was just for one simple change into the system, and that was like a 20–30 people company. So not to mention like 3,000 people.

How to avoid a mess when growing

Wiktor Żołnowski: So how to avoid such a mess, anyway? When you are… I can imagine that many of the people who are watching this already have their companies, maybe small companies of five to ten people, maybe already 20, maybe already 60. And they even need to scale it up, need to grow this company because the market demand is so high, they need to respond faster, etc. Not only because they need to hire a person for problem X, but maybe there is some true reason for that. So how to start growing your organization in a good way so you will avoid these kinds of mistakes?

Tomasz Wykowski: Yeah. And here’s the trick. Imagine that you have a Java developer, and you say, “This guy has so much work to do, maybe he might need some help from another Java developer.” So you go to the market, you find another Java developer. Now, the new person doesn’t know the system, so most likely, he or she needs to learn something from our expert. So you’re going to put them together so the new person learns from the other person. And then you’ll soon discover that you have five or ten people in the Java team–again, “team” in quotes because that’s not a team, that’s a group of people–and our expert becomes the team lead, and you end up with him being a backlog of work for this team. And you have the exactly the same with the testers, exactly the same with the front-end developers, exactly the same with the analysts or whatever. Somehow, we don’t know why, those developers stop talking to the user because you have some other proxy, and you ended up with having this Chinese Whispering just by naturally growing your organization. So that is the moment you discover this model may be a little too late because you have already 50 people in your organization. And this is when we sometimes call the Agile consultant to solve it by yourself, and this is what I recommend. But sometimes, you just need someone who will draw it for you on the wall. And so, okay, usually, again, this is about observing the system from the outside, showing it to the organization, and then we go to denial, acceptance, all of that.

So the trick is, how do you create these teams that can deliver value? And what you do is, when you grow your team, you in turn grow slowly. And usually, except for the growth crisis when you grow super quickly, which is a separate story, but if you grow slowly and you usually have one or two people joining you every few months–at Pragmatic Coders, they have like a few people joining every few days, I know, but that’s a separate topic because that’s exponential growth, and that’s a completely different experiment you need to have–but if you’re growing your company pretty slowly, then at one moment you discover that your team isn’t working as a team anymore. Again, there is no magic number for where it is, but most likely, if you have 12 people on the team, they’re going to work as two separate teams or as two separate groups. So that might be a good idea to split this into two separate teams. But again, make sure that those teams are not being built around specialization, around the technology, or on some specific component, but make sure that you can deliver value. So you split the teams, you create the teams that can deliver the value.

Now, the trick is that, for example, in those two teams, you have just one person who knows Java, or JavaScript, or C++. Now, how do you make changes with two teams and only one person, avoiding having this person in two teams at the same time? Now you have two options. The more expensive is to hire another JavaScript person. The cheapest option, and we usually do faster options, is to learn it. So have one team have a JavaScript person, but the second team learns a little bit so they can do the changes in the system. Which means that you start hiring a different kind of people because you don’t hire people with a narrow specialization, but you hire people who can learn and who can look at the system and the product from an end-to-end perspective. There is an awesome conversation, unfortunately, the conversation is in Polish, but I had a conversation with the CEO from Falcon V Systems, a company in Gdynia, and what she is saying is, “We hire people who look at the whole system. So we’re looking for people who want to solve the customer problem, not to just implement a solution.” So what you discover is it’s not just about the structure of the organization, but also about the hiring. So you need to change the way you hire people. You need to change the different kinds of people you look for. So the whole structure impacts the way you do your business.

Building the right culture

Wiktor Żołnowski: Garbage in, garbage out. And it’s not about the people you’ve hired, usually, but it is about what the people are paid for. And by “paid,” I don’t mean what they get for salary, but what the reward system is. And a reward system isn’t just a tap on the back; it’s also a reward system. So if I have a Java developer who is rewarded for doing just Java, how likely is he going to take care of having a conversation with the user? How likely is he going to take care of the testing? How likely is he going to take care of this old, stinky technology we have in the system since 2005? Not likely. Now, if you build the team around the business and they say, “Hey, we need to take care of the stinkiest technology from 2005,” what is an interesting thing that is happening–I have no idea why–but those people are really willing to work in this old, fancy technology and solve the problems for their users. And it’s happening in the organizations. That’s not just a magic kingdom; it’s really, really happening in the companies I’m working with. And I still have no idea why it is happening, but it is. So it’s mainly about building a proper culture that enforces or encourages this kind of behavior around people or around the product?

Tomasz Wykowski: That is a super tricky question. What Craig Larman is saying–and Craig Larman is a person standing behind the Large-Scale Scrum–he’s saying, “Culture follows structure.” So what he’s saying in the LeSS framework organization, you don’t have a conversation with people about the culture, but you have a conversation about the structure. And the moment you’re changing the structure and the moment people start having this conversation with the user, start solving the user problem, the culture will follow the new structure. And this is what I’ve seen. Sorry, not “I,” we’ve seen as ProCognita, because I haven’t been involved, but one of our Agile staff was involved in one of the largest IT organizations, a technical organization here in Poland, when they did change the structure of the organization from components. This change led to many changes in the behavior of the organization. Despite all the problems they had, they started delivering features instead of components, and that change helped them solve a lot of problems. And I’veseen this sometimes working in a large organization, sometimes not working in a large organization. So again, this is an experiment. The change of the structure is an experiment. But often what we do is not talking, having a conversation about the mindset, because this is super popular, “Let’s have a conversation about Agile mindset and all this stuff,” but you start doing a smaller experiment, and the culture changes as a result of those small experiments. Some of them are not small, like changing the structure of a 60-person department might not be a small change experiment, but you do that, and usually, the behavior changes as a result of the changes you do, rather than trying to explain to people why they should take care of the users. Because I can go to you and say, “Hey, you’re doing this wrong, you’re not customer-centric,” and then again, I gave you a bonus for doing just your own thing. You don’t care about the user; you care about your bonus at the end of the year.

Wiktor Żołnowski: From my experience, there are plenty of people who say that, “In my organization, it wouldn’t work because people would follow that, people who are used to the way they’re working, etc.” So for those people, when I used to be a consultant, I used to say that, “Well, you can change people, or you can change people.” And there is no other way if you want to make a change in the organization.

Tomasz Wykowski: But yes, and I would say in the current organization, it may not work. Again, this is about experimenting. And there’s also, if you don’t change the organization and people, then this might not work. So you need to change the structure, and if they don’t feel that they fit the new structure, they can change organizations. This is… so one of the things I discovered over a lot of years of my career–I’m not going to tell how many–is I stopped changing people. So what I do, I do experiments about the system around those people. I don’t do experiments about people. And usually, it helps me, and usually, it helps those people. So I’m not trying to solve problems by changing the people. In most cases, people behave really reasonably in the system we have created. So if people are doing some crazy things, my main question is why. How did we create the system to force those people to behave this way?

If you go to any places and people behave like… I don’t know, you’re flying with Ryanair and someone is yelling at you at the counter, you can say, “Well, what’s wrong with these people?” But you can also say, “What are the consequences for these people for not doing something?” In many cases, it is, “I will get fired, or I will have negative consequences for not doing something.” So the only way I can do it is to start yelling at the customer in this case. Go with the Polish train company. In most cases, you’re going to be late. And if you are late every single time you’re going with the train and you’re working for this train company, then you don’t care. You’re not going to explain to the user why they are late because that’s a natural way. You will get your bonus, you will get promoted, bonus anyways. Now, if you go to Japan and your train is going to be late one minute, everybody is going to say sorry to you, and they’re going to ask for an interview, “Why?” Because that’s not normal. So people do care if they have an impact on the system. If they don’t have any impact on the system, don’t blame people, blame the system.

Wiktor Żołnowski: So getting back to my initial question: how to design this kind of culture or this kind of set of behaviors, set of rules in the organization so a person who is going to grow their company will avoid these problems that we spoke about before?

Tomasz Wykowski: The first one was, where is it? I don’t know, but I can give you a few experiments to try. And one of the experiments you can try is building this organization around the business, so around “why” for the customers. So first of all, identify your customer, your users. And there is one caveat here, and in this case, it is like a paying customer or paying user, not your internal departments. Because often what I’m hearing is, “Oh, we have a user, this is the second department.” Unless you’re doing software specifically for your customer support, most likely they are not your customer; they are just a separate department. Even if you’re building a software for customer support, there is a customer of that customer support. In this case, you’re going to have a conversation with customer support to know how they solve the problem. Now, I had this kind of conversation in one company, a huge bank, and they said, “Well, we’re pretty Agile, we can deliver something in three months.” And I said, “Cool, you can go to the market in three months.” They said, “No, no, we send it to a separate department which implements this for the next two years.” So that is not so much conducive, I would say. But again, who’s your user?

Then you can actually define the products you have. What is your product? Now, my recommendation is the broader the definition you have, the better. So in most cases, for me, banking is one product. If you go to the bank, then you will find a plant number of products they call… I mean, things they call products. But from my perspective, I just want to have online banking, that’s it. So from my perspective, banking is one thing. From the bank’s perspective, it’s a lot of things. So what you try to do is create and define the products, how many products you have. And then you try to build the teams around this product. So the team can take problems from the user’s problem list, let’s call it a challenge, and deliver the solution for this problem, of course, by experimenting with different approaches and all this stuff, because the team also doesn’t know what they don’t know. And most likely, users are going to use the product in a different way than we think they will. So the team needs to have the ability to solve this problem, which means often skills, but also it means to be able to change the system. So if my team can only change this part of the software and they cannot touch this part of the software because this belongs to a different team, then most likely they’re not going to do the change that can have a value for the customer, that can improve the user experience. The other thing is, because you have all those ex-specialists in the organization, you figure out that you cannot create five or six teams that can solve a customer problem because you have just one expert on the X component or the X technology, and you cannot spread this person throughout the six teams. So what you discover is something I call the knowledge debt. And basically, what you need to do is invest a lot of time into learning. And so it’s not just about changing the structure, but understanding that there will be a lot of learning happening. The people need to learn how to talk to the users because you didn’t allow them to have this conversation for the last 10 years. What I’m hearing when I’m going to this kind of organization is, “The developers cannot talk to users.” Well, yeah, because they need to learn how to do it. When I was born, I didn’t know how to ski, surprise. But I was able to learn it in a safe way, so I’m still alive. And it’s exactly the same with the developers. How do you help them learn to have this conversation? And this goes for anything else you need to do in the system: coding, testing, developing, whatever. For this to happen, you need to invest time into that.

Wiktor Żołnowski: So the earlier you start teaching all of your people to do various stuff, it’s better because then this debt, this knowledge debt, will be lower or it won’t even exist.

Tomasz Wykowski: And again, this is on the team level. This is one thing. The second thing is that they need to know why they need to learn. Because again, you can say, “Hey, I’m a Java developer, I don’t want to do any testing.” It makes sense if your goal is to create Java. Except in most cases, your goal is to solve customer problems.

Wiktor Żołnowski: The rewarding system that supports this. Exactly. You’re rewarding narrow specialization, then you’re going to have narrow specialization.

Tomasz Wykowski: Now, my recommendation in this case: hire engineers, not developers. Developers are creating code; engineers are supposed to solve the problem.

Wiktor Żołnowski: You can call it whatever you want. Just you can call it developers, call it engineers. From my perspective, it doesn’t matter. It’s mainly the way you assess their knowledge, but what’s more important is the way you assess their mindset. We were still planning to have one of the next episodes about hiring people for startups, for any product company, and how we also are going to share how we do this. Because we are having this kind of people, like people who are problem solvers, people who are focused on the customers, on their needs–I mean the customers of our customers, the users and their needs–and who are also… our system is more or less supporting this kind of behavior as you described. So yes, but I know it wasn’t easy to build this kind of organization structure and also to build this kind of rewarding or even supporting system. I don’t want to call it rewarding. And like…

Tomasz Wykowski: And again, I call those people engineers. Call them whatever you want. Except that if you have hired people and told them during the hiring period that their goal is to create Java code, then they still think that their goal is to create Java code. So one of the great things at Motorola when I used to work there is we called everybody a software engineer. No matter what you’ve been doing, you’re a software engineer. You might have a different salary, you might have a different expertise, all this stuff, but one universal, “software engineer.” I really love this one. You can even have different things on the post on LinkedIn, what you do, but inside the organization, try to have software engineers or product engineers. “Product engineers” sounds even better.

Common misconceptions about scaling

Wiktor Żołnowski: Okay, so maybe there are some common misconceptions about scaling Agile that you notice when you’re working with companies? As you mentioned, you usually or you like to work with companies of 60 to 100, so they are already after the first stage of growing. And as you mentioned, they are usually calling you not without a reason. So maybe there are some common patterns that you see, that they made common mistakes over and over again. You go to the company and say, “Okay, again, they do the same, they never learn.”

Tomasz Wykowski: So first of all, there are some patterns in the organization. Talking about the scaling patterns, the most common misconception and the most common mistake is that you should not… I mean, try not to scale. That is the very, very first point. In most cases, it is ignored. I mentioned Craig Larman already, and there is a lovely slide in his training. By the way, if you haven’t been to the Large-Scale Scrum training, I know this is an ad, but it’s like a mind-blowing training, so go there. And the training is on scaling, and the very first slide is “more with LeSS,” “don’t love Scrum,” “don’t multi-team.” And he says, “We’re still going to do it.”

So one of the reasons for scaling is because we think we need to deliver more, and in most cases, the cost of scaling is way higher than the cost of focusing on the important things. There are awesome companies delivering amazing products with a small number of people. In Kraków, there’s a company called inFakt. I love those people. And one of the great things they did is they managed to finally improve the quality of the product, the value proposition to the customer, and grow the product super fast with exactly the same people. The only thing they did is they stopped doing things that are not critical. I had a conversation with Sebastian Bobrowski from inFakt, and what he’s saying is, “We’re selecting between the very, very important things to do and the very, very, very important things to do, and we select the second.”

So in most cases, what you’re trying to scale is because you’re trying to do too many things at the same time. My recommendation is to focus on prioritization rather than only scaling. If you have too much budget, coming back to the conversation we had before, hiring more people is easier than saying no to the marketing department, especially if you have a big budget, then in most cases, this budget comes from some other people who have some expectations from your product. So you need to do something, add some features, like, “Make sure this goes on the blockchain,” or whatever else. Don’t forget the AI, we need to mention this right now in any conversation we have. And you end up with having too many teams coming from too many features you’re trying to implement. So my recommendation is don’t. If you have to scale, then have a look at the structure and see how you can change the structure. Design the scaled structure when you start hiring more people, instead of hiring people and then trying to change the idea. Because in this case, you may not call me because you may not have those problems. So again, in most cases, when I’m being called, it’s because you have a structure where people don’t talk to each other, or because you’re trying to do too many things at the same time, and you end up with unless promises, because you say to the customer, “We’re going to deliver this one,” and you end up delivering something else. And that’s not a metaphor. This is a conversation I had with a customer. I go to the customer and we have a conversation, and they say, “Hey Tomasz, we have a problem.” In most cases, they have a problem with estimating, by the way. “We have a problem with estimating,” and they say, “We cannot… we don’t get what we want.” I say, “So you get half of what you want?” assuming that they’re trying to push too much work on the team. And they say, “No, no, we ask for one thing and we get a different thing.” I say, “That’s an interesting situation because it sounds like a problem… it doesn’t look like a problem with estimating.” So let’s have a look at what you have delivered in the last two weeks. Let’s have a look at how many items you have delivered in the last two weeks. And they say, “Like six important items,” ignoring the non-important items. And I say, “How many important items do you have these two weeks?” And they say, “36.” So how likely are they going to get those six items if that is your capacity? How likely are you going to get those six items you care about, not your team cares about? And yeah, most likely, you’re not going to deliver on promise. Most likely, your estimation won’t be met. So you didn’t… they weren’t met, but it’s not because you cannot estimate, it is because you cannot focus on one thing. And they say, “Yeah, but in this case, we would need to go to the team and say, ‘You guys need to work on something that is important for the customer, not something what is interesting for you.'” And I say, “Yeah, that’s prioritization.” And this is the difficult situation. So it’s easier sometimes to hire more people to do 36 things at the same time, but it doesn’t mean that it’s needed to do 36 at the same time.

Wiktor Żołnowski: But it is easier to start, yes. Easier to hire 36 teams than to make a decision not to do 30 items.

Tomasz Wykowski: So how to discover what is very, very important and what is very, very, very important, and what is not so much important? I have no idea. The moment I will have this idea, most likely, I’m going to retire. So my observation from all these companies I’ve seen is that you are selecting between the items that can give you like a million dollars and have a 52% chance of success, and something that can give you one and a half million dollars and has like a 48% chance of success. You have no idea right now. If you select correctly, then you can write a book about how to select correctly, how to do the correct prioritization. If you didn’t select correctly, then you still can write a book, but no one is going to read this book anyway. So frankly saying, I still have no idea. One of the things I know is like if you get quick feedback from the user–so you have an idea, you go check this idea, you figure out it’s wrong, you create another idea, you go check this idea, you figure out it’s wrong, and then one day, if you still have a budget, you will discover that you solved the problem–then you have a higher chance of it working. So all this idea behind the Lean Startup and doing quick experimentation, doing the hypothesis testing, all this stuff comes to mind. So again, how do you know that you are wrong? How do you know that you’re correct? In most cases, like 50% of the time, you’re wrong. Most product owners, most product managers–it’s not about you, it is about your market. In most cases, you’re wrong. And now you have two options. You either burn all the budget you have creating great software no one cares about, but you can also drink beer, eat pizza, celebrate the next milestone, and all that stuff. Or you can do a lot of quick testing. If you do a lot of quick testing, then you discover that you’re wrong. And if your organization is adaptive enough that you can change the direction–coming back to why I need agility–then what you can do is you can deliver, more likely. Again, it is not about being 100% sure still, but you can increase the likelihood of succeeding.

Product management: great vs. not-so-great

Wiktor Żołnowski: I think that we are getting to the topic of product management, because this is all what the… maybe not all, but most of product management is about: how to choose the right thing to implement and how to even decrease the scope, how to design this kind of small experiment that you will go with, with which you will go to the market fast and test it at a low cost. So what’s your experience, what’s your opinion? Do you see maybe some patterns that the companies that have like great, astonishing product management and the companies that are missing product management… maybe there are some patterns between them? Like one is better, hopefully, and another is not.

Tomasz Wykowski: What you already mentioned is like, the great companies know they don’t know. In those not-so-great companies, I’m going to call it product arrogance, we think we know. And now, if you are Steve Jobs, then you might have an intuition, and you might guess correctly. In most cases, you don’t know. And the sooner you learn and the sooner you accept–because there’s one thing that you learn, but the second thing is many companies learn and they ignore the data, and they say, “Tomasz, you don’t understand our context. Our users are not using this system because they don’t know yet about how awesome it is.” So I’m going to add more features, except they don’t log in to the system because they are afraid, because you made so complicated a login system or registration process that people cannot register. But you’re adding all the features behind the registration wall. By the way, it is again, not a metaphor, it’s a story of one of the customers. So the great organizations, they know they don’t know, and they’re doing a lot of experiments.

Now, what they can do is they focus on one thing. So instead of focusing on adding features and plenty of features, and product management comes with a list of the features and then someone does those features, what they do is they come with some impact they want to achieve. So they say, “Okay, our problem is no one cares about our product,” or “no one is logging in,” or “we lose people when they go to the payments page and they drop from the website,” or whatever else. You create a problem and you say, “Hey, this is the impact we want to have,” and you create a few hypotheses and you test those hypotheses. Now, if your system allows you to test, so you have a customer-centric team and software development is done the right way in 2023, you are supposed to have the option to do a lot of A/B testing, not to have three-month releases. Just to mention this one. So you can do a lot of testing. Now, why you should not have three-month releases? The reason for that is that if you have three-month releases, how many experiments can you do during one year? So you’re going to guess a lot less than if you can do that experiment every five minutes.

There is a story from the company TripAdvisor where the CEO is saying, “What we do is a lot of forecasting. We usually put a link on our website, you click this link, and you end up on the ‘page not found,’ but what we get is a lot of information about how many people clicked this link.” And the cost of adding the link is super low, but we don’t invest into the whole feature, we just collect the numbers. And if you have like 10,000 people who want to have this feature, then we can build this feature. But we can learn this in five minutes. Now, this kind of testing is now way more fancy in 2023, but again, if you cannot do all this testing every five minutes in your organization, that’s why you need to have all these engineering practices done right. And then you will be guessing more, and more likely, you’re going to be wrong. I mean, you’re going to be wrong again, but you’re going to learn later about being wrong. And if you learn after three months about being wrong, then how likely are you going to change all the plans you have? So aside from being a consultant, you’re also a Certified Scrum Trainer from Scrum Alliance. So when you are visiting these companies that you are consulting, do you see any common misconceptions in terms of implementing Scrum in these companies? What are the common problems or the common misconceptions they implement?

Tomasz Wykowski: Frankly saying, I don’t care about Scrum. I do care about the adaptivity of the organization. If you can use Scrum, awesome. Maybe you can use Kanban, awesome. You can do potatoes, tomatoes, oranges, that is awesome. It is not about doing something. And the number of misconceptions is growing every day because the awareness of Scrum existing in the world is growing every day. But again, the biggest misconception, I believe, here is that it is something that the team is supposed to do. So what I was trying to show you over the last minutes, hours, whatever, during our conversation, is that it is about changing the structure, and Scrum is about changing the organization. It is not something you do at the bottom. And the biggest mistake companies do is like, “We’re going to be Agile, so we’re going to go to those people at the bottom of the organization, tell them they are supposed to work with Scrum, but we’re not going to change anything else.” And they’re looking for the frameworks that meet their current structure, which is not optimal for delivering value, for testing, for experimenting. They find something that meets their needs, and they say, “Oh, that is something exactly that’s going to work here.” The problem is you have the wrong structure in the organization. And until you change the structure of the organization, until you need to change your policies, until you change the way you reward people, this Scrum thing is not going to work. So I don’t care about Scrum. I do care about how you reward people, how you make sure that they learn new things, how they have a conversation with the users, how often do they solve their problems, that they see how their solution addresses or doesn’t address the problem. This is what I care about.

The state of agile adoption in the market

Wiktor Żołnowski: Let’s talk a little bit about this adaptation of Agile and Scrum methods on the market right now. So when I used to be an Agile consultant, it was like 10 years ago or something like this, I remember we were in a situation where we were still, let’s say, early adopters of Agile. There were not so many companies. Any company that wanted to learn about agility, Agile, etc., they were considered as early adopters back then. Even a few years before that, when I worked as a developer in another software house, in a small company, we were even innovators. I remember the time when we were one of four companies in Poland that were actually using or knowing anything about Agile and trying to work in Agile. It was back in 2008, 2007, something like this. How does it look right now? I don’t have this knowledge about the market as you do right now. So the main reason I’m asking is that still, it’s like 10 years later, so I can imagine that there is a huge progress on the market. The knowledge about Agile became something that maybe already should be in the mainstream. We should have already crossed the chasm, and then people should at least start talking about it, start learning about it. But still, I see that many of our clients who ask us for working with them or something like this, what they are asking for is usually like, “We need to know what’s your estimate on the fixed budget, fixed scope project that we want to work with you on,” which doesn’t seem very Agile. So how does it look right now?

Tomasz Wykowski: There are so many things you mentioned in this question that I’m going to try to address at least a few of them because otherwise, it’s going to take us another hour. Yesterday or two days ago, I watched a great video by Jim Highsmith, one of the co-authors of the Agile Manifesto, and he said that in the beginning of the 21st century, this Agile thing was done by a few teams. Like you said, there were teams inside the organization who were trying this one. And he told a lovely story about Mike Cohn going to one of these organizations, and the CEO says, “Hey, I have three teams working in this Agile approach.” And Mike comes back a few days later and says, “Hey, you have four teams working in this approach.” So the CEO didn’t know about one of the teams. So that was a very team-led thing. Now, what happened later is that some of the executives said, “This is the game-changer, so we can do something amazing by having that in the organization.” And they were brave enough to try this with the whole organization. That was crazy 20 years ago, that was crazy 15 years ago, that was a crazy idea. Right now, as time goes on, more and more companies joined the bandwagon. And the thing is, you mentioned the “crossing the chasm” book. The thing is, if you look at the curve, if you look at how the late majority is defined, they’re more or less… it says something like those people are not looking for revolution, they’re looking for evolution. So they don’t want to have a huge change. And one of those companies who joined now the Agile movement, they don’t want to have Agile as a game-changer, as a marketing tool, as a business lever like, “How do we beat our competition? How do we work on the market? How do we compete with other companies?” They want to see a little bit of improvement and make it a little better. It’s bad, so a 10% improvement is also… that’s all we need. And there are a lot of these kinds of business companies. So most of the companies, they at least heard about Agile. Again, a lot of misconceptions and stuff. The thing is, there are two interesting things. Most of the companies, as I said, they’ve heard about Agile, but most of those companies again didn’t want to have a huge change. So one of the reasons I’m working with smaller companies again is because those are the companies who want to see those revolutions, not just the evolution, but more likely the revolution. And this is more interesting from my perspective to see real, real change happening, not just, “We’re doing the daily stand-up every two days and we call it daily” or whatever. That was a story from a customer, by the way, for those people who don’t recognize it. But they really want to have this competitive advantage coming from this Agile.

Now, just because in software development it’s happening doesn’t mean that on the other markets it is late majority. In many cases, there are awesome companies outside software development. I’m going to hardware development. Hardware development as a market is 10 times bigger than software development. Now, we are in exactly the same place we used to be 20 years ago in software development. Everybody knows that you need to do this sequentially, so plan and execute the plan. Everybody knows that the Agile approach doesn’t work because we have limitations. And there are a few crazy companies who try to do something different. SpaceX. I mean, they’re doing a test every two or three months, and then if the rocket blows up, there’s a lot of learning opportunity, and they’re going to create a new rocket, and then it’s going to blow up, and they’re going to create a new rocket. Every next time, they make it cheaper. A few weeks ago, there was information coming from SpaceX. The largest rocket just blew up in April. So that was two months after the last test. And they said, “We’re going to do another test with the new rocket, and we have implemented over 1,000 changes into the system.” I’m not talking about trivial changes, but there are significant changes, a thousand in the system. So any company who cannot do a thousand changes into the system doesn’t understand our context, and “we are special.” Sorry guys, in hardware development, it is already happening there. And one of the reasons for this one is because Elon Musk comes from software development, and he understands that you either do the quick testing, or you stay behind. So that is a revolution happening there right now. And SpaceX is still not so big a company. I don’t know how many people it employs, but it’s still, I would say, a medium-sized company, if not even a small company considering this kind of industry. Especially think about the disruption that Tesla is doing on the car market. Car companies were pretty good until Tesla came in. They changed the market, so either you catch up or you end up like I said.

Wiktor Żołnowski: So why do you think, what’s the reason that still so many people have this fixed waterfall, fixed project, fixed scope, fixed budget mindset?

Tomasz Wykowski: Think about it like this: if I have a plan, I would rather not change it. The change into my plan is super frustrating. If I want to go for a beer today and I cannot go for a beer today, that’s going to be frustrating. And most organizations would rather stick to an unrealistic plan than change the plan. So it’s more comfortable to have a plan, it’s more comfortable to have a feeling that you know what’s going to happen. Plans give you the certainty that you think you know. If you know, you’re thinking now. But that is why we have so many companies earning money on predicting the future. I mean, that’s guessing, by the way. But just yesterday, I’ve seen information on how the market is going to look 50 years from now. I’m pretty sure that that was an accurate guess. So we love to have predictions, we still don’t know what’s going to happen tomorrow, but we love to have predictions. And it is just easier. So if your company is doing pretty good with the predictive approach, so you can plan and execute the plan, then the change to the more difficult approach of a more adaptive development can be painful. So my recommendation is don’t, until you feel that there is a real, real need of doing Agile, of becoming more Agile as an organization. Try not to, because otherwise, you’re going to frustrate those few people who want to be more adaptive. The only change you’re going to have is you’re going to change the name of people and the title people have on their business cards or on LinkedIn, and that’s it. Nothing will change. And you end up saying, “Well, Agile is not working here.” It is not much about Agile in this case.

When should startups aim for agile?

Wiktor Żołnowski: So what about startups? Should startups, or maybe not all of them, but when should startups aim for being Agile, and when not?

Tomasz Wykowski: So we mentioned the Agile approach and we mentioned the predictive approach. There is one more approach that is often being perceived as an Agile approach. This is something I call “no process process,” which basically means we do what needs to be done. So if it is working for you, then don’t have a conversation about wanting to do a more structural approach to development. Agile is more structural development. Co-programming has some cons, but often if I have five people in the organization, then iterative development may not be the way to go, especially when you just started. A few people in the team, you’re doing co-programming. Of course, there is some risk behind it, especially in the long term, and some cost of it. But also, your entire product, your entire company is a very risky business, and you have like a 5% chance that you will survive the first year. So who cares about it?

On the other hand, if you discover that everyone is super busy, everybody’s doing their best, and you don’t deliver anything, and like, you spend six months and you have nothing to show to your customers, then maybe, just maybe, there’s a good moment to have another conversation. How about we deliver anything in a two-week cycle and then get the feedback, and then deliver something and then get feedback? By the way, when we were changing our website, we had exactly the same approach. We said, “It’s going to take a few days or few weeks,” and six months later, three months later, we said, “Hey, we have a lot of in-progress work, but nothing delivered to the customer.” So how about we eat our own dog food and start doing this iterative thing? And this is what we did with our website. But before that, we basically were doing complete co-programming, and it worked pretty well, except that we haven’t delivered anything.

Wiktor Żołnowski: This is why I’m always saying that especially when you’re starting in a greenfield project, greenfield product, greenfield organization, etc., starting it right will actually not cost you anything extra. It will cost you the same as starting it without any process or whatever. So why not start it right from the first time? Of course, you need to have the knowledge, so this is crucial. You need to have it. As long as you know, you need to explain, I mean, trust from this knowledge to other people. So I don’t know, it doesn’t cost anything, although if you have the right people who have that knowledge already, then probably… I think about why every startup that we started with, the one we did startup, they were doing great iterative development, except that they haven’t been delivering the value to the customer. This is why if you say, “Okay, let’s do more small hypothesis testing rather than a lot of iterative development of what people don’t care about.”

So let’s get back to Agile and startups. If you could name a few methods, tools, or practices from Agile that every startup should at least try, what would they be?

Tomasz Wykowski: I would say have a face-to-face conversation with the user, observe those people. By the way, don’t ask them what they need; see how they behave. Try to understand their problems. So don’t try to ask the question about the features they need because that’s not going to work. There’s also a super short video that is called “The Mom Test,” and this is something I would recommend to any startup owner to watch it because it shows you how not to run your conversation and how to run your conversation. So this is one thing.

The second thing is to make sure that you can do a lot of cheap testing. You mentioned that you can create software iteratively, and by iteration, I mean a lot of small tests. If you’re starting software development and you cannot deliver anything in two weeks, that’s a disaster. I mean, I understand why banks have a problem with this one, but in 2023, if you cannot do the software every two weeks, that is just… you’re supposed to go to production every five minutes, not every two weeks in 2023. Amazon was able to go to production over 10 years ago every 12 seconds or so. So it is the way it is, just about the investment into the right infrastructure, about the right skills, and all this stuff. So I would recommend starting with those two. And make sure that you’re trying to solve the problems, not to implement the features. So that would be number three.

The future of agile

Wiktor Żołnowski: Perfect. So last but not least, let’s try to guess what will happen in the next period. What do you think is the future? What are the trends right now in terms of Agile and Scrum? Is there anything that will change, or will we still just be adapting things that were discovered a couple of years ago, and we’re going in this direction?

Tomasz Wykowski: Okay, I don’t care about Agile and Scrum. I might make it clear. What I’m interested in is how the companies do and what is happening. I don’t think it’s just specific for the current situation. Based on history, what is happening is like you have companies who know how to do 20–50 A/B tests at the same time, like Facebook, Google. They are doing a lot of testing, and the way you see your application is different from the way I see my application. They know how to do it. At the same time, you have a company who has no idea how to go to production every three months. So you have a huge spread between those companies. And I believe there will be companies who are getting better and better, and the companies who, as long as they have enough money, they’re going to survive. The question is how long. That’s a separate question. Maybe it’s not too long.

If you are doing well, then probably you don’t need to have to change your organization right now. Some of the companies, they discover that they are not finance companies, they are IT companies, they are tech companies, like ING’s CEO said years ago, that “We are a tech company.” And they do invest a lot into making a lot of changes so they can do these kinds of things we just said. So we’re getting more into cheap testing. So one of the great things about the cloud, about the DevOps idea, is that you can do a lot of cheap testing. You can do a lot of testing on a small group, a small subset of your customers. You can do a lot of testing on a specific market. You can easily deploy, you can easily scale, and this is what is interesting for you as a manager. I have no idea which direction we’re going to go from this one, but my assumption is that the best companies are going to use this as their competitive advantage. So they’re going to go faster on the market. Think about Revolut as one of the examples of the companies that disrupted the market. They were so fast in going to the market that basically they had like one and a half years of being on the market in a blue ocean. No one could do anything. It took over a year for any bank to come with anything that was, let’s say, close to what Revolut was streaming. And this is what I’m interested in. So I don’t care about Agile and Scrum, I do care about the companies who are doing great things. Now, how do you do this on the smallest scale as a startup, and then a separate story, how do you grow as a company? Because as you grow, as we said, you need different experiments, you need a different structure, different skills, and all that stuff. So this is what I care about.

Wiktor Żołnowski: Okay, thank you very much for this conversation. To all of you, if you liked it, please thumbs up on YouTube and rate our podcast on Spotify and Apple Podcasts. And I hope you will subscribe for the next episodes. And thank you very much for listening and watching us. Thank you very much.

Tomasz Wykowski: Thank you very much.

Wiktor Żołnowski: Pragmatic Talks is delivered to you by Pragmatic Coders, the first-choice software development partner for startup founders. Be sure to catch all new episodes. Subscribe to our YouTube, Spotify, or Apple Podcast channels. And if you are thinking about building your own startup or struggling with product development, contact us and find out what we can do together.