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

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Brian (00:00):
Om, I don't know how to say this.
I'm just gonna say it.
Solution architects, allthe ones that I've worked
with anyway.
But wow.
They're, they're useless.
Like they, I sorry.
I was, I was trying notto say Okay.
I mean, they live in theivory tower.
They make you kiss the ringwhen you want to make a change,
it affects more than one team,

Om (00:16):
yeah.
What I'm hearing you say isthey're as useful as doorknobs
on a wall.
Okay.
That's fine.
Let's start with that opening.
Although I have to say.
in my career, I'veonly come across one solution
architect who actually wasworth his soul.
This guy really got

Brian (00:31):
Oh, so are you arguing the diamond in the
rough argument?
Is that what Yeah, definitely.
Oh boy.
Okay.
Rough seas.
Yeah.
Well, so yeah.
Well, we're doingit right today.

Om (00:39):
Let's do it

Brian (00:43):
Welcome back to Arguing Agile.
If this is your first time, I'mBrian Orlando.
Product manager extraordinaire.
and this is my co-host,Mr. Om Patel and Enterprise
Business Agility Coachto the starts, Mr. Om Patel.

Om (00:53):
Welcome.
It's great to be part of thisdiscussion today.

Brian (00:56):
we got a comment talking about the relationship
between product managersand solution architects, why do
product managers and solutionarchitects seem to be at war
when they should be partners?

Om (01:07):
You're telling me the one person
whose literal jobis to prevent your
product team frombuilding technical debt monsters
is the problem

Brian (01:17):
I can't even with you can't, like we both can't
be sassy for this podcast.
No, we can't, but okay.
We can try.
So, yeah, that brings us tothe topic of this podcast the
only reason thatproduct managers and architects
slash solution architectsclash is because the architect
role it's not a real role.
Anybody that's on the internetcrying about how Scrum as is not
a real job, that I feel the sameway about solution architects.

(01:40):
Let's argue about it.

Om (01:41):
Awesome.
Well, challenge accepted.

Brian (01:43):
These are the three things
that you're gonnawalk away with.
You're gonna know why PMsand solution architects clash
and probably otherpositions too.
You're gonna we're gonnatalk about three conversations
that you can use to try to fixthe relationship.
You notice I saidtry to, because again, it's not
a real position.
So I don't know if you're gonnabe able to, and then we're gonna
give you some tipson how to spot
gatekeeping versusactual enabling behavior that

(02:07):
helps your teams.
That's supposedto be the benefit of having a
solution architectis they can go across teams,
they can help enable your teams.
Right.
If like we're looking at teamtopologies they're
supposed to be able to enableyour teams.
So that's, that's hopefully whatpeople will get
outta the podcast.

Om (02:21):
Yeah.
Maybe we'll leave you a phonenumber to call Ghostbusters.

Brian (02:25):
Or somebody.
Or somebody call Tyronesome, somebody You better call
somebody, is what I'm saying.
The first category here.
Is why, why does this roleeven exist?
Right?

Om (02:35):
Yeah.
Maybe we could just start bydefining some of these titles,
perhaps, right.
Solution Architect or enterpriseArchitect, et cetera.
Who are these people?
And how do they wind upin those roles?
Solution Architectme is somebody who has performed
the duties of a technical leadfor some time.
And they finagle their way intoa realm in the
organization where they're handsoff basically.

(02:57):
In large organizations.
I get that you may actually havelike an enterprise architecture
board or something like that.
And these are activemembers, right?
Real card carryingmembers of that, of that guild,
if you will.

Brian (03:10):
Technical architect, solution architect.
There's a bunch of name.
Again, another reason why thisis, it's made up like there, do
you like my new sassiness levelon the podcast?
Let's kick into the steelman totalk about the steelman points
here are, they're pretty good.
Two bullet pointsthat especially for large
organizations, they make a bigimpact and we will

(03:32):
address each one of them, right?
Number one, like someone's gottaprevent the teams from creating
incompatible systems.
Or team A is trying to solvea messaging problem, so they
like go spin up an entire Redsimplementation and architecture
or whatever.
And then Team B is just usinga database.
I think about likehorror stories from like the
old Twitter world where peopledidn't talk to each other
like somebody.

(03:52):
It needs to have the final callor at least some
sort of oversight.
Or like in larger organizations,you would say governance.
That would be the dirty wordyou would use.
And then the other one is theproduct managers here, most of
them, they're onLinkedIn posting selfies, trying
to make sure theirhair looks perfect or whatever.
They don't have the deeptechnical chops
to understand whatyour teams are about to do, so

(04:15):
you need someone to be the quoteglue between teams to help them.
That's the Steelman case.
And I feel that'sa pretty strong Steelman case
in this sense.

Om (04:24):
I think there's a slight distinction there
between technical architectsor solution architects
versus enterprise architects.
So at the team level, youcould go ahead and weave out
a solution that your team needs,that's fine.
But at an enterpriselevel, are you
creating duplicate solutions?
Solutions that compete withone another?
Right.
. So those things,solutions are, to your point,

(04:45):
not compatiblebut also if you go
back to the teamlevel, at a lower
level than just the enterprise,we need to ensure
that the solutionsthat are being created at each
of these levels can scale up andperform the duties that they're
designed for.
Yeah so this might be a role forsomebody like this
person that we're,we're describing a solutions

(05:08):
architect To figure out,you know is this solution
compatible with what we'redoing as a direction with
our enterprise?

Brian (05:18):
Strong steelman points in this category.
I definitely agree.
However if I'm gonna push back,I'm gonna say again, this role,
like everyone crying aboutScrum Masters, same thing
with this role.
it exists becauseyou've got gaps.
Like you never read Teamtopologies by Manuel Pius and
the other guy, Matthew Skeleton.
And you never listen to arguing.
Agile.
67 team topologies.

(05:39):
Organizing business andtechnology teams
for fast flow fromJune 24th, 2022.

Speaker 4 (05:45):
Up people.

Brian (05:46):
By the way, that was a long time ago.
Three years ago, that podcastwas formed and we taught you
all about team topologiesand different types of teams.
Well your organization andyour tech leads and your CTOs
and whatever, they never readthe book and didn't, first
of all, that's what I'm saying.
They're not looking forhelp, nor is it being accepted.
And you have thisposition because.

(06:08):
They couldn't justread a book that says like, oh,
well your team should talk toeach other, and if they're not,
you should makethem intersect on
these lines andthink about using
org design to helpyou punch head.
In lieu of doing abunch of hard work
on 'em, that's what I'm saying.
Yeah.
They created this position andjust, they're just
shucking it off this position,be like, Hey, get in there kid.
Figure it out.
that's what this position is.

(06:28):
And of course, like the personthat has a huge ego is like,
well, I'm tappedby management to figure it out.
So you gotta invite me toall your daily standups and you
gotta invite me toall your planning
meetings and youknow, I'm gonna be
the hippo in the room basically.
'cause I got a director title orwhatever VP title,
whatever it is.
Somebody with a budget is whatI'm saying.
They just pulled out of the air,oh, I'm gonna invent this new

(06:50):
position and throwit at the problem rather than
actually solving the problem.

Om (06:54):
Yeah.
Yeah.
Those executives you know, aregetting all the help that they
didn't ask for.

Brian (06:58):
So the number one, that's why they exist.
I have worked with goodarchitects, right?
Like, people that span teams.
They're not dedicated to oneteam or another, and that's
what they do.
I think about alot of AWS shops,
a lot of people that really knowhow AWS works.
So when they comein and a team is
like, oh, I don'tknow about Hmm, we
need to implement queuing, butmaybe we can use

