Arguing Agile

AA240 - Why Product Managers & Solution Architects Are Always at War (And How to Fix It)

• Brian Orlando • Season 1 • Episode 240

Share episode

Is your solution architect a gatekeeper or an enabler? 

Join Product Manager Brian Orlando and Enterprise Business Agility Consultant Om Patel as they draw from their experiences to debate the reasons these roles - which should be natural partners - often find themselves at odds. It's a no-holds-barred look into the eternal conflict between product managers and solution architects!

Watch or listen as we explore:
1. Why the role exists and if it's even necessary
2. Who owns technical decisions
3. How PMs may be part of the problem
4. Three conversations that never happen
5. Identifying architects: shepherds vs. hoarders
6. When and how to escalate (without destroying your career)

They provide actionable takeaways including the "documentation test," the "decision autonomy test," and the "vacation test" to evaluate whether your architect is enabling or blocking your teams.

Whether you're a product manager frustrated by architectural gatekeeping, a solution architect trying to add value without becoming a bottleneck, or a leader trying to resolve these conflicts, this episode offers you solid, practical takeaways that you can start trying today!

#ProductManagement #SolutionArchitect #Leadership

Team Topologies by Manuel Pais and Matthew Skelton, Empowered by Marty Cagan (2020), Five Dysfunctions of a Team by Patrick Lencioni (2002), Radical Candor by Kim Scott, Release It! by Michael Nygard (2017), The Goal by Eliyahu Goldratt, Arguing Agile Episode 67: Team Topologies, Arguing Agile Episode 235: Changing Your Message - Adaptive vs Manipulative Communication, Arguing Agile Episode 236: Why Product Managers Should Own Pricing

LINKS
YouTube https://www.youtube.com/@arguingagile
Spotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Website: https://arguingagile.com/

Brian:

Om, I don't know how to say this. I'm just gonna say it. Solution architects, all the ones that I've worked with anyway. But wow. They're, they're useless. Like they, I sorry. I was, I was trying not to say Okay. I mean, they live in the ivory tower. They make you kiss the ring when you want to make a change, it affects more than one team,

Om:

yeah. What I'm hearing you say is they're as useful as doorknobs on a wall. Okay. That's fine. Let's start with that opening. Although I have to say. in my career, I've only come across one solution architect who actually was worth his soul. This guy really got

Brian:

Oh, so are you arguing the diamond in the rough argument? Is that what Yeah, definitely. Oh boy. Okay. Rough seas. Yeah. Well, so yeah. Well, we're doing it right today.

Om:

Let's do it

Brian:

Welcome back to Arguing Agile. If this is your first time, I'm Brian Orlando. Product manager extraordinaire. and this is my co-host, Mr. Om Patel and Enterprise Business Agility Coach to the starts, Mr. Om Patel.

Om:

Welcome. It's great to be part of this discussion today.

Brian:

we got a comment talking about the relationship between product managers and solution architects, why do product managers and solution architects seem to be at war when they should be partners?

Om:

You're telling me the one person whose literal job is to prevent your product team from building technical debt monsters is the problem

Brian:

I can't even with you can't, like we both can't be sassy for this podcast. No, we can't, but okay. We can try. So, yeah, that brings us to the topic of this podcast the only reason that product managers and architects slash solution architects clash is because the architect role it's not a real role. Anybody that's on the internet crying about how Scrum as is not a real job, that I feel the same way about solution architects. Let's argue about it.

Om:

Awesome. Well, challenge accepted.

Brian:

These are the three things that you're gonna walk away with. You're gonna know why PMs and solution architects clash and probably other positions too. You're gonna we're gonna talk about three conversations that you can use to try to fix the relationship. You notice I said try to, because again, it's not a real position. So I don't know if you're gonna be able to, and then we're gonna give you some tips on how to spot gatekeeping versus actual enabling behavior that helps your teams. That's supposed to be the benefit of having a solution architect is they can go across teams, they can help enable your teams. Right. If like we're looking at team topologies they're supposed to be able to enable your teams. So that's, that's hopefully what people will get outta the podcast.

Om:

Yeah. Maybe we'll leave you a phone number to call Ghostbusters.

Brian:

Or somebody. Or somebody call Tyrone some, somebody You better call somebody, is what I'm saying. The first category here. Is why, why does this role even exist? Right?

Om:

Yeah. Maybe we could just start by defining some of these titles, perhaps, right. Solution Architect or enterprise Architect, et cetera. Who are these people? And how do they wind up in those roles? Solution Architect me is somebody who has performed the duties of a technical lead for some time. And they finagle their way into a realm in the organization where they're hands off basically. In large organizations. I get that you may actually have like an enterprise architecture board or something like that. And these are active members, right? Real card carrying members of that, of that guild, if you will.

Brian:

Technical architect, solution architect. There's a bunch of name. Again, another reason why this is, it's made up like there, do you like my new sassiness level on the podcast? Let's kick into the steelman to talk about the steelman points here are, they're pretty good. Two bullet points that especially for large organizations, they make a big impact and we will address each one of them, right? Number one, like someone's gotta prevent the teams from creating incompatible systems. Or team A is trying to solve a messaging problem, so they like go spin up an entire Reds implementation and architecture or whatever. And then Team B is just using a database. I think about like horror stories from like the old Twitter world where people didn't talk to each other like somebody. It needs to have the final call or at least some sort of oversight. Or like in larger organizations, you would say governance. That would be the dirty word you would use. And then the other one is the product managers here, most of them, they're on LinkedIn posting selfies, trying to make sure their hair looks perfect or whatever. They don't have the deep technical chops to understand what your teams are about to do, so you need someone to be the quote glue between teams to help them. That's the Steelman case. And I feel that's a pretty strong Steelman case in this sense.

Om:

I think there's a slight distinction there between technical architects or solution architects versus enterprise architects. So at the team level, you could go ahead and weave out a solution that your team needs, that's fine. But at an enterprise level, are you creating duplicate solutions? Solutions that compete with one another? Right.. So those things, solutions are, to your point, not compatible but also if you go back to the team level, at a lower level than just the enterprise, we need to ensure that the solutions that are being created at each of these levels can scale up and perform the duties that they're designed for. Yeah so this might be a role for somebody like this person that we're, we're describing a solutions architect To figure out, you know is this solution compatible with what we're doing as a direction with our enterprise?

Brian:

Strong steelman points in this category. I definitely agree. However if I'm gonna push back, I'm gonna say again, this role, like everyone crying about Scrum Masters, same thing with this role. it exists because you've got gaps. Like you never read Team topologies by Manuel Pius and the other guy, Matthew Skeleton. And you never listen to arguing. Agile. 67 team topologies. Organizing business and technology teams for fast flow from June 24th, 2022.

