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