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.
Hey, thanks for having me back.
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.
Right, We're doing great.
Yeah, So welcome back, Jillian.
Happy to have you back on the show.
Thanks, I'm happy to be back.
Yeah.
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.
I don't know, we'll see.
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.
So.
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.
Genius, brilliant. We should have thought about this sooner, right, Okay, thanks for tuning in.
I'm sure of that.
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.
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.
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.
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.
I like that.
The biggest takeaway of all this is that doing support work is like playing telephone in kindergarten, right.
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.
I mean, I think you.
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.
Away you know what you're even doing.
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.
Yeah.
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.
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.
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.
Things, I definitely close them.
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.
What if it's actually helpful, though, Yeah.
I guess I'm just going to have to live in backwards.
Reality, to live like a caveman over here with how your AI response is?
Okay ran over.
Yeah, I don't know.
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.
Like I was.
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.
Was very silly. So anyways, I find it's about fifty to fifty. Sometimes it's helpful.
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.
Yeah. So I particularly like the book here.
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.
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.
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.
It's almost all unplanned. There's a few things that I know. Most of the time.
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.
I guess this is what we're doing. This is what we're doing today. So I don't know.
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.
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.
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.
I mean, I think that communication is really critical.
I tried to stay away from synchronous there though in the past.
What I found, and it.
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.
If they want.
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?
Et cetera, et cetera, depending on whatever that item is.
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.
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.
I don't think whatever. I don't care if they get along.
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.
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.
A lot of technical problems, we have.
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.
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.
So I usually put everybody in front of.
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.
I have experience.
Make them hug it out, it's right.
They just have to walk around holding hands until they get out they like it or not.
I want to see that in practice.
That would be fantastic.
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.
Just just chill out. Here's a juice box. It's all gonna be okay. And I think that would work really well.
I mean, I think there is something there.
I'd be careful, well, I'd be careful calling it the toddler corner.
I associate.
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.
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.
You know this.
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.
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.
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.
So I liked, you know, there is something interesting here. I think it works less for remote companies.
Uh, well, it really does.
It worked it works for remote companies as well.
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.
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.
Want to have happened there.
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.
Make those changes.
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.
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.
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.
We'll have all this stuff captured.
And that definitely leads into the hearing people that they let their concerns be noted in some way.
I think there's another real problem.
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.
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.
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.
There.
I have another pitfall, but maybe I'll hold off on that for one moment while we digest this current idea.
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.
I don't know.
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.
Yeah, for sure, I take very few things seriously non either. Okay, what's your other pitfall worn Yeah.
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?
How would you argue one over the other.
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.
I mean, someone can.
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.
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.
Yeah, I think it's a great example.
So you mentioned the bear metal earlier, right, like, oh, this application is deployed to production?
Is the is the metric?
Now?
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.
Make people unhappy.
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.
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.
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.
To get into, but I suppose.
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?
How do you know? And two?
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.
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.
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.
I mean, that's a good one.
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.
So if you feel like.
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.
If you write that.
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.
Well now we have different people. Maybe now we can get the benefit out with all the negative without the negatives.
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.
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?
Like?
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.
If you like, get more context, I mean, that's someplace to start that could.
Only wrong answers. I mean, fire a bunch of people. That definitely solve the problem.
You know.
Different if we're going to assume for this scenario, I have no power to either hire or fire anybody.
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?
Like what has to like?
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.
So that gives you.
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.
And if you're not making a decision, then.
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.
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?
I think generally taking trying to take some accountability is usually a better plan then, you know, pointing fingers and blame.
It's much more productive conversation.
Yeah, for sure, excellent, Thank you both for your input.
Thank you. It's an interesting topic.
It was.
It's been very helpful for me, hopefully helpful for all of our listeners as well.
But should we move on to some picks?
Sure?
All right, Chillian, what'd you bring?
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?
I mean, if you really like one of them, it could definitely be one at one of those?
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.
I don't know, that's that's it. That's what I got I'm.
Sure that will I'm sure that will really appeal to the demographics of the show.
Well, it might, it might.
I've definitely read some fantasy romances in my time, so.
Well, there we can't say.
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.
There might be like a little bit of room in there.
Changed characters names right on Warren. But you bring for a pick, did you bring a trashy romance novel?
I didn't romance novels, I know.
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.
So lots of good talks.
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.
So, uh, if you want to be.
Triggered, there is absolutely a conference stock waiting for you right on.
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.
I think I heard a great.
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.
All right, well my pick. I also am not picking a trashy romance novel, but.
With you guys, what are you doing with your lives?
That's definitely for this podcast.
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.
And I will read that.
I don't know that's that's gonna take.
I'm gonna have to think about that and then and then I'm going to hold you to it, though I will.
I will absolutely read it, yeah, next week, all right.
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.
With them, though, but.
I'm not gonna let up. I'm sticking with this.
It's right.
It's the winter.
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.
And you don't like have any heating inside.
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.
Those are staying well.
Yeah, absolutely, I always want to see a picture of this, you know, just for the you know, visual stream.
Okay, I'll get a picture. I'll bring it next week. Whenever Gillian comes with her trashy novel, I might.
Have to have a whole list. By the way, I don't know that, like, no, you got one one, only one.
It's a series though, that you can't without reading the whole series, Like.
I mean, it's it's really chaos.
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.
You get one shot, Jilly, Maybe maybe I'll convert the masses.
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.