Speaker 4:

Up people.

Brian:

By the way, that was a long time ago. Three years ago, that podcast was formed and we taught you all about team topologies and different types of teams. Well your organization and your tech leads and your CTOs and whatever, they never read the book and didn't, first of all, that's what I'm saying. They're not looking for help, nor is it being accepted. And you have this position because. They couldn't just read a book that says like, oh, well your team should talk to each other, and if they're not, you should make them intersect on these lines and think about using org design to help you punch head. In lieu of doing a bunch of hard work on 'em, that's what I'm saying. Yeah. They created this position and just, they're just shucking it off this position, be like, Hey, get in there kid. Figure it out. that's what this position is. And of course, like the person that has a huge ego is like, well, I'm tapped by management to figure it out. So you gotta invite me to all your daily standups and you gotta invite me to all your planning meetings and you know, I'm gonna be the hippo in the room basically.'cause I got a director title or whatever VP title, whatever it is. Somebody with a budget is what I'm saying. They just pulled out of the air, oh, I'm gonna invent this new position and throw it at the problem rather than actually solving the problem.

Om:

Yeah. Yeah. Those executives you know, are getting all the help that they didn't ask for.

Brian:

So the number one, that's why they exist. I have worked with good architects, right? Like, people that span teams. They're not dedicated to one team or another, and that's what they do. I think about a lot of AWS shops, a lot of people that really know how AWS works. So when they come in and a team is like, oh, I don't know about Hmm, we need to implement queuing, but maybe we can use a database table and maybe we can use this, maybe we can use that. And this person comes in and says like, well do you wanna use Redis or Kafka or SQS, or, you know what I mean? Like they have a half a dozen solutions that they've worked with in the past, ready and available to suggest to the team and then help the team understand what other teams are doing, right? Because they know, 'cause they either, either because of their position or because of their tenure service at the organization. And that is that architect level helping, enabling, that's what I think of as a positive in this category. The positive folks make a big difference. Yeah, the bad architects, they become the bottleneck that the team has to go through for approval and it holds up everything. It's like, oh, you can't make any decisions because quote governance says, in order to use the new server or new technology or whatever, you've gotta get the approval of these two people so then everybody down the line, product people, team, senior engineers, everybody says like, well, we're not even gonna consider that because we gotta get approval and we're not even gonna bother that. That's what it ends up being. All coming from this one person. The other one that I have next to you is the bullet point that most architecture decisions are actually team coordination problems in disguise because they have to go through the solution architect. That's been my experience. I don't know if this lines up with what you've seen.

Om:

I've seen that more often than not. Actually I've only ever, I can only recall one experience I've had where the architect was invisible. Yeah. But behind the scenes. They were laying out the architectural runway that made sense. Not for the team. Mm-hmm. I'm talking about for the organization so people are across the aisle weren't Right. Like coming up with their own solutions that would probably be incongruent with where the organization's going only come across it one time, folks one time and I've been at this game for a while, so this is actually very true. You have architects that really can do this. Yeah. And they say, well, this is the best thing since sliced bread. Yeah. I, I use Kafka in my previous life, and that's what we're gonna do here. But in reality,

Brian:

like you're, you're just, you got a hammer and you're doing every job with a hammer. That's what's happening.

Om:

Exactly. So maybe, maybe the right solution isn't Kafka. Maybe it's like an enterprise messaging bus or whatever it is. But, so these people. Derail the organization. at the risk of trying to get a project done quickly it just depends on where they're reporting into. If they're reporting into leadership that they are saying, get this done now, get this done next month they're gonna take the easy way out, right? They'll, they take the path of water, right. If they're reporting into a enterprise architecture. Structure of some kind. Usually it's a board. That say across the organization, this is the direction we're going in, right. This is where we're vested. Then great. But decisions come slow. In that case, you've got all kinds of. Reviews and approvals and approvals on approvals, et cetera. So I think there's a little bit in the podcast later, that way we could kind of touch on how to expedite that. But yeah, I've seen both sides of it, but mainly, I've only seen the one side of it, which is not the good side of it.

Brian:

Do you have any stories about when a solution architect either killed or saved a project

Om:

it's that, yeah. I have an example of both.

Brian:

Oh,

Speaker 7:

boy.

Om:

Again, without naming names, I will say, I'll lead with the good first, right? Of this one enterprise level architect. That wasn't his title by the way, but he could think beyond what the team needed, beyond what the domain needed to the organizational level. He took the time to understand organizationally where we're going

Speaker 6:

Yeah.

Om:

And to his credit, he came back and said, this is a cul-de-sac. We're not pursuing this because, and he approached the CIO with this plan real simple, like one slide deck. And he said, if we go down this path, here's what's gonna happen here. The alternatives and here's why and the CIO approved it right away. So the whole organization pivoted away from the current. Path that they were on for the better. I might that it turned out six months later I've come across that, which is somebody who is not only just thinking, well, here's what I'm hired for. I'm gonna do just that.

Brian:

What was the size of that organization? I'm just wondering.

Om:

It was a large organization by any stretch. My point is the entire org changed direction because of this one person charting a path forward, right? So kudos to them, right? For coming up with it. Well, he went over and beyond what he was hired to do. And I've, that's only happened once in my career. Now it's go to the other side. People that have throttled projects or programs or initiatives. I already alluded to some of that earlier, which is they come from a given background, so they have penchant, is that a French word? Tendency to say, listen, this is what works. I like this tool. We're gonna use this tool, right? We need this. And somehow they managed to win over their superior to kind of sway the decision their way and make the investment if it's a new thing and, and go down that path only to find just a short time later, relatively speaking, a year or so that they actually are in a cul-de-sac. Yeah yeah. So I've seen that way more often including in one case where the architect in question, they developed their own solution that they thought could plug into this. So here's a new. You know, weird shaped Lego brick that I think is gonna plug in very well with the rest of your Lego bricks. Yeah. And you need mine, right? and they entrench themselves that way. even though it turns out that's not the best solution for the org, but once you go down that path, once that train, starts rolling, it's hard to pull it back.

Brian:

I'm starting to suspect that trains are just bad analogies for software development.

Om:

If you're on an Agile release bus, let us know.

Brian:

So if you can't find a spot two weeks out on your solution architect's calendar, that should be a red flag you have a permission slip dispenser as a solution architect, by the way. Not, not someone that's there to help you. I could levy the same criticism at product managers so I've got, I've got three takeaways that I wrote down for this. One is number one count the meetings. How many of them have to do with like, reviewing and approving things versus enabling and teaching and helping and mentoring. Right. And I think a lot of this can be done you don't need a lot of review sessions with your solution architect if they're built into your backlog refinements. Yep. You know, if they're, if they're way ahead of the daily hustle and grind, there's no reason for them to be these ticket dispensing machines. Yeah. like a lot of what my experience.. But let's move on. So are they creating documentation that teams can self-serve? Are they understanding the systems? Are they helping everyone understand the systems? Or, or again, does everyone have to go back to them for that tribal knowledge?