(07:19):
a database tableand maybe we can use this, maybe
we can use that.
And this person comes in andsays like, well do you wanna use
Redis or Kafka or SQS, or, youknow what I mean?
Like they have a half a dozensolutions that they've worked
with in the past, ready andavailable to suggest to the
team and then help the teamunderstand what other teams are

(07:40):
doing, right?
Because they know, 'cause theyeither, either because of their
position or because of theirtenure service at
the organization.
And that is that architectlevel helping, enabling, that's
what I think of as a positive inthis category.
The positive folks make abig difference.
Yeah, the bad architects,they become the bottleneck that

(08:02):
the team has to go throughfor approval and it holds
up everything.
It's like, oh, you can't makeany decisions because quote
governance says, in order to usethe new server or
new technology orwhatever, you've gotta get the
approval of thesetwo people so then
everybody down the line, productpeople, team, senior engineers,
everybody says like, well, we'renot even gonna consider that

(08:23):
because we gottaget approval and we're not even
gonna bother that.
That's what it ends up being.
All coming from this one person.
The other one that I have nextto you is the bullet point that
most architecture decisions areactually team coordination
problems in disguise becausethey have to go through
the solution architect.
That's been my experience.
I don't know ifthis lines up with
what you've seen.

Om (08:42):
I've seen that more often than not.
Actually I've only ever, Ican only recall one experience
I've had where the architectwas invisible.
Yeah.
But behind the scenes.
They were laying out thearchitectural runway that
made sense.
Not for the team.
Mm-hmm.
I'm talking about for theorganization so people are
across the aisle weren't Right.

(09:03):
Like coming up with their ownsolutions that would probably
be incongruent with where theorganization's going only come
across it one time, folks onetime and I've been at this game
for a while, so this is actuallyvery true.
You have architects that reallycan do this.
Yeah.
And they say, well, this is thebest thing since sliced bread.
Yeah.
I, I use Kafka in my previouslife, and that's what we're

(09:24):
gonna do here.
But in reality,

Brian (09:25):
like you're, you're just, you got a
hammer and you'redoing every job with a hammer.
That's what's happening.

Om (09:29):
Exactly.
So maybe, maybethe right solution isn't Kafka.
Maybe it's like an enterprisemessaging bus or whatever it is.
But, so these people.
Derail the organization.
at the risk of trying toget a project done quickly it
just depends on where they'rereporting into.
If they're reporting intoleadership that they are saying,
get this done now, get thisdone next month they're gonna

(09:50):
take the easy way out, right?
They'll, they take the pathof water, right.
If they're reporting intoa enterprise architecture.
Structure of some kind.
Usually it's a board.
That say acrossthe organization, this is the
direction we're going in, right.
This is where we're vested.
Then great.
But decisions come slow.
In that case, you've gotall kinds of.

(10:11):
Reviews and approvals andapprovals on approvals,
et cetera.
So I think there's a little bitin the podcast later, that way
we could kind of touch on how toexpedite that.
But yeah, I've seen both sidesof it, but mainly,
I've only seen theone side of it, which is not the
good side of it.

Brian (10:26):
Do you have any stories about when a solution architect
either killed or saved a project

Om (10:33):
it's that, yeah.
I have an example of both.

Brian (10:36):
Oh,

Speaker 7 (10:36):
boy.

Om (10:36):
Again, without naming names, I will say, I'll
lead with the good first, right?
Of this one enterpriselevel architect.
That wasn't his title by theway, but he could
think beyond whatthe team needed, beyond what the
domain needed tothe organizational level.
He took the time to understandorganizationally

(10:56):
where we're going

Speaker 6 (10:58):
Yeah.

Om (10:58):
And to his credit, he came back and said, this is
a cul-de-sac.
We're not pursuingthis because, and
he approached theCIO with this plan
real simple, likeone slide deck.
And he said, if wego down this path, here's what's
gonna happen here.
The alternativesand here's why and
the CIO approved it right away.
So the whole organizationpivoted away from the current.

(11:21):
Path that they were on forthe better.
I might that it turned out sixmonths later I've
come across that,which is somebody
who is not only just thinking,well, here's what I'm hired for.
I'm gonna do just that.

Brian (11:32):
What was the size of that organization?
I'm just wondering.

Om (11:34):
It was a large organization by any stretch.
My point is theentire org changed
direction becauseof this one person
charting a path forward, right?
So kudos to them, right?
For coming up with it.
Well, he went overand beyond what he
was hired to do.
And I've, that's only happenedonce in my career.
Now it's go to the other side.

(11:55):
People that havethrottled projects
or programs or initiatives.
I already alludedto some of that
earlier, which isthey come from a
given background, so they havepenchant, is that a French word?
Tendency to say, listen, thisis what works.
I like this tool.
We're gonna usethis tool, right?
We need this.
And somehow they managed towin over their superior to

(12:16):
kind of sway the decision theirway and make the
investment if it'sa new thing and,
and go down thatpath only to find
just a short timelater, relatively
speaking, a year or so that theyactually are in a cul-de-sac.
Yeah yeah.
So I've seen that way more oftenincluding in one case where
the architect in question, theydeveloped their

(12:37):
own solution thatthey thought could
plug into this.
So here's a new.
You know, weirdshaped Lego brick
that I think is gonna plug invery well with the rest of your
Lego bricks.
Yeah.
And you need mine, right?
and they entrench themselvesthat way.
even though it turns out that'snot the best solution for the
org, but once you go down thatpath, once that train, starts

(12:58):
rolling, it's hardto pull it back.

Brian (13:01):
I'm starting to suspect that trains are just
bad analogies for softwaredevelopment.

Om (13:05):
If you're on an Agile release
bus, let us know.

Brian (13:08):
So if you can't find a spot two weeks out
on your solution architect'scalendar, that should be a red
flag you have a permissionslip dispenser as a solution
architect, by the way.
Not, not someone that's thereto help you.
I could levy thesame criticism at
product managers so I've got,I've got three takeaways
that I wrote down for this.
One is number one countthe meetings.

(13:28):
How many of them have todo with like, reviewing and
approving things versus enablingand teaching and helping
and mentoring.
Right.
And I think a lot of this can bedone you don't need a lot of
review sessionswith your solution architect if
they're built into your backlogrefinements.
Yep.
You know, if they're, ifthey're way ahead of the
daily hustle and grind, there'sno reason for them to be these

(13:50):
ticket dispensing machines.
Yeah.
like a lot of whatmy experience.
. But let's move on.
So are they creatingdocumentation that teams can
self-serve?
Are they understandingthe systems?
Are they helping everyoneunderstand the systems?
Or, or again, does everyonehave to go back to them for that
tribal knowledge?

Om (14:07):
My experience has always been they will ship
you of a PDF from EnterpriseArchitect, and it's such a high
level PDF that itdoesn't make sense
at the team level.
So you say, well, wheream I in this?
I'm this little box over here,so can you expand that out?
And they go, well,let's talk about

Brian (14:24):
Let's talk about that.
Pull meeting together.
So exactly two weeks out.

Om (14:27):
Two weeks out's, right?
Or more in the meantime,you, whoever, whatever your
role is, right?
You've gotta deliver.
You've got a team that you'reworking with day in, day out.
So there is that.
But the other side of it isthat if you have an organization
where these peoplehave a platform,
like an enterprise architectureboard, yeah.
Are you invitedeven on a request basis, right?
So you don't have to go to everysingle meeting that they're

(14:48):
talking about.
But when it concerns your areaof work, are you
invited into that discussion andare you given the
ability to unmuteand ask questions?
If you're not, there'ssomething else going on here.
Yeah.

