Easy Agile Podcast Ep.15 The Role of Business in Supporting Sustainability Initiatives with TietoEVRY

"Rebecca is an absolute gold mine of knowledge when it comes to SAFe, can't wait to continue the conversation at SAFe Summit 2022!"" - Tenille Hoppo

In this episode, Rebecca and Jasmin are talking:

📌 The value of the Scaled Agile Framework, who it’s for & who would benefit

📌 The Importance of having a common language for organizations to scale effectively

📌 When to connect the Scaled Agile Framework with your agile transformation

📌 Is there ever really an end state?

+ more!

📲 Subscribe/Listen on your favourite podcasting app.

Thanks, Jasmin and Rebecca!

Transcript

Jasmin Iordandis:

Hello, and welcome to the Easy Agile podcast, where today we're chatting all things Scaled Agile with Rebecca Davis, SAFe Fellow, SPCT, principle consultant and member of the SAFe framework team. Rebecca is passionate about teamwork, integrity, communication, and dedication to quality. And she's coached organizations on building competitive market-changing products at scale while also bringing joy to the work, for what is work without joy. Today, we've chatted all things Scaled Agile implementations, challenges, opportunities, and also the idea around optimizing flow, which Rebecca is hosting a workshop at the SAFe Summit in Denver in August this year. Hope you enjoy the podcast.

Jasmin Iordandis:

Hello everyone, and welcome to the Easy Agile podcast. I'm your host Jasmin Lordandis, product marketing manager here at Easy Agile. And today, we are delighted to welcome Rebecca Davis from the Scaled Agile framework. Welcome, Rebecca, and thanks for joining us.

Rebecca Davis:

Thanks. I appreciate being here. I'm excited.

Jasmin Iordandis:

Me too, especially because we are counting down the days before we get to meet you face to face, in person, at the SAFe Summit over in Denver, Colorado. And before we kick off our conversation, I just want to acknowledge the traditional custodians of the land from which we broadcast our podcast today. The people of the Djadjawurrung speaking country. We pay our respects to elders past, present and emerging, and extend that same respect to all Aboriginal Torres Strait Islanders and First Nations' people joining us today. So before we kick off, Rebecca, can you tell us a little bit about yourself and your role within Scaled Agile?

Rebecca Davis:

Sure. I'm actually relatively new to working for Scaled Agile. So I've been there a little over 90 days now, and I'm a member of the framework team, which means I help actually create the Scaled Agile framework and future versions of it. Prior to that, I led LACE at a company called CVS Health, and I've worked at a bunch of different kind of healthcare organizations across my years implementing or organizing agile transformation and digital transformation. And I think one of the reasons that Scaled Agile was interested in me joining the team is just a lot of different experiences across business agility as a whole outside of technology, in addition to within technology. So marketing transformations and HR transformations, legal transformations. But I love being at Scaled Agile and being part of the framework team. It's really exciting to help more organizations, and just the one I'm at, really understand how to bring joy to their workplace and bring value out to the world.

Jasmin Iordandis:

Yeah, cool. And you've given a little bit of information there around why Scaled Agile was interested in you. What attracted you to Scaled Agile, and did you use the Scaled Agile framework in these previous roles that you've just described?

Rebecca Davis:

Yeah. Those are great questions. I think I'm going to try to answer both of them together. But the reason I have always been drawn to the Scaled Agile framework is I ran a few different organizations, both as owning my own company and then also working in startups and working with larger organizations, where I knew that agility was important. But I was struggling as a change leader to find a way to really bring connectedness across large amounts of people. And to me, that's what Scaled Agile does for us, is after a certain size, it's a lot easier to create this common language and this common way to move forward and produce value with the framework. I also really enjoy it because there's a lot of thought that's already kind of done for you.

Rebecca Davis:

So if you're in an organization and you're trying to create change or change leadership, I'd much rather be leading the conversations and my context and making sure that I have a pulse on my particular cultural environment and pull from all these pieces, from the framework, where the thought's already been done about what are the right words and what do we do next, and what's the next step. So I've just found it an invaluable toolkit as a change leader.

Rebecca Davis:

I joined the framework team for a few reasons. One, I'd led so much change in so many different areas that, it's not that I wasn't challenged anymore, but I was really looking for something larger and different, and I've always had a belief that I really want to be the change that I want to see in the world. And I think being part of the framework team gives me access to things like this and all over the world to really help connect the humanness of people alongside with all the great techniques that we've learned, and hopefully expand it and just create a better place to be in.

Jasmin Iordandis:

Yeah. Cool. And you kind of touched on that in your response, but if we had to say, who is the Scaled Agile framework for and who would it most benefit, what would you say to that?

Rebecca Davis:

Yeah. I guess my opinion on that is I believe the Scaled Agile framework is for people who believe that their organizations have it in them to be better, both internally inside of themselves, as well as have this gigantic potential to go help the customers they serve and may be struggling right now, to really realize that potential. So I don't really see the framework as it's for a specific role necessarily. I think it's for people who believe in betterness. And those people, I found, live across an organization and across multiple different roles, and the framework just really helps you align that.

Jasmin Iordandis:

Yeah. And I think one thing that's evident from SAFe, once you learn how all the different practices and ceremonies work together, is exactly as you've said around connectiveness. And you also touched on having a common language. How important is that, when we're talking really large organizations with multiple different functions who, let's be honest, it's quite common for different functions to fall into different silos and things to break down. So how important is that connectivity and that common language, so that an organization as a whole can scale together?

Rebecca Davis:

Yeah. I don't even know how to state the amount of importance that is. I guess, specifically the organization I just came from, had over 400,000 people that worked there. And the last thing I want to is to debate what the word feature means, because that doesn't actually end up within a conversation where we have an understanding of why we want to feature or why we want this particular outcome, or how this outcome relates to this other outcome, if we're spending so much time just choosing word choice and having a conversation instead about what does the word even mean.

Rebecca Davis:

So I like it mostly because it gives us all this common framework to debate, and we need to be able to do that in really transparent and open ways across all of our different layers. So I don't even know how to quantify how much value it brings just to have this ability to bring stability, and the same language across the board, same word choice, same meaning behind those word choice, so that we can have all those debates that we need to have about what's the best possible thing we could be doing, since everything that we can do is valuable, but some things we have to decide are more valuable than others.

Jasmin Iordandis:

