Management Myths Busted with Johanna Rothman
Disruption and Innovation Podcast
Episode Date: October 21, 2025
---
Kumar Dattatreyan: Hi, everyone. Kumar Dattatreyan here with Agile Meridian and the Meridian Point podcast. Today, I'm thrilled to be joined by Johanna Rothman, known throughout the management consulting world as the Pragmatic Manager. I love that. Johanna is a prolific author with over 20 books on management, project management, and agile practices, including the award-winning Manage It! and the classic Behind Closed Doors: Secrets of Great Management. Her Modern Management Made Easy trilogy, covering how managers can lead themselves, their teams, and their organizations, challenges the management myths that hold leaders back. With decades of experience helping leaders and teams navigate product development challenges, Johanna brings a unique perspective on how organizations can disrupt outdated management practices to become more adaptive and effective. Welcome to the show, Johanna.
Johanna Rothman: Thank you very much. I am delighted to be here.
Kumar: And I'm delighted to have you here. Amazing conversation we had a few weeks ago in preparation for this conversation. Obviously, you've written a lot of books. You've written extensively about project lifecycles, feedback loops. We touched on what I call the "Agile Veneer," sort of this layer, this surface of agile goodness, right? Organizations that look agile on the surface with their JIRA boards and daily standups, but underneath remain fundamentally waterfall. What are the telltale signs that you see in an organization that's created this veneer? And what's the real disruption they need to undergo?
Johanna: So when organizations focus on the individual, and they focus on who's the expert and how can I tell who's doing what for performance management—that's when I know they have the Agile Veneer. And they can never achieve what they want to achieve in terms of agility. Now, I am not a religious agile person, right? I don't care if you use a board, if you use Scrum, if you use Kanban, if you have a homegrown approach, as long as the team releases something useful every day or two, does a regular demo and a retrospective, has a ranked backlog, and they collaborate. Those are the essence. That's the essence of agility. And the faster the feedback loops, the easier it is. But the more a manager focuses on an individual and what the individual brings to the work, the less agile the team can be. And worse, the less agile management is, because they're always waiting for the next person in line to do the next thing. That's called resource efficiency thinking. And the worst part is cost accounting focuses on resource efficiency. That's everything behind cost accounting. And our managers have to report in cost accounting terms. However, they do not have to manage with cost accounting. And that's really the challenge that managers need to consider if they really want agility and not fake agility.
Kumar: Yeah, that's a really good point and a really good observation, that sort of going to that individual rather than the team. And I suppose the opposite would be true—if an organization was truly agile thinking, is that they're not relying on the individuals, they're relying more on getting information from the teams, right? And you mentioned something about cost accounting. What would be a better way for managers and leaders to assess the performance of their team, their department, their division, whatever it may be?
Johanna: So I propose this in both Practical Ways to Lead and Serve Others and Practical Ways to Lead an Innovative Organization. But I have been an independent consultant for 30 years. No one has ever given me a performance review in 30 years. And somehow I have managed to keep improving, and I improve with feedback. Everyone needs feedback, right? I don't know anyone who does not need feedback on a regular basis. And my clients, thankfully, have been very quick to offer me feedback—most of the time when I do stuff right, and often if they don't like what I have done, they tell me. They tell me why. This kind of consistent and frequent feedback is what people need. Very few people need performance evaluation or performance management. And if anyone does need that, it's all in the management.
So think about a situation I see a lot. I wrote Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. I wrote that book in 2009. I released another edition in 2016, something like that. I still see managers spend an enormous amount of time trying to get estimates from teams about work the teams have not yet started. And the longer the managers wait for all of those estimates, that has several effects. The teams have to stop what they're doing now—at least spend a couple of hours, and often that's not nearly enough information from what the managers want—to give a ballpark estimate of what this new work is. And then the managers wait longer and spend a lot more time deciding what did we do first, what did we do second. All this, right? You have seen this. Everybody has seen this.
When I ask teams to measure their value stream map—how long does it take for work to come in and then to release—I also ask managers to measure their value stream now. How long does it take from when they first start to think about a decision until they make the decision? And often, while teams almost always get their estimates pretty spot on in terms of duration, they have so many interruptions that the duration is not really a valid duration. But the managers have no idea how long they actually spend waiting for information and then waiting for all of them to be available for yet another meeting for all of their decisions. So the wait time in organizations really outweighs any of the work time. And if managers can start to measure wait time and manage that, they will get almost everything they want.
Kumar: I totally agree with that. I was in a conversation earlier today with some leaders that were looking for how to sell lean portfolio management, I think that's what we were talking about. And it's like, "Oh, these people are so busy. They don't have time for this. There's just another meeting on the calendar." And my answer was—not just me, but the other person there—we were trying to help them understand that it's not an additional meeting. It's really more about taking the place of things that they're doing now in a more efficient manner, right? So all the different ad hoc meetings that people have to talk about schedules and projects and plans and so on, we bring the people together and we have that together in a cadenced, synchronized manner. And thereby we save time. We don't use more time, right?
Johanna: Yeah.
Kumar: And on the other comment on the cost accounting model, right, that's been prevalent. It's everywhere. It's in every industry and every company. And I'm curious what your thoughts are on a throughput accounting model—so actually measure the throughput of value as a measure of organizational value delivery.
Johanna: So I work with my clients to help them do that. Very few of them are willing to manage by throughput accounting. It's way too scary. And starting with the engineering or the product teams is the wrong place to start. It has to start with finance and HR, right? Because if you want throughput accounting to manage, then you have to change how you organize the financial decisions, which goes back to the portfolio, and how you measure and reward people. Because now you have to reward them for how they offer their throughput in terms of the team. Anytime a person increases the capacity of other people, that's how you need to reward them. And that totally changes everything.
Kumar: It should. It can, and it should, and it does when applied. But you point out the big challenge there is it's changing how people think about work in general, and how people think about planning the work, and how people think about rewarding people on the work that they do—not on their individual merits or their individual performance, but really more about how are they helping improve throughput of value for their team, for their department, for the things that they work on, the projects, the programs, or whatever they are, right? Ultimately delivering value to their customers. And so that's really a fundamental shift in thinking that takes a long time and requires the right catalyst to get those things in motion, if you will.
Johanna: Well, I really like to call it "optimizing up for an overarching goal." And that way, almost everybody can get with that idea. I don't have to tell them we're going to focus on flow efficiency thinking or throughput accounting. Oh, my God, say the accounting word—everybody kind of thinks that, they shut down. Yeah. So only the finance people love it when I say throughput accounting.
Kumar: Yeah.
Johanna: But almost everybody says, "I would love to optimize up for an overarching goal. I would love that."
Kumar: Yeah, good point. Your trilogy, the Modern Management Made Easy trilogy, is structured around busting management myths. Can you share two or three of the more damaging myths you encounter that prevent managers from being effective?
Johanna: So I think my two favorites are that we must have everybody working at peak efficiency—100% utilization, right? We have seen this. And of course, it's not peak efficiency that we need, it's peak effectiveness. So it's that optimizing up for the overarching goal, which is the one thing we need to do today to finish, and that helps us be the most effective as possible. So we already talked about that a little. Let me go on to the other myth that I find really, especially now in the age of AI, that if you're not typing, you're not working. And what I vividly remember from my programming days—I would spend hours reading other people's code and hours testing my own code to make sure I had actually done it right. Typing is the smallest piece of any kind of software development. It's all understanding what the customer wants, translating that into what we might do as part of design—whether you do some kind of design-first development or some other way, or you collaborate even with AI on proof of concepts. There are many, many ways to do this. Thinking that an agent or something else can take the place of typing means these people do not actually understand what effective product development is. If we don't understand the customer's problem, we can type all day and never get anything. And if we don't understand what already exists, we can never get to where we want to be.
Kumar: Yeah, that's so true. I suppose garbage in and garbage out, right? So what is your opinion on AI and helping people become—the promises, of course—it helps people become a little bit more productive, maybe take some of the drudgery out of repetitive tasks and all that. What is your opinion on that?
Johanna: I would love to take drudgery out of some of my repetitive tasks. So here's an example, a real honest example. I have 30 years of content on my website. Yeah. My website has evolved from hand-coded HTML in 1995 to Blogger to WordPress. I've had a WordPress site now, I think, since 2004 or 2005—about over 20 years of work. My categories are pretty good. My tags totally stink because I've evolved everything all since then. I really want an agent. I really want an autonomous agent to go through and figure out what tags are useful and make sure every single post has them. Is there one like that?
Kumar: No. I mean, I'm sure you could create one. You could design one and then sell it for others like you who have generated lots of content and need to categorize them, tag them in a way that's more effective.
Johanna: Right. But right now, this does not exist. And also, unless I want to pay what I think is a ridiculous amount of money for a spreadsheet bot, I still have to do all my spreadsheets and integrate spreadsheets from a variety of places manually. So as a self-published author, I get spreadsheets from Amazon, from at least six or seven other places. Amazon reports in the currency that the reader paid, not in dollars, which is what they pay me two months later. So every single day, Amazon has a slightly different currency conversion rate. I actually have to go in and figure out which day did this person buy this in which euro or Indian rupees or Japanese yen, and I have to make that change myself in my spreadsheets. This is an excellent opportunity for some kind of an agent, especially an autonomous agent, to go through and do this. And as far as I can tell, I might be able to get that if I'm willing to pay 20 bucks a month. Sorry, I can do it for less money than 20 bucks a month.
Kumar: There you go. There you go. Well, I mean, we should definitely talk maybe offline. There's lots of stuff out there that's available. And you would just have to spend some of your time to train your agents to do the things that you're wanting to do. It's an orchestration and an intelligence issue, right? So the orchestration is making sure you tell this bot where to go look and what information to get, and then applying that intelligence to it. If it's on this day, I want you to go figure out the exchange rate for this currency and go calculate it and put it over here. So it's doable, but it does take a little bit of time. It's not easy yet. It's not sort of like where you can talk to an agent, an AI, and say, "Hey, this is what..."—I don't know, maybe it is. The thing about AI is that it's progressing so fast that I don't know that anyone—maybe someone knows what it's truly capable of—because there's new versions of ChatGPT and Claude and this and that and Grok and stuff coming out all the time that are getting exponentially better than versions before it, right? And so who knows? Maybe something like that will be there soon. I hope so.
But I do have another opinion about vibe coding specifically, because I have found that what some of my programming friends tell me is that they like the pairing that they do as vibe coding, but they don't like the cleaning up after the vibe coding leaves a mess. And so I say to them, "Why wouldn't you just vibe code with another human and use test-driven development as you do it? And maybe even have an AI as another partner in that conversation." I think we are trying to offload the wrong things right now. This will change over time. I will even get my tagging and my spreadsheet fixer at some point. I will. I know this. But I think we are not thinking enough about collaboration as humans and AI. I think there are people doing that work and are quite successful at that work, but you're right—it's not in the mainstream.
Kumar: It's like, what can we offload entirely to an AI to do, when it should be AI augmenting our intelligence, right? AI as augmented intelligence, if you will, rather than the artificial intelligence—augmenting our abilities to do work and accelerating our ability to do that work. And there are people working on that. Peter Merrow, for one, has been talking a lot about AI and agile, for instance, as a human and a machine pair programming, for instance, just as you described. And he's been doing lots of experiments around that to prove that works. And I know that there are companies that are doing that as well. So we'll see where it goes. I'm going to turn my light on here. It was bright. Now it's getting darker. It's about fall, fall time. You know, that's what happens, I suppose.
In your book, Project Lifecycles, you focus heavily on feedback loops rather than specific frameworks. And you kind of mentioned this in the beginning of our call, right? It doesn't matter if they're using Scrum or Kanban or whatever. It's not so important, the framework. It's about the feedback loops. Can you explain why you believe shorter feedback loops are the essence of agility?
Johanna: So imagine this. Imagine you come in to work on Monday and the product leader says, "Over the weekend, a customer experienced a serious outage. So I'm going to postpone everything on the backlog for now. I want the entire team to focus on fixing this outage because this is a very important customer." The entire team says, "Yes, we will do this." And they have something that probably works by 3 in the afternoon, but they need to do some more testing. Now, the product leader has an option. The product leader could call this very important customer and say, "Are you willing to take something we have not finished testing yet and see if it will meet your needs? Or do you want us to finish all the testing before you get it?" And the customer might say—if they're dead in the water—they might say, "I want it done," or "I'll take it." I don't know what the customer will say. However, the shorter the feedback loop, the more options the product leader has and the more options the customer has.
And we do this all the time with what we call tiger teams, right? We have had the idea of tiger teams, well, since I was a programmer, so forever. But I think it's really important to now say, "How do we know what the right next step is?" And every time we can finish something and choose the next right step, we have more agility.
So imagine you don't have an emergency in the morning, but your product leader says, "For this week, I only need to get answers today from story one, story two, and story three. And as soon as I have answers from those three stories, I can decide what to put next on the backlog." Now, does that look like Scrum? No. Does it look like Kanban? Yeah. And does it really matter? No.
Kumar: No. Yeah. Absolutely. I love that. My early experience with Agile was actually in restaurants, and I didn't know anything about Agile at all. And I was a young version of me. I was probably one of the youngest general managers in mostly corporate restaurants, and I went from corporate to corporate and did my thing. They're mostly full service, not fine dining, but casual dining-type style restaurants. And in all of them, we did things that would—I think if you walked in and my original question and I asked, you know, what are the sort of the smells, if you will, when you walk in a place that they are agile. And for me, some of those smells are that people are talking to each other, they're collaborating, that they are focused on the customer in some way, shape, or form. That they understand their products really well and are able to provide information to their customers in a way that helps them make a decision. To me, those are all the hallmarks of agility, because if you can do those things, then you can communicate the story, if you will, to the customer.
And what we used to do in restaurants is try to do that. I used to try to make sure my back-of-the-house people understood the products and understood what customers want, and the front-of-the-house people understand the products and what the customers want, and make sure they both are talking to each other. And we had standups twice a day. We had planning sessions weekly with myself and my management staff. I later found out about Agile. And I'm like, "Oh, we used to do that." And so your point about feedback loops is very—it resonates very strongly with me. In restaurants, your feedback loop is in minutes, right? Because your customer tells you within minutes if their order is right or not, right? And why not employ that sort of an attitude or a mentality to the work we do in software development or in whatever we do—legal briefs or HR policies or training development or whatever it might be. So I totally get that. I love that.
Johanna: Well, I really hate the—I cannot tell you the number of times when I use longer feedback loops. And those are only a month long as opposed to many months long, because I've been kind of agile-ish for most of my professional life. When my product person said, "You gave me what I asked for, but it's not what I need now." You get that sinking feeling and say, "Why didn't I know that three weeks ago?"
Kumar: Yeah. Yeah. Your feedback loop was too long, even though it was a month and much better than three months or six months or whatever it was. Yeah. I totally get that. All right. I love that term, by the way, "agile-ish." We're agile-ish.
Johanna: Well, so my very first summer in my very first job out of school, I got stuck on the 90% done problem. It was a four-week task. I was 90% done at the end of the fourth week. I was 92% done at the end of the fifth week. I was 93% done at the end of the sixth week. My manager took pity on me and he said, "Do you have any idea when you'll be done?" I said, "No, I have no idea. No, no idea at all." He said, "Here's the secret. There's a thing called inch pebbles." And I said, "Okay, what's that?" He said, "One or two-day tasks that are either done or not done. And if you, instead of thinking about milestones, think inch pebbles." And I have used inch pebbles in my entire career. They now look like one or two-day stories. And if you always have a one or two-day story, and even if you have to have the entire team collaborate by swarming or pairing or mobbing, I don't care. But if the team finishes something every day or two, your feedback loops are sufficiently short that you can do almost anything and get really good feedback from your customers.
Kumar: I love that. That's really interesting. Actionable advice, right? So keep your story small to reduce the feedback loop and get feedback as quickly as possible. One to two days. I think that's really, really good. All right, I'm going to shift to writing books. So you've written over 20 books and now you help others write their books. What's the secret to keep—to maintain that level of productivity? Is it feedback loops?
Johanna: Yes, but these feedback loops are for myself. So I do several things. I have a spreadsheet of my word counts. I have four kinds of major writing. I have a spreadsheet for every single day of the year of where I write in any of those. And I get credit for all my words. So I have a books column, a blog and newsletter column, my Create Adaptable Life blog and newsletter column, and my fiction column. And I have that for every single day of the year. And so I can see, am I falling off my writing pace? And if so, what do I want to do about it, right? So this is specific data for me. I don't share—I mean, I cannot imagine sharing my spreadsheet of actual data. Why wouldn't I, right? There are always going to be people who write more and faster, and there are always going to be people who write less and slower. I don't care. I'm not going to compare myself with anybody. All I know is I want to have this kind of a pace with my writing.
And I find that, so my spreadsheet works really well for me. I can tell if I'm on a streak or not. And the other thing I do is I used to start writing when I had time in the afternoon. Most of us don't have time at all. So instead, I started to write in the morning. And my morning pages are now sacrosanct. I don't have to write a lot. I have minimums for my fiction writing and minimums for my nonfiction writing. But as long as I get my morning pages done, I'm happy. Other people might want evening pages. Other people might want noontide pages. I don't care, right? This is the idea of we spend our lives doing the things we spend our lives doing. There's a quote about that. I don't know who said that. Maybe I'll find it later and send it to you. But if we think this thing is important, then we will make time to do it.
Kumar: Yeah, you're so right. So it's about cadence. It's about putting on the calendar, setting the time aside. And then I think you said something really important—having some feedback mechanisms, some metrics that help you gauge your own progress, right?
Johanna: Right.
Kumar: Towards the goal, whatever the goal is. I love that. Yeah, I aim to write something at some point in my life and I never make the time, but I'm going to try that. I'm going to try the morning. I think I would probably be a better morning writer than afternoon writer or evening writer. I'm going to give that a shot.
Johanna: There are a couple of things you might consider. One is when I teach my nonfiction writing class, which I will be teaching again in January, I only ask people to write for 15 minutes at a time. Almost everybody can make 15 minutes, right? Because it's a short enough period of time. And if they can't make 15, I ask them for 10. And if they can't make 10, I ask them for five. Almost everybody can write straight for five minutes. The other thing I recommend is a book by Dan Pink called When, which talks about the science of when you can do these things and when you are putting barriers in your own way. So When is an excellent book.
Kumar: Wonderful. I'll have to get that. It sounds like it. I mean, anything by Dan Pink is probably a wonderful book. Wouldn't you say?
Johanna: Yeah.
Kumar: Yeah. All right. We're getting towards the end of our time together, but I do want to ask you one more question. And this is about the self-management paradox, right? The first book in your trilogy focuses on managers managing themselves before managing others. And I actually—your advice on writing kind of sums it up. You figured out a way to manage yourself when it comes to writing, I'm sure in other areas of your career, in your life. So I thought I would make the time to ask this. This feels like it's a necessary disruption in how we typically think about leadership, where we think about leaders as people telling other people what to do. What you're saying is, no, it's not about that—it's how you manage yourself. Why is self-management so overlooked, and what's at stake when leaders, managers skip this, I would say, foundational behavior?
Johanna: So it's very easy for people to read into our reactions as leaders, especially as titled leaders in the organization. So I once got feedback from a very, very smart VP. He had watched me as a program manager frown when somebody offered me bad news. I was frowning at the bad news, not at the person. But my VP thought I was frowning at the person. So I said, "Oh, no, I want the bad news. I want the bad news as soon as possible." So I immediately went to the guy and said, "I was frowning at the bad news. I was not frowning at you. Are you okay with me? I do not—I want nothing in between your bad news and me. Don't wait to tell me. Tell me as soon as you think you have bad news." He said, "Oh, JR, I know you."
But it was so important for me to do that because otherwise people magnify what a titled leader's reactions are. And if we don't admit when we're wrong, if we don't admit when we need help, if we are not welcoming bad news, we are not managing ourselves. Now, nobody is perfect. Me least of all. So I never say to anybody, "You have to be perfect." But if we are trying, the people around us see that we are trying. That makes all the difference.
Kumar: Yeah. Beautiful. Love it. Was that the best career advice you ever received?
Johanna: I think—well, the other really good career advice was "I don't finish projects." Now I have a checklist so I can finish things. I really hate finishing. I have a ton of starting energy. Finishing energy—oh, my God.
Kumar: Yeah.
Johanna: And the third piece of career advice that really helped was when one of my managers said to me, "You know, JR, when you talk to people so they can hear you, they are much more likely to take your advice instead of being snarky."
Kumar: Is that what you go by, JR?
Johanna: I often refer to myself as JR in my books because that has been my nickname. It's my email handle. Yeah, it's been my nickname for many, many, many decades.
Kumar: Okay, well, that's good to know. Fiction or nonfiction, which is harder to write and why?
Johanna: Right now it's fiction because I'm learning how to write it. I can settle into nonfiction, write a thousand words, you know, have that be easy. Writing a thousand words of fiction, I'm still getting what's called setting and depth. How do I describe what the characters feel? Where are they in the world? How do I make this world realistic to every single person who reads this?
Kumar: I imagine that would be really hard. I've never tried. I mean, I've written blog articles, but that's about the extent of it. We'll do one more, maybe two more questions. I mean, we could talk all pretty much all evening. I'm enjoying this so much. I got the time. I got to walk the dog. He's like looking at me funny. If you could eliminate one agile practice from existence, what would it be?
Johanna: Practice standups. I think a standup is a useless piece of information because if we're collaborating, we already know what we're doing. If we are working individually, we are probably not exhibiting nearly as much agility. So it's a crutch. A standup is a crutch.
Kumar: It's a crutch. I love that. Okay. All right, just because I said I could talk to you all night, I'm going to ask you one more question. One management trend you wish would just die already.
Johanna: Oh, well, performance management. I mean, we have decades of data—I mean, literal data—that says managing performance is useless. Yes, people need feedback, but managing performance is useless. And the problem with managing performance is it leads to rank and yank, right? Or stack ranking, or winner—right? Stack ranking. I don't understand how anybody can think that all of us individually can be ranked against anybody else in the organization. I mean, there are teams. And the environment is so—I mean, Kurt Lewin actually said everyone's performance is a function of the environment applied to their behavior. Environment matters so, so much more. So if I could get rid of performance management and stack ranking and rank and yank and all that nonsense, that's theater applied to cost of goods sold. If you want to reduce cost of goods sold, then reduce the wait time between all of the steps in the process. You will get much faster throughput. That allows you to sell more stuff.
Kumar: I love that. Yeah. Do you have any questions for me or any closing thoughts before we end our session together?
Johanna: So I have really enjoyed both of our conversations. For those of you who are listening, we had a pre-conversation. You wanted to make sure I would say something entertaining. You did. It was very useful. I think many people are going to find a lot of use in this conversation, so I thank you for that.
Kumar: Well, thank you. And when did you start this podcast and recording and all this stuff? What did you learn from it?
Johanna: Kind of an evolution. I started this maybe three years ago with my partners at Agile Meridian. And it was just sort of a whim. Let's get on YouTube. Let's talk about stuff that we're passionate about. That lasted maybe a year and a half or so. And my partners got tired of coming on the show and talking about the same things. And so I—well, we have this pattern that we call the Disruptor Method, and it's a lot of what you've written about that we've tried to put into practice in terms of management style, in terms of collaboration patterns, in terms of visibility of the work and how you motivate and lead people and all that stuff. So Disruptor Method is meant to disrupt how leaders behave with one another. So rather than individuals, we want to disrupt them to work more as a team.
And so I thought, well, why don't I just talk to people about disruption and innovation and how these two things are so closely tied to one another and how one leads to the other in some way, form, or another. If you innovate, you're bound to disrupt something if the idea is sound enough. Or if you're being disrupted, then the way to survive that is to innovate out of that disruption in some way. So that's where this idea was born, the Disruption Podcast, to talk about how people handle disruption, how they handle innovation. And you're sort of like an amazing example of that—that you're constantly reinventing yourself in some way by writing, by sharing your thoughts, by blogs, by the consulting practice that you do, by sort of simplifying these agile methods to, "Hey, it's just about the feedback, you know, shorten the feedback loop." And so I love that. And I love doing this because I get to meet people like you and share the story. And if you could say one thing you've learned that everybody should know, what is that one thing?
Kumar: I've learned how to listen better. So I've, you know, for these podcasts, I prepare a set of questions. And as I've gotten—I think I've gotten better at it—I've learned just to trust my ears more than my eyes and just listen, you know, and the questions will come. The right question will come that stimulates a conversation forward. And that's not just true for the podcast. I mean, I've used that lesson to help me in my coaching, one-on-one coaching or team coaching, leadership coaching, whatever it might be.
Johanna: I love that. Yeah.
Kumar: Well, folks, that's a wrap. Thank you so much for watching. I really enjoyed having you on the show, JR. And if you're open, we should do this again in the near future.
Johanna: I would love to.
Kumar: Awesome. That's great. Well, thank you so much for watching and joining us. And we'll see you all in a couple of weeks. Bye-bye.