Brian (15:02):
So let me maybe like, now it's time for the, this is what
I think I heard, What I think Iheard was you, you, you ask your
developers, what decisions canyou and can you not make without
the architect?
Because again, like if, if yourarchitect just like boxes the
team in to be likeyou, you can't
make any decisions without me.
And like at that point do webelieve in the lean startup?

(15:25):
Like, do we believe in whatEric Reese wrote?
Because at that point youjust found a bottleneck.
And like if we, if we'rein bottleneck territory, and
I feel at the point where we getinto this kind of
territory, it's time to startasking, can we fire this person?
or if we're in this sharedservices kind of model, can we
just not put anymoney into paying
for this person'stime and just go

(15:47):
hire our own twosenior developers
on the different teams that canactually talk to each other.
And then we'llsend our developer to your staff
meetings or to your developersync meetings or whatever you
have architecturereview meetings or
whatever you have.
And then we'll hire two people.
For the cost of what we payinto a pool of, of a solution
architect.
Right.
To, to just havesomebody do that job for us and,

(16:09):
and, and talk to each other indifferent teams.
Because everything that we justtalked about in this category
still I don't see, I don't seehow the takeaway here is not
like, just talk to each other.

Om (16:19):
Yeah, absolutely.
I mean the symptoms, right?
So when you're blocked by somesort of decision
that the solutionarchitect has to
cost, and like yousaid earlier, the
calendar's busy.
Yeah.
I mean that, there's thatside of it.
The other side of it is you'renot given the autonomy in any
way, shape, orform to do even an
experiment yeah.
With something that theyhaven't blessed.

(16:41):
Right.
So they're saying, well, stop donot pass, go, do
not collect 200.
And if you try todo anything, go
straight to jail.
It's like, eh, it's not agood scenario.

Brian (16:51):
So we've given you a couple things in this category.
I mean, we could stay on it,probably the whole podcast on
category number one, but we'regonna move on because we got
places to go.
Has your experience withthis been as painful as mine?
I would like to know inthe comments.
Let me know, please.
So in the meanwhile, it wouldn'tbe fair on the arguing Agile
podcast if we didn't ask thequestion well, who, who owns

(17:11):
the technical decisions?
Maybe the organization.
Has some real trepidationabout putting the final decision
in any one person's hands.
Maybe they've gotten burnedbefore , so what I'm saying is
your product manager, theywanna ship fast.
Your solution architect, theywanna build it, right?
They wanna buildthe best version future proof
version they can.
So when those two thingsconflict, who gets the final?

(17:33):
Say

Om (17:33):
what, what a fantastic point, right?
Who does get the final say?
I think in most organizations,unfortunately, under the guise
of delivering secure products,or products that
scale up and are.
Robust.
It's the technical people,the technical architect that
gets to really have a say inwhat's going on.

(17:55):
The product manager could comeback and shout there, still a
blue in the faceand say, we have
to do this becauseour competitors are doing this,
et cetera.
But it doesn't matter becausethese people are really the
gatekeepers at that point.
So, yeah, I agree.
And you know, I think architectsthey, they love to say, okay, we
can't go because,and they'll give you a long list

(18:15):
of reasons, well, wouldn't it bebetter instead to
say, well, here the real, maybehere are the reasons, maybe
they're right.
What are we doing to solvethose right now?
Right?
Because we gottaget to market by a certain date.
That last piece.
I, again, in my experience hasnot been it's not
been prevalent, it's not beenvery forthcoming
from these people.
And they just simply sit backand go, it's gonna take what

(18:37):
it's gonna take.

Brian (18:38):
So your product manager, they want, they wanna ship fast.
Your solution architect, theywant to make sure everything is
built right andall the edge cases
are taken care of.
when these two things come intoconflict, who gets
the final say?

Om (18:50):
The final say.

Brian (18:52):
It's like the final countdown.
Yeah, yeah, yeah.
With like, with lesskeyboards count.
Yeah.
So I'm gonna gostraight to let's
reference the HolyMarty Kagan of Empowered 2020.
Product managers should ownoutcomes.
Engineers own implementation.
That's what he says in thebook, don't throw stones at me.
That's what Marty Kickin says.
Go throw stones at him.
So architects, I think the claimthat you can make is architects

(19:14):
should enable both and notoverride either one of those.
outcomes, implementation,architects should be the bridge
between those two things.

Om (19:24):
Yeah, I agreed with it and I haven't found a whole
lot to kind of disagree withsince then.
So I'm gonna go with that.
I'm gonna say yes.

Brian (19:32):
You're going right into the steelman because the
steelman is two points.
So he says architects seeacross teams.
Yeah.
And product managers onlydeal with their one roadmap
or backlog.
Oh, and also like the technicaldebt from bad decision , that
costs us millionsin the long term.
and also it affectsmultiple teams.
So I cannot allowyou, Mr. And Mrs.

(19:52):
Product managerto be making these bad decisions
in a vacuum when they areshared components that affect
other teams.

Om (20:00):
Yeah.
And I, so, yes, agreed.

Brian (20:02):
Yeah.

Om (20:02):
Yeah, yeah.
So in this scenario though,offer, what happens is a
bit of angst here, right?
Between the, the, the productmanagement folks and the
architects.
Uhhuh, I think itbehooves product management to
think about this at a higherlevel, at the organizational
level rather thanjust but I need this yesterday.
Yeah, we could do that, butit's gonna come back and bite
your product or increment,whatever it is, right.

(20:25):
At some point.
A savvy technical architect or asystem architect should say I
understand the need to getthere quick.
However, we can'tdo that because we
have to build thisthing for us as a
company, not justyou as a product.

Brian (20:42):
Oh, listen, I'm a hundred percent on board with the pitch
that you're making right now,

Om (20:46):
but I know it's coming.

Brian (20:47):
However, oh boy.
Not to throw stones at productmanagers on the podcast where
I happen to be representing theproduct manager,
but most productmanagers, they're just trying
to get their roadmap there,deliverable their whatever over
the finish line.
That's not what you justoutlined is not their concern.

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

Brian (21:15):
I can't tell you how many times I've heard a product
manager say like,I can't believe Dome and Team
is taking inserttime period here
to do this quote.
Simple thing.

Om (21:26):
Oh dude, I come across that and whenever that happens, I
just say, wow, if you can dothis quicker, go for it.

Brian (21:31):
This is why Solution Architects is like, it's a made
up role and it'sterrible because
again, you couldhave gone to all the teams that
are affected by your changes andif you have to go to eight other
teams, maybe thatshould tell you something about
your changes.
You don't need one person tocome down from the mountain with
the tablets and be like, these15 commandments, smack, these 10
commandments.
You know?
You don't need one person to dothat, just talk to

(21:54):
the other teams.
About how you're gonna screw uptheir day to day
with what you're about to do.
Our architects love to talkabout this technical debt.
Anything and everything istechnical debt to
the point where the businessno longer even
believes technicaldebt is a thing because they've
screamed from the top of themountain so much
and you've erodedeven the concept

(22:15):
of technical debt

Om (22:17):
Well, I think when that happens
though, it's the onus is on thearchitects to be able to explain
it to the product folks in waysthey understand

Brian (22:25):
I understand.
But, most companies you'llnever get to that point
because there's this contentionabout where the architects sit
organizationally,where the product managers sit
organizationally.
And same thingwith the engineers
and the product teams and howpeople are incented it's very
complicated, so Ihave a few points
that I wrote downand I wrote these
down in a hurry.
So I don't know if these arethe best points.

(22:45):
'cause the firstone is, ownership
without authority creates blamewithout power to
change anything, so like that,that's, that's very scary that
that bullet point.

Om (22:55):
Yeah.
It's also something thatexists pretty much in every
organization because authorityis not something
you are granting to peoplethat need it.
We're getting in, we're gettinginto this whole org design and
sort of the, the org political.
Spectrum.
Well, a discussion here.