Yeah. And I think that really talks to what you were saying about helping an organization to reach its potential. It sounds like getting bogged down in what you call things or how you discuss things. And to be able to align on a common meaning in the end, you kind of need that common structure or that common language. And you're only going to get in your own way if you don't have it. So it makes total sense that the framework could really enable organizations on that journey. And in your experience, because it's implied in the name, it's about scaling agile. And I guess when we think of the Scaled Agile framework, we think of all those organizations of such a large size as the one you just mentioned, 400,000 employees. In your experience, what's a good time to introduce the Scaled Agile framework? Does it need to be right from the beginning? Does it need to be those organizations that are 400,000 people strong? Where is the right time to intersect the framework with an agile transformation?

Rebecca Davis:

Yeah. I think that's a really fascinating question, and my answer has changed over the years. I originally started researching Scaled Agile, because it was my first big transformation alongside of a large organization, and I knew there had to be some solutions out there to the problems I was seeing, and I discovered SAFe. But thinking back, I started my own startup company right out of high school actually. And I really wish that I would've had something to pull from, that gave me information about lean business cases, and speaking with my customer and getting tests and getting feedback. So I feel like the principles and the practices and the values are something that could be used at any size.

Rebecca Davis:

I think the part about scaling, the part about deciding like, "Hey, I'm going to do PI planning," I don't personally feel like you need to do PI planning if you have four people at your organization, because the point is to get teams across different groups to talk. You should definitely plan things 100%. So I think part of the idea is like, "When do I implement a train," or, "When do I have a solution train," or, "When do I officially call something LPM," versus just having discussions because my company is so small that we can all have discussions about things. I think those are a different part of implementing the Scaled Agile framework than just living and believing in the principles and the values and the mindset from whatever size or get-go you're at. Does that make sense at all?

Jasmin Iordandis:

That does make sense. And I guess then the question becomes, where do you begin and what would the first step be in implementing SAFe? And taking from your own experience, where do you start with this framework?

Rebecca Davis:

Yeah. I love that you asked that, as I've honestly seen this happen to me as well as some other change agents, where Scaled Agile gives us this thing called the implementation roadmap, and it has all the steps that you can start with. And it's proven, and companies use it and it works. And what I've found in my own change leadership is when I skip a step or I don't follow that because I get pressure to launch a train, instead of starting with getting my leaders at the right tipping point or having that executive buy in, it causes me so much pain downstream.

Rebecca Davis:

So if I were to give advice to somebody, it's, "Look, pull that map down the implementation roadmap from the SAFe site and follow it. And keep following it. And if you find that you..." I think that, back when I look back and do my own retrospective, the moments where I've decided to launch a train without training my people or launch or start doing more product management practices without actually training my people, it causes me a world to hurt later on with coaching and with communication, with feedback. So it's there for that reason. Just follow it. It's proven.

Jasmin Iordandis:

Yeah. And that's really good advice. And I think when people look at the roadmap for SAFe, there's a lot on there. But when we are talking agile transformations, necessarily there is going to be a lot that could get you there. So it kind of makes sense when all the thinking is been done for you and all those steps have been done. Just trust the process, I guess, is the message there, and following through on all of that. And I think it's really interesting, because the first step with SAFe is, as you say, getting your leaders on board. And often, we might be attracted to doing the work better. So let's start with those ceremonies. Let's start with all those things that make the day to day work better. How important it starting with the leaders of an organization?

Rebecca Davis:

Yeah. I've run the grassroots SAFe implementations where you start with the bottom and then you kind of move up. And personally, and this is a personal opinion, I'd much rather take the time and the efforts to get the communication right with the leaders and get the full leadership buy-in than be in that place again, where I'm trying to grassroot to move up and I hit the ceiling. The one thing I used to kind of tell the coaches that reported to me, and something I believe in deeply, is what we're trying to do with transformation is a journey. It's not a destination. So because we want to start that journey healthy and with a full pack of food and all those things, we need to take the time to really go and be bold and have conversations with our leaders, get their buy-in to go to Leading SAFe.

Rebecca Davis:

If they're not bought in to coming to a two-day course, then why would we believe that they're going to come to PI plannings and speak the way that we hope they will and create the change that they need to really lead? So I think that's one of the most important things, if not the most important thing from the very beginning, is be bold as that first change leader in your organization, go make those connections.

Rebecca Davis:

It may take a while. I've been in implementations or transformations where it started with just me discovering issues that senior leaders or executives were having, and going and solving some of those, so that there was trust built that I was a problem solver. So I could ask for the one hour executive workshop, which really should be a four to six-hour executive workshop, to get to the point where I could do the four to six-hour executive workshop, to get to the point where I could do PI Leading SAFe. And if that's what it takes to gain you that street cred to go do it, then, man, go do it, because that's where you get full business agility, I think, is getting that really senior buy-in and getting that excitement.

Jasmin Iordandis:

Yeah. That's really interesting. And I think building that level of understanding and building that foundation, we can't go past that. And I guess on that as well, from your experience, you've kind of hinted at one there, but what have been some of the challenges that you've experienced in implementing SAFe or even just in agile transformations more broadly, and as well as some of those opportunities that the framework has helped to unlock? So let's start with the challenges. What's some of the hard things you've experienced about an agile transformation and even implementing the framework?

Rebecca Davis:

Yeah, I'll give some real examples, and this first thing is going to sound a little wishy washy, but I also believe it, is the biggest challenge to transformation is you. So what I've discovered over the years, is I needed to step up. I needed to change. I think it's really easy to be in an organization and say, "My leaders don't get it," or, "Some won't understand," or, "It's been this way and I can't change it." And I think that the first thing you have to decide is that that's not actually acceptable to you as a person. And so you as a person are going to go fight. Not you're going to go try to convince somebody else to fight, but you are going to go fight. So I think that personal accountability is probably the biggest challenge to wake up every single day and say, "I'm going to get back in there."

Rebecca Davis:

I think from an example point of view, I've definitely seen huge challenges when the executive team shifts. So when we've got a set of leaders that we did the tipping point, we've gone through Leading SAFe, we've launched our trains. And then the organization, because every organization is going through a lot of change right now, and people are finding new roles and retiring and all that, there's a whole new set of executive leaders. And I think one of the things to discover there is there are going to be moments where it sucks, but you have to go and restart that implementation roadmap again, and reach that tipping point again, because there are new leaders. And that's hard. It really is, and it drains you a little bit, but you've just got to do it.

Rebecca Davis:

I think other challenges I've run into is there's a point after you've launched the trains and after you have been running for a while, where if you don't pay attention, people will stop learning, because you're not actively saying like, "Here's the next thing to learn. Here's the next new thing to try." So I do think it's the responsibility of a change leader, no matter if you're a LACE leader or not, to pay attention to maintaining excitement, pay attention to the continuous learning culture and really motivate people to get excited about learning and trialing and trying.

Jasmin Iordandis:

Yeah. That's an interesting point. How have you done that?

