← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
CTO Series: Navigating Growth, A Playbook for Scaling Engineering Teams With Toni Ala-Piirto
00:41:10
CTO Series: Navigating Growth, A Playbook for Scaling Engineering Teams With Toni Ala-Piirto In this BONUS episode, we dive into the journey of Toni Ala-Piirto, a seasoned software leader with 15 years of experience designing and implementing...
Loading summary
Transcript59 lines
- [00:04]
Vasco Duarte
Hey, how are you doing? I'm Vasco Duarte, your host on the Scrum Master Toolbox podcast. And I've got some exciting news. So right now, as I record this, I'm holding in my hand the signed contract for our very first Global Agile Summit. We're all in and I couldn't wait to share this news with you. So mark your calendars. May 18th, 20th of 2025 in Tallinn, Estonia. We're gonna have a transformative experience. We're putting together an event that is all about real life Agile. It's not theory or buzzwords. It's practitioners sharing what's working, what's making an impact, and how they've overcome challenges that you too will have to face, or maybe even facing. Right now, we're bringing together the best stories in Agile. From product leaders to engineering wizards to business visionaries, these will be stories that will inspire you to action. This isn't just another conference. It's a chance to connect with the people that are shaping the future of Agile. And here's the best part. Right now, we're in our super early bird phase. And that means you can grab tickets at just 25% of the final price. Look, that's not just half off, it's half off of the half off. It's an incredible deal for our dedicated community members, just like you listening to this right now. So at the summit, day one will be all about hands on workshops. And days two and three, we'll dive into leadership, product strategy, coding, testing, and everything that makes Agile thrive in organizations. Right now remember, these are all first person, real life stories. Now whether you're a leader, a developer, or part of a consulting company, this event is built to take your Agile game to the next level. So don't wait. Go to globalagilesummit.com and grab your ticket. Today, let's all make 2025 the year agile truly transforms your teams, your business and our industry. I'll see you all in Tallinn. And Remember, go to globalagilesummit.com and get your super early bird ticket right now. It only be available until the agenda is announced, so don't wait. Grab it right now. Right now that that's out of the way, onto the episode. Hello everybody. Welcome to one more episode in our CTO series. For this episode, I have the pleasure of welcoming an old colleague, Tony Allapirto. Hey Tony, welcome to the show.
- [02:53]
Tony Allapirto
Hey Vasco, pleasure to be here.
- [02:55]
Vasco Duarte
So I met Tony many years ago and between the time we met and now, he's of course evolved very much. He has more than 15 years experience in leading architecture and design for projects of all sizes. He excels in creating practical fit for purpose distributed systems. And he's known for his hands on approach, I can vouch for that. And commitment to improvement. Tony consistently delivers solutions that meet specific project needs effectively. So Tony, that was a short intro. When you think about your career and Those more than 15 years working in the business, can you share a pivotal moment, something that you think really defined your approach to your role as a cto, of course, but also to leadership and technology in general?
- [03:44]
Tony Allapirto
Yeah, that's an excellent question. And it's hard for me to find a single people at our moment. I think it's the whole journey that actually has defined my approach. And then of course there's been more significant events during that time, but there's been multiple of those. And maybe kind of as an example, on one case they had a really difficult performance issue on large customer that I went and helped on resolving it. And that was a production system that wasn't scaling where it needed to scale. And that was one moment of realization that even you think there's problems logically and steps to go through those. It seems that quite often people tend to focus on day part of the issue, they part of the system and they don't step back and view the whole issue, the whole system. And that's kind of been my approach, maybe a little bit before that already, but also after that I always try to step back and see the whole picture. In this specific occasion I end up helping a team in France and I was supposed to be there for two days, ended up being four weeks, but that's how it goes. And we did resolve the issue.
- [05:21]
Vasco Duarte
Absolutely. I mean it was a surprise already the moment you decided maybe I shouldn't go back to my home office and stay here with the team and try to help. When you think about this stepping back, kind of seeing the whole, as you said, what do you think keeps people, and of course now specifically the people you are leading as a cto, what do you think keeps people focused on those like small areas or as you said, their own part or their own contribution to the system? What keeps people focused on the smaller aspects rather than stepping back, as you say.
- [06:03]
Tony Allapirto
Robert, there's multitude of reasons for that, but what I've seen is that they actually want to excel in their job. It's not about that. And they want to do their thing really, really good, really carefully. And at the same time these people typically collaborate really well. They talk to each other, but it's just like taking that time, stepping back and thinking kind of the bigger picture might be that they haven't got enough encouragement to do that. They think that it's someone else's job to actually handle it. And those kind of things are maybe held back and it's kind of then also nudging people on that direction that hey, there's always this wider responsibility, wider picture that you can take care of.
- [06:56]
Vasco Duarte
I think that's very well said. Very often in agile teams we talk about thinking holistically, looking at what the customers need. And as you said, maybe there are people who were never encouraged to do that. Right. They were held accountable for what they did, but they were not encouraged to think about the wider consequences and potentially things that have nothing to do with the work they did. Right. Because in software it's not about what I do, it's about what the customer can do with the product we're giving them.
- [07:27]
Tony Allapirto
Right, yeah.
- [07:31]
Vasco Duarte
Yeah, go ahead, go ahead.
- [07:32]
Tony Allapirto
Yeah, I was just about to continue maybe on the leadership style and I've been wondering that and I would describe that one as a boring. My style is boring. And there's a TED talk that you can go and see about boring leadership style. And that would be describing to some extent how I tend to work. And that's, that's basically thinking ahead, preparing for the things, making sure that you don't end up in that hot water and then kind of go to the crisis mode because of that. So trying to avoid the crisis mode and creating environment where we can sustain the kind of the rate of progress that we are doing.
- [08:22]
Vasco Duarte
That's actually a good point that maybe it looks boring from the outside. But of course when you are think worst case scenarios and working with the team to find out solutions to avoid those worst case scenarios, of course that's not boring at all. Right. But from the outside it might look like, okay, there's no ups and downs, it's all kind of flowing nicely and no, no big problems. But how do you keep yourself grounded though? Because one of the things that I see is that, and of course I know you have seen this because we both come from a security industry perspective, it security that is, and there's a lot of paranoia there for good reason. Right. But you can take it too far. You can take it so far that the focus on performance, sorry, on security, ends up removing the possibility to have the performance you need for the customer. So how do you keep yourself grounded so that you don't worry too much about what might be happening. But you do you know your due diligence and think about potential side effects and negative events and so on, but not so much that it would prevent you from progressing.
- [09:37]
Tony Allapirto
That's an excellent question. Like on the security front, thinking my background on those security oriented companies and then being working in other places and to my surprise, these other companies that are not actually security companies might be way more cautious about their security and they actually overdo it because they don't know better. They actually overdo it. And from that perspective it's always hard to find the balance and kind of keep deep what is the right level. But it's kind of the same way as us in any kind of threat. I'm not saying that this is kind of what I actively do and have this magic quadrant map that hey, what's the kind of severity of these things that can happen and what. But it's the kind of the game that goes on my mind. What I have discussion with my colleagues, with my team members and trying to gauge that what kind of things that we haven't taken into account yet and might impact us in the future. And when we take risk, because it is risk taking. So when we take a risk, we know the risk that we take and we have done that knowingly. That's the most important part. Like if you don't know that you are taking a risk, then you might end up in bad situation. But there's always like don't create perfect software, there's always bugs, there's always things that we know that we should do better, we could do better. But in those occasions it's most important thing is that you know that you are taking the risk.
- [11:32]
Vasco Duarte
And that's actually something that speaks to my heart. Being an ex project manager, I definitely think about it in those terms as well. Right. Like we need to take risks. There's no progress without risks. But we need to be careful about what risk we choose to take. There are some we take without knowing, but we need to be careful about the ones we choose to take. Now one of the things you talked about is the ability to step back and looking at the holistic picture. And of course you need to do the same from your role as a cto. So can you describe some of the key processes that you've implemented in your work to ensure that the technology strategy that you are responsible for supports and aligns with the broader business objectives, but also keeps you agile enough to adapt to changes? Because of course the business objectives of today will be disrupted by a big customer of tomorrow. And that's just the fact of business.
- [12:29]
Tony Allapirto
Yeah, that's going with the business objectives. That translates to. Well, not business objective but first we start from the strategy on the company level. Taking a product vision that will basically, basically drive towards the. And with that product vision, creating the technology vision that will basically achieve our goals on the business objectives. And that requires constant collaboration with the product management, CEO, sales and of course finance and HR too. But I think how I've been doing it is that there's really, really tight cooperation with the product management and head of the product management. That we are constantly in sync and the kind of. We know that what are required from the in both ways that what is required by the product and what should we take care on the technology part and then we can shunk those roadmaps. And there's less of course there's always. But there's less kind of this back and forth like where should we spend the resources more on the new features or than on some technological improvements.
- [13:57]
Vasco Duarte
So for our clarity in your organization, currently the product organization is separate or on the side of the technology organization, right?
- [14:10]
Tony Allapirto
Correct. That's on the side, yes.
- [14:12]
Vasco Duarte
Because there are some. And we have actually one interview, one of the first interviews in this series we interviewed a CTO who was also the chief product officer. So they had merged both product and technology in order to try to create that tight collaboration that you were just talking about. So Tony, what have you learned about making sure that that collaboration isn't just a goal, but it is actually happening in practice?
- [14:40]
Tony Allapirto
I think really helping that situation is that we have already like trust and working history between the head of the current product management and we actually really know well each other. Meaning that the collaboration is natural. We don't need to have these kind of scheduled meetings to make it happen. It happens daily basis. And that kind of getting it on that level really helps. But then processes, of course we have also processes within the company and that's not the only way you need to collaborate. There's operations that you need to collaborate with, then there's sales as mentioned. And for those purposes we have these weekly syngap meetings and then also management team meetings where that collaboration then happens and topics are brought up when need to be.
- [15:39]
Vasco Duarte
So if I understand correctly, your recipe, if we could call it that way, is of course establish a good relationship with the product counterpart and then with the other parts of the organization. Make sure that you have regular and you said weekly check ins or discussions about what is going on and also where the company is going.
- [16:00]
Tony Allapirto
Yeah.
- [16:01]
Vasco Duarte
And if I understood correctly, you also said that there's an overall strategy, right. That kind of orient this collaboration that needs to happen all the way down to the daily level. As we discussed, how do you make sure that the technology part is heard when defining the overall company strategy? Because of course you are working in a company that depends on technology to sell its products, but of course it needs to sell to businesses that have all kinds of needs and ideas about what they need and so on. So how do you make sure that the CTO role in your case and the technology department is not a silent member of defining the strategy, but it's actually an active and influential member of defining the strategy for the company.
- [16:53]
Tony Allapirto
When it comes in the company strategy that typically of course that gets adjusted time to time, so it's defined for three to five years, but then it gets adjusted all the time. And as we learn and go about. But in this kind of business, to business sales, I'm a bit diverging from the question, but I think the crucial thing is that we sell what we have. We are product house, we sell what we have, we don't sell what we have in the future. So that's very clear. And then taking that into account, that what we need to be competitive, we have the product vision. What's the technology that needs to be achieving that product vision. Then there's the innovation side on the technology side and bringing those innovations that come up, then also having that flow in there. But specifically when it comes to in strategy, on the company level strategy, I would say that there's no, it's not the technology vision impacting that strategy so much, but it's we built the technology vision to support our strategy. That's my approach more to it.
- [18:28]
Vasco Duarte
And when you think about building that technology vision together with business, supporting the company strategy, of course we need to create very good collaboration between tech and business because of course the company strategy will be influenced by what is possible on the technology side. So how do you make sure that your business counterparts, say sales or the CEO or somebody who is developing the strategy, how do you make sure that they are aware of the possibilities that are there from a technology, technology side regarding the future?
- [19:04]
Tony Allapirto
And I would say that that comes more towards road mapping in my perspective that we are getting something concrete already out of it, that what's possible, what can be done strategy is bit more high level in our context. Kind of where we want to be, which type of customers and which segments and which kind of problems we want to be solving, then there's going to be the technology strategy that helps to kind of solve those issues that we identified. If we don't have a solution for it, how can we approach and build that solution? And that's aligned with the product vision there. So I don't think that this. So then it comes to roadmaping and kind of building the roadmap. Me the question. I started talking too much.
- [20:08]
Vasco Duarte
Yeah, no, no. I think that what you said is very important. I'm just going to reiterate, right. Like, do you have this roadmapping process that kind of helps business and technology collaborate? There's two aspects to it, which is discussing customer segments and problems to solve and then using the technology strategy as a space to look for solutions to those selected problems together with the product vision. This is what I heard. What is the roadmap process that you have currently? So you said that strategy is for the next three to five years, gets updated regularly, I imagine at least once a year. But how do you then run the roadmapping process together with your product counterpart and doing of course the collaboration with the business side, which is the original question.
- [20:56]
Tony Allapirto
Yeah, that's where we have these frequent sessions basically to identify. So we have six months basically roadmap that what we want to achieve in a more detailed level. And going past the six months, it gets more and more sparse, more on the vision level that these are the things that we want months to achieve. Then six months is the point where we actually have more defined how we want to achieve it. And that's where the planning effort goes. And from the RD perspective, it goes from that six month roadmap to three month roadmap where RD is actually already planning, estimating those epics. And there we have good visibility what we can achieve on the next three months. Six months is already on the ballpark level. And then past that, it's more on the vision level that what's going to happen. Of course we use the teams and we use our experience then to kind of roughly point those things in time. But we don't want to waste too much cycles on trying to have accurate estimates that when something is out in next year, when in fact probably we don't even do it, we are doing something else.
- [22:27]
Vasco Duarte
Yeah, that's actually a very good point. So I hear you have kind of three horizons, right? We have beyond six months where everything is kind of just on the vision level, I think was the word to use. Then the next six months, which is more towards. And this I Want to validate, did you say the problems we want to solve or the solutions we want to present?
- [22:46]
Tony Allapirto
Problems we want to solve. So solutions are then invented for the problems, but problems we want to solve.
- [22:53]
Vasco Duarte
Yeah. And then for the three months you are talking for the next three months or the subsequent three months you are talking already about solutions. You call them epics and you give them rough cost or estimates for those epics. And when you think about these three horizons, like I'm thinking, right. From a technology perspective, the first horizon is the most important, right. Like you know, the next three months. But of course that doesn't help you to figure out who to hire because it often takes like three, four months just to find people that you might be able to hire. So how do you keep that part in mind? Because that's also part of your role as a cto, right, Developing the organization. So how do you bring that part into the discussions with the roadmap?
- [23:42]
Tony Allapirto
Yeah, and that's the key part. Like, and that already comes to the company strategy that where we want to be in three years and we are in situation where we are doing this for next three years. We have already estimate on the kind of how we want to grow organization, our revenue estimates on three years horizon, what it means for the organization and what kind of talents we need. How do we need to adjust the organization and how that's basically how we do it. And that regards that we do have certain idea that how we want to invest on these items that we are doing in the field. So it's not anymore so much that how much it costs to implement something. It's on the level that how much we want to invest to create those things.
- [24:43]
Vasco Duarte
Yeah, that's a very important distinction. Right. Because it's not about what does it cost, it's about how much are we willing to lose. Or thinking more like from an investment perspective, right?
- [24:53]
Tony Allapirto
Yeah.
- [24:55]
Vasco Duarte
So when you talk about this like three year, five year strategy level anyway, then one of the aspects that often comes into the discussion is scaling the engineering team. Now I happen to know, because we've talked before, that you started with a very small team, but when the business goes well, there are periods of rapid growth that kind of bring really difficult challenges. So what strategies have you, Tony, employed to manage and nurture the team, but also to grow the team when it needs to scale in terms of number of people on the team?
- [25:32]
Tony Allapirto
For me, the starting point was a really small team, few persons, and we actually had to aggressively start creating a new product and a new version or Re architecting the product because of knowing risk, technical depth that that was taken. And the most painful thing about that was that to get quickly started, you take consultants, that's the fast route. But it means that those few people that exist within the company, they need to do the domain knowledge transfer, photos, new employees, not the technical one, but the domain knowledge. And then you need to do it again for your own employees once you had time to actually do the recruitment and hire those people. So for that, that's been kind of the sole one of the biggest issues, how to actually keep everyone productive and understanding and productive. I mean, on the level that not just someone else specifying what you need to be doing, but they can specify themselves based on the problem. And that requires product understanding. And that's been our key problem to get new people up to speed, understanding the product as quickly as possible. And we employed several techniques, of course, the zero normal trainings, documentation, etc. But then one of the good things have been this kind of test body. So we put people to test things and they test it together with someone who has already good domain knowledge and knows the products really well. And they actually then help this other person to do the testing, not saying what to do, but help them to accomplish. And that way getting to know the product.
- [27:25]
Vasco Duarte
So it was almost like pair testing where the new person is taking the lead and the experienced person is kind of helping them to reflect and to find the things that they need to find.
- [27:36]
Tony Allapirto
Exactly. And as you know, I'm mainly talking about developers in here and those are not always keen to do the testing part in any way. But as it happens to be, there's no testers within the company, there's no QA organization, so that's the way to go. That's the part of your role that you need to do.
- [27:56]
Vasco Duarte
Yeah. And of course when you're testing, your mindset is of learning, exploring. So it puts you already in that position of wanting to know the product better and finding, I'm sure, a lot of things that need to be changed and then being committed to those as well. Right, like really wanting to make the product better.
- [28:13]
Tony Allapirto
Exactly. And then you truly understand it. Like it's different thing. Like it's surprising how people quite often they implement something and they don't actually know how to use it. They've been doing part of the work, making something on the background that that does the business logic, but it's not on the front end and they don't actually know how to do it. So that's the way that you have to use the product. You get to use the product and then you know how it functions.
- [28:46]
Vasco Duarte
Absolutely. And if you know how to use the product, then you get more ideas. And it goes back to that idea that you were mentioning a minute ago, is that these are not people who sit down and implement somebody else's specification. These are people who are then ready to create the specifications, given a definition of a problem to be solved.
- [29:05]
Tony Allapirto
Yeah. And that's the way then how we can start scaling. Because you have teams of those people that are capable of taking new persons in and it doesn't impact. They have ways to learn that new person to understand the product.
- [29:23]
Vasco Duarte
Yeah, exactly. So that the new people actually come in. But there's already a way to integrate them. Right. They don't start by being alone and reading documents, but they start by testing together and learning the product, of course, with the help of the documents and the test body that they have and then being able to participate much quicker in the productive work. Like for example, going from testing to helping somebody else specify or doing pair programming sessions or whatever.
- [29:51]
Tony Allapirto
Yeah, exactly. And those are of course the normal ways of doing kind of understanding then the in depth the code and how things are working in there and. But that's what's lacking in my past experience, that even if you get to understand the code, there's no one really trying to get you to understand the product.
- [30:19]
Vasco Duarte
Yeah. And that's critical. Get your people to understand the product, not just the code.
- [30:26]
Tony Allapirto
Yeah.
- [30:27]
Vasco Duarte
So of course we've talked already about a lot of topics, but I always like to ask this question because everybody's experience is different. Tony, in your experience, what's the biggest challenge you faced in your career and how did you overcome it?
- [30:47]
Tony Allapirto
That's a tough question. It goes to the same category of the pivotal moments that what's the biggest challenge? I might not be able to name one single biggest one, but I think this organization scaling that I was just talking about, I think that truly is one of those that starting from the small one and starting to scale it and how to make it fast, how to get the people productive, that's been really challenging. Now that there's already this mass, it's easier to add new people, it's incremental. But when you double, triple, quadruple the size, that's really the challenging part. Now the scaling is that much easier. And there's other side of that thing also, which is one of the big challenges is that there's pre existing culture within the company. But when you Double the size with new employees. That changes the culture. They bring their own one. That changes the culture because suddenly they don't have the same culture that they are coming from the different places. And how do you keep those good practices and good culture ongoing? Nurture that. That's been kind of one of the challenges. Still is. And same it goes for the recruitment side of the thing. There's plenty of good talent and you can get good talent. What I'm finding really challenging, in addition of those technical skills, how do you find the people that have really that drive to make everything better, not just do their job, but make everything better around them and also take responsibility on it? That's the equation that I still want to crack. That, hey, how do you find that and that talent? It's not that obvious for me yet.
- [32:59]
Vasco Duarte
And actually that rings a point in my mind that there's a lot of people who know how to code and the majority of them can learn to do it better, but there's a lot less people that not just want to know how to know and code well, but actually want to overall do a good job and are committed to it. Right. Like we very often hear, especially in the, you know, CTO and CEO circles about, you know, if your people are not. If the parking lot is empty at 4 o'clock, you have the wrong people. Well, maybe that's a possibility, but there's also another possibility, which is that we are not looking for those people that are committed and can do it in the eight hours of work that we are actually paying them to do.
- [33:46]
Tony Allapirto
Right.
- [33:46]
Vasco Duarte
Because you know, and I know as well that there's people who, who go. And there's somebody who was a mutual colleague and now also a CTO who whenever he went into a problem, he made the code better. He added functionality and reduced the number of lines of code in the product in the process. Right. Like he was one of those guys that really wanted to make things better all the time. And those are kind of multipliers in terms of productivity for the whole team. Right. Because they leave everything much better and then everybody has a much easier job to work on that same code base.
- [34:26]
Tony Allapirto
Exactly. And they also help others to do that. They kind of drive the whole team performance upwards when you have such people in your team. So that really is a crucial part to find those right individuals in right positions. Of course, you need the people on all the levels from junior to lead, and that's where you need to have the balance also so that you have kind of different type of ideas and also from different generations.
- [34:57]
Vasco Duarte
And also from different generations. Because they bring different values, of course, different level of experience and so on. Now I want to ask the next question because I mean, I know you for many years and we worked in the same projects for a few years and then you moved on and did other projects. I did the same. And we have similar background because we did work together at some point, but then we also have a lot of different experiences with different products, different teams. And you developed your own thought of what would be a leadership position in an R and D organization. So in this case the CTO role. When you think about that, like what you thought about the CTO position before and what it is now that you're, you know, finally in that position, what, what was the biggest surprise for you that came with the CTO role?
- [35:59]
Tony Allapirto
Maybe the biggest surprise is, is coming from the fact that you, when, when you are not in, in, in this role, when, when you are in, in development team, your exposure, the other side of the business is rather minimalistic. You don't get to be part of those discussions and kind of working with, kind of day to day with cross functional teams or team in this case. And that kind of is maybe the time that you don't typically see what CTOs are spending in there and, and doing kind of synchronization, company level planning and also the organization planning. So maybe that side has been something that's been hidden from me. I'm not sure if that was a surprise as a such, but it's something that, it's a learning journey for me.
- [37:08]
Vasco Duarte
Yeah, absolutely. And as it was before at the development team level, when you were a developer, there's a lot of getting to know people, getting to interact with them, getting to understand where they're going. But of course then when you go to a leadership position, it's all of that plus the fact that we are also learning new skills. Right. Because we need to talk to the CEO, we need to talk to sales directors, we need to talk to customers, we need to talk to the people on the product side and all of those are slightly different conversations that we need to learn as we grow into this kind of positions. Tony, it's been a pleasure. It's really great to reconnect and of course to hear those stories. Before we go, I did want to ask you, like now that you've been a while in the CTO role in a leadership position for a technology organization, what was the book that most influenced you in your approach to this role?
- [38:07]
Tony Allapirto
I'd say I'd say that it's something that I read rather recently that's been on my mind and that's the Five Dysfunctions of a Team. And that's Patrick Emlenzioni's book. And that actually it's not a long reading, it's rather short. So you have, you can easily, easily take or listen that in as audiobook for a few hours. But I think that has been really impactful on kind of understanding how the kind of to have that commitment from everyone. What are the kind and accountability, what are the kind of pillars that you need to build? Starting from the trust. And that's kind of. And when talking about accountability, people understand that differently. And that book has one definition, definition and what it means in the business context and in a such I would recommend that for everyone to read like you can get some good insights from it.
- [39:18]
Vasco Duarte
Yeah, and you definitely need one definition of accountability in a team because otherwise you can't hold each other accountable in a team. And of course this is true for any team in any organization, whether it is C level team, front level team, whatever that is. All right, Tony, if people want to know more about you and the work that you're doing, where should they go?
- [39:42]
Tony Allapirto
That's a good question. They should find me. They should contact me because I. But only place to find me at the Moment is in LinkedIn and I have to say that I'm not that active. So LinkedIn is the best place.
- [39:56]
Vasco Duarte
Yeah, absolutely. So check it out and why not send a few follow up questions to Tony? Tony, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [40:06]
Tony Allapirto
Thank you, Vasko. It was a pleasure.
- [40:13]
Vasco Duarte
Oh boy, I bet you are buzzing with ideas after listening to this episode. I know I was. Now there are so many ways we can help the leaders we work with. So I hope this episode helped you get some of those ideas going and getting inspired hopefully also to take action. That's what matters in the end. Don't forget that. Now, if you want to check out the key lessons from this episode, check out the show notes@scrummastertoolbox.org but for now I'll say goodbye and see you in the next episode. We really hope you liked our show and if you did, why not rate this podcast on Stitcher or itunes, Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.