Om:

My experience has always been they will ship you of a PDF from Enterprise Architect, and it's such a high level PDF that it doesn't make sense at the team level. So you say, well, where am I in this? I'm this little box over here, so can you expand that out? And they go, well, let's talk about

Brian:

Let's talk about that. Pull meeting together. So exactly two weeks out.

Om:

Two weeks out's, right? Or more in the meantime, you, whoever, whatever your role is, right? You've gotta deliver. You've got a team that you're working with day in, day out. So there is that. But the other side of it is that if you have an organization where these people have a platform, like an enterprise architecture board, yeah. Are you invited even on a request basis, right? So you don't have to go to every single meeting that they're talking about. But when it concerns your area of work, are you invited into that discussion and are you given the ability to unmute and ask questions? If you're not, there's something else going on here. Yeah.

Brian:

So let me maybe like, now it's time for the, this is what I think I heard, What I think I heard was you, you, you ask your developers, what decisions can you and can you not make without the architect? Because again, like if, if your architect just like boxes the team in to be like you, you can't make any decisions without me. And like at that point do we believe in the lean startup? Like, do we believe in what Eric Reese wrote? Because at that point you just found a bottleneck. And like if we, if we're in bottleneck territory, and I feel at the point where we get into this kind of territory, it's time to start asking, can we fire this person? or if we're in this shared services kind of model, can we just not put any money into paying for this person's time and just go hire our own two senior developers on the different teams that can actually talk to each other. And then we'll send our developer to your staff meetings or to your developer sync meetings or whatever you have architecture review meetings or whatever you have. And then we'll hire two people. For the cost of what we pay into a pool of, of a solution architect. Right. To, to just have somebody do that job for us and, and, and talk to each other in different teams. Because everything that we just talked about in this category still I don't see, I don't see how the takeaway here is not like, just talk to each other.

Om:

Yeah, absolutely. I mean the symptoms, right? So when you're blocked by some sort of decision that the solution architect has to cost, and like you said earlier, the calendar's busy. Yeah. I mean that, there's that side of it. The other side of it is you're not given the autonomy in any way, shape, or form to do even an experiment yeah. With something that they haven't blessed. Right. So they're saying, well, stop do not pass, go, do not collect 200. And if you try to do anything, go straight to jail. It's like, eh, it's not a good scenario.

Brian:

So we've given you a couple things in this category. I mean, we could stay on it, probably the whole podcast on category number one, but we're gonna move on because we got places to go. Has your experience with this been as painful as mine? I would like to know in the comments. Let me know, please. So in the meanwhile, it wouldn't be fair on the arguing Agile podcast if we didn't ask the question well, who, who owns the technical decisions? Maybe the organization. Has some real trepidation about putting the final decision in any one person's hands. Maybe they've gotten burned before , so what I'm saying is your product manager, they wanna ship fast. Your solution architect, they wanna build it, right? They wanna build the best version future proof version they can. So when those two things conflict, who gets the final? Say

Om:

what, what a fantastic point, right? Who does get the final say? I think in most organizations, unfortunately, under the guise of delivering secure products, or products that scale up and are. Robust. It's the technical people, the technical architect that gets to really have a say in what's going on. The product manager could come back and shout there, still a blue in the face and say, we have to do this because our competitors are doing this, et cetera. But it doesn't matter because these people are really the gatekeepers at that point. So, yeah, I agree. And you know, I think architects they, they love to say, okay, we can't go because, and they'll give you a long list of reasons, well, wouldn't it be better instead to say, well, here the real, maybe here are the reasons, maybe they're right. What are we doing to solve those right now? Right? Because we gotta get to market by a certain date. That last piece. I, again, in my experience has not been it's not been prevalent, it's not been very forthcoming from these people. And they just simply sit back and go, it's gonna take what it's gonna take.

Brian:

So your product manager, they want, they wanna ship fast. Your solution architect, they want to make sure everything is built right and all the edge cases are taken care of. when these two things come into conflict, who gets the final say?

Om:

The final say.

Brian:

It's like the final countdown. Yeah, yeah, yeah. With like, with less keyboards count. Yeah. So I'm gonna go straight to let's reference the Holy Marty Kagan of Empowered 2020. Product managers should own outcomes. Engineers own implementation. That's what he says in the book, don't throw stones at me. That's what Marty Kickin says. Go throw stones at him. So architects, I think the claim that you can make is architects should enable both and not override either one of those. outcomes, implementation, architects should be the bridge between those two things.

Om:

Yeah, I agreed with it and I haven't found a whole lot to kind of disagree with since then. So I'm gonna go with that. I'm gonna say yes.

Brian:

You're going right into the steelman because the steelman is two points. So he says architects see across teams. Yeah. And product managers only deal with their one roadmap or backlog. Oh, and also like the technical debt from bad decision , that costs us millions in the long term. and also it affects multiple teams. So I cannot allow you, Mr. And Mrs. Product manager to be making these bad decisions in a vacuum when they are shared components that affect other teams.

Om:

Yeah. And I, so, yes, agreed.

Brian:

Yeah.

Om:

Yeah, yeah. So in this scenario though, offer, what happens is a bit of angst here, right? Between the, the, the product management folks and the architects. Uhhuh, I think it behooves product management to think about this at a higher level, at the organizational level rather than just but I need this yesterday. Yeah, we could do that, but it's gonna come back and bite your product or increment, whatever it is, right. At some point. A savvy technical architect or a system architect should say I understand the need to get there quick. However, we can't do that because we have to build this thing for us as a company, not just you as a product.

Brian:

Oh, listen, I'm a hundred percent on board with the pitch that you're making right now,

Om:

but I know it's coming.

Brian:

However, oh boy. Not to throw stones at product managers on the podcast where I happen to be representing the product manager, but most product managers, they're just trying to get their roadmap there, deliverable their whatever over the finish line. That's not what you just outlined is not their concern.

Om:

I understand, but at what cost so that's the thing. Well, they don't know. So, so that, that's, I think that's the crux. They don't know. Or they don't care. Or care, yeah. We're on the same page. They don't care. Say, well, this is what I'm hired to do, right? So I'm gonna do this. Get outta my way.

Brian:

I can't tell you how many times I've heard a product manager say like, I can't believe Dome and Team is taking insert time period here to do this quote. Simple thing.

Om:

Oh dude, I come across that and whenever that happens, I just say, wow, if you can do this quicker, go for it.