Rebecca Davis:

Hmm. So I think a few things. One, I had big lessons learned that there's a point inside of a transformation where, as an SPBC or as a change leader, that transformation is not yours anymore. So I had kind of a painful realization at one point that I had in my head the best next thing for the organization, and I was losing pulse of the people who are actually doing the work. So I think what I've discovered after that is, to me, there's a point where your LACE members and your change leaders and your SPCs need to start coming from a lot more areas. And honestly start to be made up of people who are not, at the moment, excited about the SAFe implementation, so you can hear from the pulse of the people.

Rebecca Davis:

And then I think if you can get those people and invite in and say like, "I'm inviting you to share it with me what's frustrating, what's good, what's bad, what's great, as well as I'm inviting you to tell me all the things that you're discovering out there in webcasts or videos that seem you'd like to try them, but we're not trying yet, and start giving back the ability to try new things and try things that you feel are probably going to be anti-patterns, but they need to try them anyway." So kind of a scrum master would do with a team of like, "Yeah, go try and then we'll retrospect." I think you have to do that at scale and let people get excited about owning their own transformation.

Jasmin Iordandis:

And what's the balance there between implementing the framework and taking all the good stuff that the framework says is good to do, and then letting people experiment and try those things, as you say, that may be anti-patents? Where's that sweet spot to allow that autonomy and that flexibility and that experimentation with still maintaining the integrity of the framework?

Rebecca Davis:

So I think the interesting thing is they are not actually different. So in the framework, we say hypothesis first, test first. So what I found is a layered kind of brain path where there're the steps in the framework and make sure we have teams and balance trains and all the principles and the values, and if you can live those principles and values all the time, while you're testing new things. So you test first like, "Hey, I want to try having my train off cadence from the other trains. I think it would be helpful for us." "Cool. Test that." And what we have to test it against is are we still living our principles? Are we still applying our values? Are we still applying the core fundamentals of agility and lean throughout that test and also as proof points?

Rebecca Davis:

So do we have an outcome where," Hey, I just made my train into a silo," or do we have an outcome where, "Well, now we have two different PI plannings within the overall PI cadence that one of them we merge with all the other trains and the other one is shorter because our market cadence is faster." Well, that's a beautiful win. So I think the key is it's not different, but one of the test points is make sure to check in on those principles and values.

Jasmin Iordandis:

Yeah. Have you ever seen that work well? The example that you just provided with the PI cadence, that makes complete sense, and it doesn't seem like it's going against the grain with anything that SAFe is there to help you achieve.

Rebecca Davis:

Yeah, I think that. This was kind of a little bit of what my summit talk was on last year, is during COVID, there were some trains. We had, I don't know, 30 trains. Two of them were having daily new requirements emerging from all the different states across the United States and emerging from the government and emerging from everything. Those trains were making sure everybody could get vaccinated across the United States. That's really darn important. And they needed to re-plan sometimes daily. It just didn't make sense to say, "Now we're just going to stop and go into PI planning for three days," when there wasn't any way that they could even think about what the next day's requirements could be. Since then, they still have a faster market rhythm. Then there are other trains that are working on, have a set unknown. There are trains that know that these holidays are when we need to release something or end of year is when we need to make sure that we've got something ready.

Rebecca Davis:

COVID is still in a reactive state. So what they've emerged into this year is those trains are still doing PI planning from my knowledge, I'm not there anymore, but from my knowledge. But they do eight a year instead of four a year. And four a year are on the same cadence and the other four are not, and it meets both needs. So I do think that key is test, and don't test just for the sake of it just because something feels dry or you get a new leader, and they haven't gone through Leading SAFe, but test because something actually doesn't feel right about, "We're not meeting our principles or values right now. We think that we could meet them better in this way. We think we could accelerate the flow of value in this way. Let's try it."

Jasmin Iordandis:

Yeah, cool. And on that, what are some of the red flags that you've seen in practice where those values aren't being met to be able to say, "Hang on a sec. This isn't working. We need to switch course"?

Rebecca Davis:

Yeah. Some of the things I've seen are the whole fun around when people are prioritizing their hierarchy or their piece of the organization over the enterprise value. So I've definitely seen people come to me and say, "Hey, I'd like to do his test." And when I ask the reasons why, a lot of the reasons are like a thinly veiled, "Because I would like more control."

Rebecca Davis:

So I think back to the values piece is that, "Okay, what's your why? Let's start with why. Why would you like to try something? What does that trial outcome achieve?" And, A, if it's really hard to articulate, probably there might be a bad thing going on, or if it is articulated and it actually goes against agility or lean practice and or diminishes flow or creates a silo, that's an initial gut. I think throughout testing, it's important to, the same way that we would do with iterations, have check-ins and demos, not just of what's the product being produced, but what is the change producing? So figuring out what those leading indicators would be and treat it the same way as we would treat a feature hypothesis or an epic hypothesis. We have some outcome we believe we could achieve. We're 100% open to being proven wrong. These are the things that we want to see as leading indicators as success and be really open with each other.

Jasmin Iordandis:

Yeah, cool. And it sounds like what's key to that though is having some concept of what that intended outcome is as a result of that experiment. It's not just going in for, as you say, the sake of doing an experiment. You want to have an idea of where you want to end up, so you can see if we're actually getting there or not.

Rebecca Davis:

Yeah.

Jasmin Iordandis:

That's really fascinating. And I think experimentation and iterative improvement, it kind of goes together. It's not just blindly following something because that's what you are supposed to do. It's preserving the values. That's a really interesting concept. And I think in that, would also come enormous opportunity. So in your experience as well, going back to the times where you've brought SAFe to an organization, or you've been going through an agile transformation, what are some of those opportunities that you've seen the framework unlock for enterprises or organizations that you've been leading those transformations within?

Rebecca Davis:

Yeah. I always was drawn to this idea of true value flow and business agility. So for me, what Scaled Agile helped unlock in a few of my organizations is, I always targeted that, like I'm not trying to make my thing better, I'm trying to make everything better. And with that mindset, really pushing for anybody should be able to take a class. Anybody should be able to take any of the classes. And these days, the enterprise subscription helps with that a lot. When I first started, we didn't have that. So it was also like anybody can take a class, and there should be creative ways of getting it paid for it.

Rebecca Davis:

But through that kind of invite model of really anybody, I had a nurse come take one of my SAFer teams classes, just because she was curious and she saw something about it on my blog, which ended up with her being more excited and getting to do agile team coaching for a set of nurses who were highly frustrated because their work on an individual basis was ebbing and flowing so much, and they felt like they weren't giving good patient care to coaching them on Kanban and having them all get really excited because they got to nurse as a team and whoever was available took the next patient case, and the patients were happier, and just being able to invite in and then say yes to coaching all of these roles that are so meaningful and they're so excited and they're something different.