Brian (23:11):
I think it's an org design topic because
I think it's an org designpodcast because this whole, the
whole role is because you'vegot some issues in
your org design.
If your org design was on point,you wouldn't necessarily
need any of these people.
I mean, maybe you would havean enabling team again.
Apologies, folks.

(23:31):
Go read Team Topologies.
We did a whole podcast on it,arguing Angela 67,
it was a long timeago in a galaxy far, far away,
but it holds up.
Okay.
You got an enabling team.
That team should be ableto come in.
Supplement yourteam for a sprint maybe, or a
sprint or two or whatever, whilewe're helping you
get the work overthe finish line.
We're here working shoulderto shoulder with you, not coming

(23:55):
down from the mountain with sometablets one time
inscribed in stoneand that's it.
And we never come back andrevisit the plan.
Yeah.
And then at theend of the sprint review we come
down and say like, stamp a bigrejected 'cause
you didn't follow my tablets orwhatever, that that couldn't
foresee X, Y, Z and since yourcalendar was so busy, I never
came back and revisited thedecision 'cause there was no

(24:16):
opportunity again.
Like terrible.
The, the best architects, theycoach the teams through making
good decisions, architects kindof mentor people more than they
coach people to in my opinionthat's true.
but I guess the best ones wouldhave that coaching
skill and would be able to helpask questions through like,
Hey, why would youuse Kafka when we
have this fullyimplemented retic

(24:37):
instance and allthese other teams
are doing it, and.
It looks like you guys canjust slide into the middle of
it with very little frictionand you know, you just need a
key or whatever.
Yeah oh, we didn'teven know we had one of those.
Oh, well, hey, that'swhy I'm here.
Work with me after the call.
We'll sit down for an hour.
I'll give you a key, and thenyou'll be testing

(25:00):
it and showing areal demo by the end of the day.
Oh, I had no idea that waseven possible things like that
I've seen with good architects.

Om (25:09):
Good architects can also not just simply cast
decisions and saying, you.
No.
Or yes, or you know, well, theyreally, I mean, I
mean they, they, they actuallyhave the ability,
right, to speakto, to product and
everybody else inthe language that
they understand.
And not just like technicalarchitectural jargon.
So when an architect isbasically casting decisions,

(25:33):
vetoing, et cetera withoutthe ability to, to explain
trade-offs, perhaps if wedo this, this will happen or
else, right.
Those sorts of things.
Are they architectingor are they just simply
controlling?

Brian (25:45):
I think you just answered your own question right there.
I think I did.
So I had some timein this category,
Stubb Doubt for us to talk abouta time where I,
as a PM disagreedwith an architect.
And then to talkabout who won what
shift it would'vebeen, I, I'm, IM
trying to rememberany conversation that I've had
with an architect as a productmanager where the architect won

(26:05):
because like, thisis, again, this is
like par partially responsiblefor my move to
product managementfrom working on technical teams
where you're just working,the whole team works through the
architect, and inpoorly organized businesses, the
whole technical team works forthe architect on paper.

(26:26):
They have higher fire authoritybasically.
Yep.
Or, or, or at least like theycan heavily imply and, and
that's not even to mention ifyou have like a
contractor culturewhere a majority
of your people arecontractors and
then you have thissolution architect
who's like this VPlevel person who's like, I don't
like this one QA person on thisone team because they critiqued
my SQS solution.

(26:48):
They said you shouldwrite to SNS.
Yeah.
Before it gets pulled intoSQS and I don't like that.
and they can get that personbasically fired just because
they didn't like getting accusedof being wrong basically when
they probably were wrong.

Om (27:01):
Right.
Anytime that their authority ischallenged, that they feel a bit
like vulnerable in that way andthey can take it
out on the teams.

Brian (27:07):
But that, those are all my stories.
I don't, I don't have a greatstory in this one.
So I don't knowif your architect can say no,
but they cannot explain the costof saying yes.

Om (27:18):
Well, look, I think if they can't explain the cost of saying
yes, you've got no hope of themexplaining the
cost of saying no.
So I mean, at thatpoint they're not
really protectingthe architecture or looking
after that but they're reallykind of just.
Basically gatekeeping.

Brian (27:32):
I have some quick takeaways
in this category,just to throw some
out so that we don't just railin this category.
I feel it's gonnabe that kind of podcast where
I rail on every category and itdoesn't matter.
But I'm gonna try to throw sometakeaways in there
to help people.
There's three things that Iwould say that
you can try to do.
You can try to with yourarchitect, you can try to state
the customer outcome with themclearly as clearly as you can.

(27:54):
You should be doing this anywayin primary Yeah.
To say what, what are we tryingto achieve?
And, and by when, if you like, Iunder, that's a dirty word to
say by when, but maybe there'sa market reason or a window or
something trying to hit, Just beupfront, be like, Hey, I want to
try to do this.
By this time.
Okay.
Number one, just try to get thegoal out there
and be as clear aspossible about it.

(28:15):
Number two, you wanna try to, toname the technical
constraint and why it's riskyor not risky just
try to work with your person toclearly say, this is what we're
trying to do.
And then to clearly writedown, well, these are the
constraints because thenit opens up the conversation for
you to quantify the trade-offs.
So if we do it, ifwe rush to market

(28:36):
with this, we'll have a bunch ofgarbage over here.
We'll have to do a bunch of workor two sprints to
clean up whatever, whatever.
It's, but what is the trade off?
I might be running my stuff backup the ladder.
Sure.
And my director of product andVPs or whatever
might be like, wedon't care about
any of that crap.
Get us into thisnew market, ASAP.

(28:57):
I was at a business onetime, had a bunch of technical
problems and they were trying torenew a customer.
And a customer was basicallythreatening them,
saying, we won'trenew unless you
make your system quote, quote.
More stable.
Which was completely subjective.
I mean, it basically waslike, if we feel
it's good, right?
We'll renew that was like,there's no way
you can like run abusiness off that.

(29:18):
But at that point, the clockwas ticking on the whole
technical team.
It could have sunkthe company if a customer that
was like over 50% of the revenuefor the whole company would've
just gone away.
Yeah.
It like, there would've beenmassive layoffs, probably
most of which would've beenthe development team at that
point if we couldn't solve it.
There was none ofthis like living in the ivory

(29:40):
tower letting yourhair down like Rapunzel going
on at that point.
It was, everyone needed to worktogether to solve these issues.
And then if you'retracking data and
you're actually a data-drivenorganization, you escalate with
data, you bring actual data.
To have conversations withleadership and hopefully you're
in the type oforganization where
you could actuallyhave that kind of

Om (29:59):
conversation.
Yeah, I was gonnasay, you, those
organizations arealso rare, right?
Because they just simply lookat the people underneath and
say, you failed, and then theyjust turn around, look down and
say, you failed.
Those are fourtakeaways for you.
One was free.
We promised three, but wegave you four.

Brian (30:14):
I know.
Yeah.
Hey you know, this is fine.
This is like that meme.
This is fine.
This is all fine.

Om (30:18):
This is all good.
House is burning down aroundyou, but Yeah.

Brian (30:21):
Hey, what do you think is if you find any of these
takeaways useful, let us know inthe comments.
Let's take a differentperspective on this
arguing point.
What if product managers, whatif they're not innocent in
this situation?
What if, what if a problem isself-created?
That's the category we'reabout to go into.

Om (30:39):
Wow.
All right.
So let's just say for sake ofargument Yeah.
Most of the time when a solutionarchitect becomes a bottleneck
mm-hmm.
It comes down to the productmanagement.
It's product managers that.
Cause this to happen.
How about that?
Because they'reexpressing undue, unrealistic
deadlines to getout there, right?