Brian:

This is why Solution Architects is like, it's a made up role and it's terrible because again, you could have gone to all the teams that are affected by your changes and if you have to go to eight other teams, maybe that should tell you something about your changes. You don't need one person to come down from the mountain with the tablets and be like, these 15 commandments, smack, these 10 commandments. You know? You don't need one person to do that, just talk to the other teams. About how you're gonna screw up their day to day with what you're about to do. Our architects love to talk about this technical debt. Anything and everything is technical debt to the point where the business no longer even believes technical debt is a thing because they've screamed from the top of the mountain so much and you've eroded even the concept of technical debt

Om:

Well, I think when that happens though, it's the onus is on the architects to be able to explain it to the product folks in ways they understand

Brian:

I understand. But, most companies you'll never get to that point because there's this contention about where the architects sit organizationally, where the product managers sit organizationally. And same thing with the engineers and the product teams and how people are incented it's very complicated, so I have a few points that I wrote down and I wrote these down in a hurry. So I don't know if these are the best points.'cause the first one is, ownership without authority creates blame without power to change anything, so like that, that's, that's very scary that that bullet point.

Om:

Yeah. It's also something that exists pretty much in every organization because authority is not something you are granting to people that need it. We're getting in, we're getting into this whole org design and sort of the, the org political. Spectrum. Well, a discussion here.

Brian:

I think it's an org design topic because I think it's an org design podcast because this whole, the whole role is because you've got some issues in your org design. If your org design was on point, you wouldn't necessarily need any of these people. I mean, maybe you would have an enabling team again. Apologies, folks. Go read Team Topologies. We did a whole podcast on it, arguing Angela 67, it was a long time ago in a galaxy far, far away, but it holds up. Okay. You got an enabling team. That team should be able to come in. Supplement your team for a sprint maybe, or a sprint or two or whatever, while we're helping you get the work over the finish line. We're here working shoulder to shoulder with you, not coming down from the mountain with some tablets one time inscribed in stone and that's it. And we never come back and revisit the plan. Yeah. And then at the end of the sprint review we come down and say like, stamp a big rejected 'cause you didn't follow my tablets or whatever, that that couldn't foresee X, Y, Z and since your calendar was so busy, I never came back and revisited the decision 'cause there was no opportunity again. Like terrible. The, the best architects, they coach the teams through making good decisions, architects kind of mentor people more than they coach people to in my opinion that's true. but I guess the best ones would have that coaching skill and would be able to help ask questions through like, Hey, why would you use Kafka when we have this fully implemented retic instance and all these other teams are doing it, and. It looks like you guys can just slide into the middle of it with very little friction and you know, you just need a key or whatever. Yeah oh, we didn't even know we had one of those. Oh, well, hey, that's why I'm here. Work with me after the call. We'll sit down for an hour. I'll give you a key, and then you'll be testing it and showing a real demo by the end of the day. Oh, I had no idea that was even possible things like that I've seen with good architects.

Om:

Good architects can also not just simply cast decisions and saying, you. No. Or yes, or you know, well, they really, I mean, I mean they, they, they actually have the ability, right, to speak to, to product and everybody else in the language that they understand. And not just like technical architectural jargon. So when an architect is basically casting decisions, vetoing, et cetera without the ability to, to explain trade-offs, perhaps if we do this, this will happen or else, right. Those sorts of things. Are they architecting or are they just simply controlling?

Brian:

I think you just answered your own question right there. I think I did. So I had some time in this category, Stubb Doubt for us to talk about a time where I, as a PM disagreed with an architect. And then to talk about who won what shift it would've been, I, I'm, IM trying to remember any conversation that I've had with an architect as a product manager where the architect won because like, this is, again, this is like par partially responsible for my move to product management from working on technical teams where you're just working, the whole team works through the architect, and in poorly organized businesses, the whole technical team works for the architect on paper. They have higher fire authority basically. Yep. Or, or, or at least like they can heavily imply and, and that's not even to mention if you have like a contractor culture where a majority of your people are contractors and then you have this solution architect who's like this VP level person who's like, I don't like this one QA person on this one team because they critiqued my SQS solution. They said you should write to SNS. Yeah. Before it gets pulled into SQS and I don't like that. and they can get that person basically fired just because they didn't like getting accused of being wrong basically when they probably were wrong.

Om:

Right. Anytime that their authority is challenged, that they feel a bit like vulnerable in that way and they can take it out on the teams.

Brian:

But that, those are all my stories. I don't, I don't have a great story in this one. So I don't know if your architect can say no, but they cannot explain the cost of saying yes.

Om:

Well, look, I think if they can't explain the cost of saying yes, you've got no hope of them explaining the cost of saying no. So I mean, at that point they're not really protecting the architecture or looking after that but they're really kind of just. Basically gatekeeping.

Brian:

I have some quick takeaways in this category, just to throw some out so that we don't just rail in this category. I feel it's gonna be that kind of podcast where I rail on every category and it doesn't matter. But I'm gonna try to throw some takeaways in there to help people. There's three things that I would say that you can try to do. You can try to with your architect, you can try to state the customer outcome with them clearly as clearly as you can. You should be doing this anyway in primary Yeah. To say what, what are we trying to achieve? And, and by when, if you like, I under, that's a dirty word to say by when, but maybe there's a market reason or a window or something trying to hit, Just be upfront, be like, Hey, I want to try to do this. By this time. Okay. Number one, just try to get the goal out there and be as clear as possible about it. Number two, you wanna try to, to name the technical constraint and why it's risky or not risky just try to work with your person to clearly say, this is what we're trying to do. And then to clearly write down, well, these are the constraints because then it opens up the conversation for you to quantify the trade-offs. So if we do it, if we rush to market with this, we'll have a bunch of garbage over here. We'll have to do a bunch of work or two sprints to clean up whatever, whatever. It's, but what is the trade off? I might be running my stuff back up the ladder. Sure. And my director of product and VPs or whatever might be like, we don't care about any of that crap. Get us into this new market, ASAP. I was at a business one time, had a bunch of technical problems and they were trying to renew a customer. And a customer was basically threatening them, saying, we won't renew unless you make your system quote, quote. More stable. Which was completely subjective. I mean, it basically was like, if we feel it's good, right? We'll renew that was like, there's no way you can like run a business off that. But at that point, the clock was ticking on the whole technical team. It could have sunk the company if a customer that was like over 50% of the revenue for the whole company would've just gone away. Yeah. It like, there would've been massive layoffs, probably most of which would've been the development team at that point if we couldn't solve it. There was none of this like living in the ivory tower letting your hair down like Rapunzel going on at that point. It was, everyone needed to work together to solve these issues. And then if you're tracking data and you're actually a data-driven organization, you escalate with data, you bring actual data. To have conversations with leadership and hopefully you're in the type of organization where you could actually have that kind of