Rebecca Davis:

And that same model ended up going from nothing to having a marketing person randomly take one of my Leading SAFe classes, which then turned into them talking to the VPs of marketing, which then turned into an 800-person marketing implementation. So I think the key is be open and spend time with the curious. And it doesn't matter if they're in your org. It's not like that's what I was paid to do, it's just really fun. So why not? If somebody wants to talk to you about agile, talk to them about agile. It's really cool.

Jasmin Iordandis:

Yeah, cool. And I think what I love about that is often agile may be associated just as software development teams. But as someone who's in marketing myself, I love the benefit and the way of thinking that it can provide to very traditional challenges, but the way that it can unlock those challenges in ways that not have not been approached before. And I think that there's something to be said in that too, around what you were saying earlier around maintaining excitement. And I feel like this question's already been answered, because often it's discussed, "Okay, we are scaling agile, we're going through a transformation." And it implies that there's this end state where it's done. It's transformed or we've scaled agile, but it doesn't sound like that's the case at all.

Rebecca Davis:

No, I don't think at all. I think mostly the opposite of... If you look at even yourself as a human, your whole life, you're transforming in different ways. Everything's impacting you. The environment's impacting you, whatever happens in your life is just this whole backpack that you carry around and you're transforming all the time. And the exact same thing, I think, for an organization and company. Today's age is nuts. There're updates all the time, there's new technology all the time. You and I are doing a talk from completely different countries, and there's change literally everywhere.

Rebecca Davis:

So yeah, I think part of transformation is helping your organization feel comfortable or as comfortable as possible with the rate of change happening and all the people within it, and not see change as a bad word, but as a positive thing where we can make betterness out there. And it's forever. It's a journey. It's not done. I really like Simon Sinek when he talks about that infinite game. I just feel really close to that of, we're not in it to win this moment or this year, we're in it to make a better future for ourselves and our children, and that's going to take forever. The people are in it right now and they've got to be excited about that.

Jasmin Iordandis:

Yeah. And I think that's that balance of delayed gratification, but constant improvement. So you'll feel and experience the improvement along the way. It's not like it'll be way out in the future where you won't feel the benefit of what you're doing, but it's something that's going to be built up and happen over time.

Rebecca Davis:

Yeah. And I think you reminded me just from saying that. I did that marketing transformation, and I just deeply remember a call with one of the marketing VPs who, after four or five iterations, I did a check in with her. And she's like, "My team is so happy. Is this because of agile? Is this what agile is, is happy with [inaudible 00:32:17]?" "Yes."

Jasmin Iordandis:

Yeah, joy at work, right?

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Isn't that what it's all about? That is so cool. And yet the goal initially is never to go out and make people happy. It's just one of those bonus kind of side effects, a happy side effect.

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Awesome. And I think I really want to talk about this idea, because you've mentioned it a couple times, you've even just mentioned then marketing, nursing. But then when you're in these larger organizations, you've got all these different functions. And I think it raises this idea around organizing around value. So I want to make sure we talk a bit about that, because value doesn't just happen from one function, or it's not delivered from just one function or one team. It's something that many people across an organization may have a hand in delivering. But I really want to get your take around this concept of organizing around value. What does that mean and what does that look like?

Rebecca Davis:

Yeah. I think there's a base concept that is also in that implementation roadmap around what happens first. So how do we first organize around value, because organizations tend to be organized around hierarchy. I am a VP of marketing and I have marketing all the way down. And so there's that first step of identifying what the value is that you produce as an organization. So being able to articulate it to begin with, which is not always an easy conversation. Sometimes it takes a bit of time, and then organizing all the different types of roles around what that value is. So I think that's your first thing in what most organizations implementing scaled agile start with, is just identifying it, forming around it, which ends up being what your trains end up being.

Rebecca Davis:

My experience is, because of that same rapid market change, the world changing so far, it's really important to re-evaluate how you've organized around value over time. So in my experience, one of the really healthy things that we used to do is, at the end of each year, give a chance to look at the different train structures and look at how we've organized and say, "Is this still right? And what's our strategy for next year? Where are we trying to head for our consumers and our users? And is there a different way to organize, that helps us with that?" And I say give a chance because in some years, we'd be like, "No. 80% of our portfolio is actually good to go. Things are flowing. We're doing okay." 20% of it has an entirely new strategic shift that's going to hit them, or, "Last year felt not good. We had too many dependencies. We didn't have the right people on the right trains," all those things.

Rebecca Davis:

And so at least take a pause and look at it, and see if our value still mean the same thing as it did a year ago or two years ago. Do we need to reorganize? What does that mean? What does the change leadership around it if we do need to, so that we're always focused on value, and it's not a definition that we gave ourselves five years ago and just stopped realizing that the world has changed.

Jasmin Iordandis:

Yeah. A living definition because it changes depending on what's going on in the world, but also what's going on within the organization and coming back to that idea of experimenting as well, like if you've tried out a new way of working, and that's gotten in the way. But even something that you said there really stood out is, "Okay, it didn't feel good. We might have had too many dependencies." And that brings up the idea of, "Well, how does that flow of value happen?" Oh, that sounds like there's a stifle to the delivery of value. So how do you optimize that flow particularly when there may be multiple people delivering that value?

Rebecca Davis:

Yeah. And I think Scaled Agile gives us some tools for that. So I think one of them is that first session I talked about, value stream and down vacation, so that you can really do a process for talking and discussing with the right blend of people. What is the value and how can we organize around that? I think past that point, there's another tool that I see used far less than I would think it would be, which is value stream mapping. So after we've identified it, now can we actually map what's happening? From concept to cash, which teams are doing pass offs? How long does it take to get an answer on an email? How long is it taking from testing to all the way to release?

Rebecca Davis:

So doing a lot of intentional measurement. Not measurement because we're judging people, but intentional measurement of, we organize this way, this is where all the pieces are connecting, and how long things are taking, as well as how people feel inside of their steps, like does it feel silo? Does it have an outcome? Did we put all of the designers and HR people and engineers on a train, but we made them separate teams, and so it still doesn't feel connected? That's what mapping's for. And those maps and also the program boards that actually visualize like, "Here's the dependencies," versus, "At the end of the PI, this is what those dependencies actually ended up being."

Rebecca Davis:

It's not that dependencies are bad, but they should be adding value, not restricting flow. So I think those connected stories as well as things like employee survey scores and just employee happiness are really good inputs, to, are we delivering flow. And it is a blended view. Some of it's qualitative and some of it's quantitative. But are our own internal things showing us good, bad and different, as well as how are our customers. So do they feel like they're receiving value or that they're receiving bits and pieces and they're unsure about the connected value? I think all of those are indicators.