(31:00):
For their own reasons.
Granted, but maybethat's the case.
So how how PMs.
Actually are the root cause ofsome of these architect issues
and problems.

Brian (31:11):
So I got the steelman shown on the screen

Om (31:12):
product managers are accountable for outcomes, not
technical debts that's thesteelman argument.
Yeah.
And then the second one is,architects should
proactively engageand collaborate with product and
not wait until they're invited.
So they are in the game from thebeginning, right?
Mm-hmm.
If you're in nor where thishappens, I would love to know

(31:34):
because I've notcome across many
except for maybe one that waspracticing safe as a framework
and safe has that elementwhere enterprise architects
are part and parcel of theproduct council.
So they're up there working withproduct before they solidify
direction for the product.

(31:54):
That's very, very rare.
It's academically,yes, that's what you're supposed
to do according to the blueprintfrom safe.
But in practice,again, not seeing
that very often,I'm afraid, folks.

Brian (32:03):
if I'm going to defend PMs for a second here, I feel,
well, boy, I feelslimy defending
all PMs right now,, if we're gonna be Rocky, I'm
gonna be in theircorner with the ice cube thing,
the cold thing.
I'm sure it has a technicalname for boxing.
I have no idea what it's butif I'm gonna be the cold thing,
it's like, hey, like sometimesUPMs, like you promise things.
Without ever engaging thedevelopment team.

(32:25):
Especially if you're with salesand there's no developers there.

Speaker 3 (32:27):
Oh, that'll

Brian (32:28):
be quick one, sprint boss,
whatever you say, we'll have itout in a week.
We can do that.
You know what I mean?
And then your developers arelike, what are
you talking about?
This thing's in the middle,in the core of the software.
Even if we bringdevelopers to that
conversation, theycould get stuck
in the same trap.
So I feel like abetter way is like
you involve more people and youget over that hump
the more people you involve.

(32:48):
And now we're back to like, hireyour organization.
and product Right.
Makes decisions.
but I don't know.
That's a weak argument to me.
'cause also if yougo back to that four letter word
governance, yoursolution architect
might be like, well, you can'ttalk to customers without me.
And because theywork for like two
levels above yourskip level, now
it becomes policythat no product teams could talk

(33:09):
to any customers without asolution architect in the room.
And now you're dead.

Om (33:13):
These kind of asinine rules become institutionalized
Absolutely.
After a while.
and that's how we do things heresort of thing and it completely
blocks agility.
These are things I fight day in,

Brian (33:24):
day out in my day job.
And, I've seenthem across almost
every organization at some levelwith regard to some decision.
there are certain areasyou can press on at certain
organizations.
Yeah.
And you'll get this.
The product team can make anydecision they want
except as long

Om (33:43):
as it's not technical,

Brian (33:44):
except they can't alter pricing.
Well, yeah, that's right.
I'm pointing something outthat just to be
a little over thetop to help people
understand, . Did

Om (33:52):
we do a podcast on who should we doing pricing?
We certainly did.
We did, we

Brian (33:55):
did.
And I will search for it likeit was arguing Agile 236.
Why product managers shouldown pricing, not sales or
execs or finance We talked aboutthe solution architect being
basically the, the chief, noofficer, and why
that's a problem.
If, if the PMs are complainingbut then treating

(34:16):
the the developerson the team or the architects or
whoever as like order takers.
You know, like Ithink about the, the super high
level skip level.
Like, just get it done.
I don't care what it takes.
I think about every executivewho's ever said, how hard can it
be to just add a little togglethat says light mode, dark mode.

(34:38):
Oh my goodness.
And you have no idea whatyou're talking about right.

Om (34:40):
I think this divide this organizational divide whether
it's functional or otherwise,is killing organizations.
There's gotta be abetter way I don't
have an answer necessarily, noton this podcast
at least, but youknow, how about a coalition?
How about forminga coalition that.
It's fickle and it, it'sunique for every case that you

(35:00):
come across.
Yeah.
But you bring the right peoplein for the right amount of time,
for the right things and theright reasons.
And that's it.

Brian (35:07):
I cut us straight to the actionable takeaway
because of your comment there.
Mm-hmm.
Which is discovery,not delivery.
You want to invite them.
So point numberone that's showing on the screen
now for you.
Yeah.
You want to invitethem, the meaning the solution
architect, you wanna invitethem to discovery through the
discovery phase.
Yeah.
I'm not gonna go into it.
We we probably could do a wholepodcast just on
that phase of theleast you can do,

(35:29):
I mean, this is the most minimalthing you can do.
You listen.
Oh, they never show up toany my things.
I always invite them.

Om (35:36):
Yeah, it is a difference.
let's, there'll be time.
They have an accountabilitythere.

Brian (35:39):
There'll be time in the podcast to talk
about that later.
Yeah.
About that.
Accountability, but when we'retalking to customers, we've made
them available.
Same thing is like sales.
When sales is meeting witha prospect and they put me, the
product manager on is optional.
I can choose to not show up totheir new sales prospect, but I
mean, what, whatam I doing that's more important

(36:01):
than that?
I mean, can youtalk, do you have
the teams and be like, oh, timeto sit down and talk technical
details, whatever.
Can you push that back a little?
Like I know it might impacta daily scrum but I'm like,
there should be an order inmeetings of like
number one, we'retalking directly to a customer.
Number two, we'retalking to other teams to decide

(36:22):
something between the two of us.
Number three, we're just talkinginternal to the
team, number fouris a one-on-one or something
like that.
there, there's anorder that you can
kind of work out.
, And maybe that's aworking agreement.
Maybe a top level coach can helppeople understand
like hey we canmove the meetings.
There's no cost right.
I guess this wholediatribe goes back
to what is the business contextof that thing and

(36:45):
did something witha more important
business context come up becausewe should respond
to that quickly again, there's alot of people I
even saw like I'vebeen watching a lot of stuff on
LinkedIn recently, like cryingabout Agile and like throwing
stones Agile and whatever.
If we got businessagility at the forefront of
our minds, we should justknow the order instinctually,
just know the order and just belike, wow, I'll kick this out.

(37:07):
I'll make, I'll maketime, I'll make time for that.
That sounds important.
I know it's important.
We'll make time to, toget that done.

Om (37:13):
Yeah.
Fully concur.
I think the order is probablysomething like prospects that
you are farming for first.
Because why wouldn't youwater your seeds?
You've planted That this makesno sense to me to ignore that
customers you've already got,they've signed up.
Don't ignore 'em, but that's thenext level for me.
and then there's like theorganizational looking to your
left, looking to your right.
your team level follows afterthat what's at the

(37:35):
bottom for me is.
Your EAB, et cetera, becauseall you're doing is making
technical decisions thereright now.
Do you have to make them rightnow at the expense
of those other layers that wejust talked about?
I suspect not, right?
Yeah.
Because on the wholeyou direction isn't gonna
change a lot.
Mm-hmm.
It's probably small decisionsat that point.

(37:55):
But granted, there are someopportunities where you're
talking about larger leveldiscussions on what tool
to embrace, et cetera.
Those are fairly far and fewin between.
So it does makesense and yeah, if
your organization doesn't havethat kind of a culture, you
should work with a coach to, tohelp instill that.
Right.

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

Om (38:27):
You're, you're actually precluding a really.
Important you know, opportunityfor your architect
to ask questionsof your prospects or customers
directly, not filter throughyour lens, right?
So it's not gonnabe something you
can talk to them after the fact.
Like that's better thannothing I guess, but it's not
the same, right?
You need those peoplein the room.

