Welcome back to Arguing Agile. We had a podcast a while ago
called weaponizing Efficiency. Yeah. And now we're doing sort of a
part two with a podcast we have titled Weaponizing Standardization this podcast idea came up because I
was in an interview where somebody asked me I see that you've been
through mergers and acquisitions. What is your opinion on standardization? Because a lot of times when you get
integrated into a larger company, there's a lot of initiatives. to standardize things and to
sanitize things and I can't remember the exact language the individual
used in the interview but it got me thinking I was like you know
I'd I do have some experiences in in this in this arena to talk about yeah absolutely and this happens
right whether you know whether it's an M& A or You know. Yeah. A divestiture or whatever. I find that word hard to pronounce. But anyway, split up . Yeah. So that this happens all the time. The company buying the other
company will typically come in and say,
this is how we work. Yeah. Everybody just assimilate. Right. And so this podcast is gonna delve deeper
into why that's good or why that's bad. Well, Let's not make everyone guess
about what side I'm on in this conversation, Because I'm going to dive
into point number one, when you deal with standardization, the challenge
of standardizing all of your software development teams or your processes or
your processes, if you live somewhere is that you said a good chance of stifling
innovation when you
start laying down. Heavy, heavy processes that
have to govern everything. And they had that word governance. Oh no. It's got to go through governance
before we can start any new initiatives or exploring new
technologies or do any cool stunts. Yeah. So the first thing I'd say
here is that the acquire or. The company that acquires the other
company or merges, usually there's, they're not merges of equals. They really don't bother to
get the context of the working situation of the other company. T
hey simply come in and say,
this is how we've been working. This is how everyone will be working. Right? So from that perspective and from the
point of view of the company that has just been acquired, you are stifling
innovation because you're saying, get in line and do all of these things. That we want you to do, right? These are all maybe bureaucratic
to some people, but this is how we need you to do things, right? These are the systems we
need you to use, for example. So instead of coming up
with a solution, right? You have to abide by
what you're told, right? And that I can see how that would
stifle innovation because you're, you're really not doing anything new. You're simply going along with
what's been imposed upon you. But you know, I would take the other
side cause we are arguing as well. That's what I heard. Yeah. So, so you could say, look, the company
that is being acquired, if they fall in line and work in the way that this larger
company is dictating perhaps, right? Then
what's wrong with that? Right. What's wrong with, what's wrong
with a proven way of working? Presumably the larger company survived. And they are the acquirer. So they're going to say, do it this way. And we're right. Well, let's, let's walk through this. Yeah. Let's walk through this theoretical
conversation for a second. And, and also like, it doesn't have
to be an acquirer acquiree deal. It also, like I've seen this. After IPOs, sure. For example , the company will
bring in professional manag
ement and the professional managers will
say, Oh, we need some standards. So we need some standardization. Well I also, I've seen it when like
VP level, like C level executive type of people change the operations. COO would be a good example like
COO changes and now like, well, I need to know everything is
happening because I'm I'm operations. So I need to have my fingers in all
the pies because operations, he's to know everything or a new CFO comes
in and says I don't understand where. All of t
he money is coming from, so I
need to standardize all the financing. Or where it's going, yeah, absolutely,
absolutely where it's going, yeah. I don't understand why some teams
are small and some teams are big, but on paper it seems like they're all
bringing in the same amount of money. You know, we gotta, why don't all
the software development teams have 4 people instead of 8 people or 12 people? Like, why are they all different numbers? I don't understand, this doesn't
make sense financially t
o me. So, so they're saying like That
something doesn't make sense. So from that perspective, it's
not an acquirer or query position. It's just that something changed in the,
in the, in the management of the company. That's a better way to say it. It's a less challenging way
to say something changed in the management of the company. And someone's just trying
to understand things. Well, you bring up a good point
with finance because they will be looking for standardization from
the perspective of
saving money. So they might look at it and say
you have five teams using this tool and you have three teams using this
other tool and why don't we just have one tool and then we can negotiate a
better contract with the vendor, right? From an accounting
perspective, they're not wrong. But what they don't realize is You know,
these teams have evolved to the point where they've chosen the tools they need. So if you're going to mandate
something on them, what are you actually giving up, right? And
that comes back to
the innovation piece. The teams that are forced to use
a different tool for the sake of saving money, they may not be
happy because that tool doesn't do everything they want it to do. So they're going to go along begrudgingly. Right, and you'll have impact on
motivation and all of that good stuff that happens when you tell somebody
how to do their job, basically. Well, well you're steering us to
talk about a topic here that is super important to me in product management,
which
is, hey, we've like, to go back to the acquirer acquiree conversation. We've acquired this company over
here that is very successful, and we want their customers, or their
line of business, or we want to break into this market or whatever. There's usually a reason
to acquire a company. And let's say, for example, like
Brian & Om's development software company has acquired a Brian's
side business company, right? Brian Ohm's software development
company uses AWS for everything, Brian's software s
ide company is Azure cloud. So now that we bought the company,
we said, okay, Brian, Brian wouldn't be there because Brian left the
company because Brian's not sticking around through the acquisition ha ha ha! But, the people that left, the people that
stayed with Brian's side project company, that are now part of Brian and Om's
software development company, who by the way is not owned by Brian and Om anymore,
that all, that got bought years ago. Like, several podcasts ago,
that company got boug
ht. Ha ha ha! Yeah. Like Well, we can't have you on Azure
because now we're paying an hour. We're cutting a check every
month to AWS and we're cutting the check every month to Azure. You guys need to just migrate all
your stuff from Azure over to AWS. Like, so the product manager now in play,
like looks up and says, I had to do what? Like so basically you just gave
me a mandate to standardize for the sake of standardization. Because product wise, it's gonna be
months of work to do that migration
and at the end of the migration,
what is, what benefit, what financial benefit will my product gain? Nothing. Right? Nothing. So, as a product manager, in
that position, immediately. I feel like I'm going to get marked as
the bad guy in this conversation because I'm going to say what business sense
does it make to migrate us off of Azure cloud just so we don't have this line
item expense of our service on Azure cloud because you realize whatever
money you save from not having a second bill payi
ng the Azure subscription,
you're going to double your AWS bill. Because we're just going to move
over and use bandwidth on AWS. So you're going to pay those costs. So, so really the only thing you're saying
is my, my accountant that pays the bills at the end of the year has an easier time. So, so basically you've, you've gone
through this whole standardization effort so that some back office accountant. Has an easier time once a year, you
only have to pay one bill to pay a bill. I agree. I abso
lutely agree. But I also think that there's
this from a product lens, right? If you have to do this. Yes It's a it's a decent size
effort to say the least what could you be doing instead? Right for your product. So I mean it's chalk
and cheese to me, right? Bringing in a lot of money. That's right. That's what I could be doing. Evolving the product, exactly. Or taking a vacation for a
month and not working at all. That's worth a lot more than
consolidating cloud platforms. I mean, to me it is. I
mean literally twiddling
my thumbs at my desk. Like, there's a million things I could be
doing that will be better for my team than going through a big technology underhood
change that gives no value to the end user, helps nobody in the company except
for one accountant in the back office. Well, as a product person who's forced
to do this work to consolidate CSPs, you really need to keep that resume updated. Because you're gonna get bored. I mean, at that point like, if you're
a good product ma
nager, or even if you're a Scrum Master on your team
Helping product you're gonna be asking these whys you're gonna be digging
you're gonna be doing five whys what? Why do we need to? migrate off of Azure to AWS You know and
and if you're not giving me a list of like well These are the things that are
available to you on AWS or for example Well, there's some stuff that we have
available in our AWS cloud on the back end that you guys are paying extra for
that We'll drop off of our expense list. S
o really Like our monthly expenses that
you pay extra for, cause you have all these plugins or all these custom features
or whatever that you've built, you don't need to deal with that code base anymore. So like if there are real gains Oh,
your, your logs won't be jammed with all this garbage, all this custom
stuff, because you can use our all of our modules that, that come with
AWS, it's a ton of functionality that comes with it, you know what I mean? But let's pretend you're going the
opposite
direction and Azure cloud doesn't have like sweet queuing systems
or databases or auto rollout of environments and stuff like that for you. Like they don't do that kind of stuff. And now you're going to have
to inherit all that business. Like this is terrible. This is an absolute debacle. this can put a company out of
business potentially if it's on a large enough scale, honestly. But to bring us back to the point
and also to wrap up this category is your team has innovated to figure
out how t
o deliver a solution. And now you're saying I understand
that you have maneuvered and researched to find the solution. You don't get to discover anymore. You don't get to look for the best thing. We're just going to tell you what to use. We had we had, we did a whole podcast
on different people in the company saying, I know what the customer needs. That's right. Yes. Right? An ego can't be thrown up. Like, you can't raise the shields
when you hear, how do you know? You know, we can't see that as
an
existential challenge to your identity. You've got to roll out the evidence and
say, well, this team has done a very similar thing to what you're doing and
this team you know, went down your path and found these limitations and that's
why as a company, we all decided if you're going to do an email solution, for example
we decided that this is the most secure method and this is the way to do it. And we have tech leads can walk you
through it and documentation and whatnot. Like if you're going
to standardize,
like there's a way to do it. But those conversations
have to happen though. So oftentimes it's just an
order or an edict, right? The CFO says we have to do this. Right, right. And then you go along begrudgingly with
it because you don't get that opportunity. You don't get the airtime with the CFO. A dictate. Usually it's a Exactly. It's a dictate that comes down and says
You must do whatever and the issue with that, the issue with that, it leads
us to becoming a monoculture pers
on or individual or individuals or panel or
body or governance board or whatever other things I've seen is disguised
as over the whole career that I've had it, it leads you to say, These are the
approved ways of thinking and deviating from these approved ways of thinking
is like not, not, yeah, not approved, not invited, and not, not, not welcome
so the problem with this is it leads to like rather than a diversity of thought. With all the different people that
are on our teams and all the differ
ent cultures that are on our teams, it leads
to blinders in one way of thinking. And that's a big problem. It is a huge problem. You mentioned, you mentioned
the word monoculture. Right. Or words. That's a real thing. That's a real thing because people start
falling in line and, and echoing the same thing that everyone else is saying because
you dare not utter anything different. So, we end up with The culture
and the organization becoming almost like monolithic. It's uncontrolled groupthink. It
is groupthink. And people say, well, that's
how we do things here. Let me think about how, how I would
challenge groupthink for a second. Like even, even the example, like I hate
to keep going back to the exact same example of like what makes you think that
this this is a solution that we need. You know, why don't we explore
the problem a little more. Diversity of thought starts in the
understanding the problem realm. A lot of companies like that understanding
the problem phase, like they, they
seek to hotwire that understanding
the problem phase and cut straight to like proposing solutions phase. And then the proposing solution
phase, it's super easy to co op that proposing solution phase to say
like, Well, solutions can only be proposed between the hours of 3 p. m. and 3. 15 p. m. on a Tuesday in front of
the angry review board. Or whatever, and you must stand on
a pedestal, where we can pillory you with fruit, or whatever. Like it sounds funny, , companies
have review boards like t
his, and steering committees that you, in order
to approve things and have budget be, you know budget be reserved for new
initiatives and whatnot, new ideas. Basically. Yeah. You have to go through
a big process like this. You have to go to a panel and state
your case and fill out a big form yeah, definitely. Groupthink is real. And standardization has a real risk of
precipitating the culture into groupthink. This groupthink topic is super aggravating
to me because it sort of takes on a life of
its own What you end up with is you end
up with a layer of bureaucracy that forms just to keep the status quo in place. It creates process to keep itself alive. Like I think of everywhere I've ever been,
they had like, Governance Board, they love the term governance, I don't know why. That Governance Board or Architect. Review stage or that kind of thing. It creates a layer of bureaucracy
in the organization that purely exists to justify its place. It's in the bureaucracy of the
organization tha
t sounds super confusing, but the type of architect that sits on
high and comes down from the mountain with the tablet written in stone of
the requirements and like you must do this and you may not deviate from these
things This type of thing, I think of. Yeah, we've seen that, right? We've seen that in our lives
in our previous lives, right? Where these things happen. And, yeah, to your point, I mean,
oftentimes people who are innovators, they know that this is an uphill battle. They're going t
o have to go
to these boards and defend it. Proposals and whatnot. So they tend to basically fall in line
with the standardization that's there. And don't go outside of that because
their chances of success are limited. If they even come to the periphery
of it, stay with the guardrails. We stay right between those, the lane. Right. And that's not really
fostering anything new. What you just described is like,
well, now the people that succeed in this culture now are the people that. Won't challe
nge the status quo. That's right. The people that won't like when they
see something that obviously is wrong, they're not going to be the ones that
raise their head up and get smacked you raise your head up
to say something's wrong. The thing will probably get corrected,
but you will get smacked for. Sticking your head out of the monoculture
to be like, Hey, I'm a little different. I don't think maybe that this is a smack. Like Google just got pinged with
this in the news about their Gemini AI a
nd images that they rolled. But I think they, I don't
know if they rolled back or disabled their image generation. I don't remember what they did. Did you hear about this new story? I remember hearing something about it,
but I don't know what the outcome was. There may or may not have been a big
segment of the podcast where we played around with a certain images tool
that was a lot of fun to play with and gave us some questionable images. of historical figures that we
had a riot looking through
. Anyway the, the point here is in the
bureaucracy, there is this layer of people who are there to justify Their
own jobs because they participated and perpetuated this layer of bureaucracy
and the challenge here, the arguing agile challenge here is there are people out
there that will say that agile coaches and scrum masters are part of the
bureaucracy I'm talking about right now, especially internal ones. I tend to agree with that, but I
I just want to say those people do exist to propagate th
eir own
existence, but they also exist To feed their immediate superiors
what they've been used to, right? This is what the C suite wants. So your managing directors or directors,
everywhere below the C suite the middle managers, they're going to continue
those practices because that's the path of least resistance for them. But also I have personally seen
plenty of scrum masters that do not want to challenge the status quo. They just know that coaching the
organizational level is, is futile. It'
s futile. So, so, and they also know, again,
going back to this monoculture point, new ideas outside of the status
quo are just not, not accepted. You know, they're not appreciated, and you
start getting labeled as a , troublemaker. Yeah. I only bring this up again because I've,
I've specifically observed Scrum Masters. I look at them and I
say, shouldn't you be? the person with the advanced facilitation
skills the advanced interpersonal skills to highlight hey don't you think this
culture is a
problem but no they're hiding in the culture because they're
afraid to challenge any of these issues so they'd rather be kind of safe to go along i would not bring it up and make it
such a big thing if i had not seen it more than one time oh definitely
it exists it's real it's out there Scrum Masters and Agile coaches,
especially internal Agile coaches. And even in that segment, it's people
that are coaching at the team level. Agile coaches that are primarily
focused at the team level are going
to just steer clear of anything that
is not in the guidelines, right? The PMO usually hands them a folder
and says, this is how you do things. So they're the ones that go around
saying okay, look, it says so here. It's okay to have your daily stand
up to go an hour long, right? That sort of thing, right? But those agile coaches that are not
just at the team level, but they're also really coaching the organization. They are the ones that I would look to. To bring this up to people and say,
we're
stifling people here, right? This, this is not serving anything, right? Why are we continuing to do this? And to be honest, it's still
going to be an uphill fight. There'll be labeled as the
troublemaker, as you said, right? Not a team player. You're not a team player. Okay. Well, that's not why you brought me in. Right. You brought me in to hold up a mirror. You can get rid of me. That's fine. That's the easy thing to do, but your
problems aren't going to go away. To the agile coaches out there
who
maybe have like, they've sort of insulated themselves and they're
sort of like, well, I I know that challenging the status quo is like
tough and I just don't know because it was like a lot of people getting laid
off and I feel like there's security and not challenging the status quo. What tool can you give them to
sort of like, to, to make progress toward challenging the status
quo, but also not get fired? So here's what I'm
going to say about that. If you're going to just drift along. If y
ou're going to drift along you're
getting closer and closer to that door. Right? So I would say, pick one fight
that you can win, go do it, right? Be brave, go do it. And don't ask permission. That's not gonna work too well. But then again, you're not radically
changing the core construct of the organizational culture, right? Pick one thing as a practice and say,
I don't see why this team should be following that specific practice. Stay with you, with a team and
be driven by result, by data. Yea
h. And say, here's what we tried. Here's how well it worked. Right. So we're going to do it again. And then slowly over time, you
can get other teams that you're coaching to kind of do that as well. You don't have to necessarily
make a big deal out of it and say, we're not doing this anymore. We're doing this
newfangled way of working. You don't have to do that. Just stay below the radar and do it. Right. But what we used to call
gorilla coaching in the day. Yeah. If you have this monoculture wh
ere
you can't challenge ideas, you can't point out problems, and you, and you,
you, you're afraid of, cause that's, that's a lot of what we're talking about
is you're afraid to speak up, right? Then in that kind of culture, If you're
afraid to speak up and you're afraid to point out things that are not in the
current pipeline, things that you're not doing right now, I feel that your
whole organization will have difficulty adapting to new technologies, or new
trends, or shifts in the market, or s
hifts in your customer preferences,
and you're I feel like this whole thing we're talking about now, where it's
like new ideas don't new ideas are not accepted or appreciated in our culture. Well, that's fine. I mean, I guess it's fine from the
perspective of you're going to have the people running the business and
the people you have working until they leave and then maybe you'll
replace them, maybe you won't. Seems like it would be difficult to get
people into that culture, but over time, you'
re going to lose market segment
because you just don't have a culture who is willing to be responsive and
who's willing to learn from failures. And in fact, I would, I would even
go out, I would go so far as to say. Failure probably is a word that
is just not, not encouraged to be spoken out loud in that culture. So that tells me you're
not learning from failure. So if you're not learning from
failure, and you're not learning from your own personal initiative of
learning, for the sake of learnin
g. I'm going to guess that the world, when
you look at the window in a couple days, the world is going to have passed you by. That's right. Yeah, I agree. I think you lose that,
that nimbleness, right? Yeah. You lose the nimbleness to, to
respond to the changes that are out there because you're too mired
in your own internal processes. So. What can happen here is that
company is going to lose, perhaps lose customers, lose market share. I don't know, but that's not going to
be appreciated by thos
e people that are just still in the line, you know? Yeah. We lost a customer. So what? We're still doing the right thing. Cause they're just so ingrained in
their current culture, the monoculture. Well, they're still checking the boxes. Exactly. Yeah. Yeah. They're checking the boxes and
that's not served them well. So why keep doing it? The product management equivalent to me
is when I go through an interview and I ask people, Hey, in your organization,
where do the ideas come from? Right? And
they'll, a lot of people, that's,
that's a softball question, usually. Yeah. Okay? But depending on your responses I can
dig, tell me about the last time that you picked the best signal and tell
me about the detractors and I want to know about the fights, because you have
evidence, you have data, there's people with their intuition, you know what I
mean, that say like, well, your evidence is wrong, because I know the market. Like, tell me about that conversation. Like, I'm going to dig into
the
real conversations. everything I just described is
not happening in this culture. No. You know, we're No. I'll tell you what is happening
in this culture, though. Right. In this culture, what is happening
is yeah, fill out an intake form, and then that's gonna get funneled
into the product backlog, right? It's like there's no validation, right? There's no verification. The customer actually asked for that. Oh, why? Much less. Why? Right? If you're just taking the customer's
word for things, for
example, Verbatim. Yeah, that's this culture because
you don't want to necessarily be the risky one asking customers. Why do they want something? They just told you they want something
to go build it right that that's what tends to happen in monocultures and
the end result Sooner or later is yeah, you're gonna have disenchanted customers
and they're gonna lose you leave you. Yeah, you'll lose market share Yeah, in the culture where you're towing
the party line, you're just trying to make your bo
sses happy because they you
no idea, every idea has to be sanitized. Right. What the customer wants
really is not front of mine. I mean, it's really not front of mine. I it's, it sounds absolutely bananas
to say out loud, but you're not trying to impress the customers. You're trying to keep your job. You're trying to impress the bosses. You're trying to convince everyone
that I think like you think. Yeah, exactly. And I've seen, this is really
terrible, but I've seen this where customers coming
up with certain
ideas that are outside of the the day to day, how you should be working,
they're labeled as trouble customers. Yeah, trouble customers, yeah. Oh yeah, that customer. Problem children, yeah, right. Exactly. What a shame. I've seen that, yeah. What a shame. But that is exactly what happens
in that kind of environment. So a person who is basically, like
you said, toe in the party line for a while, what happens, right? What happens is, You keep your boss
happy until they leave, and t
hen someone else comes in, and you keep them happy. Or they have different ways of working. And sooner or later they're going to
say, we don't need so many people, right? Because we're prizing efficiency. Right. And you could be out. So might as well take a chance and grab
the opportunity to make a real difference. now's the time where I wanna pivot us into
what I really wanna talk about on this, on this podcast and what I really wanted to
talk about on the weaponizing Efficiency podcast is ther
e's some underlying
need for control that is coming out. In all of this and especially in the in
the point where there's a market downturn and people start getting let go right or
entire teams getting let go or usually it's the offshore teams get let go first
and then the contracts get let go and then you know, we we save the Internal
employees for last or whatever and, and none of this is done by like who supports
what revenue stream or any of that, none, none, none of that is considered. No, i
t's, it's all, the
consideration here is which tab on the spreadsheet that person is. And even in the phases that I just
pointed out, they might say, well, these offshore people, I know they
align with my way of thinking. So I'll figure out a way to
save them and move them over to this over here for a while. Right. Yeah. I'll consolidate some teams and get
rid of basically what they're, what they're doing in this phase is they'll
get rid of the problem thinkers, right? That, that's what I've see
n in, in,
in, in the market downturn in this. But honestly, like everything
that I just described, like it all comes down to like enforcing. Micromanagement I need to be involved
in your day to day work to feel like I understand what's going on. There's a feeling involved here. That I don't believe that you're
working on the most important thing. That you are aligned
with what I'm thinking. There's a mistrust happening. It comes down to that, really, trust. I don't trust what you're doing,
there
fore I'm going to tell you how to do something, right? It's not that I don't trust you
because you have broken my trust. And proven that you're not trustworthy. It is I. You're in security. I am insecure. As a manager. Yeah. That is the issue. Yeah. Or I am just not educated
enough to understand how to look for a team that is working
appropriately on my requests or not. So I, I don't, I don't understand
the metrics to look for. Right. Right. I've just not been educated. I've kind of been thrown
into
this leadership role and not. Nobody's helped me understand what
what success looks like on paper versus not a failure or stalled progress. Nobody's helped me understand that. So I feel very insecure about it. So in order to make up for
that insecurity, I'm going to micromanage this team. I'm going to take increasing
control of the day to day. Yeah, that's a, that's
a perception thing too. I think in a lot of times, a lot of
cases, the middle managers need to have that perceived control, ri
ght? Whether they actually have control or not. And what I mean by that is the reality of
this is as soon as you're not in the room, what are people saying about you, right? It's not that you're controlling them. It's, it's that you have a. Perception that you're controlling them. They're going to do
things to make you happy. Right? And in turn, guess what? You're going to do those things
that make your boss happy. That's what this is about. You're not prizing what
really should be prized. Right
? Which is delivering customer value. You're just basically, like I
said, keeping your superior happy the other thing about standardization is
that the idea of standardization slows down individual growth like there are
less opportunities for individuals to do cool things outside of the box outside
of the norm Hey, if you want to you know, if you want to get training dollars over
a certain amount approved You got to go through a process Rather than just talking
to your manager and then they just
do it. Or if you want to get if you want to get
a new technology and bring it into your work center and just play around with
it or whatever Ed, what I was talking about before is like Azure cloud or AWS,
, AWS is a good example because AWS has. So much stuff available to you for
you to mess with so much stuff. Now, I mean, they have a AWS in house
has a whole AI ML model management sort of cloud for you to play with. If you don't want to send your
stuff out, out outside the chat, GPT because y
ou don't trust chat
GPT to not like steal or data. Cause I mean Hey, that's
their business model. Like AWS hosts models for you. You can say, Oh, I want to use
this model for this purpose. And I want to set up this thing. Right. And you can just do it all in house. If you just want to try some cool stuff. To see what you get from it. But now you've got this like, well, I mean
to set up this AWS , like application, it costs like, I don't know, like 5 cents
per billion transactions or whatever. Li
ke it's super cheap. It's super, it's very cheap. But the point is like,
if you don't have any. Financing. If your finances, if your financing
is controlled by some other board or authority or whatever, and they only meet
like once every quarter and you have to go in front of them to get a budget or
whatever, approval, nonsense or whatever. How much process do I have to
throw on top of this before people just say You know what? I'm just not gonna bother. I'm just not gonna bother. Absolutely cor
rect. I think the most likely outcome out
of that is people just say, I'd love to try that, but I'm not going to
be successful here trying to lobby for it, so I'm not going to bother. Right. That's exactly right. Yeah. Right. Here's the way I look at
it as a product manager. Brian & Om's software development company. Like Ohm is a cowboy coder he's
writing scripts for all kinds of weird stuff that may never go anywhere. They might, in fact,
they might never help. Anyone do anything. He just thin
ks the output
of the scripts are cool. Ohm loves to write scripts because
he thinks the output is cool. And often, Ohm will pull an
engineer over to his desk and say, Look at this cool script I did. Isn't it so cool and the engineer
will say, actually, not only is that cool, that is very useful, right? There is no forum for me to take Ohm's
cool script and say, here's our roadmap. I'm going to drop Ohm's cool
script into our just drop, just drop it into our roadmap. I should probably get
a sound
bite to do that. Just drop it into our roadmap because
Ohm wrote something cool that now we can write into our main program. You know, our main web application
or whatever, and like, everybody can take advantage of that. Like, Ohm's just like this loose cannon,
just writing cool stuff all day, and sometimes he writes stuff that's like,
oh my goodness, Ohm nobody needs that. Right. But sometimes you write stuff
that is just absolute gold! So a company that has the heavy
process that we're talking
about here is unlikely to have any kind of forum
where people can do that, right? As opposed to what? As opposed to maybe just dedicated
time that people are given to just experiment and play, right? And go and create something
in Skunkworks or whatever. You may not use most of it, you said, the
one thing you use, it can be gold, right? But that's just like benefit side of it. The hidden benefit is two things. The developers are motivated because
they get to try stuff, right? They don't feel l
ike they're restricted. That's one benefit. And then the other is
on their morale, right? I think maybe they're related. I don't know. But you know, I'm trying new things out,
and maybe if it can be useful to the company, maybe they'll kick a little
bit of money my way or something, right? Pizzas. It doesn't matter. So that kind of thinking. Is usually not going to be promoted in a
company that has the heavy process, right? You just don't have the appetite for it. Yeah. Well, also you're like in
a company that
has a lot of process for standardization, nobody's going to do quote cool stuff
development because they know that the company like it's going to be a lot of
process for the company to pick it up, if you're in a company where you have
like two teams or three teams and you have a product manager, one product
manager, one product line, one product manager, two, three teams, right. And like a CEO, super small company. And you just have a form like, oh, well,
we have a company meetin
g every month or every six weeks or something like that. And part of the company meeting
is people just demo cool stuff. Here's cool stuff that I
wrote, that I did, or whatever. It might not be code. It might just be cool, cool
business processes or whatever. It could be anything. Yeah, it could be anything. Literally anything. But maybe people have cool stuff
hey, here's my script that I wrote to automate this business process,
or this thing that we're doing, or this Email script, like that, th
at's,
that's, that's the thing I see a lot is oh, here's a new customer on boards. We don't have a system or whatever, but I
put their name in a list and whenever the new name is in the list, the script picks
it up and it sends them out an email, automated email or an automated email. Here's the other thing. It's slightly more complicated,
but also equally cool. This have a script that looks at our login
database and it, it knows all the users cause it has access to the user list and
it looks at
the login database and it says, when's the last time you logged in? If the last time you logged in is more
than 30 days, 60 days, 90 days, whatever. It sends you an email. It says, Hey, we haven't
seen you in a while. What's going on? You know, here's a Calendly link. You know set yourself up an
appointment to talk with the product manager or with the CEO. The CEO of a tiny little
company, five people company. People might be more apt to click a
link and schedule time on the CEO to say like, He
y, I signed up for your
application and I pay whatever dollars a month and I don't want to use it
anymore because You know, you're not servicing my needs as a customer. Well, if the automated email came from,
came from and response to and put time on the calendar of the CEO, when they use the
form, I mean, you might retain a customer. Sure. No, you're right. You're right. Absolutely. You know, that, that, that could work
in a small company and a big company, a big company, even if you wanted to
write an automated script that looks at your production, even if you can
get access to your production database. Yeah. To get the list, writing the
automated script and running it on a regular basis against production. Big. No-no. You have to get approval
for that and then. Pulling the CEO in or product manager
or whoever it is like, that's another. So I guess what I'm, as what I'm saying
is as an individual trying to look for different ways that you can grow
different ways, you can expand and t
ry different things, try cool things how many different layers Are you willing
to punch through before you're just gonna say, you know what, it's just not right. I mean, the users that log on to the
platform, log on to my website and like, they never get past the activation phase. I'm not gonna pause. It's so much work for me to
get all the different approvals to talk to these people. Nevermind, they're gonna take the
path to least resistance, right? They're not gonna do that. You're right. Beca
use they may get their hand. Slapped at the, at the minimum, right? Or they will be yelled at
and told to stay in the lane. That's not good. No. That's not good. Because you're not using the best
thing for the job at that point. And my corporate culture never evolves. That's right. Yeah. Yep. And you get frustrated, right? Because you can not proceed
the way you want to. Right. Yeah, I don't get it. I don't get it. the other thing that I don't get when
you're trying to enforce these standards Us
ually what happens is they do not get
enforced consistently across all teams. So now there's all kinds of feeling
of like, even if you wanted to enforce them consistently across
all teams, you'll get these feelings of favoritism and these feelings of
like, Oh, those people get what they need, but I never get what I need. Also I've seen intentionally giving
some teams everything they want because they're more vocal about
this pushing back than other teams. Yeah. And those teams may have different
relationships with those people that are holding the decisions. That's exactly right. And then you have the undercurrent
of politics in there too. Right, yeah, exactly right. That's exactly right. And the last thing I want to bring up,
because I think we've talked about this way more than I wanted to talk about
this category of standardization is. Your relationships with vendors. I heard a story once, somebody told me a
story once where they said my procurement department requires three equal v
endors. Three equal choices to be submitted
to them before they will allow me to access procurement funds. Even if the acquisition of a software
package or a third party package or something, even if that acquisition
is approved by whatever manager, whoever in the organization, the
acquisition, like the acquisition department, the people actually like
sign contracts on behalf of the company. They, they require. Three different quotes, basically. So, even if I know that this one
software fits all
my needs, and I've researched all the different types of
software, maybe I've signed up for free trials and I've tried them, even if I
did all the legwork, the procurement people still want three choices. And I'm saying three choices because
I know there's companies out there that want more than three choices. I've, I've heard as high as six
choices, which I think is ludicrous. So, so the reason that the procurement
department wants multiple choices is because they want to be able to note
the c
ost of all the different choices that that we're choosing between. And at the end of the year. They want to say, here's the highest
cost choice and here's the choice that we went with, which assuming
it's not the highest cost choice. They want to be able to say, we saved
the company a potential amount of money by the difference of the highest choice
and the choice that we went with. So they're trying to justify
the procurement department's existence by saying, well,
we, if we weren't around, we.
Maybe could have gone with
the highest dollar figure. But in reality, usually the
requirements and the decisions that go into the purchase. are done before any of the
purchase recs are even submitted and the, the sad part of this is
like, if we're interviewing like five software vendors to figure out what
cloud solution we have to go for Oh, like I'm engaging five different sales
departments to do the whole song and dance and to come in and do demos. And I'm wasting a lot of time. Like I'm goi
ng to invite our tech lead. I'm going to invite our product person. I'm going to invite
the procurement person. I'm invite a whole bunch of people
on our company when I know, because I've already vetted the solutions. I want to go with this one. And I wrote the requirements to highly
favor this one, in case the procurement people mess it up for me, by the way. And also, I'm only going through the
song and dance because I'm trying to check off checklists on the procurement
people's checklist, bas
ically. This, this situation you
just outlined is real. I've seen this at
multiple locations, right? I've seen this. When you mentioned that at the
end of the year, they can say this is the amount of money we saved
through a prudent vendor diligence. I bet you they're incented based
on that in some way, shape or form. If they're incented that way, then
that's the behavior that you'll get. Right. And the irony of it is, as you
said the diligence has already been done at a different level. You've
decided vendor
X is the right vendor. You may even have finance for that. You may have financial approval to
go spend the money, but procurement is a different department and. They have, they usually have long
lead times too, for some reason. I don't know why, because I guess I know
why, because they have to go through and look at the company and all of that. Right? The vendor company and all of that. That's fine. So all that time that you're
wasting, and at the end of it, they will come back an
d say. Either if you're lucky, they'll say,
yeah, you can have the vendor you want, but you've lost all that time
or they could say, no, this one's, this one's better because it, it
meets 90 percent of what you need, but we're saving X thousand dollars. Right? Yeah. You, and usually the, the way that this
will manifest is, is for the company to come down with a dictate that says the
only people allowed to sign contracts on behalf of this company or as this company
are the procurement department
or the contracts departments, whatever it is. we go back to the the purpose of this
podcast, like if you're going to weaponize it, like it's very easy to say the
only people who can spend any money on behalf of the company are these people. So basically the policies they lay down,
no matter how bureaucratic or ludicrous or whatever they are, or laborious they
are, that's the word I use in the podcast. That's a good word. Whatever they say goes. I'd say if you're in that kind of a
culture, make f
riends with these people. Because that's the way
you're going to get ahead. You know? Right. Right. Offer something. But also again. How do you deal with that? it doesn't help with customer value, it
doesn't help with value delivered, it doesn't help with speed to market, it
doesn't help with a lot of other things. it'd be better if these people are lending
their expertise to the decision process and I'm bringing them in as experts. The same way I'm bringing
in finance people. To help me with fi
nance decisions
engineering people to help me with engineering decisions again It's just we
like the normal models don't don't really help you understand how to integrate these
non technical people into your decision flows and I feel that's that might be a
big failing of the Certification and the kind of the whole industry here for sure. For sure. There's a lot there. Absolutely. I mean, all of those domains that
you mentioned HR, legal, right. All of those play into this whole thing. Sales. Yea
h, definitely. Yep. Standardization. I don't know if we gave a fair shake
to both sides of every category in a standardization, like, I understand
if your company says, okay, we're only going to buy laptops from Dell, for
example I don't know why I'm going back to the early two thousands, like I'm
only going to buy laptops from Dell because if we standardize a vendor
and say, we're only buying from Dell, then we get a solid 20 percent off
of all Dell hardware that we buy. And we only buy from th
at vendor. Like that that's, I mean, that's
clearly a savings to the company. As long as the Dell hardware
is competitive with other hardware on the market. But that's an interesting example
because you may have, and this is again real, right, companies do this. But you may have a legit reason
why a developer or some developers need Macs, for example, right? So, yeah, I mean they're expensive
compared to Dell's, I imagine, even today. Give them those things because they
need them to develop thin
gs on Mac OS. That's just an example. You can justify those
things, though, I feel. How can I develop something on
Mac OS when I don't have Mac OS? Yeah. But trying to make people that are in
these other departments understand that. Right. Because they see names
and they see numbers. So they look at, oh, you want a Mac? No, you can't have a Mac. They're very expensive. Right. Right. We've got this thing with Dell. You can have a Dell. I fought that fight with some
companies, on behalf of my deve
lopers. They just say, oh, how do I
develop without, I'm like. Right. Right. Good point. Right. And then you got to go fight the fight. But process for processes sake. Anytime when you're looking at
any kind of process, look for the benefit coming out of it. Right. To those that are going through it. And if there's no
benefit, then question it. Like, just feel free to
say, why are we doing this? This way, but not in an not,
not in an accusatory tone. I mean, just go in and say, wouldn't
it be be
tter if we did it this way? Cause it's quicker, right. Or you know, it gets us to the end result
without having so many stage gates, right? Sign offs is another big one in processes. I can't believe we did this whole
podcast and we did not talk about the number one weapon of choice
which is handoffs or signoffs or stage gates or something like that. Like I think we implied it, but
we did not specifically talk about handoffs or signoffs. I have this thing that I love to tell
people as a product m
anager, I think handoffs are a big waste of time, and I
hate them, and I don't want to do them. Well, in the lean way of thinking,
handoffs are a waste of time, and we look to eliminate those as much
as possible, or minimize them to the point where none are left. But this is real. Handoffs are real because, again, people
have that insecurity that I must be able to see things and put my rubber
stamp on it and that's the sign off. They become bottlenecks. I mean, you wait for
people to sign off th
ings. Right. And the ultimate is attending a StageGate
review meeting and then defending the work that your team has done and then
looking for approval from someone who has no clue, by the way, about the
functionality you've built, right? This is like only things that you get
at large companies because I can't, I can't, I can't even fathom as a
product manager sitting in a room with an architect who doesn't know my
business, doesn't know my customers, doesn't know why I'm building things. That b
asically has no context as to
the why poking holes in my application. Let me add a little context to what
I'm saying, because I will often put features out before they are ready. And I know that the features
are not quite right. So I am expecting, oh Brian,
you put up this new drop down. But it doesn't have the most obvious
option in the drop down that most customers would expect, I want to pull
a drop down and export this file to PDF. But you only allow me to
export it as a PNG or whatever. How
come you didn't like everybody
needs P everyone needs PDF. Okay. I know everyone needs PDF and I know
that if I put PDF, that would be the only option everyone shows, but I also
know like on the backside of the house like in the backend, like I need a. PDF processor and I know I have to
pay for it or buy one or do whatever. And, and I'm like, I'm not sure that
this workflow that leads people to saving off the file is even a valid workflow. So I want to see people go to the
workflow, select a th
ing and hit download or select the thing and then
back out and not hit download again. This assumes you have good user metrics,
good instrumentation in your application. I already know. That I'm not, that I am not servicing
the customer for what they really need, but I want to see that they take
that, that path in the application. It's really easy to push
out fake door features. Like for example download PDF. Like if we're talking about PDFs, right. I don't know why we're talking about PDFs. I c
an add a download PDF
button in my application. I can just go to developers and
say add a download PDF button. But it doesn't do anything right now. Clicking it says, downloading PDFs
is currently restricted, will be available in a future release. Or whatever. Perfect. Okay. Architect, or somebody says like, Why
would you even, why would you allow that? Like, just hide it if it's
not there because it's going to make For many reasons why. It doesn't look professional, Ohm. It doesn't look profess
ional. Says the architect. Again, they don't know my customers. They don't. They don't know what I'm going for. They don't know and you can
say, Well, I mean, that's the purpose of the stage gate. That's the purpose of the sign off, is
so that you can inform them as to the yes, yes, and also, why do I need Why
are they not assigned to my program? Well, you're in a large matrixed
organization and they just were told to go do this particular stage gate review. They just show up unarmed, unprepared
. I mean, this is what I've seen. And they will be blocking you by the
way, because they have huge egos. They're not going to
let anything slide by. Well, yeah. They decide that it shouldn't, right? Yeah. When I bring it up like that to them,
of course, they're definitely going to be blocking me when I say like,
you're not even involved in my program. You have no idea how I measure metrics. You don't know professional Brian. Putting something out
there that doesn't work. Like I've heard your opi
nion and I
think your opinion is hot garbage we could be in completely different
segments of the technology adoption curve I'm dealing with. Early adopters, you're dealing
with laggards, and you're trying to apply a philosophy, that works
with laggards, arguably works with laggards, to the early adopters. The early adopters are so happy, or even
the let's even back up to the innovators. The innovators in the technology
adoption curve are so happy to have thing that helps them with their problem.
They, they could care less that it
doesn't crash every time, let alone that they don't get another export option or
whatever even in the early majority like the fact that they have two options in the
dropdown that work for saving their thing off and then the main option, which they
really prefer, which is PDF doesn't work. They don't really care. They're still happy. That won't be a showstopper. But at least you can validate that then. You sure can. Which the architect doesn't
think about it th
at way. You know, they don't
think about it that way. We're validating this based on real
customer journey through the product. They don't think of it that way. I'm with you on the thinking that
they don't think of it that way. And by that way, my, my context
is from the perspective of what helps user the most rather than
their own ego or their own views. Or their own opinions. When you build bureaucracy for the sake
of bureaucracy, and it has to justify its own sake in their bureaucracy,
it can
't get out of its own way. That's just not, it's not possible. It's horrible. It's, it's a spiral actually. So taking this. This example of the architect at the
review, chances are they need to be able to go to their superiors and say, I did
four reviews today and you know, none of them passed or one passed or whatever. And here's why aren't I
doing a great job, right? By the same token, they can come to you
in your, in your review, they can say. PDF. Oh, wow. We're not going to spend
money on a
PDF processor. We can build that in house. We're going to build that. And I know how to do it. I'm an architect. Now you're solutioning for
things you don't even know the customer actually needs. I've seen that happen. Yes. I've seen exactly the
case you're talking about. Oh, I can build that. Yeah, you don't need to
spend money for that. Well, I mean, you can build it,
but also how many sprints are you going to dedicate yourself? To my program and who can I talk to
to make sure that that happe
ns on paper and that you don't get stopped
and interrupted Because my program is about delivering value and I would be
willing to pay to have an uninterrupted stream of value as opposed to trying
to You know jockey for position with all the things that you're involved in
like i'm just not interested in that I feel this isn't It is and is not
a great example because now I'm, I'm like conflicting two worlds. I'm conflicting the Brian
product management world of. I want to move fast, I want to exec
ute on
things, I want to try things and let the customer be the judge and to, to, to, to
follow where the customer is leading me. And the other world with this solution
architect or whatever is, I want to justify my place in the bureaucracy
and I want everyone to subjugate their demands to, to, to me trying to
justify my role and to make me happy. Hey, it takes very
little to make me happy. Just tick the box, subjugate my
ego, make me happy, and then I won't be a big blocker for you. But my chal
lenge to that is, I don't,
none of that adds value to the customer. That's right. So really, just get rid of it. Maybe in our next big you know,
corporate drawdown, like maybe we can get rid of that layer. And we can be a bit more lean. Yeah. Yeah. I mean, look, good luck with that. So definitely handoffs and
sign offs are a big, big drain. They're a big waste. They are. They're a complete waste, actually. To all the product managers out there, or
maybe scrum managers that are living in this env
ironment the customer value would
be the way to cut through this layer. I have like my customer value
and my direct customers. Like we have a process and it works
for us and the customers are happy with it and let the customers speak on your
behalf and try to cut through this and segment yourself off of the bureaucracy
and I even realize when I'm saying this, nobody's going to like that. Nobody's going to be happy with it. You're going to be, you're going to be
the black sheep out here by yourse
lf who's carved an exception for yourself in the
process and everyone will hate you for it. You're right. That is the right thing to do, right? So the scrum masters, you're
there to coach the organization. That is the right thing to do. So do it. Right. Feel empowered and do it. And also Keep that resume updated. Definitely keep that resume updated. And also, like and subscribe
to the Arguing Agile Podcast because as a small channel, every
like and subscribe helps us. It helps us a lot.
Comments