Jasmin Iordandis:

Yeah. And would you say you'd need to have an idea of what those indicators are beforehand, so you can keep an eye on them as the PI progresses? So for example, you've done your value stream mapping, you've built your art. At that point, do you identify what those measurements of flow ought to be and keep an eye on them, or is it more retrospectively where you see these kind of things getting a little bit stuck?

Rebecca Davis:

I think there's both. So definitely those metrics that we indicate inside of the framework are healthy, good for teams and trains and solution trains and portfolio. So I think there is a set of metrics that you should and can utilize. Retrospectives are key, because retrospectives create action. So while we measure, then what's the conversation we have about them? Because what we don't want is vanity metrics. And my personal way of defining vanity metrics is any metric that you do nothing with.

Rebecca Davis:

So I think a key is use them to hold conversations and create outcomes, and create actions and make sure that you're prioritizing those actions. I think there's another piece of just understanding that this is not just about team and train. So teams and trains definitely do need to improve and measure themselves, but so does the portfolio, so does the enterprise, so do the pieces that connect to each other across different trains. So I do think if you over focus on, "Let's just make our teams go faster," you may be missing the whole point of how do we make our organization flow better, which may or may not equate to moving faster right away.

Jasmin Iordandis:

Yeah. Yeah. And team and train don't exist in a vacuuming within that organization like whole bunch of-

Rebecca Davis:

No, [inaudible 00:40:43].

Jasmin Iordandis:

Yeah. Well, I think we've touched on some really, really interesting concepts, and just I can't wait to hit the SAFe Summit, which is a really good segue to the fact that the next time we meet, Rebecca, it will be in person. And you're hosting a workshop at SAFe. Can you give us any sneak peek of what we can expect to be excited about at the summit?

Rebecca Davis:

Yeah. First of all, when we meet each other in person, I'm very short. So I think I'm maybe five foot. So that'll be exciting. So Harry, on the framework team and I, are running a workshop about flow. So we'll be doing a flow workshop. I can't talk about all of it yet, because some of it we're going to announce inside the summit, but I'm really excited. So I think if you do sign up for our workshop, you're going to get active advice, and be able to work also alongside other organizations and other people, really understanding flow, and how to apply improvements to flow and how to identify blockers to flow and what to do about it. So we're really focusing on why do certain things matter and what can you specifically do about it, whether you're at the team level or the train level or solution level or the portfolio level.

Jasmin Iordandis:

Cool. That sounds exciting.

Rebecca Davis:

And we [inaudible 00:42:08] a lot of other workshops, but definitely come to ours.

Jasmin Iordandis:

Well, we've just spoken about the importance of flow, so it makes sense. Right?

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Awesome. Well, I personally am really looking forward to coming to SAFe and coming to Colorado and to get to chat with you a little bit more. But thank you so much for your time and joining us and sharing your expertise and experience on agile transformations, scaling agile and the SAFe framework itself. Thank you so much for your time, Rebecca.

Rebecca Davis:

Yeah, I appreciate it. And I look forward to maybe one day being able to do this in person with you in your own country. So that'll be really awesome.

Jasmin Iordandis:

Yeah. Cool. That would definitely be awesome. Thanks a lot.

Rebecca Davis:

Yeah. Thanks.

"I really enjoyed my conversation with Andrew Malak. We talk integrating agile techniques and tips on how to achieve a culture of accountability"

Andrew is a firm believer that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes.

Enjoy the episode!

‍

‍

‍

‍

Transcript

Teagan Harbridge:

Welcome to another episode of the Easy Agile Podcast. I'm Teagan, head of product here at Easy Agile. And we've got a really exciting guest on the show today, Andrew Malak from Spaceship. He's the chief product officer. Andrew is a true believer in creating products and experiences that solve customer problems. He believes that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes. In his current role, Andrew aims to help people take control of their wealth from a young age, educating good money habits and helping people invest where the world is going. Andrew is a family man who loves his time with his wife and children. And believe it or not, he uses agile techniques in his personal and professional life. Andrew is an economics geek. He plays and coaches soccer, football. He's a big Liverpool supporter, loves to travel, loves amazing architecture, and loves working with children.

Teagan Harbridge:

There were so many takeaways from my chat with Andrew that I really struggled to pair it down to three. But if you say tuned, here are some of the things that you're going to learn from our chat with Andrew. Why we should stop using the term agile transformation and start calling it an agile evolution. Why it's important to be open-minded to our own limitations so to break the old mindset of protecting original scope. And tips on how to achieve a culture of accountability. So I hope you enjoy. Andrew, can you tell me a little bit about Spaceship?

Andrew Malak:

Oh, fantastic. Well, thank you very much for, first of all, having me, Teagan. Spaceship is a business that's on a journey to make good money habits and investing accessible to all people. So what we look for is trends to do with industries or companies who are building the future of both industry or economies. We invest in them for the longterm, we break down barriers of entry for people, we give them a fee-free product under $5,000, no minimum investments. It's really easy to sign up. You simply download an app and you sign up and make one product selection decision, and you're done. You can start investing on autopilot. We allow you to also invest your superannuation in a not too dissimilar way.

Teagan Harbridge:

So tell me a little bit about who your target customer is, then. Because it seems like you're trying to make something quite complicated accessible for maybe first time investors.

Andrew Malak:

Well, you're absolutely right. There's a niche segment of people out there at the moment, millennials or even gen Zs, that we just don't think have been well serviced by the incumbents. And what we're trying to do is resonate with these young people as much as possible. We're trying to reduce industry jargon and really make things simple to them, because investing doesn't have to be complex. It's really about a lot of discipline around, if I can manage my personal P&L, or money in, money out, then I can create a cash buffer that can go into my assets column on my balance sheet. That's really what we're trying to do. And that kind of language, if we can get it right, can really simplify things that have typically been in the hands of financial advisors and accountants and give it back to everyday Australians who are starting out in their investment journey.

Teagan Harbridge:

Yeah, awesome. And you've been on quite a journey before landing in the FinTech space as the Spaceship CPO. So can you tell me and our audience a little bit about what that journey has looked like?

Andrew Malak:

Oh, where do I start? If you asked a graduate Andrew Malak what he'd be doing now, I don't think I would've been speaking about this because at that point in time in my career I didn't know this space would actually be around, if that makes sense. So I'll go back to my younger years, and I always thought I was going to be an architect. I had this fascination with bridges and I wanted to design things and see them come to life. And let's just say that I do that in different ways right now, but I started out working in CommSec on the trading floor. I moved on to work as a business analyst, and that's where I started my critical thinking into how businesses work and how things can be made more efficient.