(38:48):
So one of the things as aproduct manager you could
do is this.
You gotta talk toa customer or, or.
A prospect, doesn't matterwhich the meeting
that is set up, ask the otherparty the prospect
of the customer to bring theirarchitects into
the call that way your architectcan ask questions
and get immediate feedback.
Mm-hmm.
'Cause the alternativesare a lot worse.
Things get filtered andsenior develop team leads or

(39:10):
whoever it is.
Yeah, exactly.
Whoever it is that's neededat this point so I mean, my
point on this is, as a productmanager, you should definitely
be thinking aboutthis and how to short circuit
this whole communicationconundrum.

Brian (39:24):
Well, I mean, that's a great wrap for this category.
Is there any other things thatwe left out of this category?
If you're listening, let usknow the comments.
Absolutely.
We've establishedthat everyone's guilty in
this category.
That's what we've talked about.
So now let's talk the threeconversations that actually
can help solve slash fix, maybethe relationship unmuted.

(39:46):
Alright, so most productmanager slash solution architect
conflicts, they're notabout technical disagreements.
They are about threeconversations that actually
never happen.
That's what the disagreementis about.
The Patrick Lencioni fiveDysfunctions of
a Team, the 2002,trust comes from vulnerability

(40:08):
based conversations about roles,goals, and fears.
I'm gonna transition intothe Steelman side of this
conversation.
Roles and responsibilities,they should be clearly
defined by the organization ateach organization
that you're at.
So if you're a product managerat, at Brian and Om software
development company , andthen you go work
for Acme Company or whatever,you should have a conversation

(40:30):
with them about exactly how therole is different
from the previous.
Brian o softwarecompany where you
basically own theentire outcome.
Everyone basicallyworked for you, but they didn't
really work for you, but youhad a, you know what I mean?
Right.
And now you're at this newcompany where everything's like
a project plan and you're theking of the world.

Om (40:48):
So I think there's two things
that fundamentallyunderlie, rely the
ability to be ableto do this, right?
Mm-hmm.
One is to own thefact that you have
to be vulnerable and say let'shave a candid conversation.
That that's one, which again, weknow it's not that
common, right?
Because people come in with,this is the second point
I wanna make.
Yeah.
Egos.

(41:08):
You gotta checkthose at the door.
'Cause I mean, ifyou, if you come in and say, I'm
the the U, but senior productmanager, and it's
like, yeah, come on seriously.
So those two things have tobe preconditions to this, right?
Be vulnerable, lose your ego.

Brian (41:24):
You don't know, but you just
hit on a whole different podcastI wanted to have about, Ooh.
Being humble.
Being humble.
Being humble.
I like it.
Yeah.
A lot of peopledon't, they don't
know what being humble means,what does being humble mean?
Does it mean like,shutting up and
like not startinga fight, actually,
that's not whatit means you know?
What it, what it means is, bringing up that you disagree
with someone and not being ajerk about it.

(41:46):
Bringing up thatyou know, you're really worried
about someone because of the waythey're acting.
'cause they're a giant alphatype personality.
And you're concerned aboutit and you really want to talk
to 'em about it to understandwhy they're that may like
maybe somethinghappening at home.
Maybe they're in a bad place intheir life, you
don't know, , it'snot, you're not trying to win
one over on them.

Om (42:06):
This is where you come in with your empathy.
This is where youkind of divulge
away a little bitfrom this ethos of well tackle
the problem, not the person.
Well, look, you have to tacklethe problem.
Sure.
But it's the people that aregoing to work on the problems.
So, to your point,maybe these people
that are involvedor person that's involved in the
picture here has somethinggoing on in their personal life.

(42:30):
It behooves you to at least beopen to have that conversation

Brian (42:34):
The other steelman here is good, good professionals
shouldn't need relationshipconversations to do their job,
which is by the way, terrible,terrible point.
Hey, you're a professional.
You should be ableto read between the lines zone.
Yeah.

Om (42:49):
Yeah.
I don't know howI feel about this,
because first ofall, if this were
true, we wouldn'thave any problems
in the world so let me tackle itthe opposite way.
Okay.
Alright.
When do you ever get taughthow to do this?
Right?
You don't learn this in college?
Oh, you're a professional.
No, you're not.
You learn academicstuff in college.
So you come to work and whereat work do you learn about.

(43:11):
Being a good professional,you don't.
So here's how you learn.
You learn throughthe school of hard
knocks, right?
So you do something and ifit works, you get reinforcement,
great.
You'll do more of it.
Or you get pointed at forsomething and you do less of it.
But then every organizationalvalues, different traits and
behaviors and norms, right?

(43:32):
So how do you get to this point?
It is not a given.
It's not, there'snothing wrong with
seeking help here,and organizations should be open
to saying people that work inour org aren't perfect people,
and we should be providingthat support that they need.

Brian (43:48):
so again, as a product manager on the podcast, I would
like to take this opportunity topoint out that the
org chart, definestitles, reporting, structures.
it never defines how two people.
Actually collaborate underpressure if you could redraw
your org chart tosay, don't show me who reports
to who, show mehow decisions are

(44:08):
actually made inthis organization.
And everyone needsto be involved in all the
different tracks.
First of all, people wouldbe like, get outta my office
second of all, I don't even knowif they would be able to do that
because it's, it'sa very complicated
thing that I justasked for is show
me how decisions.
Actually get made.
And maybe, maybe you should dothat exercise at your work.

(44:28):
If I'm wheeling back to anotherpodcast that I want to have, but
there's no way tohave it without
being a completely unhingedI actually did have a
conversation in the takeawaysand just to throw it out
here real quick,the conversation is a three part
conversation that I'msuggesting here.
It says you have a conversationand you ask the question, what
does success look like foryou in your role?

(44:50):
And you try to understandtheir situation.
So if you're like, oh, I think asolution architect
is a made up role and doesn't doanything and just
gets lunch all dayand takes a nap.
You would ask these things andtry to connect with the person
to say what, what does successlook like?
What is your biggest fearin this role?
Right, in this position withour teams and then you say,

(45:10):
well, how do Idisagree with you?
Productively what manner wouldbe the best for me to bring it
up, you know?

Om (45:17):
Yeah.
Again, all threeof those underline the need to
be vulnerable.
Right, right.
And also not havean ego, because
if you had an ego,you wouldn't be
talking to any ofthese things so,
yeah, absolutely.
I look how many times haveyou seen this happen in your
professional life?
Do let us know, but, because Ican tell you mine,
I can summarize in great detailon the back of a Post-It stamp.

(45:40):
That's how often I've seen this.

Brian (45:42):
You know, sometimes the conversation with
the architect likeit doesn't work because they're
holding back.
There's a difference betweenan architect who protects the
system and an architect whoprotects the teams
that they serve,and an architect
who's protecting their own job.
And let's talk about how to findout which one your architect is.

Om (46:05):
All right, let's keep going.

Brian (46:07):
Oh, the Nygard book?
Yeah.
Is that the one?
Yeah.
Oh, do you knowthis Nygard quote?
I know the quote.
I actually own this bookfrom 2017.
Do you wanna read this quote?

Om (46:15):
Sure.
So this quote again,paraphrasing great architects
work themselves out of a jobby building the systems and the
environment teams,that don't need
constant vigilance from them.

Brian (46:27):
Sorry.
Work, work themselvesout of a job.
Where have we heard that before?
that's so strange.
Someone said, working yourselvesoutta the job.
Please continue.
I'd love to hear more.

Om (46:36):
Yeah.
So that's Nygard'sthesis, right?
Yeah.
So let's get straight intothe, the steel
man argument here.
Architects must stay involvedto maintain system integrity.

Brian (46:48):
That's the first part.

