AA200 - 20 Years in Tech: Lessons Learned

welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. Thanks for sticking with us on this journey to episode 200. And episode twenty four. I was looking for that one, Om. Episode twenty four. We did career profile of enterprise as a coach on Patel. And it went so well, we didn't do it again for 180 episodes, 180 on, yeah. Let's see how it's changed. My goodness. So I like, we did that one and I'm not sure when this episode will go up, but it, February 2025 will be 20 years in tech for me. 20 years in various software development roles, program manager, people manager, product management like all the titles. And I wanted to have a podcast just to kind of have a retrospective with you to kind of talk through all the different things that I've learned and wisdom that I've come into 20 years on. Let's see. This should be an interesting one. So the first thing that everybody would be interested in like the little hanging fruit would be, let's talk about how to recession proof yourself. Cause 20 years in tech. Avoiding all the layoffs and dodging that kind of stuff. That takes some kind of skill, I would think, and luck at the same time. I'm not going to discount that. So let's, let's talk about like straight off the bat, my background is, are the three double digit decline backgrounds in the job role. in the LinkedIn survey of job markets right now, is that quality assurance. Consulting and product management at the triple threat of double digit decline was on that list. So we'll see, the other one was like agile coaches or something like that. Of course. So the, the recession proving yourself like the, the, like I have this thing that I've been saying the last couple of networking events I've gone to. I'm going to say it here, my hot take, get your, get your response to it. Like unfiltered, because it's not on our list. At this point in my career, 20 years in, I don't care about job title. I don't care if you're an executive, I don't care about anything else. I care if you talk to customers on a regular basis, or you don't, those are the two dividing lines in the business. And all the people that talk to customers, recessions and all the downsizing and whatnot, and all the people that don't talk to customers on a regular basis. I worry about those people, and I will advise people, especially like in QA and whatnot, you need to get in front of the customers. Absolutely. I agree with you first of all that it's pretty much binary. You either talk to customers or you don't. You don't kind of sort of talk to them. Yeah. So that, that's true. But people that talk to customers, you're just saying that they seem to thrive right through the bad times. There's a reason for that, I think. And that is because they've lifted a day in their shoes. They understand, not just superficially yeah, I'm hearing you, not like that, right? They actually understand and empathize with customers. And if you can do that, not necessarily saying that you kind of do that as a forced thing, right? It's gotta come from within that you care about solving their problems, right? Then it doesn't matter what industry you're in. Honestly, I tell other product managers that, it's tough to communicate by just saying it. You kind of have to live it. And I tell them the customer's experience with customer service reps or salespeople that visit their site and whatnot. That is different than their relationship with product. Product relationship is more transactional. I talked to you, I get the feature, I build a feature. I put out with some release notes. Go away. we did on a podcast. We had the quad where it was a user stakeholder management and it was like a power over influence matrix , if you map out that quad, you have a different communication strategy for each piece of the quad Certain people you go back to and you're like, Hey, I want to do this feature. This is the way I'm thinking about implementing it. Maybe you run the wireframes by those people and you get their advanced input. But some people you just send them in a release notes when you're done with it. one of those pieces of the quad that you should be meeting with. Like face to face, you should actually be talking to them. I mean, face to face could be online. But it's not in person. It's talking to people in real time. You should be talking to them in real time, but also not just at the beginning, right? You should time them throughout as you're building the product, show that to them as frequently as you can, because then you're closing the feedback loop and you're getting feedback as fast as possible. I might be advancing to another talking point that we have here. Later, but most teams have the to do doing done some variation of to do to, to do picked up by development waiting on QA you know, waiting to go out to the, whatever, pipeline to stage or whatever, like Sure. It's all basically to do doing done. Yeah. Very few teams have to do doing done. And then a swim lane after that says validating with the customer that we actually solved their problem. I, I mean, I'm talking 20 years. I've seen maybe one team that has done it that way, where it's just ingrained in part of their process. And I feel if you had a system like that, that just, it was just ingrained in the process, it's like, Oh yeah, we set the board up and it's got the validation step after done. Of course it does. Why wouldn't we do that? Like if you set it up that way, it was just so ingrained in the culture. These people Problems it would just be instead of implied, it would just be like organic. It will just be part of it. So what doesn't help here, right? Are the tools. I don't know any tool that you can, that you can say something is done. And there's yet another column beyond that they stop it done. I will forces the thinking among teams that when you're done, you're done. I'm a hundred percent with you that this is one of my learnings is like, the tools are completely deficient and that's because like the most powerful tool in software development is empathy. And they're like rolling empathy into your tool by having something like a validation column that says like, okay, we did the thing we said we were going to do now. We need a placeholder for a conversation. To make sure that we're on the same page, just to follow up, to be good. You know, this is, I ascribed all of this to operational type of activities. It's just being a good operator. You said you would give me money for a thing. I said, I could do a thing by a date. I did a thing by a date. Now I just got to follow up with you and say, Hey, after I take your money, is this thing good? Does it work for you? Is there something we could do better? Get a little feedback and our relationship will develop. We'll get a little stronger as partners and you'll be happier and I'll be happier. Yeah, it's a win win. This is not a zero sum game. It's absolutely not. I mean, speaking to customers after you delivered something and actually following up in a caring way, you're building trust is what you're doing right over time. And trust. Translates to loyalty at the end of the day. I mean, you may be shocked at learning things like, okay, we deployed this in production, we're done, but is the customer even using it? Another takeaway is your time to learning is probably more valuable than nearly anything else. Reducing the time between you don't know something and now you're an expert at it I went to a networking event recently where I was going on and on about using Python and a grid framework that I was like, why can't I just get a good grid framework that I can just like, here's the grid, Mr. Framework, just do things and figure it out. Like, first of all, I figured it out. AG grid. Thanks, Ed. The time between like, I just need aggrid framework. I have no idea what I want to do to like AG grid with when you're returning a date, you never need more than like 20 pixels. To do the date and then you can flex the rest of the columns and just say like go crazy You know column length or flex equals one for everything all equal length everything all day long But this particular column it always has to be at least you know Min min with 20 pixels like until I got to that learning the time between oh, I need a grid I don't understand to I got it. I like this is how to do what I'm looking for. Like Shortening that time and making sure there's no barriers between me just going out over the entire open internet to shorten that time. Like that is what I call learning speed. I did it with grids in this example. It could be deployment or kubernetes or learning how to use AWS or how to do on prem when you're spending a bajillion dollars in the cloud. So time to acquire the knowledge you don't have, right? The time to learning that that is actually what we're saying here is that that's actually more important than the learning itself because you're going to continue to improve on that time and shorten it by The approaches you take. Never mind the fact that technology being what it is today time to learning is enabled, you can shorten it because you now have AI and it can do a lot, right? It can give you code for specific things that you can give it scenarios and say, write me Python for this and we'll do that for you. It sure can. It can't debug worth of Yeah, I know. Not yet. We started with this whole category of like recession proof your career. Like the, the people that can shorten that learning time, which, which honestly, a lot of it is done on your own time. If you're a curious person and you like doing this stuff, And you're adaptable then I think you'll be okay. You know, again, I worked at a place and I've told the story on different pockets when I was a manager of QA and I would interview people, I would tell them like, Hey, if you're, if you're a curious person and turning over your whole skillset in three years, appeals to you to be meeting all the tools and technology that you use today. Three years from now will be completely different. Like think about that completely. I mean, it's a little bit different now with AWS because AWS and like Azure cloud and stuff will probably always be there. But like even that, like 10 years ago, that wasn't a thing, right? They weren't always going to be there. So like three years from now, who knows what's going to happen. The beginning of my career, Python it did not even exist. And now I pretty much exclusively write everything in Python, like that kind of thing. If you're excited by that, you probably be okay with this, but also you, you corporate America is not going to make time for you to learn those skills. You're going to have to do it. That's not a statement like against or for. Corporate America. I'm just saying, if you want to have a lengthy career that is a truth. You got to be hungry to enable yourself basically . And it's largely in your own time. Absolutely. But this is an example of resilience adaptability, right? There are lots and lots of other ways you can be adaptable as well. And we'll talk some about some of those a little bit later. The other thing I want to talk about is the old Marty Cagan innovation or innovation theater. What does he call it? I think he calls it Product theater circus. No, he calls it theater. I can't remember what he calls it, but basically the idea of like innovation theater versus like actual product operating model transformation, or if you're more than 18 months old, like agile transformation. Organizations generally over the course of my career they can get confused utilization. with progress and this is pretty ubiquitous. Yeah, unfortunately. Yeah. I mean, that's already been talked about ad nauseam out there, right? Utilization over effectiveness. People talk about efficiency as well, right? In the same vein. It's like per dollar, what are we getting? First of all, it's very difficult to measure. And what you're getting, right? So the only thing you could do is make it relative, like per dollar, what are you getting today compared to what we got last month or, or what can we be getting next month? All of that is futile. The only thing that really matters is keeping those smiles on the customers the real change happens not from top down dictates or technology changes the real change happens when somebody agrees to change the way they think about something. And this is the introduction of product management to the field and why product management has become as successful as a career track as it is, is because organizationally, it's their job to adjust their views based on the evidence that they see. It's so ingrained. And there's some different roles coming up now. You actually researcher and stuff like that. But like, organizationally, the product managers now are the people that are leading the way through this kind of stuff. It's like normally you'd have a manager and they say oh, we have this new initiative. We're going to push whatever. And people go back to doing whatever they're doing when the manager goes away, but a product manager, like you, you're being delegated. We did a podcast on the Amazon looking backwards. Amazon will declare like a single thread, a leader like, okay, you're the person to figure out like how we store our data in the cloud. And then AWS evolves from that. Or you're the person to figure out how to bring a streaming video. And then Amazon prime works out from that. So that's the way they do it. And product management has kind of evolved from that kind of ethos it's like giving a product manager, the budget and the bandwidth to do a thing, and then like leaving them alone to do it that's, that's trust them to get the job done. Don't interfere. Yeah. That's the idea here. And then like organizations that are not doing this, like I tell people all the time, if you don't control the budget and then you have to ask for a budget, go up and find that person that you have to ask for budget that says, yes, no. That's the real product manager people. And listen, people react very poorly to that. It's a hundred percent true. It'll be the same people that have to keep going back to the well for more funding because they don't get it. People do not like being told that. That's right. Absolutely. But, but look, at the end of the day, everyone's experienced this. If you've been in this space for any length of time, you've experienced this. Well, speaking of things that are nonsense. There's a phrase that people misinterpret all the time what gets measured, gets managed or something like that, which wasn't the original quote. I think it was a Peter Drucker quote that is let me go find it. People have, yeah, find it. People have actually abused it. What gets measured gets managed is wrong and Drucker never said it. Where's the real quote though? This is gonna hurt. I was gonna say, we're dredging the internet now. I'm not gonna be able to find it here. There's a through thread through my whole career about metrics, I'll use the yearly performance review as a perfect example of this. Yearly performance review happens. Welcome to Brian Om's software development company. Your bonus is tied to year end performance. Your pay raise next year is tied to year end performance. As your manager Om, I don't know how at Brian Om's company, I'm your manager, but based on my review, we recommended pay raise for you and all that kind of stuff, except like maybe I'm out of vacation like half of December . So then you're like, you don't get your performance and whatever, but somehow. Come January 1st, your first paycheck in January has your pay raise already in it, already predetermined I can't tell you how many times that has happened to me in my career. And when I mentioned it out loud, people do this weird dance about like, Ooh, I don't know. But I understand that there are numbers that finance gave you we can both understand that's the way the corporate game is played We like the people we like we don't like the people we don't like And we know what those numbers are going to be regardless if I was a good performer in the year or not let's push the fallacy of these metrics that they matter Okay. Yeah. I mean, look, everybody has their favorites at work. And so, yeah they're going to do what they're going to do. That's the thing about humans, right? That one person who is going to judge you, how you're your performance has been. So nowadays though they say, well, we're going to talk about your performance, but your pay raise is not tied to that. In other words, you're not getting any pay raise. Yikes. That's when you say, well, have a nice vacation. I have seen quantitative metrics destroy the qualitative essence. Of the work in a majority of places that I've worked because we have picked the number out of the air and are shooting for that number. And I think anybody listening to this can understand when I say velocity, I'm going to pick velocity as a manager, because I literally don't know any other number. It's too difficult to educate myself and what the real numbers that affect performance would be, and then to go dig and look for them or to make the measurable, maybe the systems that I use. Broadly it systems, right? That they're not capable of logging the real numbers we'd like to see what, what are usage of the system by users? Stuff like that. Well, that would require like development effort to allow those things to be measured. So in lieu of that, in the absence of real metrics. We're going to make up a team velocity number in even if you do like all velocities, nonsense, we use combine, we use throughput or whatever Number of stories per sprint or month or timeframe or whatever. Even that can be game. Cause like now we're going to break our stories down into tiny, tiny little to the benefit of our team. Cause like one by one by one, the old Mike Miller Oh yeah. One, one action, one I always mess up one actor, one actor, one action, one result. Yeah, great. You should do that. But also there's a gaming of the system to be happened. So over a career I've gravitated towards let's all be cool and not measure anything. Listen, I've never met a metric that can't be gamed or manipulated, right? And this goes back a ways before agile, when we were doing waterfall, right, then what was happening is people would simply pick a number out of the air or date and say, meet this. You're going to give the, if they ask you even, right, you give their estimate, but you're going to pad it in there because you know that it's going to take longer. And if it doesn't take longer, you're not going to tell anybody you're done. You're going to just wait until that date rolls around. Oh man, padding. And you bring me back to my early career of padding of like, we had a formula that actually, believe it or not, it was nearly like 95 percent accurate. And for a project management formula, that's really impressive. It was, it was really close about, it was something along the lines of like, whatever we predict it would take to do the thing. We would add a 30 percent padding to it and then we take the whole feature or whatever it was, and we'd add an additional 30 percent on top of it. So I don't know what 30 percent of 30 percent is, how mathematically that's done, but whatever that is, it ended up being very accurate at that particular workplace. But again, that's the thing about this category. It's all contextual with the team and the workplace and the time of work that you're doing. And at that point where you're like, Oh, it depends on all these things. it's basically useless. And then when you change teams or you reform teams or you're get bought by another company or whatever, like all this stuff goes out the door. So why bother building so much around this when like the tiniest little, like a breeze rolled through. And it's all invalid. And also I feel we're ignoring the main thing we could be talking about, which is individual potential and the potential of teams, which is a group of individuals is completely nonlinear. And contextual based on what we just were talking about. Yeah. Yeah. Fully agree with that. I'd far rather spend my energy and attention on simply letting the team do its thing, keeping them intact so that they can work well together over time, reduce churn or eliminate it if you can. And then you could look back and say, Hey, listen, we did, we did something in the past that took us X. This is going to be more or less between X and Y. That's it. I'm glad you went there because the, the most important things of a team figuring out how to do something and. a team figuring out how to absorb a new person or the loss of an old person or a team figuring out how to communicate with other teams to have their work not interrupted or the decision making process not delayed. All of those things were this category is about metrics that we're talking about now. All those things don't land on the balance sheet. So we have no idea how what is the ROI in my team? Being able to unblock themselves because they've learned this skill. I can't tell you what it is. Some people might hear that and say like, well, Brian, if you haven't in 20 years, you haven't figured out how to, how to quantify, you know, the, the development of the skill of the team to unblock themselves with regard to other teams that they're dependent on and stuff like that, like maybe you haven't succeeded. Yeah, maybe, but also show me what time sheet item I should contribute these hours to where my team is figuring out how to unblock themselves. Like they're not writing code, right? They're not contributing directly to a, like a customer that like they're not on the phone with a customer, but they are working within a team going to their standups or going to their refinements or whatever, or having ad hoc meetings. And saying like, Oh, well, you have this piece of code and we have this and this, there's this deployment pipeline. So how do we contribute to whatever, whose repo do we work in? How do we work together cohesively and then not have it be a big deal when someone just wants to change something easily, like have it just be a normal part of the process. Here's another one. This developer likes, Collaborating with people they send out a message on Slack. Hey, I'm in this part of the code working on this thing today. Anybody want to peer with me? Yeah. You know, here's a meeting link or whatever. I'm on the call now or whatever. Here's a huddle. If you use a Slack, you have huddles right here. I'm on the huddle. Now I opened a huddle. Like I just opened a room and anybody can join whenever they want. Like the people that proactively do that kind of stuff are in a different league than the people that are like, I picked up a workout and I'm doing great today. No blockers. I can't communicate the database, but no blockers. These things are not reflected on the balance sheet. We don't have a good way to quantify them on the balance sheet. And that's why they potentially will degrade your culture. if it persists long enough, it becomes a problem. These are hard to measure, just like you said. I mean, the two things that come to mind are team building activities. How do you measure that? You know, what GL code do you ascribe that to? So the other thing is and you know, it's just a time element. You could measure it. But how do you measure the value of onboarding and getting somebody new on your team and getting them familiar with what's going on supporting them? Right? How do you measure that? You could say, well, we spent 14 hours doing that, but it's not like that because the next person people who are higher up measuring this stuff will say 14 hours. Okay, that's what it takes to onboard a team member. So you've just generalized this. So the next time you have someone else joining your team, you're not going to be able to spend longer than that, because that's frowned upon. Now, most people just don't. I mean, the brutal honesty of this category is the organization is critically undervalue soft skills because it can't measure it on the balance sheet. that's the thing. But, the soft skills will hurt the whole team and the organization is there's no leadership in the organization taking ownership of people development, it should be like, if people want to call themselves head of people development hr is like relabeling themselves if you want to claim that you're in charge of these things you need to take ownership of these things Otherwise, what are you doing with your life? So yeah, this is this whole thing about enabling people. I'm not talking about giving them technical courses and things like that for the, the hard skills is all the soft skills, right? Facilitation, for example, right? This leads us right into a category that like, it's, it'll be pretty quick for us because I feel like on a podcast, we harp on this quite enough, which is agile. Quote agile being at like a little a agile, it's just therapy for the organization. if you're going to sit on the couch of organizational. Uh, We're going to talk to you about like, what, why you care about process and all that nonsense instead of actually reading the principles. Like when we listened to the Clairvaux podcast, the arguing agile 192, and she was like, Oh, You know what? I'm so inspired that I figured out that a way to run better projects is to organize those projects around motivated individuals. And then we build a teams and the projects around them. I'm like, that's shocking because I mean, that is almost, almost verbatim and agile principle. Principle number five is build projects around motivated individuals, give them the environment and support that they need and trust them to get the job done. And she's saying this stuff like I think Ed pointed out to me. he's like, listen, somebody just told her that sometime, like in a coaching session, somewhere along the way. And she didn't know it was agile principle and she took it and she rolled it into her, Silicon Valley playbook of like cards to throw down on the table when you need to win at hearts. He'd be like, boom, eight of hearts. I win the game or whatever. I was like, do you throw hearts down or you try to not to throw hearts down I can't remember how you went to arts, but like she throws that card down to win the game, it's an agile principle. The principles still, like if you go look at the principles and you forget about the, the actual agile manifesto all the values in the, in the, in the agile manifesto, forget those and only look at the principles. I feel you'll have a lot of people like regurgitating what it was like written up 20 plus years ago and nothing new has been developed. they're more about revealing systemic dysfunction. If you look at every single one and then look at your organization in a mirror, they're just saying like, Hey, rather than doing these things that your organization is doing, just talk to customers and build what they want to be cool. It's easy to explain and easy to understand, but difficult to master because we have this muscle memory. We've always come up through the years, decades of working in this prescribed waterfall type of mentality. And so the other customers, no, I know what they want . I talked to them last year. I know what they want. Well, all the agile stuff is just a means to an end and you have teams that have the psychological safety to ask questions and Question everything, go wherever they want, like basically disregard job titles ask any question to any person and you have teams that don't. Teams that use psychological safety as a tool to get ahead, it's the ultimate competitive advantage in that scenario. If you're a team that has psychological safety and you have a competitive product slash team that does a similar thing. I believe you will win. A hundred percent of the time. I agree with that. I think that that advantage is also sustainable because if you're keeping that team together, they're gonna continue to improve the rate at which they improve, right? But to do that, they have to have that, psychological freedom to be able to say no or whatever question everything, right? Yeah. I think there's a few statements that I wrote down before we started the podcast teams don't fail because of technical challenges they feel because of failures of trust was a huge statement. I think that might be one of those things that's at the root of a lot of things. Failure to trust and failure to not only obtain trust, but failure to then also give trust. Yeah . Yeah. So that principle that we looked at earlier build teams around motivated individuals and give them everything they need to succeed. And then. Basically, I'm paraphrasing, but get out their way. Don't, don't keep looking over their shoulder, right? To do that, you have to trust them. That they'll get the job done, and they'll do the best possible job. If you don't trust them, they're gonna see that, they're gonna sense that. That's like, almost like a approaching a, a strange dog. I mean, the dog's gonna bark at you because he senses your fear. So that's basically the same thing here. if you have two teams, one is psychologically safe and they're, they're really working well together and the other one not so much, you don't hear anything, they tell you what you want to hear, right? In that scenario, it will become very clear where your organizational is flawed in terms of the, the, the work structure. It will become very clear. The manager over here versus the manager over here. I almost want to say leader over here and a manager over here. We'll get there. We'll get there. I mean, well so again, when psychological safety exists on your teams, courage is a renewable resource as opposed to courage is in the form of political capital that you have to expend to get ahead in the organization in a place where you're not psychologically safe. I need to interact with this other team to get them to do something for us I have to spend political capital in those pathological type of organizations where psychological safety is not a thing, but maybe I've carved out this little agile transformation with under a specific director if you're in one of these organizations where you're Agile in this corner of the organization and then everyone else is like whatever something else and Whenever you are successful Everyone is looking at you like hoping that you'll fail we did like arguing Agile 193 we outlined in different types of organizations. It was a pathological. bureaucratic and like generative. I think those are the three types of organizations. And there was a model that we outlined. But in those organizations your communication, all that stuff is not blocked by these processes or the there's no, there's no borders. You can go anywhere to learn any lesson that you need to. And in that environment, in that kind of environment, that unbounded environment, like collaboration becomes a highly valued skill. Whereas like in a bureaucratic organization in order to get a release. Out of production. Like you got to open a ticket and then the tickets got to go through a certain team and what a nightmare, an absolute nightmare just to get a normal release that you have features in. Every fence that you build. Blocks psychological safety. I think what you're describing there is what I like to term organizational rigidity as opposed to agility. And there are many layers to it, like some of the ones you mentioned, right? In that example, you can think of several layers on this. Someone has to approve the release. Right. The team's not trusted to deliver, right, what they've just built. So, yeah, this is quite prevalent, unfortunately. What I described is like, well, we have this little bubble of agility inside of our program or inside of our, group or under our director I've observed that pretty regularly. You can have a really well operating section. And then when that leader leaves, it all kind of degrades I think everyone listening to this podcast has experienced something like that at some point. But like why that happens goes back to our episode on Taylorism because Taylorism is so ingrained in this idea of like manufacturing that has been brought into software development. There's kind of a fallacy at the, honestly, I'm not even sure how relevant Taylorism is to software development at this point in my career. And we did a whole podcast, we did a lot of research on this. And we talked about it ever since episode, whatever, 62 or whatever it was when we did Taylorism I've read more about it, and, and honestly, up until this point, I think like what you're looking for for organizational design and change is true leadership Right, we can call it servant leadership. It's just leadership. It is leadership. I supposed to manage Taylorism is the opposite of leadership. Taylorism is I will tell you what to do. Here is a list Don't ask me questions . If you can't complete the things on this list, you're gone. That is management. And then Taylor explained , a disciplinarian and a timekeeper and say management positions . But they're really just like checklist positions that are following a prescriptive plan and that stuff, it really has very little place in modern software development. That's very true. It doesn't have a place really, but it's ingrained in our psyche very well, and reward systems or at the organizational level reflect that. So if you're one of those people who is saying, okay, get the pig iron into the train in less than 30 seconds. Well, okay. If you can do that, great. Then you can go back to your manager and say, if I can reduce that by five seconds, we can get X number of more big iron to the train. And you're rewarded on that . So you're basically just trying to tell your people that are working for you work faster . Run harder , right. I mean, where do you start with that in software development world? First of all, in that situation, I'm only ever going to hire men because I assume they're the only ones physically capable of picking up, that weight of pig iron, right? To deliver it in time. And then probably only men in a certain age range with, a lack of certain disabilities. So I'm honing down the market. There's a harsh worldview when it comes to honing yourself down to that, that really cuts out a lot of talent. Like if you apply the same look. At software development, which probably could be another podcast you really get like, a nearly cynical view of like, Oh, we only hire 10 X developers. What does 10 X developers mean to you? Does that mean people willing to work on the weekends? People willing to not take vacation. People willing to. be a slave to their phone , when a system alert blows up, whatever it's like, what, what does 10 X mean to you? it's there's some stories I could tell here, but I like it for the purpose of like getting through all this stuff I want to get through today. I'm not going to, but it's not that far from the Taylorism kind of view. In the era of Taylorism, in like 1914, 1920, or whatever there was a lot of workers, potentially, and they were very poor, uneducated, and they were dime a dozen, basically . They could physically do the work that you told them to do, they didn't participate in training, or understanding, or reducing ambiguity. the. Business owner really felt that it was on them to incur the cost of figuring out the best way to do the work in the modern way of working. It's completely opposite. The worker figures out how to reduce the ambiguity and it's not the business owner. companies that are adopting this way of working are the ones that are really leapfrogging the others. You can see that out there. The hard part about this is everything we just talked about today. Sometimes the best person for the job, sometimes they are not the person to get the job. And then again, this goes back to things that I've seen in my career. and even as a hiring manager like. I interview people like they're, they're very, very smart people, but they got real bad soft skills like they've completely underdeveloped. The people that can build networks, like kind of automatically, you know what I mean? They'd be like, they can become likable to the customers, the service and kind of like have constant interaction I'll give you an example of like when you go to networking events, for example, sometimes you talk to people at networking events and like, they hit you up on LinkedIn afterwards or they comment on some YouTube videos or the podcast, because we do this all the time in networking, right? Like I talked to someone about the podcast or I talked to someone about my experience and then they hit me up on LinkedIn afterwards. And then we just start talking and we kind of get to know each other like that, that picking up of our personal contact. That right there is a skill. There's the idea of like the meritocracy. If you do just do great work, if you're a 10X developer. You'll rise to the top or whatever. In my career. I don't think any of that's true i'm gonna make some claims here, right? The best person for the job rarely gets a job and I think that your Ability to network your network. So your ability to network and your actual time put in the network, your network and your proximity to the people in your network, meaning how often you're contacting them and staying in touch, stuff like that. I think that is more important than your individual capacity to do great work. And that's that, listen, even saying it. I feel dirty. It's rough to come into the understanding of like, like 50 percent of it is your ability to network 50 percent of it is your ability to do good work and you're, and you would say like, well, Brian, I do better work than anybody. And I'll say, yeah, that's true, but you're doing great development, but nobody knows about it. You're building a great product that nobody knows about you know how to do the work, but that's not where the deficiency is and that's difficult for people to hear. It's difficult to explain to people and it's difficult to try to help people get better at it. Somehow the organization is going to find a way to enable individuals to develop their soft skills, because guess what? You don't take a class in school on that. You just don't. I mean, I don't recall doing that exactly, but that's what you need to survive in today's world, right? So there's a huge gap right there. You know, we're churning out all these people, these graduates, but they don't have soft skills. Now, of course, some of them already have them, or some of them will develop them pretty quickly. And those are the people that will rise above the others. Yeah. I brought this category up. I wrote this down as a, as a note for us to talk about because the idea of like, Oh, you just got to hustle culture. Oh, you just got to grind more. You just got to do more work. A lot of tech leads specifically that I've worked with. They work 60 plus hours and they still don't make a dent. the organization still feels like we're moving too slow. What are you as a tech lead doing to impress upon these folks that are running with the organization of like, if you want this amount of speed, these are the organizational changes you need to make. Organizational design as a tool, in addition to all the traditional tools that we have. Yeah. I mean, some organizations. Quite a few actually, will not even welcome that kind of feedback from tech leads and they'll be told, stay in your lane, stay in your lane, do your job, right? The soft skills are the make or break switch in this category to where when you're bringing these things up, like I understand, where you want to go in the future. Here's how to get there, here's the variables we need to get there. Like, I feel when you paint that it's a whole different conversation. But it requires a specific skill to be able to bring that up in a way that leadership will perceive that. I agree, and part of the parcel of that skill set is also leading by example, right? I'm asking you to change, but I'm gonna change. So, that's one. And, and again, the other side of that coin is being vulnerable that this may fail and that's okay . You learn from that. in this example, I just outlined, I put the tech lead in that role. It very easily could be a product manager or a lead product manager, a senior product manager, to say. This is what the future could look like. Should we make these changes? It could even be a scrum master. So I've seen so many scrum masters that are just doing it by the book. it should be the scrum master. Their role is a challenge agent to the organization. It's a change agent. Organizationally. And they should be constantly seeking to improve organizational design to help the teams and enable the teams. Very few scrum masters are aligned to make organizational impact. So going back to just really quickly, right? If you're a product owner, a Scrum Master or whatever, and you just bring those core skills for the job . So when I say that, I mean, Scrum Master is a good facilitator. Absolutely. Great. They need to be, but that's about it. They recognize that there's an organizational deficiency in the structure. And either they, they don't have the wherewithall to even sense that, or they don't have the gumption to go up to management and say that we need to change this. Or worse yet, they don't even know Like I'm a scrum master. I work with a team. No, you don't. Even the scrum guide says you're not restricted to your team. You coach the team, you coach the product, coach the organization. What does that last piece mean? So I've seen that way too often. The scrum masters will just simply go back down into their shells work with the team. Stay quiet. Those are the ones that don't really bring any value in the long run. I dug into this category because I wanted to talk about strategy. And the more advanced I become as a product manager, I realized that organizations are really comically bad as strategy strategy is like your whole organization, all your teams together, And if they're not trying to, to achieve one thing, they're basically achieving nothing, but you need one cohesive strategy and a leader in the organization needs to set that strategy. Yep. Sometimes you can be set by a panel. Sure, this is not the podcast. I'm trying to tell you how to set a strategy. We had a whole podcast, we had two actually back to back where we talked about strategy. But a vision without a narrative of how to get there. Like Oh, we want to do this. So by what method, the Deming question was by what method do you want to do that? Like, Oh, we want to sell more cars. Cool. We'll just. Discount all of our prices where we don't make any money anymore as a company and then we'll sell a lot of cars. Well, that's not a great method. like we want to get some out of development faster. Cool. We'll just fire all QA people and we'll just send stuff straight to production. Making strategic plans and having leadership behind the creation of strategic plans, having a strategy as a company that all your teams understand and talk about and develop together that is woefully deficient in corporate America. I can count on one hand the number of companies I've worked with or worked for. Write their strategies down . Exactly.. The ones that are flying through are doing it right. The way you just described but for the majority of 'em, they're not flying through, they're muddling through. Most companies the clear driving vision of what the future looks like when we accomplish whatever our goal is, that is you normally missing we did a whole podcast, so I don't want to rehash a lot of stuff like that, regardless of how you feel about Tesla, the idea of like we want to build, we want to build the next generation electric vehicle. We want the whole world to run on sustainable electricity with their vehicles, right? It's not exactly that, but it's close to that. How are we going to do that? Well, in order to move the world towards In their vehicles, we're going to produce a high end roadster, huge margins and then when you use a margin money from that to enable us. To build a entry level vehicle, well, maybe not, but like a mid mid level view of normal, normal people can buy like a little expensive, but normal, normal people could buy. And like, that was a strategy. The strategy was we're going to build a super high end, ridiculous car of a roadster. And once it's profitable, we'll keep the team and that product line running. We'll move it over here and the profits from that we'll use to really scale out. Those are two different strategies, right? One strategy at a time. They only did the second strategy after the first one was successful. most companies don't even have that level of planning. They're just like, they're saying yes to any money that comes in the door, no matter how they can get it. the executives will tell you like, well, listen we got this plan, we got whatever, but in reality, like they don't really have a strategy. They're just saying yes. To the low hanging fruit. They have a hope and a prayer basically is what it boils down to. Sure. Yeah, I absolutely agree with that. Again, you can count on one hand, the number of companies that do this the right way. Yeah, I believe both of these one Oh three and one Oh four, but mainly one Oh four. We talked about creating a mission vision strategy. We had the pyramid of strategies and whatnot of mission vision strategy. And we talked about it, but so like when you write them down and you commit to like everything that you implement, every feature you implement is in line with one of the strategies. Hopefully you have one strategy, where I want to wrap this podcast is very few people understand. What strategy is it's an effective mission and vision strategy is the form of how are we going to do the two above, right? Right. And , if you're bold enough to write down, this is what we're currently trying to do. Maybe the metrics don't stack up or whatever, but at least you have something that you can show to all your teams. On a slideshow, your company meeting once a quarter or whatever, like this is still our strategy. This is how it supports our vision. And this is how our vision supports our mission. And you just brought everyone in line. It's shocking the amount of people like number one, can't do that. number two, that it just doesn't happen. it's shocking. It doesn't happen, but if it did, it would provide that sharp focus that everybody needs . And you keep repeating that periodically, maybe at the quarterly, whatever. That's the way the teams can stay focused because there are way too many distractions to begin with. But yeah, I agree. I mean, that's so that requires true leadership though. It requires leadership than the suggestion here. For people listening the ability for you as a business leader to craft that narrative, if you can do that, whether you're a developer on the team, Oh, we're doing this because whatever you're at a sprint review, lay the narrative out, right? you might be talking high level. Yeah Oh, Brian stop talking about like how we're going to dominate the market by being the quickest to iterate on our payment tech, whatever just show me that, that you made the checkbox default zero to instead of default one or whatever yeah, but also like, it's important for us to state the high level thing that we're all trying to do let's, let's, let's build that in let's, let's make that part of what we're, we, part of a shared understanding and, I would rather people tell me, Brian, we all know what the shared understanding is Skip over this part. I'd rather that be the feedback other than like, Brian, what, how does this roll into the big picture? How does this help sell widgets on the internet or whatever? Like, yeah, I unfortunately don't see that very often. What I see is the opposite, which is at the sprint review, developers showcasing the product by saying, well, I can click here now. It's okay to show that, but like you said, start with, here's our sprint goal. Here's how the goal meets the bigger picture. And then here's how the sprint increment meets the bigger picture by doing things along the way. Well, a lot of stuff has to fall into place to make that happen. I don't want to get too into the weeds on the retrospective, these are things that I've learned. And if you can do this. On your own and you can constantly be pointing out this is where we plug into X, Y, Z . You can set yourself over and above everyone else hopefully you elevate your team with these kinds of suggestions and you can just make it a normal part of your day to day, but even if you're in this pathological type of organization where they can't help with like ascribing blame tie things back to the mission and the vision, tie the goals back to strategies, at least the implied I think this is our strategy. That's why we did X, Y, Z. And then someone will tell you, well, that's not a strategy. This is our strategy. Okay, cool. Now you've clarified if you can't do that in one on ones before you get to the big group session, Cool. Okay. You look like you look silly in front of the crowd. You do that once and now you know what the real strategy is. again, in my career, like I was never scared of Being the person that presents my laptop to the big screen in front of everyone sitting in the room and I'm typing and everyone's yelling at me don't type that sentence, type this, here's the words to use or whatever. Like there, there's a certain amount of like humility involved in being willing to throw yourself out there and get critique. And regardless of the type of organization that you're in, whether it's the type of team that you're in or if they're psychological safety or not. Like throw yourself out there. Be involved, be curious constantly about how things work. And yeah, that, I mean, that's all stuff that's helped me. you just described how you can lead by example, basically Definitely that is the way to go lead by example. Don't be afraid, but at the same time keep that resume updated because you never know these days. We're talking about what I've seen across 20 years in tech. Oh boy, is there one thing that I've seen that I'm absolutely sure about? I would walk into the casino, put all my money on, okay. Control is like the order of the day that like the psychology of feel like it's like corporate America is like staffed by people that maybe they didn't have enough control as a child. And now that they're adults, they swing in the other direction too far. You know, maybe it's that I don't really know. We did a podcast on the ubiquitous nature of control., it's something I've seen almost everywhere I've been. Yeah, I think it's just not just the U. S. I think it's just everywhere in the Western control. We often speak about command and control. The control side of it is I think what permeates in our psyche the whole time. The command side is how to get the control and keep it. Some people, most people who work in that way are good at it. But some are not in that, Dubbed as the weak leaders, but we all know that that way of writing things is not going to get the best results It's not gonna get creativity. I think most people watching and listening to this come across the you know, the environment basically where They're working in a controlled environment. People are controlling of them. This is basically the only thing we know. This is how we know to work. It's changing, yes, but it's not changing fast enough. I mean, it is changing, but it's like changes being resisted, with the maximum tools available to the people in management we're at a point now, we had a super lively discussion the other night, even now we're globalizing the workforce to go to entire other countries that are like the culture is more apt To that type of control, Oh, just give me a worker that'll just do what I say and won't basically have a mind of their own , they are in a culture that's more subservient and people just do as they're told which suits us great because it's cheap to find that labor force and they'll just do as they're told and not resist. And not challenge our decisions, Unfortunately, that's what is prevailing in our work environment. Well, in tech especially. the other thing, we talked a little bit about trends in this podcast. That's why I always caution people about trends., the post COVID era trend of some large companies start laying off. Employees now, everybody else follows the trend of laying off , some Silicon Valley CEO shoots his mouth off on , a video or a podcast or interview or something like that. And now everyone else wants to follow him like he's some kind of idol these kinds of trends, , they're not really helpful like the Deming podcast that we just did. The Deming podcast, I mean, he uses statistics to show that the system is the means of control. And since management owns the system, management has all the tools of control. But if management is going to control the system tightly like that, and not change the system, management is going to accept responsibility for 94 percent of the variance, meaning mistakes, meaning failures. You know, which they don't do, which they don't want to do they go back into bad behaviors and everything. And we looked at all the bad behaviors you talk about in crucial conversations. They go back into punishing the backslide into blaming the blame game. Yeah, and that's the world, I mean, of get this done. We know already what this is, because you told that, and get it done by this date. And there's no negotiation there. And send me status reports throughout so I can tell you're not doing well. Well, you're going to get terrible quality work. I hope everyone knows everyone that listens to this podcast probably knows and already believes that you don't need me to give you a doctoral dissertation they're looking to bring information to authority rather than the other way around. I believe I've got that the right way around authority to the information, authority, to the information. Yeah. Rather than information to, that's the way around to the authority. That's what David uh, Marquette uh, talking about okay. In his book ship around. Building trust. I mean, you, you might be able to do that at a very small scale. Here and there. You might be able to do it with an individual against a backdrop like this. But I don't know, man. Keep your resume updated. Is it too early to break that one out? I don't know. No, we're quite a ways into the podcast. Yeah, no, listen, this is probably why I think you're seeing another trend. Which is most people only last nine months to a year in a job and they they flip around like a butterfly from one job to another. Years ago, it was never like that. I mean, the people stay there and have a career. Now, it's just job, not a career. And that's a shame. Where especially with younger folks that stay in a job for one year. Yeah. And then move on a part of it is they're Maximizing their salary that, that is a tactic in tech, you move around quickly in a small span of time, maximize your salary, and then kind of sit in one place once you get to your more senior levels, right? But I don't want to talk about that today, I have seen that a bunch, although I've never necessarily been a fan, like I like to, I like to build a thing and live in a place, you know what I mean? I like to change the system, and you know, I like to sit under the tree that I planted 20 years ago. And enjoy it, rather than like, spend my whole life Spotting other people under other people's trees? Laughs you know, an interesting thing that we could say on this topic, that is, would be a challenge to the audience. Here is Punished by Rewards by Alfie Cohn from 1993. The actual full title is Punished by Rewards, The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes. So in Punished by Rewards, which is a very interesting book which we, we should do a podcast on Punished by Rewards. Because it's got a lot of concepts that people are just not, not, not like people in the agile space or people in software development or. Whatever people, period, are not aware of. It, and one of the points that that book makes is that the carrot and the stick are two sides of the same coin, and that coin is control. So, you need to, whatever you're trying to learn taking people's intrinsic motivations And forcing a world where everything's extrinsic where you're either doing something because you're going to get a reward for it or doing something so you don't get screamed at like, it's making the whole world over like that. Yeah. Has been a disaster, basically, is the premise of the book. And like, what, how, what the world could be, like how our interactions could be if we weren't. Trying to constantly jockey for control and there are, there are ways to do it. There are ways to, to get people to be productive without the carrot or the stick. You know, you can work at a place and not have a yearly review where we sit down and tell you why we can't give you that whatever percent that you were expecting or like, we can just have an adult conversation and say, I'm not giving you that much money like, right. And here's why without the trappings of a yearly review where you get a star and you know, the kid can go to school and learn math without. I ever happened to give being given a letter letter grade and I feel like if you're going to say that in like modern american culture. You're going to be perceived as you know a troublemaker off your rocker. I was gonna say that true. Yeah, very very true so the the carrot and stick right? Why are they so ubiquitous? How do we get to that situation where people are basically just saying do this or else? You know who I'm gonna blame first Taylor, but also the actual Punished by Rewards does go into this. It does go into Punished by either it's Punished by Rewards or it is There is another book that actually is excellent that talks about the school system I'll find that, cause that's important too. John Taylor Gatto, Weapons of Mass Instruction. He will give you the history of the school system in America, and why these things are built into the culture. They're built in the culture because they're built into elementary school, basically. They're built in the way they do things there. So people grow up with that it's actually, quite literally, going back to something you normally see on the podcast, it quite literally is the only thing people have ever known. So how do we break out of that? Like, how do we break out of the cycles of control and even begin to build trust? Well, let me introduce you to something, Om, that I call regression to the mean, I've been waiting for a hundred podcasts. That's not true, but I have been waiting for like 20 podcasts to figure out how to sneak regression to the mean into a podcast. And we just did the Deming podcast, so it's , it's not a wacky idea now to bring up basic statistics and say, if you chart everything, There will be the mean. There'll be the mean of all of the. Data that you are considering and you'll have good instances and bad instances and maybe more bad instances of good and the mean will be a little bit lower than you expected. This is the quote, raising the bar. Like what is the level of the bar right now? I would say the bar is set pretty dumb. Like I said, it's at a pretty dumb level. You know, it's like, so how do you start even teaching people that there are other systems? Like, how do you teach people there are other things in Gantt charts and work breakdown packages well, you gotta educate them first of all, they gotta be willing to learn, so, there's that. That's true. So your education system probably should do something. That plays on people's natural born desire to learn. Just the joy of learning something. Which, if you think about kindergarten, kids are born with that. It's just that they're then ordained into this way of working, right? This way of behaving and so forth. You can take this argument all the way to color between the lines. So yeah, you're right. People want to, people have to be willing to learn. But assuming they are, right? How do you start to change this? Well it's a constant effort. I mean this is like where you get into like government but that's what government does is it outlines policy You know puts money and puts effort into policy so it's like the People collectively have to make an effort to say like this is something that we need to do and it needs to be backed by policy So that that is way out of the scope of this podcast. It's not a political podcast that analyzes policy. Honestly, there's probably not a lot of podcasts that analyze policy. I'd be interested to look around to see any that actually think critically and talk about policy over a 20 year period. I'm not quite sure there is a lot of that anymore. That's probably why we are where we're at right now, is like, nobody really is looking at policy over a long period of time. And businesses are definitely this way. This intellectual stagnation, because they're not, they're not like the, the ideas of Deming are hard, like an agile transformation is hard I, I was surprised that when Marty Cagan wrote the Transform book, because I'm like, this stuff is hard. You know, obviously he wrote it because he was, he, because he probably said to himself , there's stuff that I see that just holds companies back that they're never gonna get passed and they're never gonna get to any of my other books. Because they keep messing up this basic core level. And his advice up until that point was like, we'll just avoid those companies. But that's not great advice. It is really not great advice. I mean, I think other than just how we teach people or make sure that , they open their eyes to these other ways companies have to be willing to, to take that on themselves and say, we're going to do this differently now. And try it in smaller chunks, right? So try it in little areas here and there and see how it works and then evangelize it to establish that mean for themselves. Cause if you're a company that doesn't work in this way, and you're just basically coming from that whole command and control you know, ethos, how are you going to know what your mean is? Yeah. Is it just simply rock bottom? Or maybe there are people within the company that are. Armed with the knowledge that's needed to lift this up, right? I wonder like I'm, I'm putting together my PhD thesis my doctoral dissertation right now. And it's going to be that the regression to the mean at most companies, like the mean is a command and control. This, this whole default to exploitation of workers rather than supporting and lifting up workers. No on the job training. The mean is do it on your own time, that kind of stuff. I mean? Yeah, I would expect that stuff is in the mean. And, you probably could put together a survey. To go out and gather this research yourself just, just a baseline kind of like a survey that says I'm going to, I'm going to analyze elements of control type culture versus a more open type culture. And it had to be a spectrum because it's not really a binary thing, but go out and survey workers at 5, 000 companies. I don't know how you would perform something like that. Yeah, probably how you write the survey would be very important. But you probably could baseline this , and then once you build a baseline, For this regression to the mean of what the mean is. Then you'd have things to look out for to be like, Hey, most companies are regressing to the mean. Well, what does that mean? Well, they're regressing to the mean. The mean is they've got these performative. Ceremonies that they do. Oh boy, I don't say ceremonies often, people dig on the Scrum Ceremonies and then they don't say anything about yearly reviews and status updates and all these other meetings they're going to. But boy, We like to complain about Scrum. It's, yeah, it's a petty thing. I mean, call them events if you want, but yeah. So, okay, so that's where there's a start, right? Yeah, so, what, I guess, what would be some symptoms of the mean that I'm talking about that kind of help us? Like bureaucracy as a tool of control, any organization with a governance board that's where, where new ideas. You have to go through a lot of hoops to even filter in to the these are the companies that like, they don't have any new ideas. They don't, they don't innovate. I mean, they're just trying to stay alive basically. And they lose, they lose either other companies or worse yet the companies from other countries. But I think this, see, I think this phenomenon is real and I'd like to, I'd like to think about it. I like, I don't know how I already have like three, two, two, three daytime jobs right now. I don't need another job, but. It's interesting to think about like, what could we write down of the characteristics of the mean what companies regress to? Cause I think training your people versus not training your people. Most companies I've ever been at, they don't, they don't do like that. They'll offer you like, Oh, we offer employees training or whatever, but it's like. Only a certain amount. And then any training that's worthwhile is like five times the price of what they're willing to pay. There's hoops involved. You know what I mean? most companies, I think every company I've, I don't think I've ever been at a company that doesn't do maybe one or two companies. That doesn't do yearly reviews, you know what I mean? The performative yearly review tied to salary and stuff like that. Well, possibly all of those should be on that survey that you do. You've gotta find a way of quantifying that on a scale of some kind if you're doing a poll or a survey. But yeah, I agree. I think that would be tremendous, how often does your direct manager sit down with coaching sessions with you? Were, were you not talking about status reports? You're not talking about, you know what I mean, updates or whatever, and your boss is not yelling at you about doing things, like you're not in trouble. Actually helping meaning coaching meaning sponsoring you to move forward in the future coaching real real coaching If it's not your boss, do you have a coach in the company that you can turn to? Yeah, right So yeah, these are great questions. even that point is in the Marty Cagan book where he even outlines that the modern manager like this is really your only job responsibilities hiring people and then coaching and Advancing the careers and the skills of the people that are on your team. That's really it You know the old like standing over people with a stopwatch or whatever like Nobody does that anymore. Yeah, very true. Sorry, I thought I was, it sounded like I was attacking. I was like, nobody does that anymore. Nobody does that, why? Kathy I don't know. Nobody does that anymore. Jim. Sorry, I don't know why that sounded so accusatory. There's lots of Jims and Kathys out there that can relate. This goes back to the podcast where we were talking about the three different types of organizations, the bureaucratic generative, and What was the other one? Psychopathic. I can't remember what that was. Something like that. I can't remember either now, but it starts with a P. once the system regresses to the mean that's where you've got to pay consultants, outside consultants, to bring you opinions. Because you can't believe anything anybody inside the system says. Yeah, yeah, that's sad but true, right? Occasionally you'll see that. If you're in the consulting business, you know this to be true, you know. But the funny thing about this is I hear so many people that work for companies that have worked there a long time and even just the other night we heard someone say, Oh, I've found myself becoming complacent. Cause you know, I was real comfortable in the job, and I was in the flow, and everything was great and yeah, you just kinda, I don't know if I have anything solid to say about, I, I, I don't, I'm not trying to make a statement about, the worst aspects of corporate America, the predatory aspects of corporate America, I'm not trying to make a statement about that, I'm just saying the, I've seen good companies regress to this mean over time, so I really feel that mean is a real thing, and it takes effort of good people who are educated. And educated meaning they constantly seek to bring in new ideas, To educate themselves. And they're motivated to do that, to keep the company above that line of the mean. But then when those people leave, or like when the, when the, when the person's sponsoring the agile transformation that that VP or whatever goes away. Here it comes, the PMOs coming and knocking on your door, you know? And it goes back to the old ways of working because your day-to-day is basically controlled by the PMO. Under the guise of consistency and standardization. Standardization, yeah, exactly. That's right. Centralization. Yep. Yep. So unfortunately there's really no quick no quick remedy all of these are longer term plays. Yeah. I feel like, but you gotta start somewhere. And every company has somebody who's willing to say, listen, enough, right? We're going to do this. Typically what we say to people when they talk about things like Azure Transformation is that it starts with the leadership. Well this ain't gonna start with the leadership. Because the leadership didn't get to those positions by working in the new ways, right? So grassroots probably is the key here. Somebody's gotta start this. Let's go, let's start this. Well that's why even in the Marty Cagan book he says it starts at the very top. It starts with the CEO and the CEO only. And he probably, I mean Marty Cagan can shotgun straight to the CEO of the company and be like, Hey, if you're not on board, We're not doing this. And then again, in the transform book, he'll say it starts with, it starts with the CEO, really believing in buying in and supporting. We have to change our way of working so that there's actual constant pressure on it. And then you can train everybody and then we can all collect our certs and whatever. Easy when it's described like that, it does, doesn't it? We would have lots of companies already being transformed in this way, because the CEO would be on board or they'll get another CEO. That's not happening though, those people are comfortable where they are and to change like this, this is a huge risk for the company, right? They're accountable to the shareholders. They don't want to risk that. Occasionally you will get a ceo who's avant garde He'll say let's bring in marty Cagan as a consultant Marty says starts with you man, and then the ceo woman whatever and the ceo says yeah, let's go, right? So that is the top down but you're gonna find that's a very very rare. Yeah, and b when marty leaves That CEO is probably going to regress because he's got to deliver this to the shareholders right now I mean either that or like what's what's the what's the here? Let's just go to Google. What is the tenure of a typical corporate CEO? According to recent data, the typical tenure of a corporate CEO is about 5 to 7 years, with the median tenure of S& P 500 CEOs sitting at approximately 4. 8 years. Cool. So, you get about 5 years. And let's, let's assume that some of that 5 years is spent realizing there's a problem. Some of that 5 years is spent learning. What agile ways of working are and why they're wrong. And if they're even open to understanding that they're wrong. And then some of that five years is spent figuring out the right mix that works for your organization. And before you know it. It's time to go time to move on and then you're gonna take your learnings to your next company Whatever company that is and then a new guy's gonna come in. We're gonna organizationally get completely reset I think this is a very real phenomenon that probably needs to be studied and then we can at least come up with the building blocks of what education needs to be put in place and where and how. If I had a few more years, I would possibly study organizational culture, organizational design. I mean, those topics are fascinating. But sadly today is the last day on earth. Today, yes. It's today's the last day when I feel like studying, it's a lifelong pursuit. Om. It's a lifelong pursuit.. Let's be positive and move on to something that I'd like to talk about. And probably one of the last things to talk about, which is emotional damage. Let's see if you can insert that on me. EMOTIONAL DAMAGE! Let's be real. Oh, man. It's going This guy's hilarious. cause like this is one that, that this one and the podcast that we did on Cognitive Load, I think this honestly, I think this belongs in it's own podcast. I want to just skip off the top of it here. Cognitive Load. Just like facilitation skill, everyone wants employees to return to the office. But when you get there, it's like cubes and there's not enough cubes for people. So some people are sitting at like tables off on the side, like their little laptop. Whereas at home, like I've been working at home for years. I got a great desk, goes up and down, stand up, whatever. I got a super comfortable office chair. I got giant monitors, a dock that works with all my electronics and everything. Batteries, everything within reach. Why am I going to go in the office, and then, and I go in the office and get on remote calls all day long. Like, if I'm going to go in the office, it'd be nice if there was someone there dedicated to facilitating and making sure that all the employees were engaged and, helping us. Helping us have a good time and helping us take care of things when we need it. Or work through disagreements. Someone neutral that we all know and like. I mean, there are people like this that I've worked with in the past, there are very few of them. And also, these people get caught when downturns happen because you're like, Well, I'm not quite sure I think we need more beast mode or founder mode or whatever The fad of the days. Whatever the fad of the, yeah, fad du jour, I don't think we have a lot of listeners, listeners in France, but there you go, . Fad des jure. Fad des jure. I, I don't know, hopefully that doesn't translate to something bad in French. But that, the other side of that is The concept of technical debt in the way that because it's the back of the house system, we don't care about the user experience. So it's like 187 easy clicks to perform a simple database task. Or, you know what I mean? Like something like that, where we're. Or systems that we have to be like up in the middle of the night. I remember, we moved into a building and they converted a room in the building into a data center. It wasn't supposed to be a data center of the room. And it was, it was terrible. Was it whoever decided that like. They wanted to use that room as a data center. It was terrible because the room had no, it didn't have the proper cooling to be a data center. You need like a lot of AC. Sure. You need a lot of floor possibly. For, so we had AC, but it basically wouldn't keep up. So the AC would kept, it kept like freezing up and stuff like that. And the system would call. Like automated notifications. This is back in the day, this kind of stuff is like, isn't it? The cloud now companies pay five times more than they need you. And they, but they don't have to worry about having one person on staff that knows how to do all this stuff. Anyway I bring that story up, not to share my emotional damage, but to say having to deal with all those systems, like. Being like, we're not gonna have this data center. We gotta, we gotta babysit all the time. And we gotta deal with hard drives failing and all that kind of stuff. We're just gonna pay three times more and then we'll have the cloud and it'll always be available. There's a specific financial reason of moving stuff from this line item or moving stuff from this side of the budget to this side of the budget, reason why most companies do that. But putting that like disingenuous reason aside. The other thing they get out of it is they get to relieve that burden of maintaining all that stuff, all the worries and everything about maintaining all that gear. All those worries are gone from their employees. So , it's a cognitive load lifted off their employees. Now translate that into technical debt of like, I'm constantly worried that the architecture is going to fall over. As I add features on top of my existing platform without doing a big refactor or something like that, it gets harder and harder and harder to push. Changes and to keep the changes like I got these and then add teams and I got merge conflicts and all kinds of stuff and you could say, well, modern software development, you've got DevOps tools and stuff and you can mitigate a lot of this, which I agree with you, until the system grows to a certain size. And then you have the problems of Spotify and Netflix and guys like this that have like 500 APIs to do simple things. And some of those have documentation. Some of them don't, some of them have teams that own things. Some of them are not owned by the original team. Some of them, the original team's not even there anymore. It makes your job less enjoyable, is what I'll say. Yeah, not only that, I'd say, well, yeah, sand on that. As time goes by, that technical debt doesn't simply grow. It becomes more solid. It gets harder to chip away at it. Yeah it solidifies. So you've got to work hard now. To chip away at it. The best time to do it is to avoid it in the first place. Let me, let me hit you with a, let me hit you with a line that I wrote down when I was feeling especially prophetic one day. And the line I wrote down was, Legacy Systems. Reflect unaddressed communication and leadership failure. Yeah, I mean, you're right. Unaddressed communication leadership failure, and simply just, just the lack of willingness to deal with it. You know, we've got other things to do so we'll clean the house next weekend. Because we've got other things to do. And then sure enough, weekend comes around, you've got more things to do. And so you'll defer that further. Yeah, so, there's two sides of like, well, my house is always a mess. There's two sides of it. Number one, I'm not saying to the other people in the house Hey, we're all accountable, I'm not going to be the only one cleaning the house. We all need to clean the house. That's a communication failure if I don't bring that up. That goes back to our crucial conversations. There are ways to bring it up where you're not starting fights. Most people don't have those skills, so they start a fight, and then they just don't want to start a fight, so they don't bring it up, and now it festers, and it becomes , a big thing. Just the conversation by itself becomes such a big thing that it's so painful that nobody even wants to talk about it. And now you tiptoe around things that are just like, you're, I, that you literally are walking over every day, this is the software equivalent thereof, right? Yeah, exactly. The, the other side of that is leadership failure, with proper leadership, You should have never let your house get like that in the first place. Yeah, I agree. I agree. I mean, that's a, that's an analogy that we can extend a bit now. So one of the things you could do instead of saying, well, who's going to clean the house, whose turn is it? Let's create a roster, right? How about everybody clean their own room? And then we can get together and decide maybe jointly clean the common areas, right? If you did that, you'd always be on top of it. But the other thing is for everyone involved. There isn't as much work because you're doing it frequently, right? So you then go extend out in time at that point, any point in time, going in the future, whenever it might be. Your house is only going to be certain level of mess and it's not very messy, right? Whereas the alternative by, like you said, avoiding the hard conversations and making decisions, taking accountability. It's just going to get worse and worse and worse. Technical complexity. Meaning the system getting bigger and bigger and getting unmaintainable and unmaintainable because of this unaddressed communication leadership failure. Basically, a failure of the system. And since only leadership can change the system. Right, so that's where I'm going with this. Your system gets more and more complex. There's never time to work on technical debt. You can only patch bugs when they're absolutely devastatingly bringing everything down. The technical complexity, it should have been resolved when it, It got borderline bad or when it wasn't finely tuned and optimized. And that just didn't happen. And now here we are years later using all these tools that are super difficult to use. And because it's internal employees, we don't care we're not going to put money into that. Yeah. Yeah. I think part of the reason why this is also such in such a bad state is you really don't have true architects in, in the true sense of the word, I don't want to talk about titles, but somebody who really understands. The overall architecture who says, listen, it's getting dirty now, let's take time out, refactor. We don't have to stop everything, but you can do bits at a time. And that way you keep it manageable. You don't have that. Sure, you have plenty of people with the word architect in their title. it's to bring up enterprise architect and go here is some lines and blah, blah, blah. No, I'm not talking about that. I'm talking about thinking through all the ilities, right? What would happen if we project forward our growth? What would happen to our architecture? And can we do something about that now? Right? That's lacking. I've met one good. Enterprise architect who did this by the way he would move very slowly as perceived by It as well as the business for that matter But that was deliberate he would move slowly and figure it out and then he'd say this is what we need to do and the one time they trusted him to do it They could see the benefit going forward because we did scale up the usage and it it was swimmingly well I mean, it's like this guy knew what to do. Well, very few people like that exist I was gonna say that's that's a hundred percent more folks that I've ever seen. I'll hit you with another snippet of Zen Let's see how you how you how you think about this one the most expensive lines of code are written Out of fear, not logic. Well, never a truer word has been spoken. I fully agree. For any of y'all out there not doing TDD and you're like, I don't need TDD I don't know man, TDD seems like a logical way of writing most stuff. Whereas like error handling in most development that I have seen is done because bugs happen When something goes wrong, they go, let's figure out what's gone wrong. Let's check the logs. Oh, we don't log that. Okay so I agree with you that this is something that people aren't taught. I don't think right. TDD, BDD, like really thinking about what you're doing as opposed to get it done now. So you take shortcuts, right? And supposedly some people are using what they call advanced techniques by using things like. feature toggles and whatnot. But if you look at their code, you're going to find a lot of. Debris in the code meaning feature toggles that should have been deprecated They're not even in the play anymore, but they're there right so they get in the way and yeah, there are tools out there that help you but They're not widely used either. So yeah, there's a lot here Again, the most expensive lines of code written in fear and not logic. Imagine, think about that. Got to get that release out. Om, I need it out. Or what date, what day is it today? I need it out by the end of today right. And then tomorrow is never, there's never time to look back and , remedy the shortcuts we took. There's never time because there's another release due. I was going to make a joke about there's plenty of time zones. So if you just have like developers in every time zone, you can just keep working 24 seven. Well, that was the premise for offshore. And you can squeeze more out of your day but it's not true. But attempts have been made. I have worked with people that think that they're like, I want to have my developers working 24 seven. So I want to park people in whatever Eastern Europe or somewhere like that. And then people in Asia. And then have folks in South and North America or something like that. So they basically have developers every like six or so time zones. If you're running, like knocking out FinTech widgets, like why, what does 24 hours have to do with doing the best, like producing the best code? It doesn't. It really doesn't. I mean, unless you're constantly squeezing your team to like, produce faster, produce faster. There you may have something, right? Because the 24 7, that started this whole offshoring phenomenon yeah. Code is always in somebody's hands, every minute of the day. Yeah. Okay. So then what happened after that? Fast forward to like, now. What's going on now, right? People are being asked to stay in different time zones that they live in so that they can have coverage, right. So you have offshore people that are working U. S. hours. We just so that we would have overlap with them at least most of the day but then yeah, these applications that they're building are. Really, life and death application. Also that's not the way development works. I'm going to open a program and start typing something, and then at the end of my work day in eight hours, I'm going to hand it off to the, whatever, hand it off to the, well, which way, sorry, I was like, which way is the earth turn? You know, at the end of my day, I'm going to hand it off to the India folks that are just coming online, to somebody that's halfway across the world and they're going to be able to pick up exactly as well as I was. I don't know, like maybe, maybe there's maybe like, Okay. AI enhancements and stuff like that will make this more possible. Yeah. So I'm trying to sell you that you need to hire developers in all of our development centers across the world, just so code can be in someone's hands 24 seven. Like why? Right. That's a good question. Why? Why? Maybe that, that could be a contributory factor to all this tech that we built up because people don't have the same understanding of the code. They also don't work the same way. Yeah. So maybe that's something that contributed to. The state of that code now, I think Probably some big companies started with a fad of like offshoring their call center to whatever country and like look at all the money we saved on paper And nobody ever dug into any details or like follow those companies over five years And like, but the fad of the, the, the being afraid of being left out kind of permeated through the market just like again with the layoffs and with AI and blockchain and every other fad, like layoffs are a fad, except layoffs, layoffs are a fad, but they actually have a dangerous side because layoffs have the unintended, or I guess it probably is intended consequence of also like lowering the salaries for the whole market. So it's a way to keep salaries in control as well as make your company stock look good when you fire everyone near the end of the quarter before you report and then hire everyone. Yeah. Hire back at the, yeah. Yeah. I guess this is the part of the podcast where I make I make sweeping. Accusatory statements because the other sweeping accusatory statement I was gonna say is remember in the, in the, remember, like you, like you were there in the era of Taylorism, for example boy, this is gonna be a zinger. I you know if I have to set it up, it's gonna be a good, it's gonna be a zinger and it's gonna be good. In the era of Taylorism, if you physically could not carry Pig Iron to the train you didn't get paid. If you don't work, you don't get paid. Okay? And I'm talking hard manual labor. So if there's an accident or something, someone drops a picket iron and breaks your foot, and you quite literally cannot walk okay, get out. You're out on your own. Yep. You got no money to pay rent, , the company doesn't care clearly, you can't check the box on the checklist. You're out. And we got tons of uneducated workers that are in line every day. To replace you with that was that was then right that was the reality of then like the reality now is like if you're not constantly connected like you dip that you don't come to the office work there for eight hours go home and are completely unplugged from the office like that's not a thing anymore you know if you were not If you don't have work, email on your phone, your calendar, on your phone, whatever, slack or Messenger or whatever, TE teams or whatever terrible tools that you use. Like if you don't have all that stuff on your phone where you're connected twenty four seven like you're going to be looked down on at most companies like this, this, this constant connectivity, constantly being able to get in touch with you to basically demand something of you, you probably, right? Sure. This is the new norm and it's it's kind of exploitative. Definitely, definitely. I think you have to draw the lines as an individual if you can. I mean, you wouldn't find me after hours. But, but you're right about that. And here's an example of how pervasive this had become. Still is. People that are here on visas working and especially in California you know, in these big tech companies. Yeah. They live in these huge campuses, right? In these big buildings and on campuses. And They're completely connected all the time, so when they get to work, there's maybe an hour's commute to get to work. You don't get to sleep on the bus. The bus has Wi Fi. Get to work, right? You're working as soon as you climb that bus. Same thing, tail end of the day. Well, middle of the day, the same thing too. You're not going to go out to lunch because we have great cafeterias, it's fast get back to work. Oh, you need to go to the dry cleaners? Don't worry, we have a dry cleaners on campus, right? So drop off your clothes, get back to work. Same thing, haircuts, whatever. All of these things show you that it's basically control the individual to work, work, work because they're on a fixed salary to begin with and the more you squeeze them, the more you hope to get out of. Terrible, really terrible. Yeah, well, I mean, that works until you exhaust your labor pool. Again, the Tayloristic kind of instinct once you exhaust your labor pool, you have to go searching somewhere else for let me put it a different way, let me put it a different way. Once you get known for exploiting people in a specific area, you gotta pick up your bag, like the traveling snake oil salesman like the old cartoons, and you gotta go to a new town. Until they run you out of town like it's an old Gunsmoke, is that what it was? Remember that old show? Like an old Gunsmoke episode, they have to run you out of town And then they run the, they run the snake oil salesman out of town And then the episode ends and they eat a sausage Or whatever, I don't I don't remember that show I was gonna say the A Team where they go and run the land developer out of town But This predatory kind of thing is like, there's a lot of that in tech. There's a, I bring up a lot of these examples. It sounds very negative. It can be avoided. You can't avoid these companies. If you're looking to make top dollar and you want to make a bajillion dollars a year or whatever, and you're willing to sell your soul and just take abuse and say yes sir all day I guess if you're willing to do it, I guess. And I'm seeing a lot of people that are willing to sign that deal with the devil. And there's tons of, they're, it sounds like it's unavoidable. It is avoidable. It is avoidable. I think people do it. Like you said quite a few people do it. And some people I've seen in their younger years keel over through pressure it affects your health. Yeah. Is it worth it? You know, I've seen people basically die on the job in their thirties, right? Leaving behind you know, a family. Is it worth it? Yeah. You decide for yourself, I suppose. Well, I like to end these podcasts on a high note. Do we talk about a lot of stuff today? all things that I want to talk about, like I want to, normally we don't do a wrap up in the podcast, but I feel we talked about like rapid fire about so many different things on the podcast I want to change from the ordinary. I want to deviate from our Normal way of doing things and I want to kind of do a wrap up here. So on the internet today we learned it's like Regression to the mean is a real thing that we probably need to watch out for we named five, six things. I probably could come up with easily a dozen things on that list. A lot of, like a lot of stuff is tied up with the education. I guess we're going backwards. A lot of this stuff is tied into the educational system, because this is the carrot and the stick, control, systems of control. Are really the only thing that most people have known. Most people have not been put in a situation where learning is offered for the sake of learning and the enjoyment of learning. And people might I'm interested in people, if people are gonna react poorly to me even saying cause that's, that's how the old Guard that's how old ideas go out. they resist before they go out of style. And we're seeing that a lot. Like we see that a lot with exploitation right now. Although we talked a lot about exploitation in this podcast in tech, cause exploitation is, and when you, we trust me, we had a much deeper conversation about H1B visas and like this current situations and things that I've seen, none of that is going to be in this podcast because a lot of it Has to do with policy and lots of stuff that like is not in my realm of expertise, nor do I really, if we actually wanted to have somebody who's here in H 1B visa on the podcast to talk through just their experience, you know what I mean? And like what the real actual concerns of somebody that was like, hey, I know that it's exploitative and whatever, , Here's how I manage that. That would be an interesting podcast to dig into. We talked about being careful about trends. We talked about the, certification training mill, we talked about blockchain and whatever other fads, whatever the fads that we talked about, the Deming podcast had a ton of fads that we called out. And then the lack of facilitation skill, corporate America. We talked about the need for control kind of permeating everything. Along with the carrot and the stick and then we started this podcast by talking about recession proofing yourself in tech. Which can be done. You know, not easy, but can be done. It's a lot of work. I'd say it should be done. I mean, if you're serious about your career, you should really be. spending time on this. some people come to a point where they just don't want to be on that treadmill anymore. They leave tech because they don't want to be on that treadmill anymore. It is a treadmill, and then, yeah because you're basically invalidating your entire skill set. Every couple of years if you're not learning the new stuff. That's right. And, and those, that couple of years is getting shorter and shorter. It's getting shorter. Yeah, I agree. I agree. It's getting shorter and it's getting like deeper, you know and then I guess we'll wrap on leadership is rare but Taylorism is not. Taylorism is ubiquitous leadership. True leadership is rare, but there's plenty of management out there. Yeah, that's 20 years in tech. That's we kind of just went all around the world there with a little super quick wrap up. I feel like I should have something prophetic to say at the end of the podcast, but I don't. Well, in that case, I'm gonna just lean back on what we always say. You know keep your resume updated but if you like this podcast send it to a friend like, and subscribe. Every like, helps a channel. Every subscribe definitely helps a channel and keep their resume updated. Who knew a 20 year review couldn't fit in one hour 20, I think we both knew that. I just, I just didn't want to believe it