Om:

conversation. Yeah, I was gonna say, you, those organizations are also rare, right? Because they just simply look at the people underneath and say, you failed, and then they just turn around, look down and say, you failed. Those are four takeaways for you. One was free. We promised three, but we gave you four.

Brian:

I know. Yeah. Hey you know, this is fine. This is like that meme. This is fine. This is all fine.

Om:

This is all good. House is burning down around you, but Yeah.

Brian:

Hey, what do you think is if you find any of these takeaways useful, let us know in the comments. Let's take a different perspective on this arguing point. What if product managers, what if they're not innocent in this situation? What if, what if a problem is self-created? That's the category we're about to go into.

Om:

Wow. All right. So let's just say for sake of argument Yeah. Most of the time when a solution architect becomes a bottleneck mm-hmm. It comes down to the product management. It's product managers that. Cause this to happen. How about that? Because they're expressing undue, unrealistic deadlines to get out there, right? For their own reasons. Granted, but maybe that's the case. So how how PMs. Actually are the root cause of some of these architect issues and problems.

Brian:

So I got the steel- man shown on the screen

Om:

product managers are accountable for outcomes, not technical debts that's the steelman argument. Yeah. And then the second one is, architects should proactively engage and collaborate with product and not wait until they're invited. So they are in the game from the beginning, right? Mm-hmm. If you're in nor where this happens, I would love to know because I've not come across many except for maybe one that was practicing safe as a framework and safe has that element where enterprise architects are part and parcel of the product council. So they're up there working with product before they solidify direction for the product. That's very, very rare. It's academically, yes, that's what you're supposed to do according to the blueprint from safe. But in practice, again, not seeing that very often, I'm afraid, folks.

Brian:

if I'm going to defend PMs for a second here, I feel, well, boy, I feel slimy defending all PMs right now,, if we're gonna be Rocky, I'm gonna be in their corner with the ice cube thing, the cold thing. I'm sure it has a technical name for boxing. I have no idea what it's but if I'm gonna be the cold thing, it's like, hey, like sometimes UPMs, like you promise things. Without ever engaging the development team. Especially if you're with sales and there's no developers there.

Speaker 3:

Oh, that'll

Brian:

be quick one, sprint boss, whatever you say, we'll have it out in a week. We can do that. You know what I mean? And then your developers are like, what are you talking about? This thing's in the middle, in the core of the software. Even if we bring developers to that conversation, they could get stuck in the same trap. So I feel like a better way is like you involve more people and you get over that hump the more people you involve. And now we're back to like, hire your organization. and product Right. Makes decisions. but I don't know. That's a weak argument to me.'cause also if you go back to that four letter word governance, your solution architect might be like, well, you can't talk to customers without me. And because they work for like two levels above your skip level, now it becomes policy that no product teams could talk to any customers without a solution architect in the room. And now you're dead.

Om:

These kind of asinine rules become institutionalized Absolutely. After a while. and that's how we do things here sort of thing and it completely blocks agility. These are things I fight day in,

Brian:

day out in my day job. And, I've seen them across almost every organization at some level with regard to some decision. there are certain areas you can press on at certain organizations. Yeah. And you'll get this. The product team can make any decision they want except as long

Om:

as it's not technical,

Brian:

except they can't alter pricing. Well, yeah, that's right. I'm pointing something out that just to be a little over the top to help people understand, . Did

Om:

we do a podcast on who should we doing pricing? We certainly did. We did, we

Brian:

did. And I will search for it like it was arguing Agile 236. Why product managers should own pricing, not sales or execs or finance We talked about the solution architect being basically the, the chief, no officer, and why that's a problem. If, if the PMs are complaining but then treating the the developers on the team or the architects or whoever as like order takers. You know, like I think about the, the super high level skip level. Like, just get it done. I don't care what it takes. I think about every executive who's ever said, how hard can it be to just add a little toggle that says light mode, dark mode. Oh my goodness. And you have no idea what you're talking about right.

Om:

I think this divide this organizational divide whether it's functional or otherwise, is killing organizations. There's gotta be a better way I don't have an answer necessarily, not on this podcast at least, but you know, how about a coalition? How about forming a coalition that. It's fickle and it, it's unique for every case that you come across. Yeah. But you bring the right people in for the right amount of time, for the right things and the right reasons. And that's it.

Brian:

I cut us straight to the actionable takeaway because of your comment there. Mm-hmm. Which is discovery, not delivery. You want to invite them. So point number one that's showing on the screen now for you. Yeah. You want to invite them, the meaning the solution architect, you wanna invite them to discovery through the discovery phase. Yeah. I'm not gonna go into it. We we probably could do a whole podcast just on that phase of the least you can do, I mean, this is the most minimal thing you can do. You listen. Oh, they never show up to any my things. I always invite them.

Om:

Yeah, it is a difference. let's, there'll be time. They have an accountability there.

Brian:

There'll be time in the podcast to talk about that later. Yeah. About that. Accountability, but when we're talking to customers, we've made them available. Same thing is like sales. When sales is meeting with a prospect and they put me, the product manager on is optional. I can choose to not show up to their new sales prospect, but I mean, what, what am I doing that's more important than that? I mean, can you talk, do you have the teams and be like, oh, time to sit down and talk technical details, whatever. Can you push that back a little? Like I know it might impact a daily scrum but I'm like, there should be an order in meetings of like number one, we're talking directly to a customer. Number two, we're talking to other teams to decide something between the two of us. Number three, we're just talking internal to the team, number four is a one-on-one or something like that. there, there's an order that you can kind of work out., And maybe that's a working agreement. Maybe a top level coach can help people understand like hey we can move the meetings. There's no cost right. I guess this whole diatribe goes back to what is the business context of that thing and did something with a more important business context come up because we should respond to that quickly again, there's a lot of people I even saw like I've been watching a lot of stuff on LinkedIn recently, like crying about Agile and like throwing stones Agile and whatever. If we got business agility at the forefront of our minds, we should just know the order instinctually, just know the order and just be like, wow, I'll kick this out. I'll make, I'll make time, I'll make time for that. That sounds important. I know it's important. We'll make time to, to get that done.

Om:

Yeah. Fully concur. I think the order is probably something like prospects that you are farming for first. Because why wouldn't you water your seeds? You've planted That this makes no sense to me to ignore that customers you've already got, they've signed up. Don't ignore 'em, but that's the next level for me. and then there's like the organizational looking to your left, looking to your right. your team level follows after that what's at the bottom for me is. Your EAB, et cetera, because all you're doing is making technical decisions there right now. Do you have to make them right now at the expense of those other layers that we just talked about? I suspect not, right? Yeah. Because on the whole you direction isn't gonna change a lot. Mm-hmm. It's probably small decisions at that point. But granted, there are some opportunities where you're talking about larger level discussions on what tool to embrace, et cetera. Those are fairly far and few in between. So it does make sense and yeah, if your organization doesn't have that kind of a culture, you should work with a coach to, to help instill that. Right.

