Speaker 1: Welcome to another episode of the Ventures and Devils. We're
highly competent professionals here. Yeah, so I'm your host Will
Button joining me in the studio today, Warren Brod so worn.
Speaker 2: Hey, thanks for having me back.
Speaker 3: I know we were saying we're competent tech folks, but
you know, we were discussing before the call, how you
had some MacBook problems. Someone else on, you know, one
of our additional hosts had some microphone issues. Was nearing
one hundred degrees celsius as far as CPU goes. So,
you know, good times all around.
Speaker 4: Right, We're doing great.
Speaker 1: Yeah, So welcome back, Jillian.
Speaker 2: Happy to have you back on the show.
Speaker 4: Thanks, I'm happy to be back.
Speaker 2: Yeah.
Speaker 1: Let's see if we can make it through one more
recording without any of us dropping out due to technical issues.
It seems like the gods are not in favor of
that plan, so.
Speaker 4: I don't know, we'll see.
Speaker 1: Yeah. So today we're going to be talking about how
to run your DevOps team from a management perspective. You know,
based on my experience, most of the time the teams
I've worked with have worked off of a ticket queue
where tickets come in, you grab them or assign them
and you just can you continue working working through the backlog,
and that's worked pretty well. But recently, like really recently,
as of last week, I made the decision to change
my team to working off of epics. And so there's
some like some of the background of why I did that.
We had a monster backlog Q and some of this
stuff is just never going to be a priority, which
is not unusual, but it made it hard to find
what was is it relevant or what should be should
be getting picked up or actively worked on. And then
my team's also a global team.
Speaker 5: So.
Speaker 1: You know, I'm not always around to answer questions or something.
So we have specific objectives for the fourth quarter of
this year. So I just created epics for each of
those each of those objectives. And so now everything that
my team work is working on should be either part
of that one of those epics or they should stop
working on it and move to something that is on
that epic. And so that's kind of the thought process
behind it.
Speaker 3: Genius, brilliant. We should have thought about this sooner, right, Okay,
thanks for tuning in.
Speaker 4: I'm sure of that.
Speaker 3: You know, it's interesting you bring this up because I
feel like it's been a theme for a bunch of
months now, bringing up how all the teams that we
have in an organization need to be run sort of effectively,
and the best way to do that is by doubling
down on things like team topology and focusing on Dora metrics,
or having unified alignment via some sort of OKRs and
having users that you collect feedback from and request and
put them in your backlog, et cetera, and then groom
that to focus on whatever your objectives that are going
to be. So like, going objective first makes a lot
of sense.
Speaker 5: I like that idea too, because it creates like context
around what you're doing, which I find is very important.
Otherwise it's so easy to get like bobbed down in
the details or this new library or this bug report,
you know, or whatever, and not keep in mind that, hey,
we need to you know, prioritize tasks based on what
actually needs to be done, and there are a lot
of There are a lot of factors in that besides
technical issues that I think are easy to forget. So
I always like the idea of epics because I feel
like it incorporates more of the big picture into each
one of the tickets as opposed to just here's a
bunch of tickets, go work through them, guys.
Speaker 3: I mean, I think one of the problems here is
like how do you decide what model should work best
for a team, And at least from my perspective, it
comes from what is the identity or core reason that
that team exists? And I think if you're changing the
model from we work on and let's just be clear here,
I think what we're saying is there are things that
need to be done in the organization and the way
in which they get done is one team who is
not responsible for that thing but needs help to get
that done, creates a ticket so that someone else who
knows how to do that work can actually do it.
And it's a very It resembles the support organizational matrix,
where you file a support ticket and someone else goes
and works on it. I think in the IT world
it's very common, especially in non tech org organizations, where
I need access to Heaven forbid this GIRA instance or
project and other technologies, or I need to requisition bare
metal machines or virtual machines for this service project or
whatever that I'm working on. So like I do understand
where that came from, and it does mean that while
maybe that's not the best model for a service oriented organization,
you can imagine even if it were and you decided
to move to EPICS, you're actually saying, we're going to
become something different, and maybe it's the thing that you
always wanted to be. You always wanted to be something different,
and now you have a working model that matches how
you want the org structure to actually function.
Speaker 1: Yeah, there were There was a pretty sizable sequence of
events that took place to get us to this point, because,
like you said, you know, when we were operating in
a support model, someone would file a ticket and say, hey,
I need this, you know, bare metal stints, and I
just don't happen to have those laying around idle. So
it took time and effort to get one up and running.
But then meanwhile, the team that opened that ticket was saying, oh,
we're blocked because of DevOps, and so my team looked
like shit, It's like, well, we just heard about this
request four hours ago, you know, like, we're not really
blocking you. You just didn't ask us early enough. And
so then we struggled for a long time to figure
out how to get the requests into our team earlier,
you know, so we could be ready and do like
a just in time delivery thing to throw out that buzzword,
and that didn't work either. But then we had this
input from like the company and the executives and the
senior leadership, like, here's what we're focused on for Q four,
this is mission critical for the company. And so each
of those translated to different things that the software engineering
teams are going to be working on. So I took
those and said, okay, well, if they're building this, they're
actually going to need a bare metal instance or a
Kubernetes cluster or whatever it is. And so I created
epics that align with the products that the engineering teams
are going to ship, and then the tickets in the
epics are the tasks that support that. And now also
there's a side benefit of that, I've got someone on
my team who's almost completely dedicated to that team, so
they can go to their scrums and chat with them
on a regular basis and have like this really in depth,
long lived conversation so that they're in the loop and
they start hearing about all the things that we still
don't know about earlier in the cycle, and hopefully that
is going to result in being to deliver the dependencies
for them in a like a near time fashion.
Speaker 4: I like that.
Speaker 5: The biggest takeaway of all this is that doing support
work is like playing telephone in kindergarten, right.
Speaker 1: I think it's even a little worse. I think it's
like eighteenth century mail correspondence, you know, where you break
out the feather quill and the ink and you write
it on parchment and then give it to the pony
ex bess writer and they take it to the dock,
or it gets put onto a ship and sales across
to England.
Speaker 2: I mean, I think you.
Speaker 3: Have a little bit of a benefit there because in
those scenarios you can almost ensure that both parties are
somehow communicating in the same language or context. And within
the tech organizations, we have what another team could be
working on could be so based in a contact or
jargon that you just don't understand because it's heavily abtracted.
Speaker 2: Away you know what you're even doing.
Speaker 3: So not only is there a confusion of the number
of middle people for that message to get to you,
now even understanding what the why is. And I think
One of the failure modes that a lot of service
based organizations fall into is believing that the fix is
clarity of expectations and communication by creating some sort of
slas like, oh, you need a bare metal machine. We
have a line item here that says the SLA is
like five weeks, and it's like you can just write
that down and think that, oh, everyone won't be happy
now now they know exactly how long it takes the
requisition one of these new things. But the reality is
that they of course potentially need it whenever they realize
they need it yea, and realize that they need it
to solve whatever problem that they're currently having, and they
doesn't they haven't necessarily planned out that far.
Speaker 2: Yeah.
Speaker 1: I think in addition to that too, that's assuming that
they actually ask for the right thing, which a lot
of times they don't. You know, a lot of times
the request comes in like hey, we need to deploy
this piece of software we build, and then you get
to look at it too, software and you're like, oh
my dude, this is not a Docker container. Like I
don't know what Google Search you typed in, but this
is not going to run a Docker container.
Speaker 3: I mean that's not even there's quickly a outlived it's
usefulness there, and I fear that the lms are now
even more effective than Google at returning accurate results, given
what the first few result hits usually are have nothing
to do with what you're actually looking for.
Speaker 1: Yeah, on a bit of a side note there, I
think it's Google now that does the AI generated response
right at the top of the page when you type
it in. Yeah, I found that to be helpful. Not
all the time, but there's been a majority of the
time whenever like that has actually been like, oh, yeah,
that's what I was looking for, and then I just
close the tab and move on. I close the tab
worn that's something that some people do.
Speaker 2: Things, I definitely close them.
Speaker 3: So, you know, let's let's let the record show that,
you know, I think we're just two different kinds of
people here. Will Because when I started seeing the AI
overview from Google, the first thing I did was I
created a style blocker using a block to eliminate that
element from my screen. And then I went to the
network tab and found the UURL that Google was using
to get that data, and I blocked it with my
browser so that neither the display nor the network requests
are executed for this data because I have no need
for it whatsoever.
Speaker 1: What if it's actually helpful, though, Yeah.
Speaker 2: I guess I'm just going to have to live in backwards.
Speaker 5: Reality, to live like a caveman over here with how
your AI response is?
Speaker 1: Okay ran over.
Speaker 4: Yeah, I don't know.
Speaker 5: It's been like a pretty even toss for me because
I find most of the time when I'm googling something,
it tends to be like something local.
Speaker 4: Like I was.
Speaker 5: I was trying to find out where the address of
the vet was that's like five minutes away from me,
and instead I got this like AI response about like
all the different reasons why you would need to, you know,
take an animal to the vet, and I was like,
I already know I have the appointment they're getting a vaccine,
Like I don't, got like I don't need this, and
then I had to scroll like all the way down
to just get it.
Speaker 4: Was very silly. So anyways, I find it's about fifty
to fifty. Sometimes it's helpful.
Speaker 1: Yeah, that's fair. So what are the uh bringing us
back on topic here? What are the pitfalls to running
a deadlops team using epics that I may not be seeing.
Speaker 2: Yeah. So I particularly like the book here.
Speaker 3: I think I use it as one of my previous
picks called radical focus. And one of the challenges that
definitely comes up is having too much like split focus
on where you're actually going. So the book talks a
little bit about how to build the appropriate okayrs, objective
and key results for an organization. And one of the
problems that can come up is that you'll focus more
on what you believe the business needs right now that's
already been articulated, versus some of these hypothetical bets that
other teams are making, and so it can be tempting
to lean on, hey, you said it right actually in
this today that we shouldn't be working on those other things.
And so the reality is that figuring out where the
boundary should be between what you do work on that
isn't defined sometimes called toil, sometimes called unplanned work, and
what has already been defined to be worked on. From
my experience, a good understanding at the team level can
be important, but it also can change over time. Like
you can say, oh, there was a lot of unplanned
work in the past that never got done. We're going
to radically shift and today we're only going to do
planned work. But three months from now in next quarter,
you can say, oh, that's also not healthy. We probably
want like fifty percent of the time should be dedicated
to plan to work, a thirty percent of the time
it can be dedicated to unplanned short just in time
work that we can get completed quickly. And measuring these
against each other is important. So one of them is
like keep the lights on our maintenance, which doesn't always
well work itself into an objective and key result, it's
sort of done. To have an objective that's like keep
the lights on, so much more to have, like, you know,
we actually want to accomplish something for the business here,
So somehow how that can work. Those tasks can work
in because fundamentally, from an agile standpoint, plans are great,
but we have to know when the plan is wrong
and be able to adjust and still do the work
we want without getting blocked by a mindset or tool
or framework that we've used to help us to get
to this point.
Speaker 1: Yeah, I guess maybe one thing I can do is
create an additional epic just called unplanned work, and at
the end of the quarter, see what fell into that.
Bucket and then adjust from there.
Speaker 5: I also imagine it's going to be very different for
different organizations, Like some just sort of by default are
moving fast, and I have a lot of unplanned work,
so I tend to work more in research.
Speaker 4: It's almost all unplanned. There's a few things that I know.
Most of the time.
Speaker 5: It's like, oh, by the way, I have one hundred
thousand simulations that I need to run yesterday, and I'm like,
all right.
Speaker 4: I guess this is what we're doing. This is what
we're doing today. So I don't know.
Speaker 5: I just I would imagine that it's all different, and
I feel like it falls into the uh, what's that quote?
You know, plans are useless, but planning indispensable kind of thing.
Maybe there are some organizations that could really follow the
use of epics and like, you know, properly plan things
out and all this kind of stuff.
Speaker 3: I mean, it definitely goes along with how not just
the identity of the teams in the org that I mentioned,
but how you're delivering value and that can be mapped
to using the team topologies nomenclature, what's the value stream
that your organization is utilizing? Because like you can focus
around that and figure out how do we plan the
work for that value stream and maybe we can't plan
it at all. That value stream is specifically adding value
by doing unplanned work, as Hillion points out, So I
think identifying that is certainly one important aspect, and you
sort of have to decide what is the sort of
work that we'll be doing before we even decide how
we do it or what needs to be planned. You know,
what are we responsible for? And I think there's another
potential pitfall here, which is what a lot of what
you're doing is to support other teams, right You're leading
platform engineering at the company, so realistically, what are their expectations,
you know, coming up and saying I mean, I love
that you went and did this for a couple different reasons.
But I think the number one problem I usually hear
from platform engineering leaders is that, oh, our stakeholders will
be incredibly unhappy with us if we force them to
commit to providing us input at the beginning of the
quarter so that we can figure out how to best
support them and go forward. I'm like, well, they should
for sure do that, but you should also be more
lenient on handling requests during the quarter as well, but
so there are expectations and understanding as a partner in
what you're delivering, I think is important for sure.
Speaker 1: Yeah, Like, I think one of the critical pieces that
made this whole thing possible was the mandate from the
executive team saying, this is what we're doing this quarter
without question. No, it's not up for negotiation, it's not
up for debate. This is what we're doing. And that
was a huge piece to making it possible for me
to do this. But even with that, there's, like, you know,
there's always like some uncertainty around that. You know, you
may get like halfway through this project and realize you've
got to shift to make it successful. And so one
of the other changes I made along with this was
on my team. Every person is the owner of one
of the products that we build, and that person and
then they have a backup as well for when they're
sick or vacation or whatever. But one of their responsibilities
is at the end of each week, meet with the
team leader or engineering manager that builds that product and say,
here's what we did this week, Here's what we think
you're going to need for next week, and then debate
that to get the right get both parties to agree
on the deliverables for next week, and then identify blockers,
you know, like we're blocked because you haven't delivered us
a software, or your block because we haven't delivered you
the hardware or vice versa, and just call those out
so that they're known blockers. And then that has to
be done every week, so that everyone's kind of like
agreeing at a high level to what's happening for a quarter,
but agreeing on a concrete level what's happening next week.
Speaker 2: I mean, I think that communication is really critical.
Speaker 3: I tried to stay away from synchronous there though in
the past.
Speaker 2: What I found, and it.
Speaker 3: Really depends on what your report is, cross team, cross organization,
how much the leaders know each other. I found that
a thing that I've been calling flash reports is great.
So on a biweekly cadence, all the leads are responsible
for like top two to three critical things that they
want other teams to be aware of that are relevant,
not from the business standpoint and not like I worked
on these tickets or we release these features that's not
super important, but like really what they think other teams
will want to know or need to know. And then
everyone fills out their one slides worth of information and
then it's shared within the entire org so that everyone
can sort of read it.
Speaker 2: If they want.
Speaker 3: And included in that is basically what you said already,
what they worked on, what they will potentially work on,
and then maybe blocker if they know dependencies on other
teams that are interesting. And this isn't related to any
specific project or anything. But often I found that in
organizations where you depend on others or they depend on you,
you don't necessarily know what those relationships are all the time.
Like it'd be so easy if like, oh, yeah, I
know everything that everyone else is working on and exactly
how we're going to be involved there, But often I
need a kicker from them where they say, oh, yeah,
we're working on releasing a new API, and I'm like
a new API to an existing service or like a
new service or new does that mean new infrastructure? And
like they don't even know the answer that question because
they haven't thought about it. But if I'm on a
team that's dealing with infrastructure, I'm going to start thinking
about it now because it's going to remind me, Oh,
how do we do new containers in our organization, Do
we do something, is it all self service for them?
Speaker 2: Et cetera, et cetera, depending on whatever that item is.
Speaker 1: So in those those high level meetings, how do you
coach or give feedback to someone when they're not delivering
what you feel they should be delivering.
Speaker 3: So, like outside, I think there's a I think it's
about communication, right, yeah, what what is the expectation for
this team and whatnot? So I would drill part of
it down to the okayrs, are they on progress to
somewhat deliver some part of what they're doing? If the
answer is no, then that investigation process may lend itself
to oh, they're not relying on other teams or not
depending on other teams enough, and that can uncover something.
I think there is a oh, you know what if
teams aren't getting along sort of hypothetical that I often
is played out.
Speaker 2: I don't think whatever. I don't care if they get along.
Speaker 3: You know, they have their own metrics that we decide
upon and that people are agreement on, and if they're
not making as much progress as we need them to
from a business standpoint or from another team standpoint, then
that should be visible so that everyone can go and
jump on it, like, hey, you know you're not making
progress on that, And then that's where there's an opportunities
like well, we're stuck on this because so and so
other team, And I'm like, well, what happened when you
went and talked to the other team and you said, hey,
we're stuck on this, because like what was that collaboration like?
And hopefully they can resolve that between themselves. So it's
not just like they're not communicating, but they're not communicating,
but the why right, Well, they're not communicating and that's
causing this outcome or this impact in the business that
we want to rectify.
Speaker 5: I find it really interesting that you and I have
opposite opinions on if it matters if people are getting along,
because I always find that, like, well, we have.
Speaker 4: A lot of technical problems, we have.
Speaker 5: A lot more people problems, like so many more people problems,
and it really does matter if people are getting along,
because that will be such a huge stalemate if they're not.
Speaker 3: So I think it's like an implementation detail. Like for me,
I don't care if they're getting along. If they're if
the business has already put metrics in place that drive
them to achieve what we believe is important because the metrics,
the encouragement to do the right thing is going to
be based off of their salary, whether or not they
want promotions, what they see as the future for the business.
We can't force them to get along unless there's some
metric that the business cares about. That's like people are
happy to work with each other, and then you can
actually invest in that. But if it's not part of
anyone's retention strategy for them to work with others, then
they're not going to do it and just be like, hey,
you know other people don't like you, is not a
good reason for someone to change, right, Like, maybe they
think that they're totally fine and the problems the other person.
Speaker 2: So I usually put everybody in front of.
Speaker 3: You, put something concrete in front of them, right, Like,
it doesn't matter that you're not getting along. What matters
is that because you're not getting along, this project is
not getting delivered as fast as possible. And like, if
you two people are disagreeing about the architecture, it could
be a decision making problem. Like both people think that
they're responsible for making the decision or not. What actually
happens more frequently is neither of them think that they're
responsible for making the decision, and they think some magical
other third person's going to come in and be like,
this is what you do. You use this, you use
all the script here, you terror form here, whatever you know,
ignore everything else, and that just never happens. That's usually
a huge slowdown in a lot of cases. So, I mean,
I think realistically it could be people not getting along.
I definitely, in my experience, have seen way more leaders
say you're not getting along, fix this, this is a
huge problem and not actually point to why that's important.
And for technical leaders, especially ones that aren't necessarily engineering
managers who understand how people work, just telling them to
get along with others is definitely not an effective way
to convince them to do it.
Speaker 2: I have experience.
Speaker 1: Make them hug it out, it's right.
Speaker 4: They just have to walk around holding hands until they
get out they like it or not.
Speaker 2: I want to see that in practice.
Speaker 1: That would be fantastic.
Speaker 5: I mean, I've kind of thought like, if I ever
had an in person management kind of job, I'm going
to have like a toddler corner. There's to be like
a bean bag and puzzle juice boxes, and like, whenever
anybody's too stressed out, I'm going to be like, you know.
Speaker 4: Just just chill out. Here's a juice box. It's all
gonna be okay. And I think that would work really well.
Speaker 2: I mean, I think there is something there.
Speaker 3: I'd be careful, well, I'd be careful calling it the
toddler corner.
Speaker 2: I associate.
Speaker 3: Children with professional environments. I think it happens a lot.
I mean, there are, for sure overlaps in how you
manage a team versus how you rear a child, but
there are also a lot of discrepancies as well. So
like I think it's it's very important to know when
the difference is. And I do know some people would
definitely get triggered if they felt like they were getting
sent to you know, they were a child, and however
they're act now, maybe that's exactly what they needed to hear. Like,
you know, just for the record, some people may absolutely,
you know, prefer that treatment. I feel like my hypothetical
corner would definitely have some variety of schedule, you know,
A or B drugs in it or something like that.
Speaker 1: I think that's part of it though, because you have
to figure out like what type of communication does this
person respond to? And the only way to figure that
out is to get it wrong the first few times
as you're like ruling out possible solutions.
Speaker 3: You know this.
Speaker 1: I think I've mentioned this on the show in the past. Like,
I taught CrossFit for five or six years, and like
the biggest thing I learned from that was how to
communicate with people in the format that they like to
communicate in. And doing there you're working under you know,
the pressure of a running clock. You're running under pure
pressure because they're all doing the same thing together. But
there's also like a safety issue too, where if you
can't get if you can't get your message across in
a timely fashion, that person's going to end up injured
for weeks or months or even permanently.
Speaker 3: So what I'm hearing is you should first write a
survey asking them if they would like a toddler corner,
and then if you get a majority, then then you know,
create that because you know that that's what they actually want.
Speaker 5: So I would create the Toddler corner first, and then
I would have like a we would have like a
contest for what to name it, and I would just
leave the word toddler out of it, because I do
actually have some tact not like a lot of tacked,
but like just a little bit, and then we would
just pick the best name and then that's what it
would be called.
Speaker 3: So I liked, you know, there is something interesting here.
I think it works less for remote companies.
Speaker 4: Uh, well, it really does.
Speaker 2: It worked it works for remote companies as well.
Speaker 5: No, I'm saying it really it doesn't work. I can't
think of it, like like I can't think of the
good equivalent for remote companies. I have my own toddler.
But that's besides the point.
Speaker 3: I mean, could maybe there's like you have to use
this background on Google Works meeting, you know, it always
has to look like this until it's over. I do
think there's something interesting here, and I think, you know,
we're talking about pitfalls about potentially changing the way in
which a team does work. I don't think what they're
working on is super critical to that conversation. So as
long as how you're working on it is aligned with what,
like what you actually.
Speaker 2: Want to have happened there.
Speaker 3: And one of the things that often happens that I've
heard of more happening in practice than experience is a
lack of everyone being on the same page when wanting to.
Speaker 2: Make those changes.
Speaker 3: And the message that has worked best for me is
this is an experiment, like we're going to try. If
we never try changing things, we'll never find a better
local maximum. Because if we're at a local maximum right now,
it's gonna be pain to find another one unless we
make some giant leaps in what we're doing and hope
we land on another tall mountain. And so I try
to phrase it as a time fixed or time bounded
experiment where we can just see how it works, and
that usually eliminates a lot of concern because I think
people tend to see that, oh, you're changing something, this
is permanent, We'll never change in the future. It's fixed now,
it will forever be like this, rather than we don't know.
I mean, we have maybe ideas of why we're picking
this as the experiment of changing to using epics in
a historically was a service based orient organization to new
you know, we provide tools and services to help, to support,
to enable, and we'll see how it goes, and if
it doesn't work out, then we're definitely going to reevaluate.
And maybe you point to, oh yeah, three six months
down the road, I already have a calendar invite set
out that we're going to reevaluate specifically how it went,
how people feel about it, and then we can make
adjustments from there, and usually that eliminates a lot of concerns.
Speaker 1: Yeah, that's a fair point, because in doing this, I've
I've already received feedback along those lines of you know,
what if or why didn't we or whatever, and I
was like, dude, I'm just I'm making guesses here, happy
to revisit.
Speaker 3: I mean, I would just be like, oh, yeah, you
know what, I'm definitely writing this down and it's going
in this document of everything that didn't work with our process.
And after three months, you know, when we're reevaluating what
was successful or not, we're just going to come back,
go back through the list and see what happened there.
Speaker 2: We'll have all this stuff captured.
Speaker 3: And that definitely leads into the hearing people that they
let their concerns be noted in some way.
Speaker 2: I think there's another real problem.
Speaker 3: Here, which is you will find a shadow organization having
stammed up there a hierarchy where some of these customers
or your users from a platform engineering standpoint, have been
able to ninja requests into your organization to be worked on,
and now you're actually saying, Hey, this stuff that we
should have never been doing, that isn't even important for
the business. Hypothetically, we're not even going to do that anymore.
Like that's where some of the complaints are going to
show up. And I think being prepared to have the
conversation whereas like, oh, we have these things in progress,
like which one of those is more important for you?
Like you stack rank them for me? And I feel
like without having that mentality it can be challenging the
first time to realize that is the conversation that you
want to have.
Speaker 1: Yeah, now I see that point, because you can't say
yes to everything. And I think that's where a lot
of that comes from, is saying I hear you, but
we're going to say no to that.
Speaker 3: Yeah, I mean, And that's the thing is you don't
necessarily have to say no. But I think alignment between
different stakeholders is also important and clarity and so like
asking for well, how much money, Like let's pretend I
always love this hypothetical. Let's pretend my organization didn't exist.
There's no DevOps at my company, there's no platform, we
have no tools, and you have this challenge in front
of you, like what are you going to be able
to get that taken care of by yourself? And if
the answer is no, like what's stopping you from achieving that?
And then potentially saying, oh, you know, if we had
an organization, then we could take that work off from you,
And so there's a different perspective on who's fundamentally accountable
for delivery.
Speaker 2: There.
Speaker 3: I have another pitfall, but maybe I'll hold off on
that for one moment while we digest this current idea.
Speaker 5: I like the idea of keewing everything up as sort
of an experiment. I think it kind of releases a
lot of pressure and then, you know, anything that can
be done to kind of tone down the seriousness I
think is usually helpful. I mean, I suppose we should
take some things seriously sometimes, but.
Speaker 4: I don't know.
Speaker 5: The exact structure of tickets is like, well, sometimes we
just got to kind of like pick something and just
move forward with it so that we can we can
just kind of move along and get things done.
Speaker 1: Yeah, for sure, I take very few things seriously non either. Okay,
what's your other pitfall worn Yeah.
Speaker 3: I mean so one of the things that can come
up here is if you have too many epics, too
many things going on, Like I don't know how exactly
big your team is, but often, OKRs, I find that
somewhere in the one to three range for maybe twenty
people is appropriate, and that can first balloon out and
have a lot of things when we feel like every
single one of those items doesn't take so long, Like
it's not it's like, oh, well, we need more work
because what we have currently doesn't isn't enough people to
work on, Like, we have too many people to do
that work right now, So let's create more things. And
what ends up happening is you fracture the organization so
they're all focused on just whatever their silo is, and
within your own organization, they can't effectively collaborate pull in
extra people off. And so while you've solved the problem
of what your users or customers need or want by
prioritiz at that level, internal prioritization then becomes an issue
and how you align and do, like how do you
decide which of your objectives of the key is what
you're going after is most important?
Speaker 2: How would you argue one over the other.
Speaker 3: And when you have two people working on that, if
you have individual owners of different areas, then they're always
going to believe that the thing they're working on is
most critically important and always believe the thing that someone
else is working on is less important, and so it's
going to be impossible for them to get off of
that and help or collaborate where they'd have to sacrifice
something that they're doing. So I like the idea of
sort of ownership or responsibility to update the metric or
keep track of it, but as far as success goes,
it has nothing to do with this particular individual.
Speaker 2: I mean, someone can.
Speaker 3: Be a project manager without having the accountability for whether
or not that project is a success, because there's lots
of things that are outside the org that impact or
outside even the team or the individual. And one of
the things I usually caution against is making a performance
metric or measurement on something where the individual doesn't have
a majority of the impact on it, because they'll be
beholden to whatever else is happening in the world at that.
Speaker 1: Moment, for sure. So like an example of that would
be holding one of my team members accountable for shipping
a product which they don't really control because they can't
ship it until the engineering team is done building it.
Speaker 2: Yeah, I think it's a great example.
Speaker 3: So you mentioned the bear metal earlier, right, like, oh,
this application is deployed to production?
Speaker 2: Is the is the metric?
Speaker 5: Now?
Speaker 3: That could be great for the OKR for the business,
but individually or even at your org level, you have
no impact over the ability for another team to ship
that application whatsoever. You can have all the bear metal
ready according to some specification, and so maybe that's the
you know, those tickets make sense. The bare metal is
ready to go, all the necessary infrastructure is totally great,
But a anything outside of that, like, keep that far
away from my organization because it's just going to.
Speaker 2: Make people unhappy.
Speaker 3: Or maybe they'll be great at project managing other teams,
but that starts to get into a dangerous area where
your team members feel that they're responsible for someone else
outside of their loki of control to do work. You know,
they need to get their stuff done in order to
be successful in your eyes.
Speaker 1: Yeah, that's a good idea. I'm going to have to
go back through the way I worded these epics with
that in mind, because I know some of them stayed
exactly that go ahead, Julian, I was just going to.
Speaker 5: Say, so, this conversation kind of raises two questions in
my mind that I've had, you know, maybe personal experience
with that I don't want.
Speaker 4: To get into, but I suppose.
Speaker 5: So the questions are like, one, how do you know
when it's time to you know, sit back and re
evaluate and say like, hey, there's something there's something amiss
in the way that we're managing things. And then two,
how do you, like, how would you get buy in
from the higher ups if you're kind of meeting some resistance,
So I know, for example, like there's kind of one
project in particular, and thinking of that, we were all
just so in the weeds, firefighting all the time. That
kind of getting buy in to be able to say like, hey,
there's there's something strange going on, like we need to
you know, be able to sit down and make a plan,
and that of course takes time, right, So then that
was going to be you know, a few days, a week,
a few weeks, however long it was going to be
to be able to sit down with all the necessary people,
get these requirements, make this plan, and I know you know,
and like the person who was in charge was very
much against taking that time to do that. It was
more just like no, no, no, just just keep pushing
through these things and get them done. So how do
you guys propose dealing with both those scenarios? One?
Speaker 4: How do you know? And two?
Speaker 5: What do you do when you're like, I definitely know
that we need to do something, but you just get
too much push back.
Speaker 3: I really this is not the answer, But I will
say ignorant ignorance is bliss here because once you know,
you will definitely be frustrated. If you can that cannot
then affect the circumstance.
Speaker 1: Yeah, and this is probably an extreme example, but very
relevant to me. One way, you know is whenever like
senior level execs reach into your team and start making
decisions for you.
Speaker 2: I mean, that's a good one.
Speaker 3: There's a canonical term in the industry called a hippo
the highest paid person in the room or organization. Uh yeah,
that that that that's particularly one. I mean, realistically want
to push decision making down to where the information is
and not push information up to another place that supposedly
can make the decision. So I mean I find that
if you have an opinion here on a team that
something isn't working effectively, then technically it's not right. There's
a mismatch of expectations.
Speaker 2: So if you feel like.
Speaker 3: Something's not working, then it is probably not and it's
worth in investing that. Now, I that's not that's sort
of a cop out answer. I feel like to how
do you know if things aren't working? But I think
that this is where you can go out into the world,
you know, listen to podcasts, read some books about different
ways of working. I think one metric here can be
when was the last time you experimented with changing this
aspect about your organization. If the answer is we've always
done it this way, then you should absolutely make a change,
even if it's like, we know this is going to
be worse, but let's do it anyway so that we
can see the impact and remind ourselves of why we
didn't do that. And this is where like ADRs or
architecture decision records or if you have some other measurement
or documentation system, to remind the organization of, oh, we
did try this. Here were the problem, Here were the problems,
here were the benefits. You know, we probably won't do
it again because maybe the reason why it didn't work
was had some blocker which is now gone. Right, like
the tools you weren't using weren't mature enough, or you
didn't have the cash flow to execute on it, or
the right people at the time.
Speaker 2: If you write that.
Speaker 3: Down, then you can remember, oh, look at this decision
we made. We didn't go down this path, or we
didn't like it because we had the wrong people.
Speaker 2: Well now we have different people. Maybe now we can
get the benefit out with all the negative without the negatives.
Speaker 1: Yeah, I think there's something to be said about that
comment you made. If you feel like it's not working,
then it's not working. And I think I think there's
a lot to that. You know, like you mentioned, you know,
there's either like an expectation alignment or a misunderstanding. But
if you start with it at that level, it feels
like that might be some early indicators if nothing else,
you know, and then if you choose not to act
on those, you end up in an example that I
was bringing up, where the hippo comes in and starts
making decisions in your team without consulting you.
Speaker 3: Yeah, I think I mean there was this terminology that
I think came from Amazon Disagree and Commit, and I
absolutely hate it. What Like, it's one of the worst
things from my standpoint ever, because realistically, everyone should be
in agreement of what the context is. So if you
feel like something's wrong, then it's wrong because you don't
understand like you should be able to be someone should
be able to justify it to you. Why it's one
particular way versus another one. And if you don't understand that,
then that's where the missing gap is. And if you
do understand it, then why do you understand that it
should be different but someone else doesn't?
Speaker 5: Like?
Speaker 3: Why is there still a misalignment there? So I think
that's usual. Like sometimes the answer is just additional information.
You're missing context, so go out and get that context
for sure? What to do about it? Though, Julian asked
that challenging follow up question there.
Speaker 4: If you like, get more context, I mean, that's someplace
to start that could.
Speaker 3: Only wrong answers. I mean, fire a bunch of people.
That definitely solve the problem.
Speaker 2: You know.
Speaker 5: Different if we're going to assume for this scenario, I
have no power to either hire or fire anybody.
Speaker 3: You can you can definitely always leave That's another one
I found that as a leader with with insufficient authority
in an organization, one question I love to push people
on is to ask or have the conversation why don't
I have the authority?
Speaker 2: Like what has to like?
Speaker 3: Not demand like I should be able to fire this
person I don't like working with, but instead like what hey, leader,
hey boss, what would have to change so that I
could make the decision here rather than you making the
decision or someone else making the decision? What's the expectation here?
Is it ID be at a different level, Like it's
my title that's stopping me, the role that I play
on the team that's stopping me from doing that? Is
it you know something about the context, the org, the business,
et cetera.
Speaker 2: So that gives you.
Speaker 3: The ability to get additional knowledge, but it also shows
you where the timeline is, or the line is that's
being drawn where your responsibility ends. Because then if this
happens a couple of times, you can say, hey, like
we're at this line, like we said, you know in
six months, you know, or once I got this promotion
that of course, this role makes this responsibility. It's written
down in the job description, which represents what I'm doing,
and I should be able to do that, like I'm
responsible now.
Speaker 2: And if you're not making a decision, then.
Speaker 3: You're basically being lied to, right, you know, someone says, hey,
you know, you can't do this today because you're not
at the right level or the right role. But once
you are, then of course this would be your decision.
And then when if that's if you're okay with that answer,
then it's a matter of being at that role, like
what Then the conversation becomes what does it take for
me to get to that role? What's missing? Like why
might not already staff engineer or principal engineer? Who is
responsible for that? And why are they saying no, like
I would like to know because it's promotion based, then
maybe it's something else, you know, maybe it's regional or
cultural based. And for sure, this only works in organizations
where transparency is highly valued. There are definitely cultures around
the world where it's not, and you have to understand
the subtleties of that culture, which has nothing to do
with anything I can advise you with on this call.
Speaker 1: In any way, I love the professionalism and that approach, though,
instead of bitching about the problem you approached it from Hey,
what would I have to change to get to do this?
You know? And it's like, instead of putting the problem
on someone else and saying why isn't it this way,
you're taking ownership of it and saying, how can I
make it this way?
Speaker 5: I think generally taking trying to take some accountability is
usually a better plan then, you know, pointing fingers and blame.
Speaker 4: It's much more productive conversation.
Speaker 1: Yeah, for sure, excellent, Thank you both for your input.
Speaker 4: Thank you. It's an interesting topic.
Speaker 2: It was.
Speaker 1: It's been very helpful for me, hopefully helpful for all
of our listeners as well.
Speaker 2: But should we move on to some picks?
Speaker 5: Sure?
Speaker 1: All right, Chillian, what'd you bring?
Speaker 5: I forgot to pick something, so maybe skip me from
you like, look at my kindle lin see romance novels, though, Like,
what am I going to pick for the show?
Speaker 3: I mean, if you really like one of them, it
could definitely be one at one of those?
Speaker 5: And yeah, what the hell the new series by Lindsay Barroker.
It's fantasy romance. It's the usual level of unhinged that
I read.
Speaker 4: I don't know, that's that's it. That's what I got I'm.
Speaker 5: Sure that will I'm sure that will really appeal to
the demographics of the show.
Speaker 1: Well, it might, it might.
Speaker 3: I've definitely read some fantasy romances in my time, so.
Speaker 4: Well, there we can't say.
Speaker 3: I can't say they're at the top of my list.
And I feel like once you've run read one, you
read the mall where all empires. Uh, you know that's
sort of the end of the story, the point. Well, then,
I mean, I've read one, so I guess I've read
them all.
Speaker 4: There might be like a little bit of room in there.
Speaker 1: Changed characters names right on Warren. But you bring for
a pick, did you bring a trashy romance novel?
Speaker 2: I didn't romance novels, I know.
Speaker 3: And now I'm gonna have to go look through my
I mean, my my fiction list is is growing on
things that I read that I haven't shared on this podcast,
So I think that it may it may be coming
very soon once I run out of actually useful things
that I want to share. So my my my share
this week is uh going to be QCon and San Francisco,
which if I'm right when the episode drops, it will
be it will be uh, it will be this week.
Speaker 2: So lots of good talks.
Speaker 3: My CEO of Authors is talking the only security related
talk at the conference about security versus convenience, And I
think that we sacrifice a lot of convenience for quote
unquote security and don't even get that, especially when we
know fishing is so critically the problem that many organizations face,
and the ridiculous things we run on our machines and
corporate spy where we put in our offices has very
negligible impact.
Speaker 2: So, uh, if you want to be.
Speaker 3: Triggered, there is absolutely a conference stock waiting for you
right on.
Speaker 1: I love that topic, and I think your stance on
that I agree with it. But it's very rare to
hear that from someone with a security background. You know.
Speaker 2: I think I heard a great.
Speaker 3: Thing phrased recently, which is if everyone does something, by definition,
it's mediocre. So in order to be exceptional, you actually
have to do something different. And I think that's maybe
one of the biggest problems with quote unquote security best
practices today. There's actually this mentality that goes around a lot,
which is you will have a security incident, and when
it happens, if you get breached and you lose some data,
or lots of money, or customers or trust people will
look at what you did and they'll say, oh, you
didn't do all these things that we said were best practices.
That's too bad. I guess you deserve to get hacked.
And and if you did all those things, they're like, oh,
that's too bad. I guess you couldn't have done anything
about it anyway. So I really hate this mentality. So
I'm all about the threat model. I'm all about you
know what you're actually trying to protect against specifically, And
I can say, thankfully in Switzer and at least right now,
we haven't had any uh far East Asian state sponsored
actors attempting to breach into our company, but I know
that at huge sizes it can absolutely be a problem
for sure.
Speaker 1: All right, well my pick. I also am not picking
a trashy romance novel, but.
Speaker 4: With you guys, what are you doing with your lives?
Speaker 1: That's definitely for this podcast.
Speaker 3: You know, if you're going to play that card, Julian,
then I would like you to send us your favorite,
like the best trashy romance novel you've ever read, Like, Wow,
I can't believe other people haven't read it.
Speaker 2: And I will read that.
Speaker 4: I don't know that's that's gonna take.
Speaker 5: I'm gonna have to think about that and then and
then I'm going to hold you to it, though I will.
Speaker 2: I will absolutely read it, yeah, next week, all right.
Speaker 1: And it's important. It's important to be comfortable when you're
reading it, which leads us to my pick. I got
the Ultra Ideas Black Bear Pause slippers from Amazon, and
they are the most comfortable slippers I've ever had. And
they're like these big, huge, oversized slippers that look like
a bear's foot. And that is very fun, dude. I've
had so much fun with them, Like the number of jokes,
like whenever I walk into a room, my wife looks
at me and I'm like, what, you barely heard me
come in? Or she'll look at me, I'm like what,
I'm just walking around barefoot? And so the number of
puns are just endless. She's kind of reached her limit.
Speaker 2: With them, though, but.
Speaker 1: I'm not gonna let up. I'm sticking with this.
Speaker 5: It's right.
Speaker 4: It's the winter.
Speaker 1: Absolutely is it cold there will it's getting there. Like
this morning it was down around freezing, so thirty two
degrees fair and high zero Celsius.
Speaker 2: And you don't like have any heating inside.
Speaker 3: I just want to understand, like, you know, maybe you
keep your your your house much cooler than other people.
And so I see your you know, flannel shirt and
undershirt there, so I can fully understand, Yeah, we do
keep it cooler in here. Plus I just moved here
from Arizona, so I'm not quite climatized yet. And and
then the big bear slippers. I don't care how warm
it is, They're just cool as hell. So I had
to get those.
Speaker 4: Those are staying well.
Speaker 3: Yeah, absolutely, I always want to see a picture of this,
you know, just for the you know, visual stream.
Speaker 1: Okay, I'll get a picture. I'll bring it next week.
Whenever Gillian comes with her trashy novel, I might.
Speaker 4: Have to have a whole list. By the way, I
don't know that, like, no, you got one one, only one.
Speaker 5: It's a series though, that you can't without reading the
whole series, Like.
Speaker 2: I mean, it's it's really chaos.
Speaker 3: If you say, if you say it's the first book,
I will read the first book. And if you say
it's the series, I will still only read the first book.
So you got to be careful here, right, you know.
It's that you got to make an impact on me,
you know. And then after that, if it's great, maybe
I'll read the next one.
Speaker 5: You get one shot, Jilly, Maybe maybe I'll convert the masses.
Speaker 1: Whether mom spaghetti's on your shirt or not, you get
one shot. All right, excellent, all right, Thank you both
for joining me, thank you for listening to the show.
And I'll see everyone next week.