Om (46:48):
Yeah.
So the system doesn't boil overlike water in a ca

Brian (46:51):
means like I have a lot of
problems with whatyou just said.
Please continue.
Gimme the second point and thenI'll push back.

Om (46:57):
Yeah.
Distributed decisionmaking leads to architectural
chaos.

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

Om (47:14):
exactly what it is.
and you can't trust them soI'm not gonna let them.
Oh, so it's this, this is allabout maintaining control.
Exerting and maintainingcontrol.
Oh man, that's what thisis about.

Brian (47:24):
Sorry y'all.
I don't think I can, I think Igot a headache.
I gotta Oh no, gotta cutout early.
You're like that.
So if those are the best pointsagainst like, what
a disappointing category.
What can a solutionarchitect do in this category?
The best solution architects.
Okay.
They help the teams createarchitectural documents, or
at least amend they build ontop of wood, supplant them.

(47:46):
Yeah, absolutely.
Yeah.
And they, and they help theteams connect to, to potentially
artifacts that they don't evenknow exist because
that could happen.
It's like, oh, we didn't evenknow you were using Redis when
we came up withthis, like queuing home, brewed
queuing function each successfulsolution architect helps
the teams make better decisionsand go through the approval

(48:08):
process in the organization.
They help them through theapproval process.
I was at an organization onetime that was very
like the way we think of projectmanagement, in terms like you
had to go in front of a board.
They had to review your changesyour tests in UAT the results of
your feedback todecide if you, and
this is software development,by the way, the solution

(48:30):
architect really could becomeyour advocate.
They are like a lawyer at trialcounseling you.
If you decide to be your ownlawyer, they're helping you do
the best job you can right.
Arguably they, they could bedoing it on your behalf to the
group, but most organizationsdon't work that
way but the pointis that like they are expertise,

(48:53):
again, going back to arguingAgile 67, 6 7 team topologies
They're a member of the enablingteam loaned to your team for
a period of time till youclear a certain
decision or hurdle or somethingblocker yeah,

Om (49:08):
they're really catalyzing the discussions.

Brian (49:10):
Yes.
Yeah, absolutely.
Yeah.
And their valuecan be measured by
how many outcomesthey help you get
through speed of decision makingis one thing.
The speed.
Yeah, absolutely.
But I feel like the opposite is.
Probably true for most peopleis that their delay of decision
making is how theymake an impact.

(49:30):
Negatively on your team andthen the larger organization,
it's just that those metricsare not tracked it's harder to
hold these folks accountable.

Om (49:40):
Yeah.
They tend to kind of installthemselves in these
organizations and create theseindispensability.
Right.
You can't do away with them.
You have to have approvalprobably times two or three from
these different layers of the,the Solution Architects that
you have place with differenttitles perhaps, but Yeah,
absolutely.
So what we're saying on thisspecific topic is helping

(50:02):
architects.
Create useful art artifacts,documentation to help the
team hoarding architects, on theother hand, they
create bottlenecksand dependencies on themselves.

Brian (50:14):
That's absolutely true.
Yeah.
Yeah.
Your architect who they, theycan't take two weeks vacation
without everything falling apartor grinding to a
halt they're the bottleneck thatgold rat warned everyone about
ooh, years ago, Imean, decades ago,

Om (50:28):
Eli Goldratt.

Brian (50:29):
You've made yourself into a single point of failure, why
did you do that?
Why would you do that?
I mean, ego is one side of it.
I think the complete swingand the opposite
direction side ofit is ignorance.

Om (50:43):
Yeah.
The ignorance side of it is, isnot just simply a passive thing
where teams will say, thisis above my pay grade, right.
Or our pay grade.
This is for the EA to decide.
This is the other way to so the,these SAs, EAs
basically feigningcomplexity saying, this is too
complex for you.
I'm better position to dothis, right?

(51:04):
Yeah.
By the way, I'mout for two weeks,
so this can wait.
Okay that, that is very true.
I've seen that way more often.
The teams will just be likereally struggling to move along
without this kindof approval and it's not a tacit
approval, it's anabsolute approval.
Like you can't move forwarduntil you get my approval
in writing and they have builtprocesses and workflows in

(51:26):
place to kind of stem the flowof ideas and forward progress.
Because these SAssay they are the
ones that are themost important cog
in the machine.

Brian (51:38):
Well, let's step back for a minute and talk about
what are some things you canput into place.
To know this is a problem toclearly identify or maybe get
over the problem.
there are four takeaways I gotlisted here on the screen, which
is number one.
You can give themthe documentation test.
Ooh, what was this documentationtest, Brian.
Hey, calm down.
Can a new engineer can,can you onboard a new engineer?

(52:00):
I mean, or reallyproduct manager, especially
if they're a technicalproduct manager.
And have them.
Understand your systemarchitecture without having
to have a deep one-on-one withyour architect, your system
architect off to the side tohold their hand

Om (52:14):
who knows.
Yeah, you're right.
You're right.
The documentation test is real.
So if you can get an engineerto understand things that are
documented first, second time,that's great.
Right?
Product managers, yes.
You who really I think isalso critical.
Here are incoming bas do theyunderstand not
just the technical diagrams.
Good point.
Good point.
But the business logic workflow,I mean, you're not gonna get

(52:37):
everything from a diagram, butyou're gonna get the gist
of it, right?
Yeah.
So there is that test aswell, right?
It's an integral part.
It's still the documentationtest, but do PAs.
Can they grasp what's going on?

Brian (52:48):
That's a good point.
The next one I hadwas the decision autonomy test.
The point I had here is youas a product manager, talking
to your team.
What technical decisions canyou make without
having to involve the architector the solutions architect or
the solutions engineer,whatever, whatever you
call 'em, right?

Om (53:05):
Yeah.
This one is a tough one though.
I'll tell you why.
So we are talking aboutsenior engineers here, right?
Not product.

Brian (53:10):
Oh, you talking, I was gonna say the product people
don't have.

Om (53:12):
The technical knowhow to understand decisions
that pertain to the ities.

Brian (53:18):
Sometimes when the solution
architect decides we're gonnado this, not that they not
only need to be able to explaintheir reasoning.
Because I, the productmanager, as the
representative ofthe business, I have to be able
to explain theirreasoning to many
other people inthe organization.
If it's not clear, if it'slike, oh, because I just decided

(53:38):
I can't sell that to anyone.
I can't use that.
That's not good enough.
And I only bring that up becausea lot of solution
architects thatI've worked with.
They go back to that reason andthey don't want to expand on any
other reasons.
They just wannahang their laurels on because I
said so, and I'm the architect.

Om (53:57):
It's too complex for you to understand.

Brian (53:59):
Yeah,

Om (53:59):
but I mean, look, again, except it's not, but not for you
specifically yeah.
But I'd say product managementin general, we're
gonna assume eventhough technical
product managersaren't at the same
level of technicalknowhow, and I know put spa as
a, as essays,

Brian (54:14):
Like even with executives,
that doesn't fly.
They can explainit in terms they

Om (54:18):
You gotta speak their language so, yeah,

Brian (54:20):
I understand.
But it doesn't happen.
Okay, so we did a podcast it wasarguing Agile 235, changing
your message, adaptive versusmanipulative communication
arguing Agile 2 35.
This is borderline, but 235 is borderline what we're
talking about.
It's not exactly,

Om (54:37):
no, it's not what we're talking about,

Brian (54:38):
I will tell you, I only stopped to search
for that podcast because I've.
worked with many a solutionarchitect who will
try to bend the message to fittheir narrative.
Sure.
Of like, oh, well the productmanager was reckless because
we said we had this technicaldependency or whatever, and
he decided to dowhatever anyway.