Brian:

So my interesting takeaway I'm hearing, as a product manager, if I'm gonna take accountability in this category, if your architect is blocking your roadmap, but they're doing so because it's new to them or you never showed it, or you talk to customers first or whatever. You got some explaining to do.

Om:

You're, you're actually precluding a really. Important you know, opportunity for your architect to ask questions of your prospects or customers directly, not filter through your lens, right? So it's not gonna be something you can talk to them after the fact. Like that's better than nothing I guess, but it's not the same, right? You need those people in the room. So one of the things as a product manager you could do is this. You gotta talk to a customer or, or. A prospect, doesn't matter which the meeting that is set up, ask the other party the prospect of the customer to bring their architects into the call that way your architect can ask questions and get immediate feedback. Mm-hmm.'Cause the alternatives are a lot worse. Things get filtered and senior develop team leads or whoever it is. Yeah, exactly. Whoever it is that's needed at this point so I mean, my point on this is, as a product manager, you should definitely be thinking about this and how to short circuit this whole communication conundrum.

Brian:

Well, I mean, that's a great wrap for this category. Is there any other things that we left out of this category? If you're listening, let us know the comments. Absolutely. We've established that everyone's guilty in this category. That's what we've talked about. So now let's talk the three conversations that actually can help solve slash fix, maybe the relationship unmuted. Alright, so most product manager slash solution architect conflicts, they're not about technical disagreements. They are about three conversations that actually never happen. That's what the disagreement is about. The Patrick Lencioni five Dysfunctions of a Team, the 2002, trust comes from vulnerability based conversations about roles, goals, and fears. I'm gonna transition into the Steelman side of this conversation. Roles and responsibilities, they should be clearly defined by the organization at each organization that you're at. So if you're a product manager at, at Brian and Om software development company , and then you go work for Acme Company or whatever, you should have a conversation with them about exactly how the role is different from the previous. Brian o software company where you basically own the entire outcome. Everyone basically worked for you, but they didn't really work for you, but you had a, you know what I mean? Right. And now you're at this new company where everything's like a project plan and you're the king of the world.

Om:

So I think there's two things that fundamentally underlie, rely the ability to be able to do this, right? Mm-hmm. One is to own the fact that you have to be vulnerable and say let's have a candid conversation. That that's one, which again, we know it's not that common, right? Because people come in with, this is the second point I wanna make. Yeah. Egos. You gotta check those at the door.'Cause I mean, if you, if you come in and say, I'm the the U, but senior product manager, and it's like, yeah, come on seriously. So those two things have to be preconditions to this, right? Be vulnerable, lose your ego.

Brian:

You don't know, but you just hit on a whole different podcast I wanted to have about, Ooh. Being humble. Being humble. Being humble. I like it. Yeah. A lot of people don't, they don't know what being humble means, what does being humble mean? Does it mean like, shutting up and like not starting a fight, actually, that's not what it means you know? What it, what it means is, bringing up that you disagree with someone and not being a jerk about it. Bringing up that you know, you're really worried about someone because of the way they're acting.'cause they're a giant alpha type personality. And you're concerned about it and you really want to talk to 'em about it to understand why they're that may like maybe something happening at home. Maybe they're in a bad place in their life, you don't know, , it's not, you're not trying to win one over on them.

Om:

This is where you come in with your empathy. This is where you kind of divulge away a little bit from this ethos of well tackle the problem, not the person. Well, look, you have to tackle the problem. Sure. But it's the people that are going to work on the problems. So, to your point, maybe these people that are involved or person that's involved in the picture here has something going on in their personal life. It behooves you to at least be open to have that conversation

Brian:

The other steelman here is good, good professionals shouldn't need relationship conversations to do their job, which is by the way, terrible, terrible point. Hey, you're a professional. You should be able to read between the lines zone. Yeah.

Om:

Yeah. I don't know how I feel about this, because first of all, if this were true, we wouldn't have any problems in the world so let me tackle it the opposite way. Okay. Alright. When do you ever get taught how to do this? Right? You don't learn this in college? Oh, you're a professional. No, you're not. You learn academic stuff in college. So you come to work and where at work do you learn about. Being a good professional, you don't. So here's how you learn. You learn through the school of hard knocks, right? So you do something and if it works, you get reinforcement, great. You'll do more of it. Or you get pointed at for something and you do less of it. But then every organizational values, different traits and behaviors and norms, right? So how do you get to this point? It is not a given. It's not, there's nothing wrong with seeking help here, and organizations should be open to saying people that work in our org aren't perfect people, and we should be providing that support that they need.

Brian:

so again, as a product manager on the podcast, I would like to take this opportunity to point out that the org chart, defines titles, reporting, structures. it never defines how two people. Actually collaborate under pressure if you could redraw your org chart to say, don't show me who reports to who, show me how decisions are actually made in this organization. And everyone needs to be involved in all the different tracks. First of all, people would be like, get outta my office second of all, I don't even know if they would be able to do that because it's, it's a very complicated thing that I just asked for is show me how decisions. Actually get made. And maybe, maybe you should do that exercise at your work. If I'm wheeling back to another podcast that I want to have, but there's no way to have it without being a completely unhinged I actually did have a conversation in the takeaways and just to throw it out here real quick, the conversation is a three part conversation that I'm suggesting here. It says you have a conversation and you ask the question, what does success look like for you in your role? And you try to understand their situation. So if you're like, oh, I think a solution architect is a made up role and doesn't do anything and just gets lunch all day and takes a nap. You would ask these things and try to connect with the person to say what, what does success look like? What is your biggest fear in this role? Right, in this position with our teams and then you say, well, how do I disagree with you? Productively what manner would be the best for me to bring it up, you know?

Om:

Yeah. Again, all three of those underline the need to be vulnerable. Right, right. And also not have an ego, because if you had an ego, you wouldn't be talking to any of these things so, yeah, absolutely. I look how many times have you seen this happen in your professional life? Do let us know, but, because I can tell you mine, I can summarize in great detail on the back of a Post-It stamp. That's how often I've seen this.

Brian:

You know, sometimes the conversation with the architect like it doesn't work because they're holding back. There's a difference between an architect who protects the system and an architect who protects the teams that they serve, and an architect who's protecting their own job. And let's talk about how to find out which one your architect is.

Om:

All right, let's keep going.

Brian:

Oh, the Nygard book? Yeah. Is that the one? Yeah. Oh, do you know this Nygard quote? I know the quote. I actually own this book from 2017. Do you wanna read this quote?

Om:

Sure. So this quote again, paraphrasing great architects work themselves out of a job by building the systems and the environment teams, that don't need constant vigilance from them.

Brian:

Sorry. Work, work themselves out of a job. Where have we heard that before? that's so strange. Someone said, working yourselves outta the job. Please continue. I'd love to hear more.

Om:

Yeah. So that's Nygard's thesis, right? Yeah. So let's get straight into the, the steel man argument here. Architects must stay involved to maintain system integrity.

Brian:

That's the first part.

Om:

Yeah. So the system doesn't boil over like water in a ca

Brian:

means like I have a lot of problems with what you just said. Please continue. Gimme the second point and then I'll push back.

Om:

Yeah. Distributed decision making leads to architectural chaos.

Brian:

I was, I don't have, I don't have a beep to bleep out the cursing, so I'm not gonna say anything here right now sorry, was was the second point. If we distribute. Decision making someone might make a bad decision is that was the second one. That's

Om:

exactly what it is. and you can't trust them so I'm not gonna let them. Oh, so it's this, this is all about maintaining control. Exerting and maintaining control. Oh man, that's what this is about.

Brian:

Sorry y'all. I don't think I can, I think I got a headache. I gotta Oh no, gotta cut out early. You're like that. So if those are the best points against like, what a disappointing category. What can a solution architect do in this category? The best solution architects. Okay. They help the teams create architectural documents, or at least amend they build on top of wood, supplant them. Yeah, absolutely. Yeah. And they, and they help the teams connect to, to potentially artifacts that they don't even know exist because that could happen. It's like, oh, we didn't even know you were using Redis when we came up with this, like queuing home, brewed queuing function each successful solution architect helps the teams make better decisions and go through the approval process in the organization. They help them through the approval process. I was at an organization one time that was very like the way we think of project management, in terms like you had to go in front of a board. They had to review your changes your tests in UAT the results of your feedback to decide if you, and this is software development, by the way, the solution architect really could become your advocate. They are like a lawyer at trial counseling you. If you decide to be your own lawyer, they're helping you do the best job you can right. Arguably they, they could be doing it on your behalf to the group, but most organizations don't work that way but the point is that like they are expertise, again, going back to arguing Agile 67, 6 7 team topologies They're a member of the enabling team loaned to your team for a period of time till you clear a certain decision or hurdle or something blocker yeah,

Om:

they're really catalyzing the discussions.

Brian:

Yes. Yeah, absolutely. Yeah. And their value can be measured by how many outcomes they help you get through speed of decision making is one thing. The speed. Yeah, absolutely. But I feel like the opposite is. Probably true for most people is that their delay of decision making is how they make an impact. Negatively on your team and then the larger organization, it's just that those metrics are not tracked it's harder to hold these folks accountable.

Om:

Yeah. They tend to kind of install themselves in these organizations and create these indispensability. Right. You can't do away with them. You have to have approval probably times two or three from these different layers of the, the Solution Architects that you have place with different titles perhaps, but Yeah, absolutely. So what we're saying on this specific topic is helping architects. Create useful art artifacts, documentation to help the team hoarding architects, on the other hand, they create bottlenecks and dependencies on themselves.

Brian:

That's absolutely true. Yeah. Yeah. Your architect who they, they can't take two weeks vacation without everything falling apart or grinding to a halt they're the bottleneck that gold rat warned everyone about ooh, years ago, I mean, decades ago,

Om:

Eli Goldratt.

Brian:

You've made yourself into a single point of failure, why did you do that? Why would you do that? I mean, ego is one side of it. I think the complete swing and the opposite direction side of it is ignorance.

Om:

Yeah. The ignorance side of it is, is not just simply a passive thing where teams will say, this is above my pay grade, right. Or our pay grade. This is for the EA to decide. This is the other way to so the, these SAs, EAs basically feigning complexity saying, this is too complex for you. I'm better position to do this, right? Yeah. By the way, I'm out for two weeks, so this can wait. Okay that, that is very true. I've seen that way more often. The teams will just be like really struggling to move along without this kind of approval and it's not a tacit approval, it's an absolute approval. Like you can't move forward until you get my approval in writing and they have built processes and workflows in place to kind of stem the flow of ideas and forward progress. Because these SAs say they are the ones that are the most important cog in the machine.

Brian:

Well, let's step back for a minute and talk about what are some things you can put into place. To know this is a problem to clearly identify or maybe get over the problem. there are four takeaways I got listed here on the screen, which is number one. You can give them the documentation test. Ooh, what was this documentation test, Brian. Hey, calm down. Can a new engineer can, can you onboard a new engineer? I mean, or really product manager, especially if they're a technical product manager. And have them. Understand your system architecture without having to have a deep one-on-one with your architect, your system architect off to the side to hold their hand

Om:

who knows. Yeah, you're right. You're right. The documentation test is real. So if you can get an engineer to understand things that are documented first, second time, that's great. Right? Product managers, yes. You who really I think is also critical. Here are incoming bas do they understand not just the technical diagrams. Good point. Good point. But the business logic workflow, I mean, you're not gonna get everything from a diagram, but you're gonna get the gist of it, right? Yeah. So there is that test as well, right? It's an integral part. It's still the documentation test, but do PAs. Can they grasp what's going on?

Brian:

That's a good point. The next one I had was the decision autonomy test. The point I had here is you as a product manager, talking to your team. What technical decisions can you make without having to involve the architect or the solutions architect or the solutions engineer, whatever, whatever you call 'em, right?

Om:

Yeah. This one is a tough one though. I'll tell you why. So we are talking about senior engineers here, right? Not product.

Brian:

Oh, you talking, I was gonna say the product people don't have.

Om:

The technical knowhow to understand decisions that pertain to the ities.

Brian:

Sometimes when the solution architect decides we're gonna do this, not that they not only need to be able to explain their reasoning. Because I, the product manager, as the representative of the business, I have to be able to explain their reasoning to many other people in the organization. If it's not clear, if it's like, oh, because I just decided I can't sell that to anyone. I can't use that. That's not good enough. And I only bring that up because a lot of solution architects that I've worked with. They go back to that reason and they don't want to expand on any other reasons. They just wanna hang their laurels on because I said so, and I'm the architect.

Om:

It's too complex for you to understand.

Brian:

Yeah,

Om:

but I mean, look, again, except it's not, but not for you specifically yeah. But I'd say product management in general, we're gonna assume even though technical product managers aren't at the same level of technical knowhow, and I know put spa as a, as essays,

Brian:

Like even with executives, that doesn't fly. They can explain it in terms they

