← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
CTO Series: Scaling Engineering Teams and Aligning Tech with Business Goals With Toni Sallanmaa
00:40:34
CTO Series: Toni Sallanmaa on Scaling Engineering Teams and Aligning Tech with Business Goals In this BONUS episode, we explore the journey of scaling technology teams and maintaining alignment between engineering and business objectives with Toni...
Loading summary
Transcript63 lines
- [00:04]
Vasco
Hey there, agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
- [01:12]
Podcast Host
Hello everybody. Welcome to one more episode of our CTO series where we interview technology leaders to share their journey and lessons learned, which of course helps us all who work with software development. And for this episode we have with us Tony Salonma. Hey Tony, welcome to the show.
- [01:31]
Tony Salonma
Hello, nice to be here.
- [01:33]
Podcast Host
Let me introduce Tony shortly. He leads technology and engineering at Funidata developing SISU, a cutting edge student information system serving over 100,000 Finnish university users. He's passionate about agile methodologies, system architecture and software engineering. And he specializes in technology management, software lifecycle, object oriented programming and relational databases to deliver innovative scalable solutions to higher education. So, Tony, let's take a dive into perhaps a significant moment. Of course, none of us starts as a cto. We get there at some point, but we don't start there. And I'm sure there is in your story a pivotal moment, something that happened with you or around you that kind of shaped your approach to leadership and technology. What was that moment, Tony?
- [02:34]
Tony Salonma
I think I've been working with the large scale Systems for around 15 to 20 years with ERPs and so forth. So I think if I reflect back on my career, one of the pivotal moments, I would think, is that when I first got into a position, a senior development position, where I had influence over the technical decisions, influence over how we develop our solutions, that probably influenced most of what I do today, since that was the thing where it became really concrete that as a agile team, we are responsible for our product, its life cycle, its users, its data security, everything. So that's when it really clicked that everything we do has a Huge impact on everything else, even when we discount the actual product decisions. But everything underlying is really, really important to high functioning business anyway. And then you still add the product development perspectives on that.
- [03:41]
Podcast Host
For me, one of the things that comes from that story is this importance in software businesses specifically to have a little bit of, I guess we could call it having a foot in both worlds, right? Like on the business side as well as on the technology side. Is that how you would describe?
- [03:59]
Tony Salonma
Yes, I think I am always been really interested on what we do, what's the actual business we are running. I'm not only interested in technology and how it's being run. I need to know what we are doing, who are we doing it for. That's the thing that actually adds meaning to the work. Technology is fine on its own, but still it's not fulfilling enough without the actual users in it. So I think the most. If I would need to pick one attribute to having a person in a position like this, I would pick out infinite curiosity. Since there is so much to learn. There is so many things that you can put your nose into and find out how things work. So I think that's the key point for successful strategy and product development.
- [04:57]
Podcast Host
I really like how you describe that infinite curiosity because there is indeed so much to learn, so much to learn when it comes to technology, so much to work when it comes to learn when it comes to business, but also so much to learn when it comes to what processes make sense, how people collaborate. When you think about how you've developed your approach to how you run the technology, the engineering side of your business right now, what are the key processes that you've implemented to make sure that your technology strategy aligns with exactly that other area. Right, like the business objectives, but while still remaining agile enough to adapt to changes.
- [05:41]
Tony Salonma
Yeah, sure. We've started with Funny Data as a quite small company with, with a handful of developers and product people and we've grown from there. We are currently somewhere around 70 people, so we, we've seen a transformation. When you are small, this is really easy because you probably are in the same space or you can be on the same call all the time. You know everyone intimately and the challenges start appearing once people are doing different things. But I think the most critical thing is to have on all levels of your organization that you do not have a strict separation of technology and engineering and the product development or product related functions. There's a reason the product owner is a part of an agile team. I think you need to embrace that in every aspect of your organization, how you approach your engineering decisions as well involve people, have their input into what you are doing, then you'll understand your users, you understand your business, you can make better decisions. And if you think about the future, you need to have a roadmap to see what kind of technological improvements you can take into use. What's AI going to do for us? All of those things, those are in a vacuum, those are really difficult to do. You need to know your business and you probably cannot know your business intimately. I haven't been in education business ever myself. I've gone through schools, but I haven't been on the administration side. So I need people who can tell me how this works so I can apply that knowledge. And finally to your question that how you stay agile enough, I think it's also in roadmapping or planning stages on most, most companies do a roadmap of some kind. And I think that's where the magic happens that you do not set your roadmaps so that it changed you. You have put your roadmap for next year or some other period of time and that doesn't allow you to make changes if the situation arises. So you need to stay agile there to have agility in your actual operations. Because hopefully you roadmap most of your business, the things that are not features as well as the actual customer facing features and so forth.
- [08:17]
Podcast Host
Okay, so there's a couple of topics there that I would like to explore. First, starting with this idea that you can't separate technology from product. You mentioned that in the context of understanding where the business is going so that the roadmap kind of follows that business, if I understand correctly. But how do you implement that in practice? How do you bring the people with the, you know, facing the educational institutions thinking about product and the people in the engineering department because they very often they speak very different languages.
- [08:52]
Tony Salonma
Yeah, that's actually a good point since I haven't thought about that in a moment here. Because one of the first things done with SISU and with what we do is that we have established a common language since education sector is not usually very familiar to technical people that are coming in. So we need to teach them what things are and what they mean. So we spent a lot of time making sure that we use the common terms. And there are certain terms in Finnish education sector that are commonly used outside of, let's say administrative processes like in common language, which aren't very well defined. And we basically ban them in our internal discussions because if we use those, we can't know what you are meaning. So let's say domain demand, domain driven design is basically what we've done here. And we all speak the same language and we try to make sure that we have really, really open communications, our slack channels are open. We discourage using DMS to do stuff like product development decisions. So it's opt in transparency. You can see what's happening if you want to see it, but we do not force you to sit up, sit in every meeting, or use your valuable time for things that are not relevant to you. But I think it's more about tearing down silos and fostering communication.
- [10:29]
Podcast Host
I love how you summarize it, but let me highlight things so make sure I understand and kind of translate that. So through the experience that you've had so far, you understood. Okay. In order for us to be able to collaborate across product and technology, we need to create a language that everybody speaks. Right. Like the specific terms that have specific meaning. If I understood correctly, you use domain driven design as kind of the approach to defining and keeping that language alive. But how did you do it? Was it like a series of workshops or was it that you and somebody on the product side got together and started developing this, let's call it vocabulary. Right. The language that you would be using to develop the product. How did that start?
- [11:14]
Tony Salonma
Basically, this is a bit before I joined funedata or the foundations for this are a bit before there. But basically workshopping and having entities that do not have a name. You know that you have something that needs to be here, but you are not exactly sure what it is, so you keep it intentionally vague until it clicks. Now you know what the thing is supposed to be. So basically this is how we do development. To this day we are expanding our capabilities, features, feature sets. So we are bringing new data and we still model it the same way we try to understand what the real world is like and translate it into our software. And of course, one of the aspects is that our software is using the same terms as well. So the code speaks the same language as well.
- [12:07]
Podcast Host
Yeah, that's what I was going to say. Right. Because ultimately the code needs to reflect that language. And I'm guessing, I don't know, but I'm guessing that the fact that the code already uses those terms that you've defined over the years or also helps the rest of the organization, but obviously specifically the engineering organization, to keep faithful to those terms, right?
- [12:31]
Tony Salonma
Yeah, exactly. And it helps to keep the complexities out of the ui. You have certain places where you model Your data where you have all the complexity and you can what we are showing the users or different user groups that can vary but there is single point of truth, what our terms are and how we are talking about these things.
- [12:57]
Podcast Host
So if somebody listening to this episode would like to get started, maybe introducing the idea of domain driven design, what book or video or resource would you recommend they go to in order to start exploring that area?
- [13:14]
Tony Salonma
I would suggest the. It's. It's not, not a hype book at the moment, but Domain Driven Design by Martin Fowler I think is the book that I started with this. So I, I think the things laid out there are a good foundation and it's a comprehensive book. You can get the idea from there and then everything is about adaptability. You need to know how to adapt these ideas to your organizations. I don't think that you can get ready made solutions from a video or a book or a conference. You get ideas and those brew in your head. You come back to your office, you talk with other people who have their own inputs and then you get something interesting. That's a good starting point.
- [14:04]
Podcast Host
I'll put the link to the book in the show notes, but that's a very good point. We need to practice this. So another aspect is how do we keep on road mapping but keep our agility and that comes from that collaboration between technology and business. So what are some of the key strategies or techniques that you've implemented to make sure that technology and business, not just product, but of course also product keep on collaborating instead of just setting the roadmap, throwing it over the wall and then say now implement this.
- [14:40]
Tony Salonma
We try to keep the actual communication distance short so lots of interaction. And it's crucial to have your product owner to be the part of the development team because it's quite common that when you ask developers who are the key members of your team, you seem to miss out on product owners because they are often doing collaborations with customers or collaboration with other product owners. But you need to have nice foundation that the product owner is a part of the team, they are doing things together and that's where it starts for us. But we also try to visualize everything that we do. We aren't exactly using any scalable agile framework, but we have done something similar that SAFE has for increment planning days. We have a, a big room planning day where we go through all of our organization and not do exactly binding plans for anything, but it's something where we go through our goals for the next increment and we Try to visualize everything, who is doing what, what are the possible requirements for other teams. So we try to make it so that everyone here knows on surface level what everyone else is. So that also validates our plans with the product development. So product people can see what's being planned for every team and they can validate that if this is something that they need to do. But also they can see all the technical work being done and they know that we are keeping track of our product life cycles. We are doing library updates, we are doing, let's say data security audits, whatever, but everything is, we try to keep it as visible as possible and we try to track these things. So during our increments we try to keep track of where we are going and if we need to pivot to something to get our things done.
- [16:51]
Podcast Host
So you use transparency basically as the main technique to allow product to reason about, to think and then of course to give feedback to the teams about what they are planning to do. When you think about this big room planning, how often do they do it and what's the high level structure that you use to organize that big room planning?
- [17:13]
Tony Salonma
Basically we do it around once a quarter, but it depends on what we need. But once a quarter has been a good way for us to do it and we try to make it so that we aren't exactly slipping into a waterfall model and plan next quarter very rigidly. But how it starts is that we have, we bring everything, everyone to our office. It's a whole live event and there is a marketplace of goals, let's say around one of our large spaces. And everyone, everyone needs to go there and every team goes through the goals. They need to see everything that's even being proposed as a thing to do in the next quarter and they pick up things from there. There have been discussions about those earlier. We know which are prioritized higher and the prioritization depends on multitude of factors, not only the value to customer directly, but also like library upgrades or infrastructure changes or whatever like that. And once teams have those things they, they can start planning, if this is even feasible, to get done in this increment in some fashion, not, not in, in nitty gritty details, but in some fashion. And once we've done that, they can start communicating with other teams on what they need. And if someone is having things that as a company we would like to get done, but it's not going to fit to this team, maybe we'll switch it somewhere else. But this is all happening very organically. It's not being done with mandatory meeting. It's being done with everyone in the same office. And our office isn't that big. So you can just walk into other room and ask the other team what they think about this thing and how.
- [19:13]
Podcast Host
Many people are in this event.
- [19:16]
Tony Salonma
We try to get everyone involved, at least everyone in our product development things at large. So let's say around 60 people.
- [19:26]
Podcast Host
Okay, that sounds reasonable. And I really like the idea of the marketplace of goals. Right. Like you start with the direction, then the teams go around, they probably ask some questions, give some feedback, talk to other teams, kind of share, you know, which goals might fit which team. And I guess that at the end of the day or maybe the next day, I don't know, there's kind of a report back where the team say here's what we are planning to do. And everybody gets to comment on that, right?
- [19:54]
Tony Salonma
Yes. It's a high level reporting where people are reporting or presenting their high level plan to other teams. Not the leadership, it's to other teams. It's the community here. So we are, we are in this together, where we are either succeeding together or we are not. So we do not try or we try not to think this as team based successes or team based problems. It's. Everyone is in this together and we try to solve our problems together.
- [20:30]
Podcast Host
But I imagine that you anyway have leadership involved, kind of hearing the plans, giving feedback, asking questions both from the product and technology side.
- [20:40]
Tony Salonma
Yes, exactly, exactly like that. But the focus is not on leadership validation or leadership stamping the plan to say that, yeah, this is okay, so we start with the, the goal, start from our strategy and other needs. So the me and other other persons in our leadership are more involved there. So we make sure that the goals that are coming in align with what we need to get done and we try to stay out of the way on how it gets done.
- [21:13]
Podcast Host
Okay, so for me it sounds a little bit like leadership is focusing on kind of setting the strategy, defining those goals. Perhaps those are coming from sales or directly from customers. And it all starts from that direction. But then you kind of allow the, you called it the community. I really like that term. You allow the community of participants, including leaders and teams and product people, to discuss and come up with, here's what we are planning to do for the next quarter.
- [21:45]
Tony Salonma
Yeah, this is basically it. So of course we are talking, we are helping, we are coaching things forward, but we are not demanding things. So.
- [21:57]
Podcast Host
When I think about road mapping and to your point that you raised a little bit ago, which Is this idea that we want the roadmap, but we don't want to go all the way to waterfall.
- [22:07]
Tony Salonma
Right, Right.
- [22:08]
Podcast Host
So how do you keep the future in mind? Right. Like we want to go in this direction. Like, I don't know, maybe thinking back to when you started using domain driven design or adopted a new technology, whatever. How do you keep that focus of the long term future in mind, but at the same time allow the teams quite a lot of flexibility on the short term, say the quarter. If we talk about that big room planning, how do you keep these two things in balance?
- [22:37]
Tony Salonma
We do of course have an internal roadmap of like higher level things, things we are looking at where we would like to be going. Let's say, for example, right now, AI development is one of those things. We are proceeding in some areas and we would like to proceed in other areas. So those are on the higher stage roadmap. Or there would be other technical, technical new inventions or new technologies or new processes, how AI is helping us develop faster and those things. So those are mapped there. But they, they are either we talk about those with, with our teams, with our community separately, and they bubble up from their ideas to the goals, or those come at the appropriate time when our strategy aligns with that. So we want to spend resources on this thing. We want to see if this is something that would be beneficial to us. So those come as goals. And one thing that we do is we hold internal hackathons to actually get those things fleshed out for goals as well.
- [23:58]
Podcast Host
Okay, so if I understand correctly, you have this, I guess, ongoing conversation about the long term technology direction and then you allow that to come up either from product or from strategy, but through the community. So the big room planning as goals, is that how you're describing it?
- [24:18]
Tony Salonma
Yeah, that's the other way. At some points when there is something that we need to get done, then it might be a product development goal directly, but usually like you described.
- [24:30]
Podcast Host
So when you think about your career and when you think about all of the different aspects that you've learned and that of course you've developed as your own approach to the CTO role, what has been the biggest challenge that you have faced and how did you overcome it?
- [24:47]
Tony Salonma
I would think the biggest challenge is not technological in nature. It's probably the rapid scaling of organizations or teams. So we had times when we needed to expand our operations quite rapidly, not as organically as we've hoped. I think we had a few years where we almost doubled our headcount, both years. So That's a real challenge to go from a small, intimate team to a bigger organization and what that means to your development culture.
- [25:24]
Podcast Host
So when you think about that challenge of scaling quickly, meaning growing the number of people involved, I guess that puts a lot of pressure, of course, on the people involved because there's a lot more work to do because you're growing the team and still serving the customer. There's also pressure on the processes because they need to evolve to adapt to this larger group or community of development. There's also pressure on the technology. What technologies would fit in this, say, larger scale system or more customers, more users? How did you overcome that? Like, what were your approaches? What did you learn from that scaling challenge?
- [26:05]
Tony Salonma
Our approaches or some of these have come up later since we understood where we didn't do everything like we should have done. But I think one of the key factors is understanding your, your company culture, your development culture. And once you start scaling up, you need to keep that culture in mind since that's how actually the people who are already in the company think about how they've done and what needs to change and where they've been for the last, how many years they have been there. So we tried to keep our company culture in the center. So make sure that everyone who is coming in knows how we operate and they are on board with that. Of course changes are a good thing, but some kind of alignment is necessary. So strengthening your company culture is one thing. Then of course we knew that going from 10 people to let's say 50 people, the strain on organizations and processes is something really different than what's required for a small organization. So we try to identify the pain points beforehand and implement processes that we didn't have before. Maybe we need an internal discussion forum about architectural decisions, which we didn't have because everyone is in the same room all the time. Or we need to robust up our, let's say continuous integration flows because there is a lot more builds coming in which weren't the case earlier, or other things like that. We tried to identify most of these beforehand and I hope we did well there. But there were things we didn't, didn't see coming and we fixed those afterwards. And of course there's people involved. So open discussions with the people and going through the things that, why we are doing this change, what's, what's the goal of goal here and what do you think? How we should organize, how we should do these things is the most obvious thing here because most of the processes, especially relating to development, it's not something you can from the relative outside, you can see how it should be done. You need to ask the experts who are doing daily on how it should be organized.
- [28:39]
Podcast Host
So I hear from this story that aspect of involving the community was right there from the beginning and you kind of also scaled it up. As you scaled the organization, you also scaled the approach of how to get the community so product business development involved in making those decisions.
- [28:59]
Tony Salonma
Yes, exactly. So we try to involve people in decisions like this so we can explain why we are doing this. Because changes that come out of nowhere and do not have a basis on strategy or whatever, those are the worst kind of things you can do. So we try to avoid this.
- [29:21]
Podcast Host
And what's your perspective as a CTO of a company and you've already said you are working on how to take advantage of the latest AI technology. What's your perspective on the rise of AI and how it might affect software and product development in the future?
- [29:38]
Tony Salonma
There are a lot of good things happening. There are some things that still need a bit more refinement, but productivity is on the rise, of course. And if we look at how we develop stuff, there is a lot of things that AI can do a lot easier than we've done in the past. Let's say generating test data, doing boilerplate things and lot more of that nature. So that's one thing where we've seen improvements. But then of course we have strict requirements for our cybersecurity and data safety. So generating code also means that then the developer needs to go through all of it and understand where it's coming from. And then there's a code review step where another person still goes through that. So that's not something we where we've seen that much improvement because the understanding of what's being generated also takes time and this, these two. So that I think there are a lot of things that where we can extract a lot of value and there are things that probably should stay with humans for at least the time being. And of course for from a personal perspective, I actually like following problems with code. And at some point I think I'm moving to describing problems for someone else to solve when I use AI tools. And at least my personal satisfaction goes down a bit when I can't go code the ingenious solution I've dreamed up when I use these things. But that's a personal problem, not exactly a business problem.
- [31:27]
Podcast Host
Yeah, it's a very important point that the way that people relate to that technology, AI specifically is going to be an Important part of how it gets adopted, right? Like very often it's easy to think, oh, we would like AI to do all kinds of repetitive tasks and help us with the repetitive tasks so that we have more time to solve interesting problems, like what you said. And the way that the technology gets applied will affect people's motivation. So I was thinking, just like as you were saying, that you still like to solve problems with code, that if we try to use AI to do that, we eventually come up with a lot less motivated and less engaged developers, which in the end is going to be a risk, specifically from the cybersecurity perspective, because people are less alert, less attentive to what the AI is generating. And at least personally, I see a huge risk with CyberSecurity when using AI generated code. Not, not the least of which because you never know who created the AI, what, what kind of things they have trained the AI with and may have injected into it. And it's easy to imagine that some models will have malicious training in order to allow an attacker, an adversary, to take over any system that is developed with that model.
- [32:52]
Tony Salonma
That's why I think every company doing development where there's AI involved, comprehensive AI policy should be something you need to work on if you do not already have that. Lay the ground rules on what you can do, what you can't do. It's easier for everyone when there are actual guidelines on how to do things. And you do not just leave it up to every developer to do what they think is the best way to do things.
- [33:21]
Podcast Host
Absolutely, that's a great point. All right, turning a little bit to another aspect of the CTO role, which is how do we manage the organization that is our responsibility. What are some of the key performance indicators or KPIs that you use to measure the success of your organization?
- [33:40]
Tony Salonma
We use a lot of things, we don't use them well, we use them as KPIs, but we do not measure them in the sense that there will be goals attached to these in the traditional sense. But we do use DORA and Space framework. So we measure on how often we deploy, how much problems do we have, and all those things from space. I would like to point out the one thing that we think very highly of is measuring the well being of our software teams. Usually when you think about measuring performance of software teams, you go to amount of features produce or something like that. But actually the well being of people in those software teams is a key factor for us as well. And we like to see that. Then of course, we we check on that retrospectives are being kept, what kind of trajectory the teams are on. We do a lot of things on the people side of, of the equation, but on the technical side, one of the things we try to keep up with is that how much of our development work is going to keeping the lights on and how much is elective development, where we can actually make decisions on what to develop, which aren't mandated that the software is going to break if we do not do this. So we try to keep up on those kind of percentage on what our work is being directed towards.
- [35:17]
Podcast Host
And how do you measure that percentage of work between elective and keeping the lights on?
- [35:23]
Tony Salonma
It's not an exact science, but we use JIRA as I imagine most of the software companies are using. So we have a data warehouse attached to that and we try to use our JIRA data to find out these numbers from labeling and other things from there. So that's how we keep track of this.
- [35:48]
Podcast Host
So you have some kind of policy on how to label specific items in jira, like epics and stories, and then you kind of mine that data for an oversight of how much is keeping the lights on, how much is selective software development?
- [36:02]
Tony Salonma
Yes, and we mine up quite a lot of things from that data to help our organization, but also help our teams and product owners see where the time is being used on. So it's not just for leadership, it's for the teams as well. That's even more the even more important part.
- [36:25]
Podcast Host
And when you think about your journey as a cto, what was the book that most influenced you in your approach to that role?
- [36:34]
Tony Salonma
I. I think there are a lot of technical books that I could choose, but I still think that the organizational books have been more influential to me. So one book that really influenced my thinking on how to organize our teams and how to organize a product development organization was Team Topologies. And that talks about what kind of roles different teams have and so forth. And the other is on leadership and how I approach approach leading the organization is radical candor and how to give honest feedback and get results through that.
- [37:16]
Podcast Host
And these are of course, books that we've featured here on the podcast quite often. I'll put a couple of links to other episodes where we discuss these books. Tony, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge. But if people want to go and find out a little bit more about Fundidata and the work that you've been doing, where could they go?
- [37:40]
Tony Salonma
I would think that for funidata what we are doing with the higher education sector. Our social medias, our LinkedIn page is the premier way to see what we are cooking up. And for me personally I think going to my LinkedIn or shooting me a message through there is the easiest way to get in touch. And I'm always happy to discuss all of topics related to software development and technology in general.
- [38:06]
Podcast Host
Absolutely. It's been a pleasure. Tony, thank you very much for being with us here.
- [38:11]
Tony Salonma
Yeah, thank you very much. This has been a blast.
- [38:16]
Vasco
All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted to real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile Gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no estimates, we got the pioneers of no estimate estimates in those.
- [38:55]
Podcast Host
Deep Dive interviews as well.
- [38:57]
Vasco
Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of.
- [39:16]
Podcast Host
All of that AI slop you see everywhere.
- [39:18]
Vasco
And of course without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join a community that's shaping the future of Agile. And we have so much for you. So check out all the details@scrummastertoolbox.org membership because listening is great, it's important. But doing it together, that's next level.
- [40:05]
Podcast Host
I'll see you in the community Slack 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.