(54:59):
Yeah.
Not exactly, because you toldme that your connection pooling
in the database wasn't that biga deal and it totally should
scale to a hundredconcurrent users or whatever.
If the architectis out for a week
does our businessstop functioning?,
I'm aiming this at the solutionarchitect.
I could aim this at anyoneelse certainly.
But I feel these folks that worktheir way into this position,

(55:25):
right, between teams, If theydisappear for a
week, I think thewhole program does
grind to a halt and either theprogram grinds to a halt or
a lot of stuff gets escalatedover and around the quote normal
business process.
Yeah.
You like, well, VPOm said we could do it because
solution architect Brian is out.

(55:46):
So he just approvedeverything while Brian was out.

Om (55:48):
If you have organizations where Brian's already put in
place all the things we talkedabout just earlier, right?
All the documentation, etcetera, and the
knowledge sharing, it shouldn'tmatter That Brian's out for a
week or two weeksbut yeah, this is
what we're saying.
This is the vacation test.

Brian (56:02):
I can't think of anything we left outta this
category, but ifthere is, please let us know.
Yes, please do.
for the final category on thepodcast, we have
to talk about whenyou absolutely must escalate and
then how to do itwithout killing your own career.

Om (56:18):
Alright, so let's get to this, right?

Brian (56:20):
So in the Radical Candor book, kim Scott says, escalation
isn't tattling.
It's caring enoughabout the outcome
to involve people who can changethe system.
That's a wild statement, whichleads me to believe we need
to do a podcast about that book

Om (56:35):
it's a lofty statement to say the least.
But yeah, good luck

Brian (56:38):
Listen, if you can change the system and be running up
that hill, like that's, I gotred texts on a
screen most peoplewill say like, Hey escalating
a relationship problem.
I'm like, just doesn't getalong with Brian to leadership.
That's gonna make you look bad.
it is 99% of the time.
Yeah.
Unless HR already has a thickfile with two Cs, a thick,

(57:01):
a thick file.
On that other person.
sorry.
Like it's gonna make you lookbad and there's just no reason
to put that on your career.
Right.
the other side is like, HeyOm, you're a professional.
I expect you to resolvewhatever it is with the other
person without quote, botheringleadership.

Om (57:20):
Yeah.
So escalating with it, itdepends on your org structure or
your org culture.
You could do that or if youcould do that, but if escalating
reasonably frequently doesn'tbode well for you.
You know, HR is going to putyou in a bucket.
It's the right thing to do when.
You've tried things and youhave evidence.
Don't just go in and withoutevidence and say here's the

(57:42):
problem you triedsomething and you can absolutely
back it up.
Okay, escalate.
That's fine.
But don't do that all the time.
Also, don't escalate theperson escalate the problem.

Brian (57:52):
Oh, good point,

Om (57:53):
How does your organization perceive and handle such
escalations, right?
Mm-hmm.
That should be yourstarting point.
So,

Brian (58:00):
So I got the points here.
They're on the screen here.
Okay.
So in order, you said, don'tescalate the person, escalate
the, the decision making processis broken or the
issue that came upbecause a current
process is broken.
So you're basically escalating.
We need clarity on how toresolve this.

(58:21):
Thing that happened, you'renot saying, we need you to make
a decision that this person'sbad, or you need
to call out this person as beingbad or whatever.
Right.
Because that's just notgonna happen.
And I have to go back earlyin my career for me doing this
kind of stuff.
'cause earlier in my career myattitude is like,
this person sucks,like this super unresponsive.

(58:41):
Like they're bad at their job.
I have to kick their back tothem two or three times.

Om (58:45):
Say tackling the person, not the problem right there.

Brian (58:47):
It would've been tough advice
to give to myself at that pointin my career.
Now, where I'm later inmy career.
I would go over and sit withthat person and be like, I'm
here to sit with you until we'veworked through the
issue, you know?
So that you know that likeyou need to dedicate your full

Speaker 6 (59:03):
Yeah.

Brian (59:03):
Brain power to it.
Or maybe I can help you come offof the decisions
that you're on ordelays or whatever if you've got
a lot of stuff going on, I'llsit with you and work through
that with you frame it as weneed clarity on how to resolve
this situation,not blaming it on
the person, again,building on the previous step.
And then the final pointhere on the screen is when

(59:25):
we disagree.
. How should wemake this decision
when we disagree?

Om (59:29):
I'll tell you how, how it went for me when this happened.
Early on, very early in mycareer, I did escalate and
I did tackle the problem,not the person.
But they said, well,who's normally your go-to?
Right?
So at that point,you have to say the name, which
I did, and theysay, well, they're
indispensable.
Yeah so here's what we'regonna do.
We're gonna giveyou somebody else

(59:50):
who will help you.
And that somebody else was thisperson's peer.
and they were both from thesame nest.
So this guy made the samedecisions as the other person
would've made.
Course it didn'tget me any further but it was a
lesson learned from me, whichis understand your organization
and see which way you wannago after that.
So again, that ofcourse you learn to course this

(01:00:11):
is one of those Ichalked it up to.
it's an experience thing.
lesson to learn.

Brian (01:00:14):
Alanis Morisette said, taught us you live, you learn.
To wrap this category, ifyou're afraid of escalating a
broken process, because it mighthurt someone's feelings, like
at that point youcare about being
liked or stepping on toes orpolitics too much.
Yeah.
More so than you care aboutdelivering

Speaker 5 (01:00:31):
value.

Om (01:00:32):
Absolutely.
Or you just careabout preserving your own job.

Brian (01:00:36):
Okay.
I'm going to sail through thetakeaways here.
Document the pattern.
We already talkedabout documenting.
You might want to quantify theimpact if nobody else has, more
likely they haveto say that like,
Hey, this, this decision processhas delayed X amount of
features for y amount of weeks.
Affecting the amount ofcustomers pot, even if it's

(01:00:57):
all potential.
At least you're puttingsome numbers behind that.
Yeah.
You're dealing with the problem.
You're not blaming a personat this point.
You're just saying, Hey,because we had to delay
these decisions because of thisorganizational process.
That's what we're saying.
I know it might come across,especially when
ego gets involved, it might comeacross as, oh, this one person
hasn't made the decision or wenton vacation, or whatever it is.

(01:01:19):
Yeah Hey, hey, hey, I'm nottalking about that person.
I'm talking aboutthe organizational
process that we'refollowing now.
That's what I'm talking about.

Om (01:01:27):
Yeah.
Just aim for a onepager that just says The cost of
delayed decisions or decisionsnot made.

Brian (01:01:32):
And then proposing a fix is
as easy as what Ioutlined, when I
said you just askfor the decision making process.
When it's unclear,you ask for that
to be clarified.
Yep.
Yeah.
document the pattern you needthe more examples, the better.
Three examples is pretty good.
You quantify thecustomer impact, you propose a

(01:01:53):
fix, you know?
'cause there's alot of psychopaths
out there that say, Hey, don'tbring me problems.
Only bring me solutions.
Only bring me solutions becauseI can't be bothered to think
That's right.

Om (01:02:02):
Exactly.

Brian (01:02:03):
Alright, so this one, what
do you think aboutthis category?
What do you think aboutour solutions?
Here are three very simplequestions here.
Let us know in the comments.

Om (01:02:12):
Yeah.
And if you're an S.A., pleasegive us some thoughts that
you have aroundthis podcast too.
But also don't forget andsubscribe.

All Episodes

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

Episode Transcript

Popular Podcasts

Las Culturistas with Matt Rogers and Bowen Yang

Crime Junkie

The Brothers Ortiz

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}AA240 - Why Product Managers & Solution Architects Are Always at War (And How to Fix It)