Om:

You gotta speak their language so, yeah,

Brian:

I understand. But it doesn't happen. Okay, so we did a podcast it was arguing Agile 235, changing your message, adaptive versus manipulative communication arguing Agile 2 35. This is borderline, but 2 35 is borderline what we're talking about. It's not exactly,

Om:

no, it's not what we're talking about,

Brian:

I will tell you, I only stopped to search for that podcast because I've. worked with many a solution architect who will try to bend the message to fit their narrative. Sure. Of like, oh, well the product manager was reckless because we said we had this technical dependency or whatever, and he decided to do whatever anyway. Yeah. Not exactly, because you told me that your connection pooling in the database wasn't that big a deal and it totally should scale to a hundred concurrent users or whatever. If the architect is out for a week does our business stop functioning?, I'm aiming this at the solution architect. I could aim this at anyone else certainly. But I feel these folks that work their way into this position, right, between teams, If they disappear for a week, I think the whole program does grind to a halt and either the program grinds to a halt or a lot of stuff gets escalated over and around the quote normal business process. Yeah. You like, well, VP Om said we could do it because solution architect Brian is out. So he just approved everything while Brian was out.

Om:

If you have organizations where Brian's already put in place all the things we talked about just earlier, right? All the documentation, et cetera, and the knowledge sharing, it shouldn't matter That Brian's out for a week or two weeks but yeah, this is what we're saying. This is the vacation test.

Brian:

I can't think of anything we left outta this category, but if there is, please let us know. Yes, please do. for the final category on the podcast, we have to talk about when you absolutely must escalate and then how to do it without killing your own career.

Om:

Alright, so let's get to this, right?

Brian:

So in the Radical Candor book, kim Scott says, escalation isn't tattling. It's caring enough about the outcome to involve people who can change the system. That's a wild statement, which leads me to believe we need to do a podcast about that book

Om:

it's a lofty statement to say the least. But yeah, good luck

Brian:

Listen, if you can change the system and be running up that hill, like that's, I got red texts on a screen most people will say like, Hey escalating a relationship problem. I'm like, just doesn't get along with Brian to leadership. That's gonna make you look bad. it is 99% of the time. Yeah. Unless HR already has a thick file with two Cs, a thick, a thick file. On that other person. sorry. Like it's gonna make you look bad and there's just no reason to put that on your career. Right. the other side is like, Hey Om, you're a professional. I expect you to resolve whatever it is with the other person without quote, bothering leadership.

Om:

Yeah. So escalating with it, it depends on your org structure or your org culture. You could do that or if you could do that, but if escalating reasonably frequently doesn't bode well for you. You know, HR is going to put you in a bucket. It's the right thing to do when. You've tried things and you have evidence. Don't just go in and without evidence and say here's the problem you tried something and you can absolutely back it up. Okay, escalate. That's fine. But don't do that all the time. Also, don't escalate the person escalate the problem.

Brian:

Oh, good point,

Om:

How does your organization perceive and handle such escalations, right? Mm-hmm. That should be your starting point. So,

Brian:

So I got the points here. They're on the screen here. Okay. So in order, you said, don't escalate the person, escalate the, the decision making process is broken or the issue that came up because a current process is broken. So you're basically escalating. We need clarity on how to resolve this. Thing that happened, you're not saying, we need you to make a decision that this person's bad, or you need to call out this person as being bad or whatever. Right. Because that's just not gonna happen. And I have to go back early in my career for me doing this kind of stuff.'cause earlier in my career my attitude is like, this person sucks, like this super unresponsive. Like they're bad at their job. I have to kick their back to them two or three times.

Om:

Say tackling the person, not the problem right there.

Brian:

It would've been tough advice to give to myself at that point in my career. Now, where I'm later in my career. I would go over and sit with that person and be like, I'm here to sit with you until we've worked through the issue, you know? So that you know that like you need to dedicate your full

Speaker 6:

Yeah.

Brian:

Brain power to it. Or maybe I can help you come off of the decisions that you're on or delays or whatever if you've got a lot of stuff going on, I'll sit with you and work through that with you frame it as we need clarity on how to resolve this situation, not blaming it on the person, again, building on the previous step. And then the final point here on the screen is when we disagree.. How should we make this decision when we disagree?

Om:

I'll tell you how, how it went for me when this happened. Early on, very early in my career, I did escalate and I did tackle the problem, not the person. But they said, well, who's normally your go-to? Right? So at that point, you have to say the name, which I did, and they say, well, they're indispensable. Yeah so here's what we're gonna do. We're gonna give you somebody else who will help you. And that somebody else was this person's peer. and they were both from the same nest. So this guy made the same decisions as the other person would've made. Course it didn't get me any further but it was a lesson learned from me, which is understand your organization and see which way you wanna go after that. So again, that of course you learn to course this is one of those I chalked it up to. it's an experience thing. lesson to learn.

Brian:

Alanis Morisette said, taught us you live, you learn. To wrap this category, if you're afraid of escalating a broken process, because it might hurt someone's feelings, like at that point you care about being liked or stepping on toes or politics too much. Yeah. More so than you care about delivering

Speaker 5:

value.

Om:

Absolutely. Or you just care about preserving your own job.

Brian:

Okay. I'm going to sail through the takeaways here. Document the pattern. We already talked about documenting. You might want to quantify the impact if nobody else has, more likely they have to say that like, Hey, this, this decision process has delayed X amount of features for y amount of weeks. Affecting the amount of customers pot, even if it's all potential. At least you're putting some numbers behind that. Yeah. You're dealing with the problem. You're not blaming a person at this point. You're just saying, Hey, because we had to delay these decisions because of this organizational process. That's what we're saying. I know it might come across, especially when ego gets involved, it might come across as, oh, this one person hasn't made the decision or went on vacation, or whatever it is. Yeah Hey, hey, hey, I'm not talking about that person. I'm talking about the organizational process that we're following now. That's what I'm talking about.

Om:

Yeah. Just aim for a one pager that just says The cost of delayed decisions or decisions not made.

Brian:

And then proposing a fix is as easy as what I outlined, when I said you just ask for the decision making process. When it's unclear, you ask for that to be clarified. Yep. Yeah. document the pattern you need the more examples, the better. Three examples is pretty good. You quantify the customer impact, you propose a fix, you know?'cause there's a lot of psychopaths out there that say, Hey, don't bring me problems. Only bring me solutions. Only bring me solutions because I can't be bothered to think That's right.

Om:

Exactly.

Brian:

Alright, so this one, what do you think about this category? What do you think about our solutions? Here are three very simple questions here. Let us know in the comments.

Om:

Yeah. And if you're an S.A., please give us some thoughts that you have around this podcast too. But also don't forget and subscribe.