Rich Visotcky: Welcome back, everybody. I think this is the first time here on air that we have had Jim, Sander, and I all together. The crazy trio finally together. Jim and I have recorded a bunch together here. You've seen a bunch of that. Jim and Sander, you've recorded together for a while, but now how did this happen? How did we all just get here together at this exact same time?
Jim: The way we always
Sander: Oui.
Jim: do, Sander says let's let's record.
Sander: Let's do dumb shit and then somehow we end up here.
Rich Visotcky: You were wonderful at just throwing those ideas out there. Like including I I think the last time we did that and we were just talking about drinking whiskey. We probably did a lot of dumb shit when we were drinking a bunch of whiskey together out
Sander: Yes.
Rich Visotcky: in Boston. Yeah, yeah. It happens.
Sander: I missed that man, I missed that.
Rich Visotcky: I do too. Those those gatherings informally over conversations, drinks, food, that's where like the the real meat happens. We should maybe do one of these whole episodes where we are loudly chewing into the mica. I'm sure our People would love that, but at least we'd have a conversation over a meal. And that'd be
Sander: Yeah.
Rich Visotcky: good sometime too.
Sander: It you know, that always makes me think about things I recommend in organizations as well to also make this actually tied to something that happens in organizations. change does not happen in meetings, change does not happen in spreadsheets, nor does it happen in Miro or with AI. Change actually happens in these Typically off-limit conversations, the conversations that you usually don't have when you're sitting in an office space. It really happens at the smoking area during lunch when you go out for a walk. But especially with beers down in a bar where everyone could let their guard down and be a little bit more like they are like they really are. And then you have these authentic conversations and not just looking into spreadsheet. Ooh, do these numbers mean? No, now we can talk real talk. And Whiskey, etc., really does help. the conversations that we had as PSTs in PST face to face, especially those in Boston, etc. That's when you really connect to people and when you can have a normal conversation, man to man or woman to woman, person to person. Because something that I see too often in organizations that people speak to a position, speak to the suit and a title rather than to an actual conversation or sorry, to an actual person, right? And that is something that you can just not be in a bar. In in a bar, you're not that man that manager or that CEO or that high ranking person. You're just another guest in the bar and you're talking to a normal person rather than anything else. So yeah, definitely it is a good idea to to have a whiskey, have a beer, have some informal drinks with your team, with your stakeholders to actually get shit done.
Jim: Is it change that happens in those places or do you think it's better categorized as like inspiration or brainstorming or innovation? Or is it change?
Sander: I've seen more effective results come out of these conversations that then get traction than in in meetings themselves that take way too long. Like the the proportion of investment when it comes to time, conversations, meetings, etcetera, in in the office versus those are effective in bars, the bars win time over time.
Rich Visotcky: and even then, is it really innovation? Because like no one plans innovation. Actually, I should correction plenty of people plan innovation, and that's just not how it works, right? Just innovation is a creative act, it happens in that moment. It reminds me of one of my friends, one of my favorite quotes for that friend gave is that you can't force poetry. Right? The the good things just happen. And yet I think it's maybe human connection that happens in there. And sometimes when you actually make a connection. That's when we start to find those. Ooh, we could do this together. Right. we've unlocked this either idea together. We found a problem together. Let's go work on it together.
Sander: How often do you come across teams, organizations in general that really have a good idea of what innovation truly means?
Rich Visotcky: Very infrequently.
Sander: infrequently is already very gentle, I would say, very generous. In my experience it's mostly perceived what they what organizations that I come across see as innovation is actually just finishing stuff that was already on the board, but then now they actually take time for it.
Jim: Yeah, I I see very, very little innovation. I see a lot of people trying to create market parity, you know, compete with their their their market competitors and say, well they have this, so we have to have that. I I think true innovation, solving in existing problems in a whole new way or creating something new for a new market is extremely rare these days. And and it's becoming more rare because people are de there's a bias to well that that must already exist. And there's a a phrase that I heard recently from a product designer, which is called not invented here. And these big companies, many of them have a either a stated or an a subconscious or unstated policy of if it's not invented here, it doesn't matter how good the idea is. Because they don't want to deal with paying people for their idea. They don't want to pay outsiders. There's probably many psychological things behind that reason that a company would say, Well, that's a great idea, but it's not ours. It didn't originate here, so we're not even gonna entertain it.
Rich Visotcky: Your your prompt there about not invented here got me thinking about the the remaining member of our Fantastic Four mentioned recently. we were talking about frameworks, right? And like what what do people actually need to use? And I think that's a case where companies go in the opposite direction. I don't know what what you've seen, but when people talk about how they operate, they want to import it. They they specifically don't want to invent it here. They're bringing in Scrum. They're bringing in Kanban. They bring in Safe. They bring in, you know, PMP. They it doesn't matter what it is, but they're always bringing in something from somebody else to tell them what to do that wasn't necessarily designed for them. Maybe it was designed for ultra generic or something else. And I feel like they get lost a lot of the times along the way by trying to import this thing that wasn't invented here. Jim, but I have you seen that too, only one here?
Jim: Yeah, I mean I think we probably should just make sure the three of us have shared understanding of what we mean when when we say framework. So my my description of a framework is it's scaffolding. It's required elements, usually of a process or method to do something. I I think of it like a skeleton or like the framing in a in a house. You can add things to it, but the framework provides kind of like that structural load-bearing entity. And I think often I've seen people and clients say, Well, we want some of this, but none of that, and and we want to add this thing to it. Or this won't work here. We've tried this before. And that's kind of in this spirit of, well, when does a framework? How do I know if this is a load-bearing wall that I that I shouldn't remove, or if this is something that I can remove or something that I can add. How how do the two of you see the concept of a framework, I guess?
Rich Visotcky: Sander, why don't you kick it off
Sander: A framework to me is nothing else but the outer walls that we can push against. Right? It's that's all what I always convey in in the trainings I teach, especially when they are in person, it's easier to do there. Like we have the outer walls, but it doesn't describe how we operate within these four walls. We can decide whatever we want to do as long as it makes sense to us and they can actually deliver something. Now the rules of these walls are don't drill holes in there. Don't throw in the window. You know Anything that does not touch or break the structural integrity of those walls. Other than that, a framework is nothing but that to push against. Does that resonate with as well, Rich?
Rich Visotcky: Yeah, what what it the word that resonated with me that you said was rules. simple set of rules to follow that tell me what needs to be done or what can't be done, but never how to go and do it. Right? Like that I I played soccer, I've played Ultimate, the the rules on the game are pretty simple. How each team plays it, how each player goes about. achieving those rules and trying to to score, win the game, it's really kind of up to them. But, you know, it's a it's something that we can all come back to and use to figure out, all right, how are we gonna, how are we gonna satisfy this rule? How are we gonna achieve its purpose and move on from there?
Jim: I I have an example that I believe to be related to this concept of designing a framework. But if it is ends up being a tangent, let me know. Do either of you have a firm opinion? I'm gonna ask a two-part question. Is I'm curious your opinion on the concept of a vertical sliced work item. And I'm gonna be kind of vague and not use certain words to not trigger anybody, but a work item. That contains multiple elements of the solution. It could be copy, could be audio, could be video, could be UI, could be back end business logic, could be mainframe level coding, versus more higher quantity of component or segmented things. Like A, do you have an opinion on that? And B is the modern way of work and the the influence of AI and agentic things, is it changing that?
Rich Visotcky: I'll kick that one off. I have an opinion. And to even get away from vertical slice, something usable is what I go to. Right. And I don't care how we're building it or what it is. You give me a part that I can't do anything with. Doesn't matter. so I I think that that focus on what's the what's the thing I'm trying to solve here? What's the problem that I'm trying to get at? And what's that. work piece look like. I don't care what goes into it. If I haven't solved the problem, if I can't use the the solution in some kind of way, it's it's just a step that I have to wait on until I can get to that solved problem.
Sander: Exactly. I would agree with that. Yeah. And i it doesn't doesn't matter if you do that with Scrum, with cloud, with AI, your stakeholders don't care about how you do it as long as you get their problems fixed, right? If you go to the garage with your car, you're not gonna ask what type of oil that they use to change it or k what kind of size of of the wrench they they use to to untie everything. You just scare that your car gets fixed.
Jim: Well, so the and the reason I'm asking is I'm getting a lot of pushback from a new client who is saying, Jim, to write items the way you are suggesting, just the way I've always suggested them, which is exactly what the two of you are saying, is in I don't want to have to do the sum of the parts. I want our backlog items to be actually useful and valuable independently. It requires usually people to work together because I have ran across full stack people, but I've never ran across a single team where every single person can do everything. And I'm like, exactly. That's the point. The point of creating items like this is that you are going to need to collaborate. You're gonna need to work with your teammates. I'm just curious if if You agree. And if if this holds true, when I see the size of teams and the makeup of teams changing rapidly in the last year to eighteen months.
Sander: There's multiple things there and to to unpack. I think that people have to work together as a result of because PBIs in general in itself are nothing. Like they
Jim: Mm-hmm.
Sander: are not useful, they're not valuable, they're not nothing. They're just a way to write down what out what someone else came up with, ideally, and sometimes transcribe through AI, but still it comes from somewhere else. So PBIs themselves don't hold any value, it's useless. To hold against anything. It just facilitates the conversation around it, or should facilitate facilitate the conversation around it, especially if you focus on user stories. Now, many organizations, many teams I've worked with, PBI is almost synonym to user stories. However, if your user stories are not written by or with your user, they are no user stories. They are just stories, or I actually call them Puma stories. Pulled out of my ass because we're just we're thinking about stuff that doesn't exist. That we pretend that we know our users want, which we don't because we didn't talk Does that then result in talking to users or having multiple people work together to actually fixing something? Yeah. But the original th point of product back to guides is being useful, that does not uphold because they're not.
Rich Visotcky: it also made me think a little bit about the the collaboration aspect, Jim, and I were you implying that this this person you were working with didn't want their teams to collaborate and was almost trying to manage when they when they did or didn't collaborate in their work?
Jim: Yes. The the
Rich Visotcky: Okay.
Jim: the the implication is we have subject matter experts. Why would we create work items that would require an expert in one thing to work with an expert in another? And I and to tie this all back to the a framework, Scrum is a framework. It is an empirical process control framework. And it is still, no matter what anybody wants to say, as far as the the most recent surveys, industry-wide surveys that I've seen, the most popular framework across respondents in the world, full stop, no ifs, ands, or buts. So if we assume that Scrum is Scrum and and Kanban's are methods, strategies, frameworks, et cetera, and they use those. And they believe in the concept of a team to different extents, but Scrum, I I feel believes in the concept of a team. And I the way I describe it is it's we versus me. I think expecting people to work together is good. The subject matter expert, silo, whatever you want to call it, whatever is anti-that. is is the alternative.
Rich Visotcky: to even come away from that and build upon what Sander said, the with the product backlog meaning nothing, that it's the end result that matters, we're often at a place where we maybe aren't skilled enough or experts enough to do all of that work ourselves. And we're also maybe mismanaging it, like managing the work at the wrong level. So by the time it gets to whoever's gonna do it, I don't care how they want to break down the work. Right? That that doesn't matter and and perhaps in your case this manager was trying to manage at a level that they shouldn't have. They're trying to manage some of these more specific detailed type things rather than saying like what is the problem that you're trying to solve. And as the world of work has evolved, especially with the advent of AI, sometimes we might be able to leverage AI to either replace one of those experts or act as one temporarily if we don't have them there. Like I I think that's great as a solo Person, like I'm not great at everything. I don't know every programming language out there. And I can use AI though to help me with certain aspects of that and then check its work and augment alongside, right? As a almost like a team member, but not as a team member. And so that collaboration to me is I'm now thinking about how do when do I want to get involved in the details of the work, but when is it the problem that I'm trying to solve that comes along? And it Whereas if I had a team, I would just be working with them, like, hey, we need to talk about this because let's go and take this grand idea that somebody pulled out their ass. It's probably me in this case, right? And go solve that problem. Right? You know, versus just like, right, well, let me tell you what to go do. I think that's just the wrong level of the work. We've already gone too far
Sander: Well
Rich Visotcky: and are probably wasting time with that kind of breakdown.
Sander: Yeah, and there you know, there's multiple aspects in this this conversation so far that A that resonate obviously but also that are very widespread. A to come back to what Jim was saying, Scrum is one of the most popular frameworks, if not the f most popular framework out there. However, Scrum is a single team framework. And if you apply that in organizations that work in a scaled environment with many, many, many teams working together, without considering, like now we have to apply a scaled framework, and I don't mean safe. Please, by all means, do not use safe, but anything else that actually supports the achievement of your goals, whether that's Nexus Less safe, safe or anything else that does help you in the right direction, then you'll immediately move away from Scrum. You still have You're a single team Scrum, but combined with other elements. So per default you're not doing Scrum anymore, right? And that now I'm getting into the nitty-gritty of the the framework itself. But that's what I see again, like the last couple of days when I'm train when I'm teaching in in large enterprise organizations, you completely forget about the whole value stream and it's so siloed into a single team component. we were talking about one of the trainings is envisioning and storytelling, so they're they're building their visions that we were talking about. what should my vision be in my team? I'm just a small part in this whole chain. Then you don't have a product vision for your team because you do not have a product, you have a component of, like there is a very small cog in the whole system. Look at the whole system, and that is how it should be optimized. And if that's not there. If there's no system for this, if there's no framework for that, you should develop something for yourself. Like what Spotify did. I would love to see that in more organizations. And I don't mean that organizations should adopt the Spotify framework because A, it doesn't exist, but B copy pasting something that worked in other organizations is almost guaranteed to fail in yours. Find something that works for yours. And especially now what you were saying, Rich, with the event of AI now coming down and raining on everyone's shoulders. But there are no guardrails, there are no outer walls to push against. In place in many organizations, this is going to be a shit show for many. End of rant.
Jim: So
Rich Visotcky: I love that take. It it also it makes me think like, you know, when you said going up to scale, I purposely avoided dipping my toes into offering any kind of scaled framework methodology, whatever, to any of my clients, because by the time you get to that level, we're getting so integrated into how this organization operates and what they're trying to achieve, none of them fit. They're just they're a mess. So I less safe, whatever. They're good in their own right. I just I would never recommend to a client to implement any of them. I would say let's build that from the ground up. I don't know, Jim. Are you do you encounter the same? Is it is it different for you? Yeah.
Jim: Hundred per hundred percent. And I I use the same phrase every time. Nail it before you scale it. Do do good single team something. Scrum, Kanban, custom, whatever you come up with, do it well small, and then build it out. Do not
Sander: Organically.
Jim: Or yes. And only build it out to solve a problem. Like you're saying, Sander, like if you have multiple teams working in an organization on one product, you you're gonna need a at least some other mechanism or layer inside your framework to coordinate, to map dependencies, map trajectory, look at speed and and change and all this stuff. But then stop. Don't go to the extreme. It just sounds so easy to say that. I feel like I've been saying that for 15 years because I have, but there are still people that need to that need to hear it. I want to come back to the concept of a framework because I feel that a framework is not synon the word framework or the concept of framework is not synonymous with process. And your description, Sander, of the outside walls. leads me to believe that you kind of see a framework as a form of a of a constraint or a box or a boundary. And I'm wondering if we can agree that things like workflows, vocabulary, metrics would fall under the umbrella term of framework.
Sander: I would say they are complementary to but not part of.
Jim: Okay, so let's say I have a
Rich Visotcky: I back that up.
Jim: framework to deliver value for a product at this company, a specific company. What what how would I visualize that framework? Like if I if somebody said, can you describe this framework? We're about to hire eight people. We need
Sander: Yes.
Jim: to hand them something. What what would be like how would I describe the framework to someone?
Sander: So so essentially you're looking for like what are minimum components of a framework?
Jim: Minimum and maximum er maybe not maximum, but like where does that boundary stop? Where does something become a complementary practice and a core practice of a comp of any given company's custom framework?
Sander: Ooh, I've got some ideas on this, but Rich, you tell me.
Rich Visotcky: Yeah, to me it it's when you start getting into you have to do it this way. Not you know, you have to provide this result, but you have to do it in in a certain specific kind of way. We might be getting a little bit beyond framework to that point in time. so it when when you said metrics, that was the red flag for me. Cause I'm like, how why do I have to Why do I have to look for very specific numbers or like how I go and get them or whatnot? It it's a maybe too far of a constraint that doesn't encounter the fact that those might not be the right metrics. Might still be going after the same objective, but we don't actually we're not actually measuring the right things to get there. so yeah.
Jim: Well, let me add something to this then and let you two react to it. So let me give you an example about metrics, since it seems like you've both kind of keyed in on that. I normally I I think all three of us do, but I also normally work at the leadership level that has multiple teams working together. And an example of what I mean by metrics is i if I have a product with a value stream that's that five teams are working on. And and I need to be able to set people's expectations around the company. I have to set mechanical engineering's expectation. I have to set the factories expectation. I have to set the help desk expectation, like when we're going to release the next version and when they can and expect an influx in customer calls. I need numbers to influence like that trajectory, that roadmap. When when are we likely to have that? When are we likely to have this? So what I mean
Sander: That's the last one.
Jim: by as part of the framework to say every team in this framework that's going to work together. needs to report on throughput. And we want as a leadership level to be looking at let's just say work item aging. And we want to look at this calculated field. Like we have this certain field in all of our backlogs that if something pops to the top of that, it's it's a stop everything and work on that. Those three little elements, and we're not even gonna dictate how you have to calculate those inside each team, but we're saying these are the three things that we need to be able to steer by, govern by, drive by, set expectations by. Is that in the spirit of being in the framework or is that too far?
Sander: I would say its throughput is already so specific that people will take that as an actual. Like you have to have throughput. It assumes that there is throughput. Right? And it so that means that if we do not finish anything, we have no throughput and therefore the framework doesn't work. And then you'll get in within two months, you'll have no framework X is dead. Doesn't work. Doesn't work here. Not invented by us. Whereas, like let's take my window here. It is literally within a frame, right? And it just has the outer walls. You can complement it with sunscreens, you can decorate it, you can do all sorts of things. But the core components are that light should come through, and I've got thrip the triple glass. So it should have X, Y, Z, I don't know what the exact isolation numbers are, but it should insulate to a certain level. It should also not fall out, so it should be sturdy enough that we can push against something and it has a goal, which is to let light in and to protect me from the elements outside. But it doesn't say how did that actually actually is being done, it's not being described, and it can I can complement with all sorts of things.
Rich Visotcky: Jim, and everything you described, I was I'm hearing a a hidden problem or a hidden need behind it. Right? Like you you're talking about the ability to forecast and go through this, you know, throughput. I I agree, it's it's already way too specific. Why do we have it? What's it for? And and what's it's really for is like, did we create something that solves the problem? How do we know that we solved the problem? How and how are we checking in that we've actually and validating that that's happened? So it's it's less around creating throughput and using that to plan out a potential release. It's that, you know, can you know, can we get this thing solved? And like Sander said with the window, its whole purpose is to let light in. The even even what you were saying on its efficiency rating to me doesn't matter. I you used to have single pane glass windows right here that would whistle and you know what it got windy. and they suck, but they did their job as a window. And I replaced them with more efficient windows, and I they're they're quieter, they're more comfortable. That's great, but their job its job is to let this light in. And that's and they stay as part of the house. That's it. Right. So, how do I make sure it's still doing its job and it's doing its job well? You know, I can put a hole here, but then I guess the other part of a window is it lets me actually close off the outside from my house without you know removing its visibility.
Sander: Yeah, so it solves the problem of being exposed to the elements. And I think I think a core part of a framework is rules of empowerment slash ownership. Like who owns what, who does what, who should not do anything. I think that might be even more explicit. Like I think that's one of the things that I miss with Scrum to be more explicit on that no one that I I don't want to have that ambiguo ambiguity, I would say. That anyone else can overrule product owners in in their job. And if so, if you're gonna create a a framework for yourself, also make it very specific. Like other people who are not in the team do not own or decide on XYZ. Maybe at like as as a as an appendix at the end, which is where appendices are, but make it very specific. Also define a little bit of a cadence, like how often do we check in? So we can ha we have some expectation of progress. At least to check in whether we are indeed making progress. But also very clear problem statements that we should solve.
Jim: when Ryan threw out this concept of designer framework, my immediate thought was I refer to this as cafeteria scrub, cafeteria agility, cafeteria whatever. Meaning I I got my tray and I I'm company A. I got my tray and I I'm gonna say I want a little bit of this, a little bit of this tapioca pudding, give me a little bit of the yellow stuff, give me a little bit of pork. Give me a little bit of this dessert. Cool. That's my meal. That's what I like. Somebody else can come right along from the same company but on a different team or a different company, Company B, and build a whole other tray made up of processes, frameworks, vocabularies, metrics, and all that, and and grab their tray and leave. that's fine in theory. But when you have multiple people working together, I find it a little bit to be utopian to think that we don't need any level of consistency. I think that's where the experience hand comes in to say to people, you wanna swing a hammer and break down that scaffolding or you don't want to add this to your tray, here's why that's a really shitty idea.
Sander: I agree. I think consistency is key here, but that doesn't mean it has to be consistent across multiple organizations. Consistency comes from the team executing it.
Jim: No, not across multiple organizations. But what about across multiple teams at one organization? Because like what I find with your guys' opinion on throughput is it seems to be, and correct me if I'm wrong, is we should be measuring value and outcomes over throughput, which maybe you're interpreting as like counting things. And I would say, well. I I didn't necessarily mean just counting things, but I find that counting value is much, much harder for organizations than counting things. So I normally start with them by saying you have four teams working together on this release. This one is releasing zero things. This one is releasing 14 things. Now we don't know if it's 14 pieces of shit or if it's zero big giant things that are about to to be a huge amount of of value for the company, but I just find it useful to have a common vocabulary and some numbers that we're all going to look at and let people react to that than to say, I'm just gonna blindly trust these four groups that are working together on one big thing
Rich Visotcky: yeah.
Jim: to do whatever
Sander: the
Jim: they want.
Sander: the danger in that is that that is then being perceived to be progress, whereas I would argue that the only measure of progress is the number or number of problems resolved versus the impact that has made.
Jim: Sure.
Sander: And we can have a fucking high level of throughput and still resolve shit. So did we prove the progress? Doubtful.
Rich Visotcky: and I think for me, I wasn't going for like the output outcome, split there. It was more of just there is a meta piece behind throughput and it's more around managing work, like managing a flow of work or communicating you know, with people that you're gonna collaborate with, either someone downstream that depends on something that you have, managing the amount of waste that you've got going on in your system. something like that is more of when I hear throughput, that's what it's for, right? The number on its own doesn't really matter. But if I understand I'm getting way more things out than I could possibly consume and validate that have actually produced some kind of value, it might actually tell me that I should slow down. But it again, it goes back towards the validation of did I solve the problem? Is there an issue in the way that? work moves within my organization or that people collaborate within my organization. If if they're just, you know, trying to stay busy, or it like you said in your teams, one team's producing zero, another team's producing a lot, I'm not gonna say either team is necessarily better than the other. One just might be getting blocked by somebody or might not be able to consume something or whatever else. It's an indicator to go find the other problem. that needs to be solved within that whole value stream, that within that whole workflow right there.
Jim: Well, I I'll tell you my opinion on the concept of a framework when clients ask me about this and and when they challenge the the concept of any framework, any structure or consistency. Okay. and I wanna and then I have a question at the end of it that just came from a client meeting Friday. And I'm very curious to see how you two feel about this. So my opinion is There is no right framework. There is no right process. There is no right vocabulary. But we need something. When we don't have anything, when people are struggling because of a lack of consistency or lack of shared understanding, we need something. And everything I do is written in pencil, meaning it can change. But we need something for people to react to instead of just saying if there is no right answer or perfectly healthy answer, then there's no answer. Like to me, that's a problem. But the conversation Friday the comment was made to me, we were talking about a process and specifically a workflow, a series of steps that a work item moves through. And at one end of that spectrum is to do doing done. And at the other end of that spectrum is a highly granular 18 step process. And I was advocating for something in the middle, but maybe a little more granular. Not overengineered, not down in the minutiae, but definitely more than not started, started and done. And my opinion on that, well actually I'll get to my opinion. The comment that was made that I'm curious what your guys' reaction to is a process will not change people's behavior.
Sander: No, incentive does.
Jim: Okay. Tell me more. What do you mean by that?
Sander: People don't see the reason or feel the reason to change, they won't. The process does not create an incentive for people to change. If you put a gun to their heads, which I highly recommend you don't, they will start running.
Jim: All right. What do you think, Rich? Will a process change people's behavior?
Rich Visotcky: A process could influence a change in their behavior. I don't think on and it might change it temporarily, but if it's not aligned with what they're trying to do or what they want, whatever incentivizes them, that process will become a shadow process. a shadow process will come out out of that, and people will start acting and working and communicating about something completely different. than whatever the official, the espoused way of working is.
Sander: Yeah. And the other way around as well. Like if you give them an incentive of well, if we do this, we solve the most frustrating part for people in their divorce process. and and you know, create something that el alleviates people from their stress levels, that's a very different incentive than describing the process how we get there. like Simon Cynic always says, people don't buy your product about w for what it does, but why it does what it does, or why you do it, decide actually. It is really the reasoning why behind it that be that makes people move. Literally, quite quite literally and and and metaphorically.
Rich Visotcky: Yeah. I think that a good process could help create the conditions to have things work the way you want them to, that they weren't before. And that might influence and incentivize people to follow the process or change in the way in which they work. But they already wanted to go there. Something else was probably preventing them from doing it in the first place. And so I totally agree with what Sander said that if if you're connecting the why behind this processor framework, which You know, that's the part that I went to in my mind was Action Manifesto and individuals and interactions over processes and tools. If I have a process that supports the people and how they're interacting with each other and what they're trying to achieve, they're more likely to follow that process. If it's if it forces on them different types of interactions that just do not gel with how what they're you know, what they're trying to do and how they want to interact, they will ignore it and come up with a different process.
Jim: So let me okay.
Sander: I got a question for both of you, regarding process. Processes are standardized ways of working, right? Standardization implies that there is a certain level of predictability. Would you then argue that in the complexity that we work and that Scrum operates and the other frameworks operate, processes cannot survive because we have such a high level of volatility and therefore predictability and therefore stable standardization is just a utopia.
Rich Visotcky: the type of work that we do, that feels pretty close. Like not that, you know, standardization isn't you know impossible, but it's usually better fit for more repeatable problems.
Jim: I always say standardization and standards suck, but consistency is is amazing. Consistency makes people feel good, safe. it reduces cognitive load so that people can use their brain more. I've had many people say, Well, aren't those the same thing? Aren't standards the same as consistency? I'm like, no, they're not even close, in my opinion. And maybe I'm being pedantic, but consistency might be like we have a way of measuring throughput. We have five teams, and they might all measure it very slightly differently. Some might use a value-based metric, some might use a raw quantity. We might have a support team that's measuring the the number of calls, but we all know why we're doing it. And we're saying we are trying to show you this is what we're doing. This is how this is how it's going. This is our burn rate. That's consistency without forcing a standard because you I don't know that you could find a standard that would work for a support team, a blue sky, blue ocean team, and a team that's supporting components of the whole that have been around for 15 years. And to me, that's the difference is standards. I have the same appeal feeling on standards as I do on best practices. Like
Sander: Yeah.
Jim: Reject the concept out of hand because there are no, there is no one best practice, singular. Now there could be practices, there could be best practices that often work, but that's to me more in line with consistency than it is standardization.
Sander: Yeah, so the what you're saying means that we cannot standardize a process for delivering our work. We can do that with measuring stuff like the metrics and and how to visualize them. That can be followed by a process. But resolving problems does not cannot be done with a process.
Jim: Well, I I'll give you a re a a very real recent small example is I
Sander: Uhhuh.
Jim: was sub suggesting a certain workflow, a a series of steps that work items go through. And the objection that was raised was, yeah, yeah, but what about epics? Epics epics don't go through this stage or this stage. So
Sander: Who fucking cares?
Jim: so the whole thing is shit. I'm like, no. All of those, in my opinion, have a if applicable at the end of them. Meaning if something doesn't apply, then you let the humans use their brain to say, that doesn't apply here, so I'm gonna move it to the next thing that does apply. Well, but then then it's not standard, so why do it? Well, because it's consistent. Because we're reducing the the amount of of mental load that already overburdened engineers are having to expend thinking about the right word in the right scenario for the right type of work and we're we're being more consistent.
Sander: and I'm gonna be an asshole with this, but that means that standardization immediately excludes innovation because there's nothing standard about innovation, so therefore these people would not innovate either.
Jim: Let's come back to I want to hear what Rich says about that, but I wanna c I wanna challenge the idea that there is no way of being innovative. Because I've learned something in the last couple weeks that has
Sander: You cannot standardize innovation.
Jim: let's put a pin in that for 60 seconds because I've had my world rocked in the la in the last two weeks on this topic. Yeah.
Sander: Not good for you. I'm happy for you.
Jim: Yeah. Yeah, he's he's a really sexy guy. He rocked my world.
Sander: Rich.
Rich Visotcky: The the the cap that was coming up to me, Jim, on on what you just mentioned. I I like the separation between standards and consistency. Standardization and consistency. Cause like I mean I standards I think of like, you know, a meter is defined by the amount the the distance that a sp beam of light travels in a vacuum over a specific period of time, right? So like that's a standard. Everyone can use it, no matter where you go, it doesn't matter where you are. And the consistency though is is good. Like and you keep you keep coming back to like definitions that help make things more clear, more specific, you know, that and that those definitions might be different in different organizations. A perhaps a good framework allows us to set and make those definitions clear and specific, even create standards if we need to. and it should create that consistency without forcing standardization. Like everything has to go through exactly this process. So I would want a framework to to add consistency more than standardization. So that when I do run into that issue, how can I be consistent in how I approach it or solve it while figuring out what's the right approach for this specific thing? Or as things might change.
Sander: Measuring progress against your goals? Like do do we make any meaningful
Rich Visotcky: Yeah. Yeah. Measuring progress against your goals, measuring
Sander: step toward the resolution of this problem? And if the answer is yes, we're
Rich Visotcky: Yeah.
Sander: making progress toward making progress.
Rich Visotcky: And internal and external goals, like goals that are internal towards your your group, how you're working, you know, just being more more effective in the result, or even more efficient. I don't care. and external goals, whoever you're serving, who benefits from your services and goods, those you know, people like the the problems you're solving for them. you still need a way to measure your progress towards those goals.
Sander: I agree. Yeah. Jim, standardization of innovation.
Jim: I'm a part of a couple other communities and one of them is is around making, fabrication, design, whatever you want to call it, across mediums. Metal, wood, 3D printing, whatever. Last year I read Rick Rubin's book about creativity, and I read some stuff by David Lynch about his creative process. And there's a really good book. And I'm looking for the name of the book and the author that I can drop in the show notes. But there is a process for creative problem solving. I think you'd be fine with it because it's not to say this is exactly how you do it, but it's to say these are required step or okay, maybe not required steps, but these are steps in the process to be creative, to solve a problem.
Sander: Well I said they're more like rules.
Jim: Yeah, I I guess. Like an example is one of them is, and I'm paraphrasing here, so don't don't come at me with pitchforks in this, but one of them is bring all the materials, information or goods that you need about the problem to to one place.
Sander: Yes, so refine the problem.
Jim: Okay. Well, not even refining the problem, but bringing the materials. Like if you are trying to solve a problem for the the physical production of something, like you might go out and find four of the last things you produced and all the components and the boards and the wires and the and you might put them all in one place.
Sander: Sure. Essentially centralization of resources around the problem. Yeah.
Jim: Yeah. Then you you you understand the problem and you you really clarify like what is the problem with this?
Sander: Mm-hmm. Mm-hmm.
Jim: And then one of the steps is after you go through the the these first two or th and three steps is you you walk away for a little bit. And
Sander: Mm-hmm.
Jim: the belief here is that the innovation, the actual critical thinking is going to occur when you're not staring at those things. Now, can you mandate this? Can you create a framework around creative problem solving? Sure, many people have. if you just Google creative problem solving techniques or frameworks, you'll get thousands of responses from Toyota to IDEO to Mockfla, all different types of process tools and people that think they've got it figured out.
Sander: Yeah. There's one prerequisite to walk in a way, and that's you actually have time to let your brain ease. Because if you're in the office and you're gonna go do work, your mind immediately gets filled. That is also why men always win arguments under the shower, because then they have like the capability, the capacity, the mental capacity to actually think and let these ideas sink in. Right? And then they
Jim: No.
Sander: r they go over the conversation again, yada yada yada yada. Because then you actually have the space. To think about this to contemplate and to let those processes in your mind roam freely.
Jim: Right. Well and and and that's my point is is it could you create a framework for that? Absolutely, you could create a framework for that that is both lightweight and adaptable, but yet is a series of required elements or scaffolding or load-bearing walls or whatever analogy we want to use to help people do that. You can't guarantee an outcome, but I think you can set people up. to be more effective because when it comes to anything in life like I think you can find a process that is consistent behind it.
Sander: Yes. There is a
Rich Visotcky: I think
Sander: by the at the University of Haifa, the her name is Mycellas. I'm not I'm pretty sure I butchered, but this I did some research on this. This is actually the first part in The Anatomy of a Product. it's about generating original original ideas, the neural underpinning of originality. That's what the thesis is called that dives into this. that you you need the mental clarity to actually make these things stick and that you know. You may your brain makes the the better connections when you have the downtime to actually relax a little bit and to think about that. So that's why nature typically is a a a freeing space to come up with original ideas.
Rich Visotcky: the thought that popped in my head as we as you were talking about how we come up with the original ideas and the types of structures that can help you solve problems. And Jim, you when you said can't guarantee an outcome, but I can give you a way perhaps to get to one. all these discussions we're having here on on building a framework, I think, are really interesting because what we are talking about is I don't think we've actually helped Build a framework for anybody right now. And that's maybe a good thing for everyone out there, is that we're not trying to say this these are the things you must go do if you want to do the product fields framework. We maybe uncovered though a bunch of principles that a framework could have, like a good framework could have to help you go through and and achieve whatever your purpose is. It's to to ideate and problem solve, to build a product. for someone and solve a problem to become successful in your industry, to help reorganize your teams, many different frameworks out there. But we're getting towards some just key principles of keeping that problem in mind, all right, setting some measurements against your goals, that that sense of consistency by if you're gonna define something, make sure it's explicit, Let let everyone see that whole system. Those are not these are not rules like we would define in a framework, but they're the principles that would underpin anything that we came up with from here.
Sander: I would say so. I would like to take
Rich Visotcky: I like that. I
Sander: a to take another time. I know you gotta go, Rich, I but I would I'm I'm very much interested in diving into this topic a little deeper in another another moment. Let's see what we can come up with to make it little bit more explicit for organizations to really start working with their stuff.
Rich Visotcky: Yeah. Yeah. I think, you know, and while you all wait with bated breath to get towards that next discussion, maybe something to keep in mind in your own sense as you're looking at how are we going to get through these next few months as we as we wrap up the year, as we kick off a new financial year, is that what are some of the principles that underlie the way in which we want to work, the way in which we want to to treat each other, the types of things that we're trying to go and achieve together. And if you keep those principles in mind over the specifics on how you should go and work, it might help get you to a better place.
Sander: Like that.
Jim: Can we end with
Rich Visotcky: Jim?
Jim: just a an opinion on if this custom framework thing is good or bad? or any caveats you would give a listener if they're going to design a bespoke framework?
Rich Visotcky: Take it off since I kicked off the whole thing.
Sander: If it works then stupid.
Rich Visotcky: What's it, Sander?
Sander: If it works today and stupid.
Rich Visotcky: I think it's good. I think that when you build a framework or a process or whatever you have based off of what you're trying to achieve and and what you know, it's going to work for you. And you might not have the most ideal things because like Jim, you were talking about before the cafeteria angle, right? Or something like that. You maybe don't know the extra pieces you should bring in. But least you're starting from a sense of what you're trying to achieve and solving that problem and learning from there. So I'm all about designing your own thing because you're going to stick with it and learn a lot more that way. Jim, what's your take on that?
Jim: My my take is it's fine to design something bespoke for your team, your company, your department, whatever, but please be careful and get an outside opinion about your blind spots. Because I'm a big believer in what's called Gaul's Law, which is any complex system that is found to work has evolved from a simple system that works. So I I normally tell people we need to start somewhere. Let's start, let's not start at the easiest thing in the world. Let's not start at the hardest thing in the world. Let's find something middle, but let's let's write it in proverbial pencil so that we can add things or remove things as we go on. it's not good or bad. It's like most things in life. A in moderation and B, just be careful and know that we are all. But if you're gonna call something custom and or bespoke because you're gonna ignore the hard parts or the shit that won't work here in favor of what will, you're missing the point. Because a good framework should stand alone and it should require it should not just be what you can do today. It should be what will work. And if that requires you to make changes or to spend political capital or to challenge the way the organization has always done something, that is the point.
Sander: I agree. And then as a last question, and then I will brutally shut up, but I think this is an essential one. Do you feel, do you agree, that every framework should have the option to continuously evolve and adapt to something that works for to the like the progressive insights?
Rich Visotcky: Yes, and it should provide the kinds of constraints that Jim was just talking about. Right? It it it should give you a set of bounds to figure out how to evolve, to keep you focused.
Jim: Yes, it should. The timescale that we use to review it should grow because we should be rapidly iterating and adapting early. And then there should reach a point where it's like th this is just how we work now. But it doesn't mean we can never change it, but it means we probably don't need to talk about it every week, every two weeks, or even every month, because that puts a load on people and it creates a bias that if you're asking me if we should change this, many people will say, Well, of course, we should make this change. And then
Sander: Yeah. So
Jim: you're you're overworking it. You're over kneading the dough. you're watching the water boil or you're you're Keep opening the oven to look at your pizza, and you're actually harming the end product. There needs to be a point where it is good enough is good enough for a while, and then something will happen. Either you'll have a lot of success, you'll be like, damn, we had that success because our framework. We work the system.
Sander: Yes.
Jim: The system works and we work the system. Or you'll have a problem and you're like, shit, we forgot about that. Let's adapt. our framework, our way of working to account for that new thing that just happened.
Sander: meaningfully or mindfully adapt based on emerging insights and with that every framework should be an agile framework. And I think that is the perfect one line to conclude to conclude this episode.
Jim: The way we always
Sander: Oui.
Jim: do, Sander says let's let's record.
Sander: Let's do dumb shit and then somehow we end up here.
Rich Visotcky: You were wonderful at just throwing those ideas out there. Like including I I think the last time we did that and we were just talking about drinking whiskey. We probably did a lot of dumb shit when we were drinking a bunch of whiskey together out
Sander: Yes.
Rich Visotcky: in Boston. Yeah, yeah. It happens.
Sander: I missed that man, I missed that.
Rich Visotcky: I do too. Those those gatherings informally over conversations, drinks, food, that's where like the the real meat happens. We should maybe do one of these whole episodes where we are loudly chewing into the mica. I'm sure our People would love that, but at least we'd have a conversation over a meal. And that'd be
Sander: Yeah.
Rich Visotcky: good sometime too.
Sander: It you know, that always makes me think about things I recommend in organizations as well to also make this actually tied to something that happens in organizations. change does not happen in meetings, change does not happen in spreadsheets, nor does it happen in Miro or with AI. Change actually happens in these Typically off-limit conversations, the conversations that you usually don't have when you're sitting in an office space. It really happens at the smoking area during lunch when you go out for a walk. But especially with beers down in a bar where everyone could let their guard down and be a little bit more like they are like they really are. And then you have these authentic conversations and not just looking into spreadsheet. Ooh, do these numbers mean? No, now we can talk real talk. And Whiskey, etc., really does help. the conversations that we had as PSTs in PST face to face, especially those in Boston, etc. That's when you really connect to people and when you can have a normal conversation, man to man or woman to woman, person to person. Because something that I see too often in organizations that people speak to a position, speak to the suit and a title rather than to an actual conversation or sorry, to an actual person, right? And that is something that you can just not be in a bar. In in a bar, you're not that man that manager or that CEO or that high ranking person. You're just another guest in the bar and you're talking to a normal person rather than anything else. So yeah, definitely it is a good idea to to have a whiskey, have a beer, have some informal drinks with your team, with your stakeholders to actually get shit done.
Jim: Is it change that happens in those places or do you think it's better categorized as like inspiration or brainstorming or innovation? Or is it change?
Sander: I've seen more effective results come out of these conversations that then get traction than in in meetings themselves that take way too long. Like the the proportion of investment when it comes to time, conversations, meetings, etcetera, in in the office versus those are effective in bars, the bars win time over time.
Rich Visotcky: and even then, is it really innovation? Because like no one plans innovation. Actually, I should correction plenty of people plan innovation, and that's just not how it works, right? Just innovation is a creative act, it happens in that moment. It reminds me of one of my friends, one of my favorite quotes for that friend gave is that you can't force poetry. Right? The the good things just happen. And yet I think it's maybe human connection that happens in there. And sometimes when you actually make a connection. That's when we start to find those. Ooh, we could do this together. Right. we've unlocked this either idea together. We found a problem together. Let's go work on it together.
Sander: How often do you come across teams, organizations in general that really have a good idea of what innovation truly means?
Rich Visotcky: Very infrequently.
Sander: infrequently is already very gentle, I would say, very generous. In my experience it's mostly perceived what they what organizations that I come across see as innovation is actually just finishing stuff that was already on the board, but then now they actually take time for it.
Jim: Yeah, I I see very, very little innovation. I see a lot of people trying to create market parity, you know, compete with their their their market competitors and say, well they have this, so we have to have that. I I think true innovation, solving in existing problems in a whole new way or creating something new for a new market is extremely rare these days. And and it's becoming more rare because people are de there's a bias to well that that must already exist. And there's a a phrase that I heard recently from a product designer, which is called not invented here. And these big companies, many of them have a either a stated or an a subconscious or unstated policy of if it's not invented here, it doesn't matter how good the idea is. Because they don't want to deal with paying people for their idea. They don't want to pay outsiders. There's probably many psychological things behind that reason that a company would say, Well, that's a great idea, but it's not ours. It didn't originate here, so we're not even gonna entertain it.
Rich Visotcky: Your your prompt there about not invented here got me thinking about the the remaining member of our Fantastic Four mentioned recently. we were talking about frameworks, right? And like what what do people actually need to use? And I think that's a case where companies go in the opposite direction. I don't know what what you've seen, but when people talk about how they operate, they want to import it. They they specifically don't want to invent it here. They're bringing in Scrum. They're bringing in Kanban. They bring in Safe. They bring in, you know, PMP. They it doesn't matter what it is, but they're always bringing in something from somebody else to tell them what to do that wasn't necessarily designed for them. Maybe it was designed for ultra generic or something else. And I feel like they get lost a lot of the times along the way by trying to import this thing that wasn't invented here. Jim, but I have you seen that too, only one here?
Jim: Yeah, I mean I think we probably should just make sure the three of us have shared understanding of what we mean when when we say framework. So my my description of a framework is it's scaffolding. It's required elements, usually of a process or method to do something. I I think of it like a skeleton or like the framing in a in a house. You can add things to it, but the framework provides kind of like that structural load-bearing entity. And I think often I've seen people and clients say, Well, we want some of this, but none of that, and and we want to add this thing to it. Or this won't work here. We've tried this before. And that's kind of in this spirit of, well, when does a framework? How do I know if this is a load-bearing wall that I that I shouldn't remove, or if this is something that I can remove or something that I can add. How how do the two of you see the concept of a framework, I guess?
Rich Visotcky: Sander, why don't you kick it off
Sander: A framework to me is nothing else but the outer walls that we can push against. Right? It's that's all what I always convey in in the trainings I teach, especially when they are in person, it's easier to do there. Like we have the outer walls, but it doesn't describe how we operate within these four walls. We can decide whatever we want to do as long as it makes sense to us and they can actually deliver something. Now the rules of these walls are don't drill holes in there. Don't throw in the window. You know Anything that does not touch or break the structural integrity of those walls. Other than that, a framework is nothing but that to push against. Does that resonate with as well, Rich?
Rich Visotcky: Yeah, what what it the word that resonated with me that you said was rules. simple set of rules to follow that tell me what needs to be done or what can't be done, but never how to go and do it. Right? Like that I I played soccer, I've played Ultimate, the the rules on the game are pretty simple. How each team plays it, how each player goes about. achieving those rules and trying to to score, win the game, it's really kind of up to them. But, you know, it's a it's something that we can all come back to and use to figure out, all right, how are we gonna, how are we gonna satisfy this rule? How are we gonna achieve its purpose and move on from there?
Jim: I I have an example that I believe to be related to this concept of designing a framework. But if it is ends up being a tangent, let me know. Do either of you have a firm opinion? I'm gonna ask a two-part question. Is I'm curious your opinion on the concept of a vertical sliced work item. And I'm gonna be kind of vague and not use certain words to not trigger anybody, but a work item. That contains multiple elements of the solution. It could be copy, could be audio, could be video, could be UI, could be back end business logic, could be mainframe level coding, versus more higher quantity of component or segmented things. Like A, do you have an opinion on that? And B is the modern way of work and the the influence of AI and agentic things, is it changing that?
Rich Visotcky: I'll kick that one off. I have an opinion. And to even get away from vertical slice, something usable is what I go to. Right. And I don't care how we're building it or what it is. You give me a part that I can't do anything with. Doesn't matter. so I I think that that focus on what's the what's the thing I'm trying to solve here? What's the problem that I'm trying to get at? And what's that. work piece look like. I don't care what goes into it. If I haven't solved the problem, if I can't use the the solution in some kind of way, it's it's just a step that I have to wait on until I can get to that solved problem.
Sander: Exactly. I would agree with that. Yeah. And i it doesn't doesn't matter if you do that with Scrum, with cloud, with AI, your stakeholders don't care about how you do it as long as you get their problems fixed, right? If you go to the garage with your car, you're not gonna ask what type of oil that they use to change it or k what kind of size of of the wrench they they use to to untie everything. You just scare that your car gets fixed.
Jim: Well, so the and the reason I'm asking is I'm getting a lot of pushback from a new client who is saying, Jim, to write items the way you are suggesting, just the way I've always suggested them, which is exactly what the two of you are saying, is in I don't want to have to do the sum of the parts. I want our backlog items to be actually useful and valuable independently. It requires usually people to work together because I have ran across full stack people, but I've never ran across a single team where every single person can do everything. And I'm like, exactly. That's the point. The point of creating items like this is that you are going to need to collaborate. You're gonna need to work with your teammates. I'm just curious if if You agree. And if if this holds true, when I see the size of teams and the makeup of teams changing rapidly in the last year to eighteen months.
Sander: There's multiple things there and to to unpack. I think that people have to work together as a result of because PBIs in general in itself are nothing. Like they
Jim: Mm-hmm.
Sander: are not useful, they're not valuable, they're not nothing. They're just a way to write down what out what someone else came up with, ideally, and sometimes transcribe through AI, but still it comes from somewhere else. So PBIs themselves don't hold any value, it's useless. To hold against anything. It just facilitates the conversation around it, or should facilitate facilitate the conversation around it, especially if you focus on user stories. Now, many organizations, many teams I've worked with, PBI is almost synonym to user stories. However, if your user stories are not written by or with your user, they are no user stories. They are just stories, or I actually call them Puma stories. Pulled out of my ass because we're just we're thinking about stuff that doesn't exist. That we pretend that we know our users want, which we don't because we didn't talk Does that then result in talking to users or having multiple people work together to actually fixing something? Yeah. But the original th point of product back to guides is being useful, that does not uphold because they're not.
Rich Visotcky: it also made me think a little bit about the the collaboration aspect, Jim, and I were you implying that this this person you were working with didn't want their teams to collaborate and was almost trying to manage when they when they did or didn't collaborate in their work?
Jim: Yes. The the
Rich Visotcky: Okay.
Jim: the the implication is we have subject matter experts. Why would we create work items that would require an expert in one thing to work with an expert in another? And I and to tie this all back to the a framework, Scrum is a framework. It is an empirical process control framework. And it is still, no matter what anybody wants to say, as far as the the most recent surveys, industry-wide surveys that I've seen, the most popular framework across respondents in the world, full stop, no ifs, ands, or buts. So if we assume that Scrum is Scrum and and Kanban's are methods, strategies, frameworks, et cetera, and they use those. And they believe in the concept of a team to different extents, but Scrum, I I feel believes in the concept of a team. And I the way I describe it is it's we versus me. I think expecting people to work together is good. The subject matter expert, silo, whatever you want to call it, whatever is anti-that. is is the alternative.
Rich Visotcky: to even come away from that and build upon what Sander said, the with the product backlog meaning nothing, that it's the end result that matters, we're often at a place where we maybe aren't skilled enough or experts enough to do all of that work ourselves. And we're also maybe mismanaging it, like managing the work at the wrong level. So by the time it gets to whoever's gonna do it, I don't care how they want to break down the work. Right? That that doesn't matter and and perhaps in your case this manager was trying to manage at a level that they shouldn't have. They're trying to manage some of these more specific detailed type things rather than saying like what is the problem that you're trying to solve. And as the world of work has evolved, especially with the advent of AI, sometimes we might be able to leverage AI to either replace one of those experts or act as one temporarily if we don't have them there. Like I I think that's great as a solo Person, like I'm not great at everything. I don't know every programming language out there. And I can use AI though to help me with certain aspects of that and then check its work and augment alongside, right? As a almost like a team member, but not as a team member. And so that collaboration to me is I'm now thinking about how do when do I want to get involved in the details of the work, but when is it the problem that I'm trying to solve that comes along? And it Whereas if I had a team, I would just be working with them, like, hey, we need to talk about this because let's go and take this grand idea that somebody pulled out their ass. It's probably me in this case, right? And go solve that problem. Right? You know, versus just like, right, well, let me tell you what to go do. I think that's just the wrong level of the work. We've already gone too far
Sander: Well
Rich Visotcky: and are probably wasting time with that kind of breakdown.
Sander: Yeah, and there you know, there's multiple aspects in this this conversation so far that A that resonate obviously but also that are very widespread. A to come back to what Jim was saying, Scrum is one of the most popular frameworks, if not the f most popular framework out there. However, Scrum is a single team framework. And if you apply that in organizations that work in a scaled environment with many, many, many teams working together, without considering, like now we have to apply a scaled framework, and I don't mean safe. Please, by all means, do not use safe, but anything else that actually supports the achievement of your goals, whether that's Nexus Less safe, safe or anything else that does help you in the right direction, then you'll immediately move away from Scrum. You still have You're a single team Scrum, but combined with other elements. So per default you're not doing Scrum anymore, right? And that now I'm getting into the nitty-gritty of the the framework itself. But that's what I see again, like the last couple of days when I'm train when I'm teaching in in large enterprise organizations, you completely forget about the whole value stream and it's so siloed into a single team component. we were talking about one of the trainings is envisioning and storytelling, so they're they're building their visions that we were talking about. what should my vision be in my team? I'm just a small part in this whole chain. Then you don't have a product vision for your team because you do not have a product, you have a component of, like there is a very small cog in the whole system. Look at the whole system, and that is how it should be optimized. And if that's not there. If there's no system for this, if there's no framework for that, you should develop something for yourself. Like what Spotify did. I would love to see that in more organizations. And I don't mean that organizations should adopt the Spotify framework because A, it doesn't exist, but B copy pasting something that worked in other organizations is almost guaranteed to fail in yours. Find something that works for yours. And especially now what you were saying, Rich, with the event of AI now coming down and raining on everyone's shoulders. But there are no guardrails, there are no outer walls to push against. In place in many organizations, this is going to be a shit show for many. End of rant.
Jim: So
Rich Visotcky: I love that take. It it also it makes me think like, you know, when you said going up to scale, I purposely avoided dipping my toes into offering any kind of scaled framework methodology, whatever, to any of my clients, because by the time you get to that level, we're getting so integrated into how this organization operates and what they're trying to achieve, none of them fit. They're just they're a mess. So I less safe, whatever. They're good in their own right. I just I would never recommend to a client to implement any of them. I would say let's build that from the ground up. I don't know, Jim. Are you do you encounter the same? Is it is it different for you? Yeah.
Jim: Hundred per hundred percent. And I I use the same phrase every time. Nail it before you scale it. Do do good single team something. Scrum, Kanban, custom, whatever you come up with, do it well small, and then build it out. Do not
Sander: Organically.
Jim: Or yes. And only build it out to solve a problem. Like you're saying, Sander, like if you have multiple teams working in an organization on one product, you you're gonna need a at least some other mechanism or layer inside your framework to coordinate, to map dependencies, map trajectory, look at speed and and change and all this stuff. But then stop. Don't go to the extreme. It just sounds so easy to say that. I feel like I've been saying that for 15 years because I have, but there are still people that need to that need to hear it. I want to come back to the concept of a framework because I feel that a framework is not synon the word framework or the concept of framework is not synonymous with process. And your description, Sander, of the outside walls. leads me to believe that you kind of see a framework as a form of a of a constraint or a box or a boundary. And I'm wondering if we can agree that things like workflows, vocabulary, metrics would fall under the umbrella term of framework.
Sander: I would say they are complementary to but not part of.
Jim: Okay, so let's say I have a
Rich Visotcky: I back that up.
Jim: framework to deliver value for a product at this company, a specific company. What what how would I visualize that framework? Like if I if somebody said, can you describe this framework? We're about to hire eight people. We need
Sander: Yes.
Jim: to hand them something. What what would be like how would I describe the framework to someone?
Sander: So so essentially you're looking for like what are minimum components of a framework?
Jim: Minimum and maximum er maybe not maximum, but like where does that boundary stop? Where does something become a complementary practice and a core practice of a comp of any given company's custom framework?
Sander: Ooh, I've got some ideas on this, but Rich, you tell me.
Rich Visotcky: Yeah, to me it it's when you start getting into you have to do it this way. Not you know, you have to provide this result, but you have to do it in in a certain specific kind of way. We might be getting a little bit beyond framework to that point in time. so it when when you said metrics, that was the red flag for me. Cause I'm like, how why do I have to Why do I have to look for very specific numbers or like how I go and get them or whatnot? It it's a maybe too far of a constraint that doesn't encounter the fact that those might not be the right metrics. Might still be going after the same objective, but we don't actually we're not actually measuring the right things to get there. so yeah.
Jim: Well, let me add something to this then and let you two react to it. So let me give you an example about metrics, since it seems like you've both kind of keyed in on that. I normally I I think all three of us do, but I also normally work at the leadership level that has multiple teams working together. And an example of what I mean by metrics is i if I have a product with a value stream that's that five teams are working on. And and I need to be able to set people's expectations around the company. I have to set mechanical engineering's expectation. I have to set the factories expectation. I have to set the help desk expectation, like when we're going to release the next version and when they can and expect an influx in customer calls. I need numbers to influence like that trajectory, that roadmap. When when are we likely to have that? When are we likely to have this? So what I mean
Sander: That's the last one.
Jim: by as part of the framework to say every team in this framework that's going to work together. needs to report on throughput. And we want as a leadership level to be looking at let's just say work item aging. And we want to look at this calculated field. Like we have this certain field in all of our backlogs that if something pops to the top of that, it's it's a stop everything and work on that. Those three little elements, and we're not even gonna dictate how you have to calculate those inside each team, but we're saying these are the three things that we need to be able to steer by, govern by, drive by, set expectations by. Is that in the spirit of being in the framework or is that too far?
Sander: I would say its throughput is already so specific that people will take that as an actual. Like you have to have throughput. It assumes that there is throughput. Right? And it so that means that if we do not finish anything, we have no throughput and therefore the framework doesn't work. And then you'll get in within two months, you'll have no framework X is dead. Doesn't work. Doesn't work here. Not invented by us. Whereas, like let's take my window here. It is literally within a frame, right? And it just has the outer walls. You can complement it with sunscreens, you can decorate it, you can do all sorts of things. But the core components are that light should come through, and I've got thrip the triple glass. So it should have X, Y, Z, I don't know what the exact isolation numbers are, but it should insulate to a certain level. It should also not fall out, so it should be sturdy enough that we can push against something and it has a goal, which is to let light in and to protect me from the elements outside. But it doesn't say how did that actually actually is being done, it's not being described, and it can I can complement with all sorts of things.
Rich Visotcky: Jim, and everything you described, I was I'm hearing a a hidden problem or a hidden need behind it. Right? Like you you're talking about the ability to forecast and go through this, you know, throughput. I I agree, it's it's already way too specific. Why do we have it? What's it for? And and what's it's really for is like, did we create something that solves the problem? How do we know that we solved the problem? How and how are we checking in that we've actually and validating that that's happened? So it's it's less around creating throughput and using that to plan out a potential release. It's that, you know, can you know, can we get this thing solved? And like Sander said with the window, its whole purpose is to let light in. The even even what you were saying on its efficiency rating to me doesn't matter. I you used to have single pane glass windows right here that would whistle and you know what it got windy. and they suck, but they did their job as a window. And I replaced them with more efficient windows, and I they're they're quieter, they're more comfortable. That's great, but their job its job is to let this light in. And that's and they stay as part of the house. That's it. Right. So, how do I make sure it's still doing its job and it's doing its job well? You know, I can put a hole here, but then I guess the other part of a window is it lets me actually close off the outside from my house without you know removing its visibility.
Sander: Yeah, so it solves the problem of being exposed to the elements. And I think I think a core part of a framework is rules of empowerment slash ownership. Like who owns what, who does what, who should not do anything. I think that might be even more explicit. Like I think that's one of the things that I miss with Scrum to be more explicit on that no one that I I don't want to have that ambiguo ambiguity, I would say. That anyone else can overrule product owners in in their job. And if so, if you're gonna create a a framework for yourself, also make it very specific. Like other people who are not in the team do not own or decide on XYZ. Maybe at like as as a as an appendix at the end, which is where appendices are, but make it very specific. Also define a little bit of a cadence, like how often do we check in? So we can ha we have some expectation of progress. At least to check in whether we are indeed making progress. But also very clear problem statements that we should solve.
Jim: when Ryan threw out this concept of designer framework, my immediate thought was I refer to this as cafeteria scrub, cafeteria agility, cafeteria whatever. Meaning I I got my tray and I I'm company A. I got my tray and I I'm gonna say I want a little bit of this, a little bit of this tapioca pudding, give me a little bit of the yellow stuff, give me a little bit of pork. Give me a little bit of this dessert. Cool. That's my meal. That's what I like. Somebody else can come right along from the same company but on a different team or a different company, Company B, and build a whole other tray made up of processes, frameworks, vocabularies, metrics, and all that, and and grab their tray and leave. that's fine in theory. But when you have multiple people working together, I find it a little bit to be utopian to think that we don't need any level of consistency. I think that's where the experience hand comes in to say to people, you wanna swing a hammer and break down that scaffolding or you don't want to add this to your tray, here's why that's a really shitty idea.
Sander: I agree. I think consistency is key here, but that doesn't mean it has to be consistent across multiple organizations. Consistency comes from the team executing it.
Jim: No, not across multiple organizations. But what about across multiple teams at one organization? Because like what I find with your guys' opinion on throughput is it seems to be, and correct me if I'm wrong, is we should be measuring value and outcomes over throughput, which maybe you're interpreting as like counting things. And I would say, well. I I didn't necessarily mean just counting things, but I find that counting value is much, much harder for organizations than counting things. So I normally start with them by saying you have four teams working together on this release. This one is releasing zero things. This one is releasing 14 things. Now we don't know if it's 14 pieces of shit or if it's zero big giant things that are about to to be a huge amount of of value for the company, but I just find it useful to have a common vocabulary and some numbers that we're all going to look at and let people react to that than to say, I'm just gonna blindly trust these four groups that are working together on one big thing
Rich Visotcky: yeah.
Jim: to do whatever
Sander: the
Jim: they want.
Sander: the danger in that is that that is then being perceived to be progress, whereas I would argue that the only measure of progress is the number or number of problems resolved versus the impact that has made.
Jim: Sure.
Sander: And we can have a fucking high level of throughput and still resolve shit. So did we prove the progress? Doubtful.
Rich Visotcky: and I think for me, I wasn't going for like the output outcome, split there. It was more of just there is a meta piece behind throughput and it's more around managing work, like managing a flow of work or communicating you know, with people that you're gonna collaborate with, either someone downstream that depends on something that you have, managing the amount of waste that you've got going on in your system. something like that is more of when I hear throughput, that's what it's for, right? The number on its own doesn't really matter. But if I understand I'm getting way more things out than I could possibly consume and validate that have actually produced some kind of value, it might actually tell me that I should slow down. But it again, it goes back towards the validation of did I solve the problem? Is there an issue in the way that? work moves within my organization or that people collaborate within my organization. If if they're just, you know, trying to stay busy, or it like you said in your teams, one team's producing zero, another team's producing a lot, I'm not gonna say either team is necessarily better than the other. One just might be getting blocked by somebody or might not be able to consume something or whatever else. It's an indicator to go find the other problem. that needs to be solved within that whole value stream, that within that whole workflow right there.
Jim: Well, I I'll tell you my opinion on the concept of a framework when clients ask me about this and and when they challenge the the concept of any framework, any structure or consistency. Okay. and I wanna and then I have a question at the end of it that just came from a client meeting Friday. And I'm very curious to see how you two feel about this. So my opinion is There is no right framework. There is no right process. There is no right vocabulary. But we need something. When we don't have anything, when people are struggling because of a lack of consistency or lack of shared understanding, we need something. And everything I do is written in pencil, meaning it can change. But we need something for people to react to instead of just saying if there is no right answer or perfectly healthy answer, then there's no answer. Like to me, that's a problem. But the conversation Friday the comment was made to me, we were talking about a process and specifically a workflow, a series of steps that a work item moves through. And at one end of that spectrum is to do doing done. And at the other end of that spectrum is a highly granular 18 step process. And I was advocating for something in the middle, but maybe a little more granular. Not overengineered, not down in the minutiae, but definitely more than not started, started and done. And my opinion on that, well actually I'll get to my opinion. The comment that was made that I'm curious what your guys' reaction to is a process will not change people's behavior.
Sander: No, incentive does.
Jim: Okay. Tell me more. What do you mean by that?
Sander: People don't see the reason or feel the reason to change, they won't. The process does not create an incentive for people to change. If you put a gun to their heads, which I highly recommend you don't, they will start running.
Jim: All right. What do you think, Rich? Will a process change people's behavior?
Rich Visotcky: A process could influence a change in their behavior. I don't think on and it might change it temporarily, but if it's not aligned with what they're trying to do or what they want, whatever incentivizes them, that process will become a shadow process. a shadow process will come out out of that, and people will start acting and working and communicating about something completely different. than whatever the official, the espoused way of working is.
Sander: Yeah. And the other way around as well. Like if you give them an incentive of well, if we do this, we solve the most frustrating part for people in their divorce process. and and you know, create something that el alleviates people from their stress levels, that's a very different incentive than describing the process how we get there. like Simon Cynic always says, people don't buy your product about w for what it does, but why it does what it does, or why you do it, decide actually. It is really the reasoning why behind it that be that makes people move. Literally, quite quite literally and and and metaphorically.
Rich Visotcky: Yeah. I think that a good process could help create the conditions to have things work the way you want them to, that they weren't before. And that might influence and incentivize people to follow the process or change in the way in which they work. But they already wanted to go there. Something else was probably preventing them from doing it in the first place. And so I totally agree with what Sander said that if if you're connecting the why behind this processor framework, which You know, that's the part that I went to in my mind was Action Manifesto and individuals and interactions over processes and tools. If I have a process that supports the people and how they're interacting with each other and what they're trying to achieve, they're more likely to follow that process. If it's if it forces on them different types of interactions that just do not gel with how what they're you know, what they're trying to do and how they want to interact, they will ignore it and come up with a different process.
Jim: So let me okay.
Sander: I got a question for both of you, regarding process. Processes are standardized ways of working, right? Standardization implies that there is a certain level of predictability. Would you then argue that in the complexity that we work and that Scrum operates and the other frameworks operate, processes cannot survive because we have such a high level of volatility and therefore predictability and therefore stable standardization is just a utopia.
Rich Visotcky: the type of work that we do, that feels pretty close. Like not that, you know, standardization isn't you know impossible, but it's usually better fit for more repeatable problems.
Jim: I always say standardization and standards suck, but consistency is is amazing. Consistency makes people feel good, safe. it reduces cognitive load so that people can use their brain more. I've had many people say, Well, aren't those the same thing? Aren't standards the same as consistency? I'm like, no, they're not even close, in my opinion. And maybe I'm being pedantic, but consistency might be like we have a way of measuring throughput. We have five teams, and they might all measure it very slightly differently. Some might use a value-based metric, some might use a raw quantity. We might have a support team that's measuring the the number of calls, but we all know why we're doing it. And we're saying we are trying to show you this is what we're doing. This is how this is how it's going. This is our burn rate. That's consistency without forcing a standard because you I don't know that you could find a standard that would work for a support team, a blue sky, blue ocean team, and a team that's supporting components of the whole that have been around for 15 years. And to me, that's the difference is standards. I have the same appeal feeling on standards as I do on best practices. Like
Sander: Yeah.
Jim: Reject the concept out of hand because there are no, there is no one best practice, singular. Now there could be practices, there could be best practices that often work, but that's to me more in line with consistency than it is standardization.
Sander: Yeah, so the what you're saying means that we cannot standardize a process for delivering our work. We can do that with measuring stuff like the metrics and and how to visualize them. That can be followed by a process. But resolving problems does not cannot be done with a process.
Jim: Well, I I'll give you a re a a very real recent small example is I
Sander: Uhhuh.
Jim: was sub suggesting a certain workflow, a a series of steps that work items go through. And the objection that was raised was, yeah, yeah, but what about epics? Epics epics don't go through this stage or this stage. So
Sander: Who fucking cares?
Jim: so the whole thing is shit. I'm like, no. All of those, in my opinion, have a if applicable at the end of them. Meaning if something doesn't apply, then you let the humans use their brain to say, that doesn't apply here, so I'm gonna move it to the next thing that does apply. Well, but then then it's not standard, so why do it? Well, because it's consistent. Because we're reducing the the amount of of mental load that already overburdened engineers are having to expend thinking about the right word in the right scenario for the right type of work and we're we're being more consistent.
Sander: and I'm gonna be an asshole with this, but that means that standardization immediately excludes innovation because there's nothing standard about innovation, so therefore these people would not innovate either.
Jim: Let's come back to I want to hear what Rich says about that, but I wanna c I wanna challenge the idea that there is no way of being innovative. Because I've learned something in the last couple weeks that has
Sander: You cannot standardize innovation.
Jim: let's put a pin in that for 60 seconds because I've had my world rocked in the la in the last two weeks on this topic. Yeah.
Sander: Not good for you. I'm happy for you.
Jim: Yeah. Yeah, he's he's a really sexy guy. He rocked my world.
Sander: Rich.
Rich Visotcky: The the the cap that was coming up to me, Jim, on on what you just mentioned. I I like the separation between standards and consistency. Standardization and consistency. Cause like I mean I standards I think of like, you know, a meter is defined by the amount the the distance that a sp beam of light travels in a vacuum over a specific period of time, right? So like that's a standard. Everyone can use it, no matter where you go, it doesn't matter where you are. And the consistency though is is good. Like and you keep you keep coming back to like definitions that help make things more clear, more specific, you know, that and that those definitions might be different in different organizations. A perhaps a good framework allows us to set and make those definitions clear and specific, even create standards if we need to. and it should create that consistency without forcing standardization. Like everything has to go through exactly this process. So I would want a framework to to add consistency more than standardization. So that when I do run into that issue, how can I be consistent in how I approach it or solve it while figuring out what's the right approach for this specific thing? Or as things might change.
Sander: Measuring progress against your goals? Like do do we make any meaningful
Rich Visotcky: Yeah. Yeah. Measuring progress against your goals, measuring
Sander: step toward the resolution of this problem? And if the answer is yes, we're
Rich Visotcky: Yeah.
Sander: making progress toward making progress.
Rich Visotcky: And internal and external goals, like goals that are internal towards your your group, how you're working, you know, just being more more effective in the result, or even more efficient. I don't care. and external goals, whoever you're serving, who benefits from your services and goods, those you know, people like the the problems you're solving for them. you still need a way to measure your progress towards those goals.
Sander: I agree. Yeah. Jim, standardization of innovation.
Jim: I'm a part of a couple other communities and one of them is is around making, fabrication, design, whatever you want to call it, across mediums. Metal, wood, 3D printing, whatever. Last year I read Rick Rubin's book about creativity, and I read some stuff by David Lynch about his creative process. And there's a really good book. And I'm looking for the name of the book and the author that I can drop in the show notes. But there is a process for creative problem solving. I think you'd be fine with it because it's not to say this is exactly how you do it, but it's to say these are required step or okay, maybe not required steps, but these are steps in the process to be creative, to solve a problem.
Sander: Well I said they're more like rules.
Jim: Yeah, I I guess. Like an example is one of them is, and I'm paraphrasing here, so don't don't come at me with pitchforks in this, but one of them is bring all the materials, information or goods that you need about the problem to to one place.
Sander: Yes, so refine the problem.
Jim: Okay. Well, not even refining the problem, but bringing the materials. Like if you are trying to solve a problem for the the physical production of something, like you might go out and find four of the last things you produced and all the components and the boards and the wires and the and you might put them all in one place.
Sander: Sure. Essentially centralization of resources around the problem. Yeah.
Jim: Yeah. Then you you you understand the problem and you you really clarify like what is the problem with this?
Sander: Mm-hmm. Mm-hmm.
Jim: And then one of the steps is after you go through the the these first two or th and three steps is you you walk away for a little bit. And
Sander: Mm-hmm.
Jim: the belief here is that the innovation, the actual critical thinking is going to occur when you're not staring at those things. Now, can you mandate this? Can you create a framework around creative problem solving? Sure, many people have. if you just Google creative problem solving techniques or frameworks, you'll get thousands of responses from Toyota to IDEO to Mockfla, all different types of process tools and people that think they've got it figured out.
Sander: Yeah. There's one prerequisite to walk in a way, and that's you actually have time to let your brain ease. Because if you're in the office and you're gonna go do work, your mind immediately gets filled. That is also why men always win arguments under the shower, because then they have like the capability, the capacity, the mental capacity to actually think and let these ideas sink in. Right? And then they
Jim: No.
Sander: r they go over the conversation again, yada yada yada yada. Because then you actually have the space. To think about this to contemplate and to let those processes in your mind roam freely.
Jim: Right. Well and and and that's my point is is it could you create a framework for that? Absolutely, you could create a framework for that that is both lightweight and adaptable, but yet is a series of required elements or scaffolding or load-bearing walls or whatever analogy we want to use to help people do that. You can't guarantee an outcome, but I think you can set people up. to be more effective because when it comes to anything in life like I think you can find a process that is consistent behind it.
Sander: Yes. There is a
Rich Visotcky: I think
Sander: by the at the University of Haifa, the her name is Mycellas. I'm not I'm pretty sure I butchered, but this I did some research on this. This is actually the first part in The Anatomy of a Product. it's about generating original original ideas, the neural underpinning of originality. That's what the thesis is called that dives into this. that you you need the mental clarity to actually make these things stick and that you know. You may your brain makes the the better connections when you have the downtime to actually relax a little bit and to think about that. So that's why nature typically is a a a freeing space to come up with original ideas.
Rich Visotcky: the thought that popped in my head as we as you were talking about how we come up with the original ideas and the types of structures that can help you solve problems. And Jim, you when you said can't guarantee an outcome, but I can give you a way perhaps to get to one. all these discussions we're having here on on building a framework, I think, are really interesting because what we are talking about is I don't think we've actually helped Build a framework for anybody right now. And that's maybe a good thing for everyone out there, is that we're not trying to say this these are the things you must go do if you want to do the product fields framework. We maybe uncovered though a bunch of principles that a framework could have, like a good framework could have to help you go through and and achieve whatever your purpose is. It's to to ideate and problem solve, to build a product. for someone and solve a problem to become successful in your industry, to help reorganize your teams, many different frameworks out there. But we're getting towards some just key principles of keeping that problem in mind, all right, setting some measurements against your goals, that that sense of consistency by if you're gonna define something, make sure it's explicit, Let let everyone see that whole system. Those are not these are not rules like we would define in a framework, but they're the principles that would underpin anything that we came up with from here.
Sander: I would say so. I would like to take
Rich Visotcky: I like that. I
Sander: a to take another time. I know you gotta go, Rich, I but I would I'm I'm very much interested in diving into this topic a little deeper in another another moment. Let's see what we can come up with to make it little bit more explicit for organizations to really start working with their stuff.
Rich Visotcky: Yeah. Yeah. I think, you know, and while you all wait with bated breath to get towards that next discussion, maybe something to keep in mind in your own sense as you're looking at how are we going to get through these next few months as we as we wrap up the year, as we kick off a new financial year, is that what are some of the principles that underlie the way in which we want to work, the way in which we want to to treat each other, the types of things that we're trying to go and achieve together. And if you keep those principles in mind over the specifics on how you should go and work, it might help get you to a better place.
Sander: Like that.
Jim: Can we end with
Rich Visotcky: Jim?
Jim: just a an opinion on if this custom framework thing is good or bad? or any caveats you would give a listener if they're going to design a bespoke framework?
Rich Visotcky: Take it off since I kicked off the whole thing.
Sander: If it works then stupid.
Rich Visotcky: What's it, Sander?
Sander: If it works today and stupid.
Rich Visotcky: I think it's good. I think that when you build a framework or a process or whatever you have based off of what you're trying to achieve and and what you know, it's going to work for you. And you might not have the most ideal things because like Jim, you were talking about before the cafeteria angle, right? Or something like that. You maybe don't know the extra pieces you should bring in. But least you're starting from a sense of what you're trying to achieve and solving that problem and learning from there. So I'm all about designing your own thing because you're going to stick with it and learn a lot more that way. Jim, what's your take on that?
Jim: My my take is it's fine to design something bespoke for your team, your company, your department, whatever, but please be careful and get an outside opinion about your blind spots. Because I'm a big believer in what's called Gaul's Law, which is any complex system that is found to work has evolved from a simple system that works. So I I normally tell people we need to start somewhere. Let's start, let's not start at the easiest thing in the world. Let's not start at the hardest thing in the world. Let's find something middle, but let's let's write it in proverbial pencil so that we can add things or remove things as we go on. it's not good or bad. It's like most things in life. A in moderation and B, just be careful and know that we are all. But if you're gonna call something custom and or bespoke because you're gonna ignore the hard parts or the shit that won't work here in favor of what will, you're missing the point. Because a good framework should stand alone and it should require it should not just be what you can do today. It should be what will work. And if that requires you to make changes or to spend political capital or to challenge the way the organization has always done something, that is the point.
Sander: I agree. And then as a last question, and then I will brutally shut up, but I think this is an essential one. Do you feel, do you agree, that every framework should have the option to continuously evolve and adapt to something that works for to the like the progressive insights?
Rich Visotcky: Yes, and it should provide the kinds of constraints that Jim was just talking about. Right? It it it should give you a set of bounds to figure out how to evolve, to keep you focused.
Jim: Yes, it should. The timescale that we use to review it should grow because we should be rapidly iterating and adapting early. And then there should reach a point where it's like th this is just how we work now. But it doesn't mean we can never change it, but it means we probably don't need to talk about it every week, every two weeks, or even every month, because that puts a load on people and it creates a bias that if you're asking me if we should change this, many people will say, Well, of course, we should make this change. And then
Sander: Yeah. So
Jim: you're you're overworking it. You're over kneading the dough. you're watching the water boil or you're you're Keep opening the oven to look at your pizza, and you're actually harming the end product. There needs to be a point where it is good enough is good enough for a while, and then something will happen. Either you'll have a lot of success, you'll be like, damn, we had that success because our framework. We work the system.
Sander: Yes.
Jim: The system works and we work the system. Or you'll have a problem and you're like, shit, we forgot about that. Let's adapt. our framework, our way of working to account for that new thing that just happened.
Sander: meaningfully or mindfully adapt based on emerging insights and with that every framework should be an agile framework. And I think that is the perfect one line to conclude to conclude this episode.