Andrew Malak:

I dabbled in teaching for a little bit, I taught high school economics and religion for a little bit. And then I eventually landed in a product role at St. George Bank prior to the merger with Westpac. At that point in time, the light bulb really came on. I realized, "Hey, I like creating things. I like to change things. I don't like to just do things," if that makes sense. And that wondering mind that doesn't like the conform was finally let loose, if that makes sense. And I haven't stopped enjoying it. I loved my time at Westpac, made lots of friends, worked on really cool, successful projects, and implemented lots of things that had great results. Worked on lots of things that have failed miserably and learnt a lot out of that. And when the opportunity at Spaceship started to surface late last year, it was just too good an opportunity to not really come in and have a go. So yeah, it's been quite the journey.

Teagan Harbridge:

Yeah, wow. And I love a good failure story. And you said you've had lots. Can you think, just off the top of your head, what one of those big failures has been?

Andrew Malak:

Where do I start? I think our first attempt at taking a digital experience to allow customers to acquire a product online was quite a failure that taught us a lot. We basically took the systems that our back office staff used and just made it available to customers. And the real good learning out of that is there was a lot of traffic and a lot of demand, but not enough completion ever. And the best learning that came out of that... This is back in 2006, so internet speeds were just starting to pick up. Broadband was starting to go mainstream and customers' trust around doing more transactions that used personally identifiable data was starting to normalize at that point in time. Up until then, people quite reserved thinking, "I'm going to lose my personal data," et cetera. So when we decided to do that, we saw that there was a lot of demand but we quickly came to the realization that we used to train staff for four to six weeks on how to use the systems before they knew how to service customers using them.

Andrew Malak:

But then we've deployed it into production for customers to self-service and realized quite quickly that the experience for customers had to be much more guided than the experience for a staff member. This is where the evolution of usability or design thinking started to come in. We started thinking of, "Well, how do we make these things so easy that a first-time user can go end to end and not encounter friction?" And this is where our understanding of design principles, customer testing using verbatim and anguage that can resonate with a first-time user becomes critical to the execution. It's not just good systems but it's good user experience sitting on top of systems.

Andrew Malak:

That's probably the one that resonates with me the most because I've held that to a very high regard throughout my whole career. Now everything I do I think of, "Where's the friction? How do we make sure there's no friction? What's the customer going to feel throughout this experience? How are we creating unnecessary anxiety in that experience for the customer, and how do we move that away? How do we become more transparent but still be simple?" And yeah, that's probably the one that resonates the most.

Teagan Harbridge:

Seems like a tremendous learning opportunity early enough in that project and something that's stuck with you since, so great learning opportunity.

Andrew Malak:

Absolutely.

Teagan Harbridge:

We've got a ton of customers who are at all stages of their agile transformations, and I know that this is something that you've had experience with if we go back to your St. George, Westpac days. Can you give our audience any tips or stories that you encountered when you were going through those agile transformations? What lessons can you share with our audience?

Andrew Malak:

Oh, I have lots of lessons to share, actually.

Teagan Harbridge:

This is what I love.

Andrew Malak:

Look, I like to position it more as agile evolution more than agile transformation because no matter what you try to do, you're not just going to drop waterfall and become agile next morning. Honestly, I've seen so many attempts and every single time I see that the graduality of the change is a better predictability of the final outcome that you're going to land. So ultimately the Holy Grail that everyone's aspiring to is that, as a leader, you can rock up to a team stand up unexpected and then, without being told who is in what role, who the product owner is, who the engineer is, who the QC is, who the designer is, it becomes hard for you as the leader to work out who's who because at that point in time the team is so well converged on customer outcomes that they will self-organize themselves around what each person needs to do.

Andrew Malak:

And most of the language being used is really around, what are we trying to define the customer? What's the best thing to do within the capacity that we have to deliver this feature to market as quickly as possible, capture value for the customer and the business as much as possible? This takes a long time to get to, where you can start normalizing to a standardized, common set of goals, common cadence, and common ways of working. And I think it's ultimately about how much empowerment you can give people and how much as a leader you can relegate yourself in the background to allow them to work it out themselves as long as you're coming in and nudging things along the way and helping people course correct along the way. So the good news is that I actually think at Spaceship, we're pretty close to getting there.

Andrew Malak:

We have been running scrum and we have been running sprints for a long time, but it has been largely ceremonials. But over the last quarter, we've done a really good job at embedding more cross-functional people into these teams. But the goal for us is that now we feel like our throughput has actually increased and that the constant flow of information between the teams is becoming more natural and there is actually less ambiguity between the teams around, "All right, we built it this way. The API is no longer consumable. It doesn't fit what we're trying to do from our front-end and there's less back and forth." So we can really see that the amount of friction between persons in the team is really starting to reduce dramatically and we're starting to see that throughput really increase. Having said that, the best way to go about an agile transformation is just get started.

Andrew Malak:

You can sit and plan out things and plan towards utopia as much as you want or you can actually just get going. So when I say by get going, I say you have to start by getting buy-in from all the leaders of the different cross-functional teams, because if you don't have that buy-in at the leadership level, it's just not going to work because there's going to be blockers, there's going to be escalations. And if all these things result in conversations around, "Should we keep doing this?" Or, "Hey, maybe this is not the right thing to do." That needs to be off the table really early on and it needs to be a total commitment at the leadership level that we're going to make this work and whatever we encounter we're just going to fix forward. Once you have that commitment at the leadership level, you need to very clearly define the values that the team is going to be handed to work with, because agile itself, it's not a process, it's a set of values that the team needs to just take and start working with.

Andrew Malak:

So we could go and rattle individuals and interactions over processes and tools or working software over comprehensive documentation. Well, give these to the team and they're going to say to you at day one, "We can't go to all of that straight away." So they might actually say that day one, "We're still going to need some documentation because we're not comfortable yet. We don't understand the language of the other people in the scrum team well enough to be able to go and actually code off the back of a conversation." But by the 10th sprint, the 20th sprint, that misunderstanding of what the product owner wants or what the designer is trying to achieve in an experience starts to become embedded in the mind of the engineer.

Andrew Malak:

The engineer understands the customer a lot more, and then you can make do with less process and less documentation and less negotiated outcomes and more commonality across the team. The other thing that then starts to kick in at that stage is that ability of the team to pivot in response to a change and not see that as a threat to what they're trying to achieve. The old ways of working was, define that scope, protect that scope, and not let things disturb that scope, whereas if you're halfway through a project and you get some really good information that tells you that maybe you are not on track to achieve a good outcome, you should be welcoming that. And the team itself in the beginning is going to find that an irritation, but over time they'll become more comfortable with pivoting off the back of new information.

