Your Job Description Is A Lie (Who Actually Makes Decisions) | AA266

Your job description was written to get you hired, not help you know if a decision is your to make.

That gap between what's on paper and who actually decides is where careers go to die. 

Experience & Process Improvement Leader Clint Murt once again joins Product Manager Brian Orlando and Enterprise Business Agility Leader Om Patel in a debate on why job descriptions and/or job role descriptions may buy false comfort, when executive "intrusion" is actually legitimate, and the problem with decision-making that nobody owns.

Listen or watch if you're interested in :
• Why job descriptions go stale the day they're posted
• How that "startup magic" that becomes chaos at 100 people and burns out your best talent
• When that exec has the right to overrides your roadmap
• Why RACIs are fiction and what to use instead
• Practical fixes for decision rights

If you are a product managers, agile coach, or tech leader tired of role confusion and turf wars, this episode is for you!

#ProductManagement #DecisionRights #OrganizationalDesign

Flow by Mihaly Csikszentmihalyi, David Marquet, RACI matrix, OVIS framework (BCG), Spotify model

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

INTRO MUSIC
Toronto Is My Beat
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Transcript

0:00

Your job description is a lie. It was written to get you hired, not help you make decisions on a Tuesday afternoon that gap between what's on paper and who actually decides is where careers go to die. And no amount of clarifying roles meetings is to fix it So this applies only to jobs that actually require making decisions, which is pretty much all them. I don't know where you're going with that one podcast. Clint, I'm under impression that you write job description two or participate in hiring. And I do bit that. OK, You might be just person we need talk about this. welcome back Arguing Agile. And this your first time, welcome. I'm your host product manager Brian Orlando. And this is my co-host, enterprise business agility consultant and the duke of decision rights, Mr. Om Patel. And we're joined today by Clint Mister Clint Murt. Welcome back. Happy back. Clint and I had discussion at networking event and that is the that's how the genesis of this podcast came up we were talking about romaxing which probably won't be the title this podcast talk about mixing said if if the job description is the Clint is back on wrong artifact for let's clarify roles then like what the suggestion to modern businesses. And think we both agreed Oh, so we decided let's, let's bring it to Om. Let's see he has idea. Listen, we having I have none no. Thanks his like andI forgot job descriptions may help hiring but not really your performance on job. It doesn't really impact that. So do today is talk about job descriptions and how they're the wrong artifact for clarifying who makes what decisions. We're to break down why writing tasks into job descriptions might only buy you false comfort to little for temporary relief Om] little Just saying you might real doctor. We'll explore why some that startup ambiguity that was actually magic early on may kill your company. then we're going talk about why executive meddling into your roadmap as one example might actually be legitimate. That might be interesting topic. and then we'll we'll talk about the meta problem that nobody knows who owns who decides. Yeah. And as always, we will leave you with some takeaways end. So hang tight for bit. category we're to talk about. The instinct when roles confused is to write down get clarity and to put it in job description or some kind of document somewhere. So the problem is job descriptions are hiring documents. They're written to So here is the first attract candidates. And that's not really best place to keep living document of, you know, on Tuesday Om and I. I decided whatever needed happen, and then Clint wrote it down somewhere. He was one that size between two us. And now we refer back to what Brian owns and is accountable for. Like that's not really job description material. It is convenient. However, is it for someone? Probably not the applicant. Probably I would say not really convenient hiring manager most time either or convenient in the like larger organizations where your folks that go out do recruiting aren't really parked anywhere near the hiring manager or you know, the work. Right? Yeah. Or the work. I guess depends on where it's sourced from too, right? Like lot times the, the hiring documents, something that H .R. just pulls out file somewhere that knows how old is, who knows it matches the actual role of what's needed and then whether not any kind of like if it's a it's backfill. Right don't think think we ask enough. Like is this still role that we're we're hiring for? Like this still relevant to team or team going a new direction? So think the hiring manager has enough conversations with the people doing work and then the people shaping product direction and things like that before throwing job job posting out there. Oh I got good one. I got good one. It was one. was from networking event. was the people writing job descriptions only know how to swing into polar opposites. looking for product unicorns right now is like in vogue inside. I want someone who has great product sense or they might actually say great product taste. and someone with 10 years deep industry expertise and someone who, know presentation skills. Good luck. or to the complete opposite side like totally and has great watered down job description that you know you got people applying for that. They are completely not qualified because you obviously didn't hone job description in any way, shape, form. And one classics from not too long ago is just, know, when people hiring for agilists they would simply just take up this job description of old for a project manager search and replace project manager for scrum master. It's great example. Sadly, think we're seeing some that now also though because they're looking for an A .I. whatever. Right. I brought owner product manager and they take a job description that has more of the .I. in it and liberally sprinkle that in the J .D. but at expense of some core product skills or least that sounded like black and white. But it's maybe not expense of diluting the core product skills. Yeah being a former middle manager who used to you know. I used catch a lot flak. now I'm thinking about this topic. I catch lot flak from H .R. about wanting to like completely own job descriptions because I had a, I had boss manager that really was very micromanage. wanted be included there. They wanted put their stamp on everything. You know mean. They couldn't just like let something pass through be like Brian's doing good job. delegated this to him know, trust he's going get done. They're I trust you're done. But I to see the final draft. And then you see the final draft. I'm oh, one more thing one more thing. yeah. Yeah. That's was my boss to make long story even longer, I think I'm the perfect person on this podcast to argue against. so would expect one the against points to say the act of sitting down and writing does force the conversation that people are avoiding. at least you're documenting it. So it's handled. Yeah. just the sake argument. Let's let me take the other side. that was not yes. And that was boy. That was a butt stop. Let me stop right there. Oh yeah. Yeah. So from perspective of that manager Maybe what they do is ensure success by make sure don't hire wrong person. So they're putting quote unquote guardrails around you. That's how I've seen it go down. But the heart, the guardrails aren't guardrails. They're rigid walls usually And you're just simply checking box that time. They just get someone else do work instead. mean you got, you know, say in this typically is what I've seen in practice. But yeah, the way it's parlaid is So make sure that you know you're hiring the right person. was guardrails end up being along lines of like do this. Not this is what I'm thinking for this I remember long time ago now was hiring for a technical role hands on. Right. But also for somebody was a forward deployed engineer. didn't call that in that case call a suitcase project manager. Sorry, was a forward deployed project manager. Oh yeah, that's was. little, little retroactive continuity on podcast. little retcon. So essentially the my boss time, he had person mind and for the interest that he had in that is should, you should really interview this person. See what think. Just, just to have initial thing. ask, he related this person? Because in my story, was, he was he was a friend So while not a familiar relationship, he was friend. And and way was presented me is you should take look this guy. think he's some. Yeah. And went very quickly from there. To, you know, we need hire this guy before before he leaves work somewhere else. Like why? Yeah, because you know, because said so. And was friend this guy. Yeah. As turned out, we did hire this person within six months. We also fired that person. That sounds right. Not saying if was related to the hire or not, know, it might been for lack core skills, lack of customer skills because you're on site after all. such as such waste time and money. It's just more considerations that need be like taken into account that sometimes people don't think about. But that situation to, you lose that one. was no bringing that up. was definitely on a loose Yes. I'm glad you told that story Om, because it actually fits very well into my top point that the cynical view this is hey, listen, we did job. documented it. We did what asked for. We checked box, rubber stamp, whatever call it. But the also the academic here is sort the exact same. They're parroting the same thing. They're saying a role clarity requires it requires explicit documentation know, had meeting. These the takeaways from it. You know, we were all there. We signed off. And all duties as assigned. Yeah It's like the cover all sins right there. to finish my case, your honor, like the last point here, I feel is the last one here is pretty bulletproof about job description is like that. I, the normal practitioner, normal product manager are just trying job say like I've never looked back my job description to wonder like I charge final say of this thing or that thing? the academic point ironically being called academic. This the wrong word use is is clarity because not looking for role clarity that point. You're looking for accountability. the academic as far we're concerned here podcast is basically the like the person on the Internet who's like writing books or giving talks in big rooms and waving their arms around and who's never done Who's never done it before? know, this is not the person who does every day because because practitioner who's doing day is listen to this section be that's great, Brian. Right? Like have a decision log whatever, but like I've never seen that no one's ever done before. So useless information me. just refer RACI or the DACI DACI that they see. What was one of OVIS I prefer something like this. And we're play games, prefer Ovis from the episode had couple episodes ago where one person just tells us and then they, they just pointed to people be their henchmen like you you, you're, you just fall. I know why. Like I'm a villain 1920s. Now you just follow me around and then say yes. That's right. that's real framework. Oh, Ovis. Oh man, podcast you. don't know it's maybe not live yet. Maybe that's problem I don't know. we get some better it's some better points here. Oh yeah role confusion I think was one of that was original thing, Clint, we were talking about with the role confusion is your job description don't help you when you're working. Like you're if you're working product manager and you have technical lead and technical lead says we can't build that now because we got this technical debt and we'd have to rearchitect And the project manager says, I don't care. This most important thing. So do it. Do it. Let's get done. not do because I've been there many, times. I'm developer. I own all developers and all work So we're not doing that because that just gets you labeled as difficult work with. Not a team player and not team I'll tell you what player. Right. Closer to that revolving door. And and and I will tell you what what you're hear know. You're situation. You're hear boss say just figure out. Let's figure breach compromise. Occasionally boss might say we're not doing that or more likely to come what may because we can't afford lose sale. Figure out like that and you sit down and hash out who actually does have what decision needs be written down somewhere. needs be logged somewhere. The normal agile teams like I would when get conflicts if someone were like networking event and were was bringing this topic up first all, say thank for bringing good topic up because can't stand hearing more stuff as the topics that people bring up. But I'd say thanks for bringing this topic up because real thing How know you're in this conflict? And then like what decision log? What is how even create that? And you know because would think what would say without hearing any deeper the story is put your working agreement once you decide between you, you know, and that be decision log that I would use. But that's just the team. You know, mean, don't have decision log between you your boss decision log between, you know, managers of different departments that overlap and that kind thing. Yeah, team level work agreements are fairly well known What less well known is what you do, know as far working agreements either laterally across teams or vertically. So mid -level management leadership. I've seen ways working type of documents created here but they tend to be little bit more vague in these circumstances thou shall escalate or whatever. But you can't really get down to the. The detail that's needed because decisions change all time. Like the circumstances where you need make these change. I mean it, this, I don't know I'm doing pretty good on my steel man defense points here. Like the decisions should not change. That tells me there's a problem organization. decisions are changing. Like if I'm product manager for, know, Brian's fantastic product, any decision about Brian's fantastic product should come to me. That, that's it. Like there shouldn't be technical leads making product decisions. And your question that perspective, yes. But you know if you've made these things explicit some point the past, now you've go and update them because you, you have different things that consider. Like for example, you're embedding AI into this. Right? So what's stop from doing whatever wants? Who decides the latitude that I has in your product? let's say Clint and I are both product owners and product managers. Right? Clinton has Clinton's fantastic product and have Brian's fantastic product. We're both in the fantastic product suite by way. That's great. fantastic. Do know that we both want embed .I. in our products and we both have our own development teams. Right? So the development lead like Om, development lead is going say, we need build some kind shared component something like that but my team is off like have any bandwidth for whatever certain period time. And Clinton saying, can, I'll just now and put my product now. maybe some executive somewhere else is wait minute. We don't even know like AI is good. And what vendor we go with? go like Clinton's team is just choose Google as our provider. Like I don't do that. How I know anything about Google? Maybe we want use anthropic or maybe I'm Daddy Dario scared me on Internet. I don't want use anthropic. So Clint so you don't see saying like Clinch is make my point. So those decisions weren't there as considerations the past but now they are. Yeah, that's what mean by they change. The other thing you should least have some strategic guidance from like the SLT or C suite whatever call them on what direction and considerations go into that. Right. So that can least kind of bring like like my fantastic product would least bring Brian's product owner in. Yeah, like it. know, what your, what your limitations? Because can least put that together even you don't have dedicated time. Yeah. So that can take those considerations into our research and ensure that hopefully if it's not, know, if we're competing for funding, which if we are Clinton's fantastic products gonna win I mean Oh, maybe, the getting. that's other thing that's not job description is the, the strategic guidance that settles those kind of things without having to escalate make decision well if you have that level of direction from the .L .T. then you don't need job description. don't need Racy like these the things that going win out. And it's documented in black confluence to be able to make that decision. So it should, it should settle those out even though there's no clear cut decision matrix on this person's opinion matters more than this person's. long as strategic direction matches, you should be allowed to make that. But the problem comes when have two super capable people who are both able to spin both their priorities into that strategic direction. then you need escalate. We also walk fine line between OK, if I take all these weird, weird issues and disagreements and priority conflicts that might come up into account when I'm writing this documentation, it's never going end because there's always another. What if So it's, it's the balance between that and then being too vague where nothing gets done ever and every decision needs come you. Yeah. So I think one thing that we ended up agreeing on section was stop writing Java inscriptions as a purely marketing slash external tools. And some kind of we don't, we didn't, we don't know what is this early podcast. We have other sections talk about exactly what is but start naming who holds each decision right and put them somewhere I started this note that's screen now with into job descriptions. But then when was doing the prep, I'm that doesn't make sense. Like can't go in the job descriptions because then the job descriptions will just become bloated 15 page messes as time goes on Hopefully not because hopefully your roles evolving. Listen, if one person is doing so many things that over time their list of what make decisions on grows to the point where they have several pages. It's different podcast. think. Yeah. Yeah. Yeah. So what's your last decision that your team argued about let us know in comments and bonus points if you ended up with one single name that on final call. All right. setting. Just one little tick because know we're still, we're still casual let's up difficulty here. Right? What if some that role ambiguity that you're trying to end was actually the secret sauce that made your startup work the first place? we've already made the declaration that job descriptions are the wrong place to put decisions. But what feels like magic at a company of 10 people is pure chaos at company of 100 people. So that ambiguity that you're trying preserve, it does not scale. it certainly doesn't scale. And that, that, that thing you feel like when you're scaling well that can smell like that's burnout. That's called. It's a compounding debt of stress, heroics, and invisible work that nobody owns. That's that's what is. Oh, that might news to some people there. don't know. Maybe boy. behavioral you know, startup founders want the same level control at 100 part this is people as they did at 10 people. Right? They're scaling up but they find it hard let go because that's how they grew by having control and having the org move in a certain direction. But now if they ease off the gas, it could go anywhere and they just can't take that chance. Right. That's what I've seen very often with startups. Yeah, there is good people and unfortunately wake of that because people that trusted when were 10 person strong and now you're questioning those people as you get to 50 and scale up even higher. So you go from the small to a medium size or that's where I see lot casualties. People just leave and you lose good people or fired. Yeah, I'm go with solid maybe on this one. I don't know expected me to go solid maybe but I'm try stay on steelman side of this podcast. The the founders maintain the same level control at 100 people that they had 10. I'm going to say yeah, yeah, of course. Of course do. What's missing though you can't like. Right. what's missing. What's missing is the expertize that you need to acquire to have that quote control. I'll say quote control because it's not what you really need do is you really need give up total control. Yes. And then learn a different skill the day day is going be ambiguity all day. But any of the employees that we have should be trained enough or expert enough to jump on figure out get it done. then that I think that's level control that we're really talking about. Is control or is it trust or is it both? Maybe because got trust your employees to do the right thing the right time and then let go of that. the other one that think misconception, right? Is was the magic the fact that 10 people or 10? Oh man, love how applies everywhere. So a guy once wrote book called Flow by Mihail Chaksamday. And took long time to learn say that guy's name Was it that more? So there's conditions flow everybody argues how, how many there are. But was magic that the one person was control and they were able to get feedback everybody and make all decisions all time all once. Or was it that feedback was quick? The boundaries were clear. People were empowered able to make their own decisions within their scope because were more trusted which is point brought up. Yeah Or was just good old guy and everybody around in my decision save day and made company huge. I think was closer to achieving flow for everybody. That faster feedback because CEOs right there, the founders right there make decisions. And then when that scales, they want to keep the experts are doing work close to work while adding bunch people between them founder them and the CEO not elevating them into those roles. Right? Yeah. That's why was it was difficult Om to answer your question about control because it assumes that when company was small the founder had the need for control the first place. And I don't know I make my argument. If make my argument on that assumption, I'm lose my argument. the founder only if they only gravitated towards being controlling. It was because when company was small and were five people whatever everybody did everything, the chain to the decision maker was extremely short the turnaround time was extremely short. Like literally we could all be sitting one room every single day and turn to the or you know, a remote. to Slack and you hit up on Slack and I respond immediately because it's on my phone. You know, I'm founder. never sleep whatever. Right? It's that level of of the the decision chains are very, tiny. They're very close work and worker and they're very quick, very quick turnarounds. Like better part that would be at some point the founder would need decide. I don't need say in this thing anymore. And I completely did say I trust you to do. It's like it's like it's basically what Dario is claiming that does. But in actuality, it's what people do is say you're now going responsible for all of process A and or Clint, know, you're now be responsible for everything involving Clinton's fantastic product. The point you're making is really I think the the nexus of what David Marquez is right. Bring the authority to the information. As was commanding nuclear sub, that's what he did. didn't make all decisions because knew the information lived further down and he empowered them to make the decisions But if you're growing as an org from a ten person or a hundred person, you really do have have that. I mean, delegation is just one thing. Right. But have have trust that person is to do the right thing. that's, that's the part that doesn't. So the submarine story, the Navy's nuclear power program, there are a lot training that goes into that before you get to that point. Yeah. And even on non-nuke side on the sub, there's lot training that goes into that before get that point. So it's very easy to tell a bunch civilians like move the authority to work. That's all have do. But they don't tell you is the person I'm delegating this authority to is highly trained in their area and understands what I want them to do or like the the goal of what I'm telling them do Yeah, I mean a point. But think corporate equivalent to that would be, you know, hire right people then train them to do their job as opposed to training. You learn that your time. This is something see all the time. You're setting up my pushback right now Om, you're like you're you're doing job. Listen, we're switch chairs here second because you're doing my job for me too well. corporate America typically is not going to not going to not not train you. They're not put any money into you at basically your car that they're driving for the next 100000 miles. then they, you know, were next 40000 miles actually. And then they're you know, leasing new one basically and not put any money into it. The story corporate America was putting money into folks and retaining folks and keeping a staff at a certain level expertise. Because if you don't do that, the opposite that is role specialization which will increase the larger the size your organization. So the organization is larger and then you start putting boxes around bunch people that work in specialized roles say, these people can't make any decisions that have to do with whatever, know, whatever outside their special specialty. Now you're basically pulling decisions away from large swaths people. And now in that setup truly becomes like I've removed decision making ability of any these people because they're they're only here to do a very small specialized job And I don't value their opinions outside that very small specialized job which is a slippery slope to and don't value their opinions. Yikes. shower time. Oh boy. Yeah, absolutely. Jeepers. But keep going because you've got million shares that you're to, you know, cash out. I don't think that's true all cash in sell out down. don't know the there's fourth one somewhere. I don't know. so I've got some, I've got some points here and I don't know any these undermine argument. think ambiguity, ambiguity at scale is compounding debt. So in a startup when, when I am doing something and I don't know what the right move is right decision makes decision, I my boss is probably founder whatever. And then we clarify it. And then I know who makes decision and what is. And when we scale now, we're, know, 200 people. I might not know to go to anymore. and the other question is when you're in that, when you're in that startup environment and that decision gets made, know why decision was made way? was the, I say justification because it's not like you're, you know, founders aren't trying hear. They justify their position to developer. context just rational. that is the context and the thought process behind that given to set them up to be able to make these decisions the future because that's the, yeah, that's the compounding debt on the other side that is like if they come you for every decision, the cognitive load on any kind leadership position is be terrible. Yeah, I would, would take omen this point to say it's at some point I think that founder scale very well don't, if they don't learn the coaching ability to be able ask employee you think we should do? And then why do you think that? growing their employees by putting it back on them you tell me. This is when I hire consultant company to tell me how to coach people. right? Pay them by slide. Oh, oh, we got move on. guess it's too good. is too good let's what, what, what lose in scaling shared contacts, direct trust, immediate feedback you know, you don't lose ambiguity by scaling like those org charts make with the with pyramid scheme. I don't know keep saying calling man. That's be, it's got thumbnail for this episode. that the role mixing pyramid, the role mixing pyramid all job titles. That's right. How many squares get? Anyway, so I was talking about what lose. lose shared contacts, direct trust, immediate feedback. I think you can preserve the startup energy and have clarity when you grow. But it requires you to continually have conversations and then to write them down. And to keep dividing where your founder not, you know, under the the amount cognitive load where they're basically useless. You know, they're complete slave their calendar. They're buried. Yeah, right. Right. Yeah. And very few people do that. The founder trap, the real startup trap founder trap here they want startup control at scale and they don't ever develop any skills for people Yes, if there are takeaways here they're be super quick. Stop protecting ambiguity as startup culture. Stop protecting ambiguity and calling it startup culture. calling ambiguity startup culture because it's not like the startup culture has the greatest shot to be the most straightforward informed, you know culture that there is and then start separating decision rights from execution because you can, hey, do this case? then somebody tells and that's it. That's like was part it's done part execution. And then everyone goes back work everyone forgets that we actually made decision about, you know, how work. So whatever artifact you use to kind of keep track these decisions. That's a living breathing thing. Right? That's dynamic. Right? It needs be updated as and when needed. Oh boy. Have ever worked somewhere that used where startup as excuse for role chaos? Let us know how it ended in the comments. And diddid end. I can't scale any further. Can't skip. We already scaled all way. So but now we're going talk about the one executive who keeps overriding your roadmap. Do they actually have the right to do that or should they get out my office? was say get **** of my office but I can't because don't care. so so talked about job descriptions and role ambiguity of working startup. Now let's talk about the thing that actually gets product managers to go on Reddit tirades on our product management. So when executive overrules product person or the VP of sales commits to something that will be done on the roadmap by their time frame. So that that actually might be it actually might be right. The sales person might own piano or whatever, VP of product whatever, might own the P and L. How do you know? Would that be documented somewhere? You know, it sounds like something would be straightforward. But in my experience, it never is so executive intrusion. That's we're talk about next. I mean, you can call that if you know again, this is this another easy one for me who has been manager before to be on the opposite side of. It's also and it's also easy for me be opposite side in product because maybe not 50 50. Maybe it's been like 70 30 where I have the actual budget versus I don't with 30 percent being I have actual budget and 70 percent. Being that don't, the one that I always default to that I get in most fights about is the cynical steelman point here that says whoever owns panel owns the roadmap The way I say it people is whoever owns the piano is the real product manager. That's way I say people. And oh boy, does it rub people wrong way when I say it? you're basically just proxy. You're not really owning the product or managing. Take your pick mean, you like without a PNL, academia like decision rights should should align with accountability scope. like the academic one here like theoretically like decision rights should align with accountability. It's logical step. But the rest of it is, is emotion and ego on one hand, yes, it should but the other hand, it's very rarely have I ever seen that true. even I like that. Like luckily can like not take job if things don't smell right. but even I, the overwhelming majority places I worked, the director product or VP whatever, own the budget. And they didn't tell you. I know much money generally people make and know much money the product brings in. What you trying hide? So it's always been excuses. that's nice new Land Rover they have park I told that story on another podcast the guy came in with his new beamer. There was no, there was no bonuses for anybody development department. No, two percent bonuses all around. But he came in with a new beamer. Yeah, he was another these. I own budget. It's complicated finance PE. It's very complicated. Oh, doesn't seem that complicated. That's complicated all. Yeah, seems like the more the team offshore, the more expensive car buy. That's what seems like. Direct correlation right there I don't need chart for that data scientist. It's a direct correlation. Oh man The typical one is practitioner which the one feel for. I'm the .O. in name and sales or VP whoever really decides everything. that we had somebody at at the networking event that is pretty much like how we what do you. Right. The only thing if you don't own PNL, can think telling him like show how, how these decisions will, will move that. Right And they were telling him lot things like that. think I think somebody said like just keep cash in your paycheck. So they know that another one. Maybe almost. Yeah, sounds very Om. keep your resume real and you keep bank. Keep doing it and keep that resume That's right. Keep resume updated keep catching your checks. And I think mine was like talk more customers than they do. think that was my suggestion. Right. Is know, what he was describing. That was way that shop sounded. They needed be scared of what were say. And then if it's like that first place and you do that, what are the odds that you're still be there after they're afraid Oh no, no, absolutely not. know, you're gone. So catch paycheck. Keep resume updated. seemed me the only pragmatic solution at the time First all, just say you guys doing great job my side this. mean, some these, some these, when you get into those toxic cultures, there's not much can, there's not much can do. But mean mean, and then going back the role description, the whole, the whole role description thing is, is when you to hire somebody. Is that either be super fine unicorn? Yeah. Or be so broad that cast a super wide net get everybody and then hiring manager nitpicks you down to like three people that don't correlate all. make result. It makes no sense somebody normal reading it nice thing about a super generic watered down resume that the that your boss's boss fought you on to eliminate lot specific stuff is then can lobby hire their person there and have their had that one person your program being their eyes ears.**** Om, it's long time since got eyes ears [UH] it's been while. with eyes ears. Internal spy. So there are some good points here[UH] like hey set set strategic direction communicate your intent and goal and then let the delegated decisions just let them go. you know, hey, because you can like in coaching, should able to follow up on any decision that you don't necessarily agree with or you want you as leader. Right. Or hiring manager or I don't agree you hiring this person I don't like this thing. Hiring person probably not great example because you probably do want to try. I'm trying think my situation with like the the boss my situation, he never did interviews He never got in the business interviews. And he wanted like have say job descriptions stuff like that. But real close end, did start getting interviews. But it was embarrassing because he wouldn't. He was kind of interviewer that he didn't read resume until he got the room person. I'm like, even here, dude? What you like? You just, you're embarrassing me in front the children. Like, come on [UH] I do so much work. Yes, know. feel like know these people. Yeah. Inside that by get there. And I'm like, you know, go, you go have the conversation afterwards. Well, everybody think? Right? they're like, well, they're, their answers came off little bit this way. And you're like, you know, coming from medical industry, they're going to look at things little bit like this and they're fast turn around or you know, this person was in more on the data side. So they're going to all depending what you want. Yeah. You know one don't like this category is don't like when executive says like trust me have more contacts than you. I don't like that. that's the old [UH] product management, right? Trust customers would love it. Just go build Right? Yeah. Where's the evidence? Yeah, that's hippo card that gets thrown. That's like trump card or a uno reverse card gets thrown down you're like, oh sorry, it's not reverse card because at least then had be lucky have card hand. It's just you know, it's basically flipping table over like, win. what extra context have so that I don't have come you this later? Right? Yes. Yes. Especially they're not like especially we've actually sat down like we talked about first category and and talked about and written down These decisions that I'm supposed make so we don't have to grind our whole organization to halt and try get a hold somebody at, know, something, know, early morning whatever. are great example for me because I can't tell you amount time somebody like I invite stakeholder to refinement because they have knowledge that the whole team needs have. They could just tell me and could write down what the thing is. But then the whole team will only know what I was thinking to ask. And then the translation whatever wrote down. So there's like a, there's a funnel that just happened there. Whereas if I bring the stakeholder into the refinement meeting and I'm asking questions front whole team and somebody team interpret something different way, they can ask a clarifying question. And we have working relationships with each other, so they don't mind stepping over me. You know, I don't care they interrupt that kind thing. I had stakeholders who big league me. You guys know what big league is, Of course. Yeah. OK. Sometimes said that for front of another audience. They had no idea talking Like I'm big leagues. I'm not bother showing your meeting. The meeting was invited whatever. I'm like, cool. And then they wonder why prioritize their feature? Because I'm like, well, you didn't show up get contacts team. You care enough. I'm taking out road map. And I have since I have final decision about my product like you know. Yeah. since you're so big league pulling you in [UH] so can get custom with this job. Oh man. You don't care enough because didn't show up Random overrides will hollow up authority and train org to wait. They'll train people York to wait for the hippo come in [UH] So nobody will make decisions anymore. They'll just wait the hippos into thethe decision latency. Yeah So by definition that better infrequent if they're random. Yeah. And then even even after like that person tries to step step away from doing that, they'll continue to. Right? Yeah. They gave us direction. Right? They, here's the intent behind want the outcome they want. We can, we can get there. It's like so I love using this for trying to communicate like when I'm coaching people on like [UH] how to adjust what they're saying in direction they're given based on like the audience. Right. And where they're at and building trust with their teams. how you tell a two year old to get from point to point B is different than how tell a teenager or an adult to get from point A to point B. You know the toddler. You're tell them look both ways before cross the street. Make sure there no cars coming that you can see and then cross as quickly possible and and get to point B. And you're to turn left here, right here, blah, blah. And this is why. And you explain those things so that they have, you know, cultural behavioral context of how the world works and to get there. Whereas like, know, adult[UH] just tell Brian, meet me Wal-Mart 19 at 230 and Brian make all necessary hopefully decisions to get to Wal -Mart at 230. He's only to step front of the most expensive rolls Royce because that's how we're all this country know they can afford it. I'll looking my phone while I'm on crosswalk. need be told not look my phone while walking. when you, when you do those things and you, you build that context with team, they stop, they stop having wait on you you're just able to tell them a general outcome that you want and they'll get there. But got give them space get there. That's it's the oh yeah, my team has autonomy. I let them things all the time on their own. everything tell them do. That's right Every single tell them exactly what do. You can't just dictate every detail need to if you want to grow team want scale and the same thing rolls into world description rolls into world descriptions. Yeah, that's one the same thing there. You can either go through could detail every task that you want this role be able do. Or you can give the general idea which allows you cast just wide enough net. You call out your, your specific areas that you, you want some focus or some experience in. And expertise or then you, you let it go from there and you set up your boundaries. Right? if impacts more than two teams bring this decision to next level of escalate. Right? But again, those, the job description, role description, not right place to, to iron out those boundaries. Right? Because you're trying attract talent. if if [UH] if we have a take away here, it's a stop fighting executive override rights because you're lose every time. That's why. and then start making them explicit, transparent and predictable. So like a predictable intrusion by management you can handle, you can handle it. OK, well, you can deal with it. can handle it and won't devolve the whole culture all once at least in one swoop anyway. So surprise intrusions are chaos. It's the job of any executive manager or whatever call it to make their override pattern visible and documented if possible. And please, that doesn't mean that you just put in you know, does whatever the manager product manager tells to do. And don't put that job description. don't, don't through. Indeed [UM] stop overwriting. Mm And like you said, start making them explicit, transparent, predictable, which is you're giving that context behind. So whole thing we've talked about somebody mentions intent on the submarine. Yeah, but you're giving context so that can make those decisions and eventually stop stop doing that. Right. But difference between hey don't forget brush teeth before bed and like stop playing the video game. Turn it off. Go brush your teeth. Right. Hey don't forget brush teeth before bed. Did you brush teeth? Yeah. Oh man, I need brush teeth before bed. And hopefully that starts happening on its own. Yep. So has executive ever overridden decision that you thought that you owned? Let us know comments if they really explained why and what their reasoning was. and they gave you all context to make you feel good about it. We will wait long time Not that long though because we've got to move on to the deepest deep problems. Who decides who decides because clarifying roles in itself is decision rights question. And it is usually question that is [UH] unowned. if you're startup though, this is easy question to answer. But beyond that, gets murky. mean, it might even be easy startup because startup have multiple founders then they might fighting about this. So yeah, it's, it's a, it's a meta problem [UH] See, I spoiled, spoiled. was say it's it's meta problem. But but not this meta problem. That's a thought guys to kick out that. So if what I just said was true, itself a decision rights question. And it's usually unknown. And that clarifying roles is means that the org can't fix thing because fixing it requires authority and that authority is what's in dispute. So you're stuck turf war. You're not sure you should be jet or shark or you know, sign out the Zuck over here. don't that. We can all agree on that. mean the steel man here is the easiest one steel man Om, the only someone with org wide authority can decide those decision rights. Like come from top period[UH] I know I agree with that 100 percent. That's why we're here. Oh, I mean, so thing, the thing I've tried do is look at decision impacts. Right. But I'm in, I'm on the people side. I'm kind on the, the HR side but not completely. So try to look at there's several parties talk to because you, the authority got be given in more ways than one. Right Unless you work for, you know, E .A. then it could, it's never going it's never happen. But talk to people. So from H.R. standpoint, the right way to that would talk to the people who the decision impacts and see who they think should make where should lay might not talk them altogether but might talk them apart. Yeah. And then you know because the upper levels are to delegate the decision authority and they you want get the boundaries from them. And so you want what they're delegating off what boundaries are be with hits enterprise wide scale or global or you know whatever guys are as a as company set that boundary. If hits this level, need to come me below this. could do whatever they need to as long lines was strategic goals could prove that. Yeah And then you, you find out where that lays and get that documented documentation isn't to refer to every time you need know to your job. It's the, it's accountability portion. you made this decision. It went good and or bad. And why did make it? Well, long as why made it aligned with the stipulations that were there. You're fine. Yeah, you should be in a good and good company. You would fine. It's almost like there's a Venn diagram happening between like Venn diagram is different [UH] functions of role like financial function, product rights function, something else. Right. then like you don't like don't all evenly align over people and some them overlap. But a lot them do. And that's we're kind describing is each one those needs different clarity. Definitely needs be written down somewhere, somewhere. Yeah, like the idea of documenting the impact and what happened and just finishing that off with how would you do this differently next time given the same circumstances. See, I like the idea documenting as well like the hang up though is with the cynic on this. says H .R. Owns role clarity, not me like I'll push back on that one. I'll, be the Sisyphus pushing that rock up hill all day long Om, is that I don't think H.R. don't think modern .R..R. is trained at all to do this. The organ design stuff doesn't live under .R. They don't know anything about it. That's right. Odd to me. It's, it's, it's not just odd me [UH] It's[UH] tragic. question too, along with role clarity. Where, where is everybody learning how their organizations should structured? Who's, who's telling everybody this? Their immediate manager [UH] Oh, I know. know we just asked CEO and then he tells us if have access CEO. mean, it's small organization. There go to lift phrase from home. They're all muddling through They are badly badly. It's kind too like who like what tells you that you're adult, right? oh, I'm adult. need stop it's that brings doing these things. That's, that's the kind thing like when hit when startup hits certain point, they decide they need grow up and and what. listen you guys. guys are knocking my arguments out of park today. Is that you're really doing great job. Keep up good work. Like I'll tell you what tells you're adult. taxman tells you what you're adult. But what brought like the practitioner is what I hear in this argument right now. The practitioners just say listen Om, like we, we tried to clarify role clarity. We tried to sit down like do this Venn diagram thing, Brian. all we did was in fights and all did was waste bunch time. took so long. And like don't need this anymore. Like I'll just ask my boss. And yes, it's pain having him process whatever. But like it's, it's better than, you know spending all my time in meetings. This is the developer that doesn't know why anything gets done that complains that they don't know when things change. But also they're here crying that they to spend time meetings. I'm like you need to be the backlog refinements. Just update the JIRA. Take Brian. Sure. That's that says we can't write down all this stuff. know, it's complicated in our industry. We're same practitioner different. We're special. You know, Agile doesn't documentation. That's Decision rights allocation requires hierarchical authority. So if you're do decision rights, you need some kind authority that I opened up[UH] all opened up Om, this category basically saying that this is more more formal version of what just said I have a sidebar here. this, this is the instinct. the top down role degrees have authority to stick. But the question is do they actually match the work or it just fiction? Because we asked boss and told us is way does. But then when actually look workers work, doesn't mirror what the boss said all. And and boss not actually engaging. They're not and they don't know about work design and actually don't know anything about way work gets done. So they're just making decision because they want make a, a fast B decision beats a slow A plus decision. They're, that kind person And that is, that's genesis behind the RACI matrix oh, which by way is a fictitious document because in no circumstance race stands true with regard to the four characters there. Right. And individuals at end day so mapped into this thing. So now we say ohoh, we need you. We need Om the project manager that's usually will tapped. We need on the project manager sit down and do racing metrics now for whole organization and all stakeholders map everybody out and write everybody. is such a, such a. This is such project manager asked it's so bold of an ask to think that a project manager can sit down and basically sketch out the architecture of how decisions get made in the whole organization and get it right and list every stakeholder for every decision[UH] I understand. I'm like exaggerating like tiniest a bit. so it's only for this organization this product whatever is. But like useless document is useless and it's waste time. Well, so it has done plenty these in my sorted past. I can tell you this as project manager. You come up with a RACI. Yeah. And things start happening. know, somebody will complain and say, hey I really am not the A here. I'm not accountable. That's right. So you simply move their name to the responsible because it's the next responsible thing do as a project manager. Right? So what I'm making is project manager. It rates on this thing to kingdom comes know. So they don't necessarily know anything but says place to start. Right. That's the other side the argument. like, well, why have race? Well, place start. least it also gives you hopefully some people can tap if they're truly R's and A's here. Everybody else could be off the RACI altogether, especially ones that are the I's informed. Why do inform me? Right? I need know. But if I didn't inform you, I'd be mess. Because could turn around say nobody told me. So I'm put name in the I column. it sounds like you want races be iterative and not something that just gets done then set aside for Listen, it's Racy is 100 percent. In my experience, something that a project manager just spent too much time does once knocks it out and then it's in concrete in stone or in reality it's a SharePoint somewhere that never gets looked at. Drive. Yeah, agreed. gets looked when things go wrong. And you're right. you're right. It should be iterative. It should be living. And maybe maybe we have opportunity to bring RACI into the 21st century and start using it. who who who are you looking[UH] HBR says consensus is dead and proved with consensus. That was good [UH] is where we talked about [UM] one the authors of the article reviewed and that was a BGC consultant. was a, I guess, senior director something like that. don't remember his job was. But BCG had don't use RACI. They use Ovis[UH] Are agile to 62 framework. And don't ask what Ovis stands for owns veto influence and supports. OK, but it's not what you think because the one single person owns the decision. And the execution and resolving conflicts around it. And then two people have veto power, I believe, or maybe one person has veto power. And then and then the there's a limited amount people with influence But it's really meant to like consolidate power with like one person. That's the whole point OVIS. to not make one person have to talk to many people. mean, was basically what got. I'm really, poorly representing OVIS that was idea is BG came up with their own little, know, pet model. They know their audience, suppose. Yeah, it does you one neck to choke if that's your objective or. Legitimizes your grasp for all encompassing authority. Absolutely. Let's move on to, me seeding some ground here of the top degrees We already talked about the top down degrees like they don't, they need match the bottom up efforts. This is every agile transformation I've been part of. top down degrees don't work bottom up negotiation needs referee. So both are required. that's it. The fastest, the fastest better points section we've ever done And we go through points. That's it. Yeah. Oh, OK. So [UH] take away. Stop trying clarify roles without naming a referee or knowing referee Right. then start with who has authority settle disputes or whatever that you know whatever that decision is. Who's the arbiter? Who is arbiter? Yeah. Because most time I'm telling you now you're know. That's right. Like the financial decision thing that were talking about before. You don't even know who who holds reins to budget. mean obviously it's gonna someone finance [UH] that bubbles CFO. But maybe that's plan. Go straight CFO. Hey, who owns finance for this? is man finance? Oh, somebody's looking man to finance his name is Sam Gippity Altman. Oh boy [UH] I knew knew going come picture. Some he always does like I think he needs be ten thousand dollar pyramid somewhere. needs can we make something that just slide Sam Altman and randomly here? Absolutely. should be a, it should be virus like the old school viruses that were just funny. Yes, yes we absolutely can listen. It doesn't even take any work like Sam Altman finds way So who has authority to settle role disputes on your team? And us know comments and feel free to tell us the truth. Yeah, we have no name. We don't know. That's fine know, hey, us know So let's bring all back home let's talk about something can actually use on Monday morning. Let's talk about fixes. We're get our fix right now. That's what's happen. So so walk through the job description traps. We've walked through the startup role ambiguity, executive overrides and problems of who decides. And now we're going talk. practical fixes for these impractical problems. So no amount of improvements to the job descriptions are to solve this. you need [UH] some sort of [UH] decision rights log or overlap or Venn diagram or something. A living document that names who decides what who updates it and then what we do when things change or when questions come up. And that's right Om, another document. one will read this. this cynic can go along with all day because nobody reads these things It's, it's, it's not really about reading though. It's, it's, know, it's about having boundaries for roles because otherwise don't know how do this like you keep all brain. That's do it. that is how people do Keep their brain. One person knows it and then that person leaves and then nobody knows what's going on. Oh boy [UH] you want to really find out things that you don't know organizationally that are not written down. Wait until people start leaving and then you find out what they really did job. But even in orgs that actually do document stuff, this still holds true. think people don't read this. don't know. Most people don't even know where to find such documents. that's, that's, that's one thing is like it's buried confluence in like four different subspaces of subspaces. Yeah It's one H .R. adjacent manager type pulls it out when they need to build job description to to list role. And then gets tucked back again. But like the other thing that talking about earlier is lot these are written in in our language. Right? It's like what is what ensures stakeholder alignment. mean? Great man. Yeah How apply that? Like is or which stakeholders and which situation and which. Yeah, yeah, yeah. So these docs don't even get updated. said that earlier. But that's true. There's a there's a there's more points here that think are really good. this is probably the best steelman I'm have. So I'm going to, I'm chew the scenery here for minute. Like the academic here going say, well, if you're have any kind of decision rights framework or Venn diagram whatever probably Venn diagram is. If actually try sketch this out. Good one. It's probably good one. Right? Because otherwise it'd be like weird borders that go around tiny like like finance would like the product manager have a little tiny sliver finance. But they wouldn't have like governance finance whole organization. is kind a distorted Spotify model almost. You're drawing borders all around everywhere. It's between tribes. It's, it's like Spotify model except whatever, exceptactually need it and it actually has to function. And we actually have use it. And also one's get famous by posting it. We're just to help ourselves for more fun on Spotify. See Arguing Agile 246, the Spotify model, the viral org design that never existed. That's we write this one probably get cut out too. Sorry, I'm killing your editing. luckily Fable fixed my editing! So we're alright! All right No, were watching video that came up that was Spotify walking through their like redone headquarters. And my wife was like, this is why raise my prices. No. And she canceled it on spot. And I was all right, I've telling that forever. But this, this week, know, there know, know, thing about the Spotify wild is they're like in office call. thought were remote company but were. Were never remote company? were always office when they came out with the model. weren't remote. Yeah. OK, so were never remote company. oh, oh, you know, and then the other one, the other one in this category that excites me most is practitioner says look, just need know to ask about this thing. don't, I don't care about design or where H.R. sits or whatever. That might got cut out podcast. don't know. Maybe like I just know ask. don't care. That's it. just work here. That's the I'm looking at it to fix to fix something because had people come me and like, hey man [UH] who do I to for this? I'm like, oh it's in confluence somewhere And then read document. I'm like, oh, it's not there. Yeah. So that's we sit down again. We try sit down with everybody and figure out where that's supposed be and then document it. But it comes down to thing and the cynical view of another document that one's read. Right? Why? because I don't wade through six oceans worth of.R. speak just to know I want know who to ask you would like there's so much tech in like the typical, you know, for me and like software development world, there's so much tech seem like normal stack. feels like every company is the same, like five tools whatever. They all use Slack. They all use some kind email, know, like that kind stuff. You would think that that there'd be somewhere know, like your slack bio or something like that to have link to your, you know, your little Venn diagram of, if you have decision authority, some people truly haven't. They're just specialist doing specialist job and they have to bubble all their decisions up, But other people that actually have decisions that they have the authority over. Why that not just visible? You know, it's like find out where somebody the org chart. Like usually in companies can dig and find org chart and you can find where the somebody is. It's little bit pain sometimes depending on technology But usually that. But you can't find this. Brian is, know, Brian's fantastic application. Like, well, what the borders of Brian's fantastic app? You can't just decide make corporate agreements with Gemini whatever How does anyone know that that's not my wheelhouse? I can't decide change price my application. There go. There's another border that nobody knew about. It's time price hike. we're Spotify over here because don't truly own your product, your fantastic product, random and frequent so there's some better points here which think all agree with the, the decision rights log beats the job description. mean, we already said multiple times job description not not right place The log has have an owner. It's living document. already talked about that. And then and then things we didn't talk about is like the goal here is visibility to decisions, the transparency to who makes what decision. So goal visibility. Like we're not trying to do the RACI metrics hit every single person whole organization plus stakeholders plus whatever. Like that's waste time. Don't do it. I'm talking about RACI Also, don't use any these artifacts as a blame tool. Right? That's not the idea[UH] on number three start small. Now we have everywhere. Yeah, could be snooping in on your meetings and stuff which already doing anyway. Probably right the next. So I could actually start to pull out some nuggets vis a vis, know, these decisions. Right. And start to least create repo of some kind, which obviously not enough, but it's a start. So that's how get ahead. Start small, but can also use AI. What you're proposing now great. I've worked with few executives, especially when was first product manager organization that are going hate this because they want the ability to basically maraud into any product decision because they remember time when was just them. struggling to swim whatever upstream. don't know. why they're salmon but they remember. They remember when they had the authority do that. So they want into customer and start talking about things intersect with road map. They're not say stop. Let me go come get Brian. they're just have conversation. That is problem yeah, it is problem but it's also reality. Yeah, I get that. So vein of trying helpful to those us that still listening here. Right helpful. Maybe just make them part the, you know, part the solution. Right? say you own this much anybody else. Yeah. So they're not caught like on an island. know. Maybe but also like I'm willing say maybe that's a maybe that's a a separate situation like that you could because you have earn that person's trust slowly over time and you have to get them to remember to bring you along. You know, in conversations you previously were not included in. again, there's a I'm planning whole I've been planning for like years, a whole nother podcast on that specific topic being first product manager it does happen. Yeah. But but also there's some bosses that are not, you know, not first product manager. They just are overly controlling. They want have. Yeah. You know, they be every conversation. Should we repeat that advice? always give them [UH] that's case. yourself find job. What is the advice? don't know. Keep that resume up. Oh, that's right. That's right there is takeaway here stop writing job descriptions to solve a stop trying to solve your decision confusion with job descriptions. Right. And also stop trying solve by just keeping head. Stop trying solve it by ignoring it. There's a bunch different trap. Stop trying solve by doing and then just start start writing down. Start writing down. It doesn't matter how how write down. Start writing down. Yeah. Hey, I wrote down, but then document didn't go anywhere and we never update. Okay, fine. But least wrote down. Remember where you put it Right. And always remember you parked your car or that I just edited podcast. don't know it'll before after this one. were going on on about tying your camelot. don't know what doing that day. remember that too. don't know how we got into don't know either. Oh, it was a weird podcast So what some of your decisions that your team argues about? Let us know comments and also us know the let us know know who decides each one or not. And with that said, we're to move out to the final sticky that I've got on screen right here So started with claim that job description is lie. And and so we're finishing with screen can pause on right here We've got the five takeaways from this podcast written on You can pause the podcast. can copy down sticky somewhere. Put on side your monitor so you can work them in the next week at your work. and that's [UH] that's, know, that's this podcast So to say thanks to Clint to turn over floor to Clint and or Om and see guys have any final final thoughts. I would add revisitation cadence that. OK, like when you're all things were up good. Things change over time. Like Om said it should be iterative, iterative. And you should decide cadence on how often that gets revisited, whether it's every fiscal year or every quarter new products get created, new teams get spun up, spun down. Yeah, things, things change. make sure that yes, you set this. Yes, things get added to it. But make sure revisit it in like a regular attempted meeting and sort it out. See if everything's still sticks. good luck trying line all calendars up. Right. All righty. Well I just wanted to end on one note here. Intrusion is not the problem that you think it is because every time I come across situation with clients, go, those execs, they come down, intrude and interrupt all time. That is not the real issue here. The issue is unpredictability when they come. So fix situation as we've described this podcast, you'll better handle those[UH] those little[UH] intrusions or whatever extrusions, whatever want call them Thank you very much for staying with us this long. And [UH] let us know what you think this podcast in the comments below. Also, us know about any other topics want us to delve into. Like subscribe while you're there. And remember, every intrusion is an opportunity for contextual understanding.