Episode 53: Part 2: Digging Deeper Into SAFe With Eric Willeke
Melissa Perri welcomes back Eric Willeke for part two of this SAFe conversation on the Product Thinking Podcast. Eric and Melissa pick up where they left off and dive into the product management and portfolio management parts of SAFe, discussing how product management fits into the SAFe architecture and how it works at scale.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and Eric talk about:
Product management needs to create an organization that is capable of making strategy real. [4:04]
"If you are impacting the market through your work, that's changing your strategy and you need that feedback loop," Eric tells Melissa. [6:36]
Eric advises thinking of design strategies and guidelines like visual tables of contents. "What we're looking for when we look at the picture is an entry point, a place I can click; and if I know nothing about the product discipline, I can start to dig in and look at design thinking and understand," he remarks. [8:25]
In Fortune 50 companies, for every agile technical domain there is usually only one expert. At the core, Eric stresses, it's about learning and teaching. "If we want to crack the product problem Fortune 50 scale...it starts with education and getting people to think differently, and creating an environment that can select for a different set of behaviors." [15:30]
To change a company culture, leaders have to first ask themselves what must be true for the company to be a healthy environment. Think about the problem you're trying to solve then act as if it's the future when that problem is already solved. This mindset creates belief. [17:51]
Companies that started with continuous deployment and architecting for flow, manage to avoid more problems than companies who didn't begin that way. [24:28].
Good portfolio implementation for SAFe is based on maintaining relationships and determining the money flow. Portfolio management is conveying strategy into a structure that can implement it. [28:28]
Strategy is a continuous behavior leaders must immerse themselves in. Strategy cannot be mechanical, Melissa adds. "You can't get an inspired creative process nor can you get an evolving flow-based architecture out of a mechanical strategy and environment," Eric comments. [36:52]
When asked what he would change about SAFe, Eric lists a few things: anchoring on the competency world view as opposed to the table of contents view, more emphasis on the customer as the center of the big picture, and making core values and mindset a priority. [45:32]
Eric gives advice for companies just getting started with SAFe, and what they should look for before deciding to adopt the framework. [48:22]
Resources
Eric Willeke | LinkedIn | Twitter
Transcript:
Melissa:
Hello and welcome to the product thinking podcast. Today. We are back with Eric Willeke to talk all things SAFe in this part two episode. So welcome back, Eric.
Eric:
Great. Thank you. Excited to be here again.
Melissa:
Yeah. So, uh, last time Eric and I talked and if you haven't heard it yet, I highly recommend going to listen to that episode first. Um, you can find it in our backlog of podcast, wherever you're listening to this. Uh, we, we talked about SAFe and we talked about the context of SAFe. And if you don't know what SAFe is, it's scaled agile framework. A lot of companies are implementing this especially enterprises to try to scale their agile operations across the business. So in the first episode, Eric and I broke down, what is SAFe? What's the context in which you would wanna apply SAFe? How did it get started? Um, we started to, you know, debunk some myths about SAFe. We started to talk about, uh, critically, you know, where are some opportunities for advancement or where would you not use SAFe as well? Which I thought was really cool.
And today what we're gonna do is dive into the product management and portfolio management, parts of SAFe, a little bit deeper since that's where or I care and start to talk about like, how does this scale and, uh, you know, how product management actually fits into the SAFe architecture. So that's where we're gonna pick up. So we were talking a little bit before we jumped on the phone, Eric, um, but I'd love to first understand a little bit about, you know, the structure. Of SAFe it's you know, it, it's bridging on a lot of building off of just the scrum framework or the kanban framework and the XP frameworks to really scale this into a framework that could be used at every level of the organization. So when SAFe starts to think about product management all the way from the executives, right? Setting the strategy and figuring out the strategies all the way down to the teams, what are the most critical components for us to understand about where product comes into play in the SAFe framework?
Eric:
I, I think for me, I'm, I'm gonna actually step outside of SAFe for a moment to elaborate this. And I, I escaping, I think of was haw that talks about flight quite a bit, and this kinda comes out the kanban environment and, and the different kind of levels of agenda that leaders need to have in a company. And when I look at the levels of agenda, there's kind of the corporate system level, how do I set up an organization that is able to choreograph itself to accomplish the right goals? And we can set those goals. We can allow those goals to emerge. There's a lot of ways to arrive at strategy, but we need to create the organization that is capable of making strategy real. And I think if that's kind of the design and when we talk about portfolios and the biggest picture questions around the enterprise, that that's where my head goes, how are you building a system that allows the things you want to emerge as opposed to, what do I need to go build?
And of course there's interrelationships there in the back and forth, but kinda the next flight level I look at is inside that system, we call say, we would call this inside the SAFe portfolio. Uh, what am I trying to accomplish? What are the goals and how do I get there? And that has its own subset of setting up teams and trains and whatever your organization is that need to yield those results. But really, really there, I'm more focused on what are the goals I'm trying to achieve? What do I want to accomplish with this product, as opposed to what is the product ecosystem I want to emerge? And then at the more, most detailed level as the doing of the work side, the team, or for large investments inside the agile release train, how do we actually get that stuff done? How do I take that vision and desire and set of goals and kind of all that good product based thinking and iteratively and experimentally make it real.
And if I look at that from a SAFe perspective, what I really just described is the enterprise, the SAFe portfolio and the execution unit we can call an agile release train, and I'm, I get a little fuzzy on the language there because there's some, it depends on how big of a product is and how much you're investing, whether that's the team or a train or what have you. But I really go back to those three flight levels and kind of those three big agendas. How am I designing the overall system? What am I trying to accomplish with this area of the system and how am I gonna do it tactically day to day iteration by iteration.
Melissa:
Cool. So, you know, one of my questions about this too, and it's the same thing I bring up, I think when we talk about scrum and we talk about agile a lot with product management is, um, I've always said, you know, Agile's not about figuring out what it is to build, right? It's about really figuring out how do we do the work? Is that the same for SAFe? Um, is there any guidelines or processes or something that's like going out and, you know, tells you how to look at the world and figure out what to do? Or is it more about getting the work done and coordinating the work
Eric:
Little little in between in SAFe's case? So SAFe will state has it's up in the enterprise article and around strategic themes that you do need to have enterprise strategy process. It's not gonna tell you which one, because there's been a different strategy process of the year, every year for the last 70 years. And there's a beautiful infographic for that somewhere. Um, but it will say that you should probably consider market conditions, your overall company goals, your economics, the permission to play you have in the enterprise. Um, and you should consider a feedback loop from your portfolio that if you are impacting the market through your work, that's changing your strategy and you need that feedback loop. And then there's a pretty picture in one of the articles in the top left of the framework that kind of shows all that, but it doesn't tell you exactly how you should create your strategy or especially can't tell you what your strategy should cuz otherwise you get like, um, Wordly strategy generator with a Madlib style strategy.
Melissa:
Yeah. I always think those are funny too. and it's, uh, kinda, they're all too true. Yeah. And they're all too true. Right. I I've read so many strategies that sound like they came right out a strategy generator. Um, okay. So, so a lot, lot more it's giving you guidelines on what would good look like as an input into the system, but it's not telling you exactly what that should be, which, which I think makes sense. So there's probably work and parallel I'd imagine like at every one of these levels, if I'm just thinking about like, how do we do product management on each level? Like what would you do in an executive product management role versus like a mid-level product management role versus like a tactical product management role? It sounds like there's probably other activities that we're doing alongside this. And I know like one of the things that we have on the team level side in, in the essential, SAFe part is it says design thinking, but it's kind of like slapped on there is that like meant for, you know, these things are doing it in parallel. Cause I, I feel like that's where people get confused. They're like, right. When do I do this customer centricity design thinking, , you know, parts of this stuff. Like what what's, what are those types of things put on the diagram for?
Eric:
So I guess that's one thing I've I see a lot of people get confusion around the big picture and what it's meant to convey. And the easiest way to think of it that I recommend is it's a visual table of contents. It's attempted to be organized in a way that kind of makes sense for flow, but it's two dimensional and it has to be something you can print on, hang on a wall. I mean that, that's kind of the job to be done for the diagram is to provide access to the framework and help you remember the contents and the ideas. So people like the customer used to be on the right as receiving the outputs to the train and people had no issue with that. So we move her to the left and I was like, now it's left on, on the left. Well, realistically it's, it's an entry and a table of contents.
We know there's a customer. We know we need to pay attention to them. We know we need to engage in design thinking when we think about our customers. And if I roll up to the top and I look at, uh, strategy, I should probably do some market segmentation. I should probably understand my, uh, key personas. And I need to understand the difference between my buyers and users and, and like all of that stuff is intended, but I could also create an entire picture thing, pragmatic or something that is just those concerns that is equally complex or more so than SAFe. So really what we're looking for when we look at the picture is there's an entry, there's a place I can click. And if I know nothing about the product discipline, I can start to dig in and look at design thinking and understand, well, maybe I should understand the problems I could solve before I pick one.
And maybe I should actually think about a problem before I start writing code. And maybe you can distill it down to that ducks and bunnies example, or you can take design thinking and make it an entire deschool program and take it out to an incredibly complex space. And I think if you drill into any icon, uh, unSAFe, you're gonna find that same emergent complexity as, as an expert in the space, you're gonna look at what SAFe provides and say, this is trivial. It's not deep enough. Like how could they say this captures my area. And then as a complete novice, you're gonna be like, huh? I never even thought of having to have a large solution that is actually a group of multiple entities trying to build towards a common goal. That's a, that's an interesting thinking. And as a novice, I've watched people's eyes open when they think about decentralization and decomposing a large problem into smaller problems. And it might seem obvious to a product manager expert, but to somebody who's just getting started, it's like eye opening and enlightening. Um, and that, and that might get back to the other question you asked, like, who's the customer say, what level is it? And who's written for. It's like, yeah, kind of, we talked about this, uh, last time, but it's written for enterprises. It's a very generic customer as a target.
Melissa:
Yeah. How, when I'm looking at this too, I'm curious, like we've got all these things that we need to keep in mind. One piece of it. And I know we, we talk about this a lot is experimentation. Um, so we've got this large solution, uh, level of SAFe, and we've got these release trains, um, below it as well. Uh, we've got iterations. How do we balance, you know, that large solution train with trying to make sure and experiment around if that large solution is the right solution. Like when do we do that? When it comes to SAFe, like how does that get factored into all this?
Eric:
You know, I'll give some answers about how it should or could happen, but I'll also, so before that just acknowledge, this is probably one of the biggest risk factors in any framework. And I've seen it with scrum and small scale and SAFe team of teams of teams like it's designed for thousands of people. So the risk is dramatically magnified of just getting a purely mechanical implementation. Um, I like Cutler and the way he talks about the feature factory and SAFe as written, without putting intent behind not going there will result in a feature factory. And that could be transformative for companies in and of itself. Like if you're in a spot where you can barely get a feature out the door and it gets you to where you're plugging out reasonably value add features one after another, that's a huge improvement, but it's also like, in my mind, it's like the first 20% it's like, congratulations, you've mastered step one.
Now let's stop doing that and, and think bigger. Um, one, once you get into that think bigger, SAFe can put experimentation anywhere. Cause really what you're asking is can a product manager experiment at any of those levels and SAFe, frankly has nothing to say about that. You can put experiments in your backlog or you can put fully deterministic features with a full visual spec in your backlog. That's your choice and you get the right team and that some of them will gleelfully lean in and help you experiment and do multi variant testing and come back and, and tell you the results of the small experiments they ran on their own in a distributed manner and that's phenomenal. Or you put a different team and a different product manager, and they're gonna carefully implement every single story directly to the acceptance criteria with no variation and no additional thoughts. And that's that's company culture. And you'll see those extremes complete dependent on the framework, but I will acknowledge a framework like SAFe and the structure it provides does add that risk. And it will trend in that direction if you're not intentionally trying to take it away from there.
And I, I think I'd say that's just true of any large structural thing, like society, government, agile frameworks, uh, any, any domain of human existence probably trends in that direction.
Melissa:
Yeah. I agree. And it, you know, it's interesting cuz like whenever I talk to you about these types of things, what I hear from you is, you know, this is a framework and I think we we've talked about that before. You should not be blindly following it. But um, it sounds like there's a need for this to be successful, to have people, you know, looking in all in all of their roles, but especially in the product management role, that's where I'm just coming from. Not that this is overly special, but like who, who know what they're doing, right? Like who know how to build a product who know when to go experiment when not to go experiment when to like, you know, start driving it, otherwise it can just go, you know, haywire where it's just like follow the line and never, never stop right.
Become a feature factory and like you said, that's the first 20% so cool once we can ship. That's awesome. But now we gotta make sure we can actually ship the right things. Um, I'm feeling like a lot of this comes down to like having people who have good discretion and good training in their roles to be able to pick their heads up from this and look at it and go, okay, now it's time to actually validate that this thing, now it's time to do this. Right. Like they, they know their role enough to do that. Um, but I find in a lot of the large companies that, you know, turn to SAFe or turn to these things, we don't have those people, right. They're not usually coming from super experienced product management backgrounds. Do you find that too?
Eric:
Um, I'm gonna say it's not about super experienced or about any one discipline. Um, in the larger companies, I have found that the culture of the company has selected against those traits. Whatever came before agile, um, following instructions and um, some variation of the perfection mindset of say what you do and do what you say or, I mean, different companies will couch it differently. But that expectation of say, do as the thing that gets you promoted, um, firefighting cultures and the, the arsonists that come along with them and the, um, desire, the like overwhelming desire for predictability, that's where you start. And that's where a lot of leaders, they bring that bias into change and into agility. And of course that's what you get with agility. Then if that's the bias you carry in. Um, so I don't actually find it's about expertise cuz I'm, I'm working with a fortune 50 right now and for every single agile technical domain, like behavior driven development, phenomenal, uh, container use, um, curing functional languages into highly performance shapes, like all these esoteric and really powerful.
They have an expert in that space, but they have one expert and those bright spots don't get bigger. And if we think about like distilling down agile to its roots, it's to its core, it's about learning. It's about taking the goodness from one person and giving, making that goodness from many people. And as a result, a lot of my time as a, I'm thinking myself as a transformation architect these days, a lot of my time is like any architect is educating, not building these predictive structures, but educating people on how to design those structures themselves. So you get that generative self-reinforcing world. And if we want to crack the product problem at, at fortune 50 scale, which is one that's right in front of me right now, it's top of mind for me is it starts with education and getting people to think differently and um, creating the environment that can select for a different set of behaviors.
Melissa:
Yeah. Wow. I'm like, I'm like letting that sink in for a minute because I think it makes a lot of sense. Like it's true. I, I see, I see people who are, I, I work with a lot of the enterprises too. Right. And they'll always ask me, do you have any product managers we can hire, every single person I've recommended as a product management person into those organizations don't stick around cuz they're like, I can't get things done. I can't go out on my own and you know, try to push boundaries or do experimentation or like, you know, really get into super strategic things because the culture around them doesn't respect that. Right. It doesn't embrace that. Um, not that I think you can't change that eventually, but a lot of them don't start there right. When they go to look for those people. So like what you're saying really resonates me with me that is that as well. And that's probably why we don't see great product management in some of the larger enterprises. They're just not embracing that type of mentality. Um, so where do you start when you're trying to do an organizational transformation with this? Like how do you get people to embrace learning more? Like how do you change that culture?
Eric:
Um, there's a few things. Um, the one that's most powerful that I see right now and I'm going on recency bias here. So I'll acknowledge my own bias is the whole idea around act as if so you to look at a problem, ask yourself the hard question it's around, what must be true for this to be a healthy, better environment for whatever problem you're trying to solve. And then where can you act as if it's the future in a way that creates belief and, and at one level I could distill it down and say, oh, this is just a marketing game, but in a lot of ways, culture and culture change is about changing behavior. I mean, my, my working definition of culture is it's the sum of all behaviors. And as part of that, I, I, I look at leadership behaviors as counting extra.
So where can I get cross-functional groups of leaders to start focusing and behaving in a different way. And when they do that with enough consistency over a long enough period of time, and that could just be weeks, not years, then other people start to notice. And when other people this and they see their leaders behaving in a certain way, that creates the permission to behave differently themselves and then they keep doing it. And I mean, I wish, I wish I could claim to have like figured this all out on my own, but really you look at David marquet and leadership as language. And this is exactly what he's talking about. I mean, I think everybody around SAFe seen the submarine video. If you've not seen Marquet's submarine video, go watch the submarine video on RSA animate. It's beautiful and wonderful. And to me that is the mindset that SAFe should carry at it's best because that's the mindset that companies should carry at their best has nothing to do with SAFe.
Yeah. And you, you get enough leaders behaving differently. Um, one of my, uh, core cultural pillars in the effort, again, recency bias that, uh, one of the core cultural pillars we're focusing on is the idea of cross-functional management team. We, we believe a scrum team should be cross-functional and have my definition cross-functional is, has all the skills, responsibility, access, and permission necessary to accomplish what it's been asked to accomplish? Why are we asking more of our leaders? Like let's put a product leader, a development leader in charge of, or big air quotes there, this thing, and then expect them to solve it on their own without their peer managers, with other disciplines and other backgrounds and access to other teams and capabilities. Let's get those people working as a team and then cascade that or reverse cascade, whatever an uphill cascade is to various levels of leadership.
Melissa:
Yeah, that, that makes a lot of sense. The, you know, we were just, we were also talking about this right before we get on. Do you find a big difference between enterprises that are maybe more software native? Like what they do is they actually sell software versus the enterprises that probably started from not a software basis, but are now using software to help, you know, drive their innovation. So give you example, like, um, SaaS, like Salesforce sold software, uh, banks originally sold financial products. Like that type of difference. I call them software native and tech enabled type companies. Um, when we're talking about like this culture and this learning, do you find that it's like all enterprises, do you think it strays more towards the ones that are like tech enabled than software native? How do you think that plays into the adoption of SAFe and the adoption of like these principles as well?
Eric:
Um, I, I struggle with that one a lot. And agile itself has its roots in technology. So agility is couched in terms of technology in many cases. And I, I think we've all been at plenty of conference sessions and workshops and stuff where we try to take agile beyond like agile and marketing, agile and finance we're wherever you want to go. And I think there's a lot of power there, but most of the literature assumes you're talking about technology. Um, the part of it, I look at that I struggle with a little bit is I almost wanna flip what you described a little bit and like look at it as like, okay, which companies are tech limited versus having broader business portfolios. Like almost let's, let's look at it from the other side and say, cool, shiny software, only company. You haven't had to face all the real problems yet.
And, and then ask if the SAFe help you with the rest of the problems or not as compared to a relatively simple SaaS company. And I see, I don't wanna take anything away from SaaS companies cuz they've mastered creating simplicity and flow at scale in many cases and are, are transforming our world on our behalf for better or for worse. And they can do because they're not constrained by these other factors. Um, and I sort to look at those constraints and I think SAFe has a lot of tools in it for managing those dependencies. Um, and at that point it's just dependency management. We have additional constraints, we have monoliths and ideas in the company and market conditions that we have to work around. And those constraints just simply don't exist for some companies. Um, which is why it's much easier for a software only company dot execute a traditional company.
Um, until you grow big enough that you start to run into all those things. Um, I'm thinking, I don't know, let's look at zoom because we're using a zoom call to record this. And what, what happens the moment zoom decides to have a conference room offering that has to integrate with a hardware device or has to have a bespoke, um, thing that it sells that is hardware enabled in order to allow it to extend into a new market. Um, and I, I just think of all the supply like zoom does and have to think about hardware, supply chain. It has no muscle for that, but the moment they do suddenly there's a whole new discipline and you have an executive team who won't know how to create an organization that can yield that effectively unless they bring in new talent or learn very quickly. Um, so I think it changes things, but I dunno if it makes SAFe no more or less applicable, it just SAFe has tools that help solve those where maybe other process frameworks don't yeah.
Melissa:
Okay. So I'd like to challenge you on that just a little bit, because I do think there, you know, especially now there's more and more large enterprises that were SaaS companies or are still SaaS companies, but they play in very highly regulated spaces like Stripe. Stripe has all the regulation, all the complexity that we're kind of talking about cross board of transactions, you know, crazy regulations that you would have to do in the financial industry, all those types of things. But um, I think if you compare Stripe to, you know, like a, a bank that's been around for a hundred years, we'd say like Stripe is probably faster at the software parts of it. Right. Because they, they started from the software parts of it. Right. They've got kind of the flow there. So is it really that the companies don't have to deal with all the same things these other companies are having to deal with?
Or is it more like they started from software or like they're birth outta software. They knew how to like do the software pieces and these other companies are trying to figure out like the companies that have been around longer, maybe didn't start from software are trying to figure it out. Like to me that, that seems to be one of the issues. So they look to things like SAFe to give 'em guidelines on where do I start? But I don't know if you've had any experiences working with companies that did start from like a software perspective and embrace SAFe because they ran into the scaling challenges once they got there. Like you were talking about with zoom I'm curious to hear about anything like that too.
Eric:
Yeah. And, and maybe I wonder like maybe if we look at DevOps instead of software, okay. Companies that started in the era of continuous deployment and architecting for flow have managed to avoid entire stacks of problems that companies that didn't start from that mindset have to figure out how to solve and reverse engineer. And, and if you, if we look at it from that point of view, like, and anything since like 2009 in the agile infrastructure session that kicked it all off, then companies that were already solving those problems from day zero and could go to market smoothly with zero friction. Yeah. Those companies don't need the same degree of process support. They've already figured that stuff out and it's been build into the culture. It's built into the behaviors. It's kind of like in the water. And when I look at my, I have a five step mindset model that I use for going through change for companies like level five is basically figuring out what's next because agile isn't even something you have to talk about anymore. And if you could jump, start to the there and never go back then you're right. They, they don't need to think about software process frameworks cuz it's just part of the company. I mean, there's, there's still scaling considerations on what happens when the sheer weight of the company gets big enough. Um, but that's different than software process.
Melissa:
okay. Yeah, that totally makes sense to me. So it's kind of like, um, you know, we can consider these companies that have been treating, you know, on the newer end of software, understanding continuous delivery, getting the DevOps stuff, like keeping up with the pace of innovation, kind of at a place where it's like beyond SAFe, like SAFe gives those people who don't have that type of structure or discipline or have never done it before a way to learn it through the culture. But your hope is that these companies get to a place where they're just like, this is how we work. Right? Like we're not really like doing, looking at this framework, like so hard. It's just that we found flow. We found a steady state to be able to release products that actually matter.
Eric:
Yeah. And I, and you might still, I mean the, the resulting system might still look something like SAFe. Like I, I found a whiteboard sketch, uh, couple days ago I made in 2013, about four months before I, I first encountered SAFe in a meaningful way. And there's a three, three tier nested and structure that addressed the three flight levels we talked about at the beginning of the call and I don't care how good you are and how internet native you are, how, uh, DevOps native, you are, whatever term we want to use. You're still going to have flow at multiple levels and you have to have a system or a solution for doing that, whether it's, um, uh, Cutler has his nested structure of different goals or SAFe with its nested backlogs and accompanying visions or less with kind of the anchored and the details of who's working on what within it.
You still gotta have a way to support those generally at least three levels of flow. Yep. Um, and, and my kinda attitude there is SAFe as, as good as any, as long as you don't let the, let it become mechanical. So I, I don't think companies ever grow out of that. You still have to have a strategy. You still have to have a product level vision. You still have to have something to manage the doing of the work. Yep. I agree with you. Um, yeah. Yeah. And how, how you choose to do that and what you call it at a certain point I don't care. I mean, all software development is the same six boxes with different lines and shapes.
Melissa:
Yeah. That makes sense. And, and I guess that's one of the things I hear from you about why you like SAFe too, is that it helps provide this structure for the portfolio management spot of it, the multi-product lines. Uh, how do you think, like how does SAFe and you teach like how to manage the different product lines, how to think about portfolio management. What's the real tendency around that. And is it more about creating the strategy is more about flowing the strategy? Like what's the big pieces that make it work for SAFe in your opinion?
Eric:
So if I go to the portfolio concepts themselves, I, I do my best to think about any technology landscape as a collection of products. And some of them are internal product with internal customers. And some of them are external go to market products where you have the, at a complexity of like sales and marketing and all that producty stuff where an internal product, your sales and marketing might be going out and talking to your five key stakeholders once a week. So different, different levels of complexity on that kind. And when I look at the portfolio that way, when I see a pile of solutions or products or whatever you wanna call those clumps, then a lot of what I see a good portfolio implementation as doing is maintaining the relationships between them and determining how much money flows to each of them. Um, because that's really what portfolio management is.
As a nutshell, it's conveying strategy into an operating structure that can execute against that strategy. And that means you kind of need to know what your value streams are, what your value network is, depending on what level of language you want to use. You need to know what the pieces are. You have to know which ones you need to make, make obsolete soon, which ones are new shiny growth engines and kind of do the horizon space thinking. And you need to manage that ecosystem almost like a product itself, but it's very abstract. I mean, you're talking like portfolio architecture and business architecture there, not product architecture or product backlogs and visions. Um, and, and if you do that well, you should create an environment where each of those individual things can run fairly smoothly on its own with limited and well understood dependencies with others. And I, there's no point at which all dependencies go away.
I mean, you're always searching for this perfect portfolio design where everybody can run truly independently and it never gets perfect, but you're keeping it like at a tolerable level where you're going as fast as feasible while still allowing the right intersections that create innovation and interesting conversations and opportunities, um, SAFe. Doesn't convey that very well. I, I know it's the intent. Um, partially cuz I was at the table when we were writing some of this stuff. Um, it's really hard to get that thinking out in, on pages and into words. So you can easily read what it's there as a governance solution, cuz you know, it has to be governance. You could read it as a execution and this is all about portfolio management and operations and yeah, that's in there too, cuz it has to be there. Um, or you could read it as this beautiful opportunity to create strategy and inspire everybody to pull in the same direction and manage the relationships between them. Well, that's closer to the intent, but it doesn't come through the pages very well. And I would love advice on how to make it come through the pages better cuz I know how to weave a story on this, but it's really hard to write about
Melissa:
Yeah. That's been the, I think the hard part and, and some of the feedback that I've heard on SAFe too, right. Which is like kind of just puts like enterprise government up in the top corner and then it's like themes portfolio, vision, and then it looks very process oriented. Right. And it's like, how do you get to those pieces? And those are the pieces that I've spent like a lot of time on with scale stage companies. Right. Or helping trying to get executives at enterprises to understand like there's a lot that goes into actually pulling that together and you gotta make it tight. But I completely agree with you. Like my top, when I talk about strategy in escaping the build trap, like my top thing that I talk about is strategic intents. Right. And that's business level initiatives. Right? That's that's how does, where do we want to concentrate on different markets?
How do we wanna think about innovating from a business model perspective? Not necessarily from a software perspective and if you are a SAS company, it might look, it's gonna be pretty straightforward. Like you are strategic intents go into your software pretty nicely. But I think when you're in, um, a more complicated company or a tech enabled company, like a bank, a lot of different things in there, right? Like we've got financial products and software products and everything kind of coming together to develop that product vision below it. Um, but I usually see a lack of, uh, understanding from exactly about like what is actually required from them to put together a good strategic theme, a good strategic intent, a good portfolio vision so that the software directive on the middle and the lower levels can pick it up and run with it and be like, yeah, I have exactly what I need in context. And now I can go and more of our time is spent deciphering what I, it was that the executives actually wanted rather than just being able to like pull it and go do our own work. Um, so when you, when you're saying I'm not, is that like the piece where you're like, I'm not, I don't think SAFe has that like down on the paper. Well, to explain like how to do that pieces.
Eric:
Um, some of that, some of the, like what's the intent. I mean we're when we look at that level, we're talking pretty big sums of money. We're talking fairly senior executives. Um, we're actually talking about a comparatively small market segment in terms of number of people. Like you think about 60 million developers in the world and what 60,00, 6,000 executives that are setting these kind of strategies. I mean at a meaningful size company, um, let's call it 60,000. So fortune five, we'll call it the fortune 5,000 or global 5,000, say 10 executives per company. Like that's, that's kind of the market scale for portfolio level strategy and may maybe double that. Um, it's, it's hard to write down like here's, here's a shape and a process for what must be created, but oh, by the way, the core competency here is deep thinking and storytelling.
Melissa:
Yeah. It's like a little hand wavy when it get tells that. Yeah.
Eric: And, and you and I can sit and have a conversation where we're talking about deeply abstract complex, early stage design thinking type ideas. And I don't know about what your mental model is, but mine is a dotted line box that might become an enterprise epic or it might become a value stream. Exactly. And it's like Shrodingers artifact. We don't even know which one it is yet, but we're trying to write it down in a process framework to describe it.
Yeah that's been like a big issue that I've had. Um, cuz I I've been getting everybody go, oh cool. Like you put the strategy stuff in escaping build trap, make a class on how to make strategy. And I'm like, I can do it when I see all the data, but it's so hard to explain to people how to do it and you're right. Like there's probably what 6,000 people at these large enterprises doing it. Um, but for every company it's, it's so driven by like context and problem solving and being able to put the systems together that it's not like I, you know, step one, pull data out of the system, step two, interview this customer, right? Like it's not a straightforward process like that. It's, it's more like a circular, deep thinking thing where you come back and you're like, I have explored all the possible avenues and I've poked holes in all the different opportunities and are the opportunities I think we should go after.
Um, which is very, very hard to explain. And I, I think from my perspective, like in every, and it happens on every level, right? Like that's not just a portfolio strategy at that point or a strategic strategy for an enterprise. That's also like what product manager do on the teams too. And it's for a much smaller scope, but like that's basically a life in a product manager world is like, yeah, it's gonna be a lot more scope. And it's a lot easier to teach somebody how to go out and interview customers and do these things to, to do that. Like you teach, 'em all the things that go into figuring out what the strategy is for product. It's really hard to define like exactly how you put those pieces together. Cuz it's almost like a puzzle. And that I feel like goes all the way up into the executive thinking as well. But I feel like those pieces make, get left out of agile frameworks a lot because it is hard to, like it's hard to explain, right? It's like really hard to explain how those things come together.
Eric:
Yeah. And that's, by the way you just also described just our different backgrounds. You also described the exact same challenge. I face with architecture. Yeah. Completely. I consider myself an architect at heart and it's the exact same pattern top to bottom, just different set of concerns. And if you click into the enterprise article, like you'll notice SAFe attempts to say here's the big categories of stuff you gotta figure out without telling you how it's like, yes, you need to understand who is your portfolio collaboration that is going to create the strategy cuz it's not one role. So it's like, step one, get the right people together. Cuz this is hard. Um, step two, consider all these things and like just a, a few of things, mission core values, the business drivers. What's your distinctive company, competence. What are your financial goals, the competitive environment. What have you done last that's feeding forward into the next like each one of those is like an hour long conversation, minimum to even get agreement on what the current reality is. Um, and when I do design thinking, by the way, at this scale, I actually put, I, I, I actually look at it as a triple diamond, like there's or a half diamond at the front. That's like converge on a shared understanding of reality before you even try to start understanding your, um, problems you could solve.
Melissa:
I love that. That that is so important. Yeah. And I, I, I like that a lot and that's a big issue that I see. Like it, it takes months of work too and like a lot of implementation and this is why I'm so big on product operations right now. But just to get that data to UN have the shared understanding of what reality looks like, right? Like if nobody's actually looking at that data from a day to day perspective, you either, where do you get reality from? Like it's whatever you can see whatever's like apparent to you, but that might not be the actual truth, right? Like that might not actually be what's going on. It's just, you don't know what you don't know cuz you don't have it at your fingertips.
Eric:
Yeah. And I think there's a habit people have of treating strategy as if there a strategy it's a noun, it's a proper thing. And I, I view strategy. I think you've said this a few minutes ago, much more like product management. It's a continuous behavior and you have to immerse like coming into a strategy is one of the hard things that I do as a consultant. I drop into different companies all the time and I spend a deep amount of time just trying to swim in the strategy and I can go out to the investor DDEX and get some of it and I can see their quarterly reports. And that kind of tells me what the company believes is important enough to share. And then I can go interview a bunch of different executives and I can have drinks with different product managers. And like through all this, I can get a pretty good social view working model of what their strategy is because it's the things that are important.
And then the moment you try to add a quantitative layer, you've just drowned another layer of data to your point, that takes months to gather. And, and I think we spend too much time there instead of on the storytelling and the figuring out what's important. What do we truly care about out? And I don't wanna take anything away from the disciplines of market analysis and segmentation and the deeply quantitative capabilities people can bring to that. But if we don't start with the story and we don't start with the ethos and the mindset and the values of what the company believes is important, then I, I, I think you get a mechanical strategy the same way you can get mechanical processes. And I'm curious, and this may be a question back if I'm allowed to do that. Yeah. Can a, can you get inspired product management within a mechanical strategy?
Melissa:
I don't, I don't know. I don't think so. Um, what I, I come into companies, right. And the biggest issues that I see is that there is a strategy that's usually mechanical. Like you're talking about. And my biggest question for everybody is what does that mean? Right? Like it's like a super hand wavy strategy where it's like, be the best. cool. like, what does that mean? Like be the best at what? Right. Or hit these goals. Okay. But how right. And you know, the, how is for the teams to figure out, but like what does that goal mean? Why are we going after those goals? Where are they really coming from? Um, it's the hardest place I've seen for product managers to really thrive because, uh, in those cases too, they're usually not seen as strategic thinkers, like we're talking about. And like you just mentioned, it's like they were seen as people that get that mechanical strategy and then go execute on them.
Right. But they have no say like what happens, this is what always happens in this case is like, they go start executing on the strategy. And at some point they realize this isn't the right strategy and you go right now what, but it was a mechanical strategy that was written down. So it's not allowed to be questioned. And that's where we get back into this whole cycle of you just keep building and building and building and get into this build trap. But yeah, I, I, I don't think so. I don't, I think that's the point is like, you don't get any of that. If you're just doing it for the sake of like, Hey, we went into a room for three hours and we came out with this and we gotta go hit these numbers go, cuz it doesn't emerge naturally then.
Eric:
Yep. And I'll, and I'll, I'll flip that back and say in the same way of what you just said, you can't get a inspired creative process. Nor can you get an evolving flow based architecture out of a mechanical strategy and environment either. Yep. So I, I think in environments of the unquestioned strategy where there's no feedback loop from reality to the strategy and from the internal market to the strategy, then you're going to get mechanical, everything, product management, SAFe, everything else was gonna feel very mechanical and top down machine like. Yep. For sure. Um, and the best you can hope for is a feature factory or a build trap there. Yep. Which may be better than you have. Don't get me wrong. But like I, this is where a lot of it comes back to the, at least a top table, whether it's the top table of a product or a portfolio, maybe not the whole company, but ideally the whole company needs to inspect and recognize that evolution is real.
Like iteration is a concept at every scale in a company and it's getting faster and faster and that's why, why agility and things like that are important. We need faster decision, response time. We need the ability to reason we need the ability to react and change. Um, like my working definition these days for business agility is the, it's the ability to sense create and respond, to change both in external and internal markets. And I've explicitly added that last phrase because as any meaningful size company, your inside is unknowable, you have to sense your market internally the same way you have to sense your market externally.
Melissa:
That's cool. I like that too in SAFe. Like where do you, I'm looking at the diagram again. Um, but I'm trying to find like how do you do the feedback loops between portfolio, large solution, essential like those three different layers? What is, is there a specific cadence, a specific ritual or anything that you do to feed that information all the way back up into your strategy?
Eric:
Um, I have a talk that I do that I talk about purpose deployment and aligning the different hierarchies and there is a purpose hierarchy and SAFe, but it's the one hierarchy that's not visible. It's scattered across the diagram. It's not clear. And you could say that's a prioritization decision and that you would probably be accurate. Um, cuz it's easy to see like, okay, here's story feature, uh, capability, it's big invisible and right there vertically aligned on the picture. I can see the people hierarchy. Here's the team, here's the leadership triads at the various levels all the way up to the portfolio. Um, I can see this cadences and how those sec, between the day level cadence, the iteration level, the quarterly cadence and so on up. But we don't talk about vision as a hierarchy. And I think vision and and purpose as a hierarchy is where you find that feedback loop you're looking for. You convey purpose downward and you learn from whether that purpose is good or healthy through the metrics and the KPIs and achievement of your OKRs and the faster and smoother you can make those relationships across the levels. The, um, easier and better will be. And maybe I'll send you that slide to, um, put in the show notes cuz I've got it all on one page that just kinda shows how they line up. Cool. And, and to answer your question, it's all about respecting the linkages across the levels and ensuring those relationships are healthy. And that's the human relationship between your like product manager and product owner, your system architect and your tech leads and kind of things like that. It's your backlog hierarchy, but do the stories accurately reflect the intent of the feature to the features accurately respect the intent of the, the larger, epic, or capability or theme you're working towards. Um, does your team level charter and vision match the purpose of your release, trains, charter and vision match your portfolio goals? And if you kind of mess up any of those hierarchical cross layer relationships, you're gonna get some interesting behaviors for all definitions of interesting
Melissa:
Yeah, that makes sense. Um, okay, so it's not readily shown though in here, but we're basically relying on the conversations of people and the storytelling and the, the vision architecting to, to pull those things together.
Eric:
Yeah. And I think some thing that's not clear to people at a glance, you that kind of gray Tabby thing off to the right. Yeah. On the side of the diagram, we call the spanning pallet the stuff out there by definition are the things that apply at all the levels. Oh, okay. So they're not off the side and separate it's like you will have an enterprise roadmap, you'll have a portfolio roadmap, you have a product roadmap, you might even have a team roadmap, um, shared services. You might have a release train that has a five person group that's supporting technology, um, infrastructure like system teamy type stuff. Or you might put that up to levels. Um, you have enterprise milestones and then as you get further down the organization, there's more and more unique to the product type milestones. Like everybody in the company cares about your big trade show every year. Um, but only the, um, you used Stripe as an example, um, only the team owning a certain vendor relationship for the backend processing cares about their milestones. So that that team has additional milestones. Um, so everything on that right hand pallet is just kind of here are really useful concepts that you can apply at whatever level makes sense. Um, I could argue design thinking should be over there and customer centricity could be over there, but then, then it looks less important as opposed to being right at the front of the pipeline.
Melissa:
Okay. Yeah. That makes sense. Um, I could see that too. That helps. I'm like I'm looking at this now and I'm like, that does make more sense now. I did not know what that little thing was for. Um, so, you know, in that kind of vein of things, as we're thinking, uh, know as we're wrapping up, what if you could go and you do this, I guess. So like if you could go change some stuff about SAFe, what would you like to see change? What do you think are some of the biggest pitfalls? What do you think are some of the areas where you would like to improve or enhance?
Eric:
Um, so one the surface areas already there. So I'll use that to talk about it. If you click the overview tab at the top of the big picture, you, you see the seven competencies, there's 21 things that companies need to get really good at. And if I could go back and change anything, I would start with this in almost every case. Like I, I print this in and that's the big picture I put at the front of the room when I teach and then halfway through with the executives, I might pull out the big picture if I need it. So I, I would, I would go back and spend a lot more time anchoring on the competency view of the world rather than the table of contents view. Um, and I do in my day to day, but it's hard as, as soon as you try to take theory in concepts and make it real, you end up on the mechanical side, you're trying to tactically do stuff.
And as soon as you start doing stuff, you start creating weight and drag and all the burden of writing code. You know, you know, this is a product manager, like the more code you write, the harder it is to be a great product manager, cuz it's slows you down and you've got drag. Um, so I would go back and I would put more and more energy into purpose. Um, truly having the customer in the center as the picture finally shows here and um, anchoring on the competencies and what you need to be good at as a company to be truly agile or inspired agile as opposed to what do you need to go do?
Yeah. Um, beyond that, I would probably find more ways to bubble the principles up. So again, in a table of contents, view of SAFe, the, the principles are at the bottom, you click, you get the core values and the principles and kinda that's the important stuff. And it's visually there. And the storyline around it is this is the foundation like lean agile leadership is your foundation. If your leaders don't behave this way, the rest of everything above it fails. And you'll notice it kind of visually reflects the house of Lean's type style thing, where you have the goal of business agility at the top and lean agile leadership at the bottom and then a pile of icons instead of pillars, but that gets lost. So the other thing I do is like almost have a collapsed view that is core values, mindset and principles for first.
And we teach that as the entire first day. Like when you, when you are exposed to SAFe and a good instructor will spend most of the first day talking about the agile principles and lean mindsets and so on. But then as soon as you get into the rest of it, you forget that. So I do a lot more work trying to bake that back into everything, what that's necessary, like everything in the course where and how people talk about it and what we advertise and everything else. I would probably spend more time there, because I think that's where you get the real change.
Melissa:
I feel like that's similar to like how we think about, you know, team level agile processes as well. It's one of the biggest things I hear from all the agile practitioners, right. Is like focus on the agile manifesto and the values and the principles of the agile manifesto, but not so much on the mechanics. And everybody gets really pulled into it told me how to do it this way. Right. But they're not thinking through the context. They're not thinking through the why. They're not thinking through the purpose of like what those things really drive. Um, and that's a lot of what I've seen was SAFe too. So I, I do like that focus on, you know, bring back these values, think about those things, really do it. And if you didn't know what the values of SAFe was, cuz I didn't, until I clicked on that button down there that I didn't even know existed. It's built in quality transparency, program execution and alignment, which are all things that you need to run a company really well, which is great. So like I agree with those core values, um, what would you suggest for companies that maybe are getting started with SAFe and trying to figure out if it's right for them? Like what are the things they should look at to say, is this the thing that we should adopt for us?
Eric:
So I'm gonna, I'm gonna channel Ray Arell who led transformation Intel for many years. And I think you and I both view as somewhat of a mentor. Um, and I remember him standing on stage and saying scrum and SAFe. They're both countermeasures. If you don't have the problem that's trying to of don't use the solution. And what I take away from that is start with the problem, start with why really go and understand what problems in your enterprise are you trying to fix? What goals are you trying to achieve You cannot achieve today and hold SAFe up against those. Don't hold SAFe up against other process frameworks. Don't hold SAFe up on its own as a, a standalone decision. Look at what you're trying to achieve, what aspirations you have at a company and what is standing in your way of achieving those aspirations and challenge yourself.
Can I solve those problems better if I use a tool like this because the goal must remain. And I, I struggle with this day in day out at every transformation I support and lead, the goal must remain, what are we trying to achieve? And how are we trying to make this company better, more are capable, more responsive to the market. And if even for a moment, you start to fall into agile for agile sake or SAFe for SAFe sake or scrum for scrum sake or any variation of agile is the purpose of its own. Then your agile transformation is on the cusp of failure because the moment it loses sight of the goals is trying to achieve your starting down a mechanical path. And the further down that path you get, the harder it is to pull it back.
Melissa:
I think definitely some wise things for us to think about as we go out on our transformation journeys. So thank you so much for being with us again today, Eric. And if you did not listen to the first episode with Eric, I highly re you go back and listen to that too. Um, it was very insightful, a lot about the context of SAFe and um, you know, what we see companies doing wrong, which was fantastic to start with. Uh, where can everybody find out more about you and learn more about what you teach?
Eric:
Um, LinkedIn is my kind of go to, you can find a fairly outdated website at ericwilleke.com and my day to day business website at elevate.to.
Melissa:
Great. So thanks again for listening to the product thinking podcast. We'll be back again next Wednesday with another dear Melissa episode. And if you have any questions for me, remember that you can submit them to dear melissa.com. Thanks so much for listening and thanks Eric for being with us.