Teagan Harbridge:

Yeah. It's a big mindset shift. I was just having a discussion today about, where does being agile and being reactive, where's that line in the middle. And when does taking information and pivoting because you think something will be better, when can we break that mindset of, "Oh, we're just being reactive?" No, we're being responsive.

Andrew Malak:

Yeah, yeah. And look, I think the word reactive itself naturally has a negative connotation to it, but agility in mindset allows you to flip that on its head and say that no one can work things out in totality to 100% of what's possible, so being open-minded to our own limitations first and foremost allows us to acknowledge that when new information comes in, it is because we didn't think through the solution 100%, but let's also be okay with that because no one can. So I think it's flipping on its head and acknowledging it upfront and saying that this is going to happen, but when it comes we will assess the information we have with the capacity we have with how far progressive we are and make a decision that's right for us, for the customer, and for what's possible.

Andrew Malak:

So I take it as the more information you get along the way, the more reinforcement of, are you doing what's right or should you pivot and change at that point in time? The other thing that happens really early on is that if you as a leader can create a really clear vision around customer outcomes and establish your first cross-functional team and hand over that vision to the team, it becomes theirs. Don't hand over the backlog to the team. Don't give them a ready backlog, just give them the vision and then tell them, "You guys work out what your backlog looks like." When they come up with their own backlog, as long as you as a leader don't see that it's just a list of Hail Marys in it and there is a fair bit in there that is well spread out between hygiene things, strategic things, and a few moonshots and the balance is right, if the team has come up with their own backlog, the motivation they have to build their own ideas just goes through the roof.

Andrew Malak:

And that's what you want to achieve. You want to achieve clarity that the work fits with the vision and the motivation that you get out of the backlog being created by the team itself gets you that throughput enhancement. The other thing that you're going to struggle with really early on is chunking things down to fitting within the sprint cadence. I think that's one that's often been my biggest challenge when moving towards agile practices early on. Typically in the first few sprints, you always have overruns and things don't complete in the sprint because we end up thinking we can do more than we can and it takes us a while to work out, in wrapping up something that becomes shippable in a sprint, you probably take a little bit less in that sprint because you've got to test it or you've got to do a release in that sprint, or you're going to do a PIR in that sprint, or you're going to do a lot of retros in that sprint. Start to sort of formulate what you're going to take through the next planning cycle.

Andrew Malak:

So you've got to budget to that capacity, and I'll find that teams underestimate the magnitude of that work. So be okay with that. Overruns in the first few sprints don't mean you've failed, it means you're learning how to plan better. And then make sure your retros and your pivot off the back of that into your next planning sessions is taking information that is now new to you, and making sure you're working with it. I think as the leader, though, you have to set the expectations that teams can make mistakes and that it's a safe environment.

Andrew Malak:

And I've seen many agile... I was about to use the word transformation, even though I've just said I don't believe in transformation. Any teams that are adopting agile principles expecting that in their first few sprints they don't have any hiccups, and that if throughput falls in the first few sprints, then there's a bit of a, "Oh, well you told me this thing was going to increase our throughput." Yeah, but not straight away. So I think just being realistic with yourself and what's possible, and that shift in itself, until it normalizes, takes a bit of getting used to. The teams need to know it's a safe environment, that if their productivity suffers, if they make mistakes or if they break things, it's going to be okay. We'll fix forward.

Andrew Malak:

But then also there comes a point in time where we have to be very clear about the culture of accountability around using that capacity really well. So what I've found, that the best use of that is the showcase. And what we've done at Spaceship, because we're trying to reduce the amount of ceremonies, we've combined both the planning playback in a sprint as well as the showcase into the same ceremony. So what we do is we play back what we built last session using a demonstration of working software and comparing the amount of work we've executed versus what was planned in the previous sprint. We're saying we've got 80%, 90% through the work and this is what it looks and feels like, and this is what we're deploying to the customer. Then we actually showcase what we plan to do in the next sprint.

Andrew Malak:

And that's part of the showcase, is our hand on heart commitment to, "This is what we as a team are committed to doing in the next sprint." And then that accountability to the organization becomes something that keeps us on track throughout the sprint. As distractors or things that are not committed in the sprint come our way, we quickly think about, all right, can we accommodate these things? Do they need to be done? Are they going to take us off track with what is planned? Are they important enough? Is it a major defect of production, and can customers no longer access our app? Well, drop what you're doing and attend to that. Otherwise, if it's not material, keep focused on the work that you've committed to in front of the organization.

Andrew Malak:

After this you're going to start to experience some growing pain, and the growing pain is good because it means that agile is working and more teams or more feature opportunities become possible for the business. There's going to be a lot more hype around moving to agile. Other teams are going to come across and say, "Oh, how do we piggyback off what you're doing?" Et cetera. This is good. This is good, but what it means now is that some new risks are going to actually start to be introduced. Working with common code, common dependencies, or even common people being needed to be doing multiple things just means that you now need more coordination. I'd say to anyone who reaches this point in time, this is where people feel compelled to start introducing some new roles, coordination roles. And I'd just say, be careful because that can start add to your overhead really quickly.

Andrew Malak:

I find the best way to ensure that teams continue to be in sync is with the right dialogue at the right level with the right rhythm. And this is where I think keeping it simple to just the scrum of scrums works really well. I like the scrum of scrums to be balanced between both product owner and tech lead from each team being present, and a cadence of one to two times per week works really well. And as long as the product owners across the teams and the tech leads across the teams know what the other teams are working on, know what could impact their own work from a release perspective or scheduling perspective or an environment perspective, I think that tends to work really well as well.

Teagan Harbridge:

Yeah, wow. Lots of nuggets in there and certainly things that resonate with our experience here at Easy Agile, being a small company that's grown really quickly. So I can definitely relate. We've had conversations about, do we introduce new roles into this company? We've introduced a new cadence of meeting rhythms only the last couple of months, so we're going through these things too.

Andrew Malak:

Absolutely. Absolutely. What have been your biggest learnings so far?

Teagan Harbridge:

I think that you cannot underestimate communication, and it really does come back to that cadence and that rhythm with the team. And we're experimenting at the moment with a daily huddle where we're talking about, how do we embed showcases more regularly in our cycles? We've got a big demo at the end of the cycle. How can we make that a more ingrained part of our culture? And it really does come back to that culture of accountability as well. So yep, it's all resonating.

Andrew Malak:

Yeah, absolutely. Look, you can go to whatever industry you want but the problems are usually similar. And the great thing is that having these conversations is very important to fast-tracking your way forward, because your problem is not unique to you. Someone else has seen it in someone else has figured out a way. And I think what I like about the FinTech industry is that we compete on products and services, but there's a lot to learn from each other. And even if you just go outside of FinTech, there's a lot to learn from other industries who have adopted agile practices.

Teagan Harbridge:

If we take a bit of a flip, we've gone from your professional career and your experience into a more personal level. You mentioned that you use agile techniques outside of work. So I'm not sure if many others are in the same boat, but can you elaborate on this? What does that mean? What does that look like?

Andrew Malak:

Okay, I hope you don't think I'm extremely weird. We actually have a family campaign. So I guess if I go back to how we've come to actually doing this. Becoming parents, we would look at our children and see so many things that we want them to be better at. And in trying to give them constant feedback, which felt like the feedback was so much that it's all being drowned out because there's so much of it. In fact, my oldest son actually gave me that feedback. He goes, "Dad, why don't we focus on one thing at a time?"

Andrew Malak:

And I was like, "Wow, okay." For a ten-year-old to tell me that, that was amazing. So we came to realize that we needed to narrow and focus on one improvement area at a time, and we don't move on to the next one until we've actually closed out the first one. For example, my oldest son, very clever boy. We're trying to focus with him on the discipline of process over just getting the answer right, because he is clever and nine times out of 10, ask him a question, he's got the answer and he just wants to say it.

Andrew Malak:

But we've started to try to break down the question and work more on the process with him so that in following the process, coupled with his natural ability, we will get more answers right more often. And that's what we're working through at the moment. So our family's scrum wall at the moment has a mix of things on it. Everyone has their own swim lane, and in each swim lane there are a few tasks, some related work or study, some relating to household chores, some related to health or exercise, and some related to acts of kindness. And what we aim to do is make sure that we're moving things across in all four categories every single day. So yeah, you can use agility wherever you'd like but I think that mindset in general, that if I wake up every day and do things that make me better than I was yesterday, then I'll get to keep moving forward in my personal life as well as my professional life.

Teagan Harbridge:

And do you have WIP limits?

Andrew Malak:

We don't at the moment, and we're not doing showcases at the moment. We'll see how we can introduce them in the future.

Teagan Harbridge:

And how was the introduction of a Kanban board at home? How was that received by the family? Have they enjoyed it, has there been any feedback?

Andrew Malak:

Well, it wasn't actually planned. It started by just sticking some Post-its up on the fridge to remind us of stuff. And then one day I said to my wife, "You know what? This reminds me of what we do at work. Why don't we formalize it?" She had a bit of a chuckle but then one day she came back and then she found it there. So yeah, it wasn't really planned.

Teagan Harbridge:

Awesome. And you've already been super generous with your time so I'll close it out with one final question. What advice do you wish someone would have given you when you took the leap from product management into product leadership?

Andrew Malak:

Yeah, that's a really good question. I think first and foremost, that you've got to make sure that you drop your need for perfectionism, because first and foremost, you might have been the best product manager yourself. You might have been amazing. And I'm not saying I was, but if you were and you step up in leadership role, you're going to have people of different abilities working for you. And what you need to understand is that they're going to need some time learning their role and learning their trade. And just don't get in the way of them learn. So for example, you might see someone doing something that may not be the best or most optimal use of that capacity in that sprint. You might feel the urge to jump in and course correct. But if you let them go and just hear their feedback post the retro, they might've had that learning themselves, and a learning that they get for themselves rather than being told by their leader is going to be much more useful for them.

Andrew Malak:

You have to drop your need to make decisions and be in control because, again, the more you can relegate yourself to a servant leadership role and let the team make decisions, when they make decisions and now have to go back up that decision with execution, they're more likely to put their heart and soul into it. The more they feel like you are going to make the decisions, the less inclined they are to think through problems themselves, and then they'll keep bringing the problems back to you. So every time someone asks you a question that has a black and white answer, throw it back to them and ask them what they think, because that way you're coaching them to work it out themselves. And then the last thing that's really important is, I feel like it's really important to think through how your organization allows you to be different and take advantage of that differentiation.

Andrew Malak:

So for example, at Spaceship here, because we're small, we're not a large corporate, our customers are a little bit more forgiving. So you have a limited capacity to build experiences and you can't do all things at the same time. Understand that and take advantage of it, and get your team to also learn that. Because if you're trying to how the all edge cases, it will take a lot longer to get something to market and you might use a lot of the team's capacity to build edge cases. And you can't really afford that when you're in a start-up.

Andrew Malak:

So for example, we launched a new investment portfolio yesterday. We launched the Spaceship Earth portfolio, our first sustainable investment portfolio and it's a sign of more things to come hopefully in the sustainability space. But in launching that, we knew that we have a limitation in our experience or our product set today where each customer can only have one portfolio. We knew that existing customers would want to invest in sustainable investing, but our commitment to them is that it's in our backlog and it's actually the next feature that we're actually going to take to market.

Andrew Malak:

And in explaining that to our customers, they've been very understanding, that they know our throughput is limited but they also know that their voice is being heard and we are building the things that they're telling us about. So I would say that the best piece of advice to tell my young self is to make sure that you get the balance right between the voice of the customer. That's going to tell you all the hygiene things that your product lacks in terms of experience or gaps. And then get the balance between new strategic things that you can go after and new things that you can take to market, as well as a few Hail Marys every now and again. We call them moonshots. They may or may not work, but it's exciting, and if it works, can 10X your volume. And they are the things that are likely to go viral. So getting the balance right is very important.

Teagan Harbridge:

It's been wonderful, Andrew. I've definitely taken a lot away from our chat today, and I'm sure our audience will too. So thank you again so much for your time, and good luck.

Andrew Malak:

No Teagan, look, thank you very much. And it's been a pleasure speaking to yourself and Easy Agile, and I wish you guys all the best too.

Teagan Harbridge:

Awesome. Thanks Andrew.

Andrew Malak:

Have a good afternoon.

In this episode, I was joined by Sherif Mansour - Distinguished Product Manager at Atlassian.

We spoke about styles of product management and the traits that make a great product manager. Before exploring the idea of a shared brain and the role of a product engineer.

Sherif has been in software development for over 15 years. During his time at Atlassian, he was responsible for Confluence, a popular content collaboration tool for teams.

Most recently, Sherif spends most of his days trying to solve problems across all of Atlassian’s cloud products. Sherif also played a key role in developing new products at Atlassian such as Stride, Team Calendars and Confluence Questions. Sherif thinks building simple products is hard and so is writing a simple, short bio.

Hope you enjoy the episode as much as I did. Thanks for a great conversation Sherif.