Getting your ideas across can be difficult for a new person on the job or even a seasoned professional. Join in as the panel tackles different strategies for communicating ideas and “How to get your way”. They also share their experiences on how to handle the team when they encounter problems.

What's going on, everybody? Welcome to another episode of Adventures in DevOps. Joining me into the studio today is Jonathan Hall.

 

Hey bud, how's it

 

Welcome

 

going?

 

back.

 

Thanks.

 

Congratulations.

 

Thank you.

 

Jonathan welcomed a new member to the family last week, right?

 

Yeah,

 

That's

 

Tuesday.

 

right,

 

Two.

 

congratulations on the new baby.

 

Thank

 

Can't

 

you.

 

believe I forgot about that. Only for like a minute though.

 

that. And as you may have guessed, also joining us in the studio is Jillian Rowe. Hi Jillian.

 

Hello, hello.

 

I'm still excited to have you back on the show after your

 

Aw, thank

 

Yes.

 

you.

 

worldwide tour. So today, I need your help in talking about a specific topic. I want to know how to get my way. So that's the topic of today's conversation.

 

Cookies.

 

Cookies, donuts.

 

Yeah.

 

I was about

 

Bring

 

to

 

cookies.

 

say bribery,

 

Yeah.

 

straight

 

Bribery.

 

up bribery has quite often worked for me.

 

Great.

 

Yeah,

 

Well, join

 

I'm not

 

us

 

above

 

next time

 

bribery.

 

on Adventures in DevOps.

 

Yeah, thanks for listening, everyone.

 

That's it, we

 

No,

 

solved it.

 

this actually came up as part of a conversation I was having with someone. I'll set the background of it. They are a new member on the team. And while they have experience in their profession, they may not have a ton of credibility with the team being the new member. They're not in a management or authoritative role. But they're working on this project where they have a high level of confidence that they're going about the wrong way to solve this problem. And this particular individual is struggling to influence the members of the team to change their approach. So I thought that would be a good topic for today in how do you get people to change their mind? You know, what ways are effective and what tools can you use specifically for those areas where you may not have decision making authority. And even if you do have decision making authority, you know, I think it always works out better if you portray your ideas so that everyone or a majority of the people get on board rather than just saying, I'm the boss, we're doing it my way.

 

I don't know, that's how I've always done it. I've just said I'm the boss.

 

Right?

 

Who's funding

 

You like

 

this?

 

paychecks?

 

Ha ha

 

Who likes

 

ha

 

paychecks? Who

 

ha

 

wants

 

ha ha.

 

more paychecks? There's an Oprah meme there somewhere. You get a paycheck, you get a paycheck.

 

So after I've made that joke, let me just clarify that actually I don't operate that way at all even when I am the boss. So I don't think this question has to be limited to people who don't have authority. I think even if you do have authority, it's good to find more organic and natural ways to get buy-in rather than saying, do you want a paycheck? Okay, then do it my way.

 

Yeah, agreed.

 

For the health of the team, for the morale of the team, for the quality of work, every aspect. Unless you absolutely have to start pulling rank, that should be a last resort, I think.

 

Yeah, yeah, agreed.

 

Yeah, I'm a little bit concerned about sort of, I suppose there could be a lot of different kind of context to this question, but if you're very new on a project, I think it's very easy to kind of see all the mistakes without understanding the context, right? We all make trade-offs throughout projects, over and over and over again, over time, those trade-offs can, they add up after a bit. let's just say. So I think it, I don't really think you want to be that person who comes in and is like, let me tell you all about how much you suck. And everybody's like, listen, we know, we know we've been here, okay? Like we get it.

 

Hahaha

 

Because I've definitely, I've been on both sides of that fence actually, which was kind of an important life lesson. So if you're that person, don't do that. If you are the, if you're like the person in charge, yeah, I'm with Jonathan. I don't do that real draconian kind of way of doing things. My sort of... way of doling things out is like if you're doing the work you you get the final say within reason like I don't want people making up new operating systems or something but like if you want to use I Don't know what like scikit image instead of pillow or like, you know These things that are kind of like they're there are trade-offs, but they're basically equal Or like you're picking. I don't know what the hot new web frameworks are like you're picking one or over the other Like for the most part, I'll go along with any of that, possible exceptions being if something is really, really not maintained and I don't want it to be my problem to maintain it. But I'm wondering, is there any more context to that? Like, do you know how long was this person on the project? Were they, like, what was happening?

 

Yeah, yeah before I jump into that I want to highlight something you said there because I think it's really important to get the context You know being the new person in there. I Think it's really important to have the conversations of how they got to this decision Because I can tell you from firsthand experience. I've been in this situation and thought this is just not the right way to do it and pushed for my solution and almost always like the more confident I am in my solution, the more wrong I actually

 

Hehehe

 

am because I was missing the background information of what things they're considering or what things I don't know about that led them to the decision they're making. And yeah, so to answer your other question though, they've been on this project for about a month now. And the project itself has been going on for a couple of months, so they're getting into it. And it's over a chosen technology, like we're going with this technology. And I'm trying to think of how much I can say without selling this person out or causing anyone any grief. But basically, they are going with a hosted Kafka solution. And if you're not familiar with Kafka, it's a streaming platform where just data just streams through and you pick off the pieces you need. And it works really well for dealing with data at high volume. But in their case, they're not dealing with high volume. And given that Kafka is a streaming platform, it's also not a good fit because it they can't handle streaming data. They have to take a message from the solution, whether it's Kafka or something else, stop what they're doing, go address that, and then come back to it. So they can't actually even stream the way that Kafka likes to be used anyway. So that's the background scenario there, is they've kind of committed to this platform, and it just doesn't look like it's the right one.

 

So my first advice, if somebody came to me with a question like this, my first advice would be, it's kind of a, it's almost a cliché, but it's really true, and that is to seek first to understand. And

 

Yeah.

 

I think you've alluded to that, but I want to make it black and white for the listeners. before you start passing judgment on what you see is wrong, and what you see may well be wrong. I mean, I've come into new projects and frequently what they're doing is outdated or doesn't make sense, or it's a kludge from six different people that had different ideas. There's a lot of ways that things could be done wrong, but seek to understand. And I think the key to that is realize that the thing that you're looking at that makes you go, what the hell made sense to someone in some context?

 

Right?

 

Figure out what that context is and you'll be a huge part of the way towards solving it. I mean, now you may come to realize, you may come to decide that, oh, this thing actually isn't wrong. More likely though, you will come to realize, yes, this is wrong, but there's these other constraints I hadn't considered I have to take into account when proposing my alternative.

 

I think that was very well put, very succinct. I agree.

 

Good answer. I would do the applause

 

Sound effects are

 

sound

 

broken

 

clip

 

this week.

 

here, but I can't find it in the list. So

 

We'll

 

for

 

just play

 

all

 

something.

 

our listeners,

 

Play

 

yeah,

 

anything else.

 

just

 

Just imagine

 

for our listeners,

 

it in there.

 

permit.

 

What was that?

 

Did that actually work? That was supposed to be preview.

 

There we go. All right.

 

So, okay, so first, so yeah, I think we're all in agreement there. First is understand the problem, get the background, get the context of it. And um... That's going to lead you to either confirm or destroy your initial suspicions. So let's say that you still believe that this is the wrong approach and you want to influence them to change. What are your thoughts on how to take the next step?

 

Build demos. That's been how I've sold literally everything. It is my superpower right up there with being underestimated is that I can build fast

 

Hahaha

 

demos that show people, I'm like, this is the thing that I want. And it does better than any meetings or PowerPoints or presentations or emails or whatever else I've tried. The best thing has just been, I'm just gonna throw together a really quick demo and it's held together with like. duct tape and wishful thinking, but it always gets the point across. And then that's just always been the way that I've had a lot of success with showing people. like, okay, these are kind of my ideas, this is what I think should happen. And because it is a demo and I don't put like a ton of time into it, if it ends up going completely sideways, which by the way they have, there have been times when I've been like, I think I have a really good handle on this problem, this is what I think could solve it. And then the scientists just come and tear me to shreds because I was so, so, so wrong, but it was a demo, so I don't care. And it will also deepen your understanding as well because like whenever I go and I... you know, I demonstrate this sort of application or workflow management or whatever it is that I happen to be doing to people. Like they'll ask questions and they'll say, okay, but we do this and could it work, you know, in this fashion? And it always leads to a much more, I think organic conversation where you get more context than emails, PowerPoints, Slack memes, I don't know, anything. Code reviews, like

 

Hahaha

 

those poor guys at Twitter.

 

Do you have them fax the code reviews over, print them out and fax them?

 

No, but that is too funny because I thought I was the queen of petty, but I think this person, whoever set that up, they win. Like I'll, you know, I'll hand over my crown to them because that is fantastic. I love that.

 

For context for the listeners, I saw someone tweet out yesterday that Elon is supposedly doing the code reviews and so to make it easier for Elon, someone set up a web service where you can submit your code to be reviewed and it will fax it over to Twitter HQ for him to review. I just want to say bravo. That was... Elon's new role in Twitter. I think just like the dedication to go through with that plan, I sincerely applaud that.

 

Ha ha ha.

 

I think that's great too, the level of comedy right there.

 

Yeah, for sure. So Jonathan, what about you? How do you sell this once you are convinced that you're

 

Yeah.

 

on the right path?

 

So I actually would do a couple things before a demo, in most cases. I want to know who I need to convince and what they care about.

 

Yeah.

 

There's a lot of different types of convincing that might have to be done. Sometimes you're showing someone a demo, look at this shiny new thing, is all you need. And they're like, oh, yay, that's awesome. I'd love to do that. It's shiny, or it's fast, or whatever. thing that they like about it. Other times you could show the best in the world and it sounds like some grumpy old bearded guy in the background who looks kind of like me is going to say, yeah, but what about and they're going to start throwing objections at you. So I think it's really important to know who you need to convince and what they care about. Do you have to convince upper management? Do you have to convince the CEO? Do you have to convince just your peers, other individual contributors like yourself? Do you have to convince... product management, people in different departments, different teams, who do you have to convince? And then, so understand that, who makes the decision? Is it a single person or a group? And then what do they care about? Which of course comes right out of what I said earlier about understanding why things are how they are. Once you have that context, you'll already have part of the answer to what do they care about? Because you'll understand the use cases they built this thing for, presumably. And then, you know, maybe related but a little more in depth there, the personalities of the people you need to convince can be really valuable information too. Some people are convinced by facts, some people are convinced by emotional appeal, some people will not be convinced no matter what. Just because they don't like you or whatever, or they think you're too junior, or whatever reason they have up their butt, maybe that's, there's no convincing them. And yeah, so that's a good sort of inventory to take. Who do you need to convince and what do they care about? And further recognize that not everybody who's involved necessarily needs to be convinced. Maybe you don't need to convince the grumpy old guy in the server room if you can convince the friendly product person down the hallway or whatever. So

 

Right?

 

take it strategic. sort of inventory of the people you have to convince or people involved and determine who you need to convince. And that will really help you decide. And then from that point, then you can build that demo if that's appropriate and you'll build a better demo because you'll be building it to showcase the things that your audience care about.

 

Yeah, I think that really ties into something that I think doesn't get as much focus as what it possibly should. And that's just the social skills of engineering. Because you're interacting with people. And when you're interacting with people, different people have different personalities and different things that they care about, and different ways that they effectively communicate, whether that's visually, audibly, or.

 

Talk to you.

 

tactile there we go thanks I was drawn a blank on what else humans can do but yeah yeah

 

Some

 

so

 

humans,

 

understanding

 

not all.

 

your yeah exactly yeah yeah I don't want to don't want to exclude anyone but yeah like you got to understand how this person likes to communicate and one of the I read a book I think it's been a year or two ago Never split the difference by Chris Voss and he does a great job of breaking this down it was really a fascinating book to read given the topic because he Talks about these different things that we're talking about here, but then he was a former I think CIA hostage negotiator

 

I think FBI, yeah.

 

FBI

 

I've

 

yeah

 

read the book too, yeah.

 

Yeah, and so he follows up every lesson with an actual FBI story. So it's kind of like

 

Thanks for

 

part

 

watching!

 

action book, part educational book, and it was really effective. And my wife read it as well. She read the Kindle version. Then she got the physical copy of the book. Then she got the audio copy of the book. And I honestly haven't won an argument with her in two years because of that. So.

 

My wife hasn't read the book and I haven't won an argument either, so...

 

I used to do okay. I could hold my own but since then I don't even bother anymore.

 

You shouldn't, Will. You shouldn't.

 

hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahah

 

So I suppose the next step, if you need to convince someone is to hire Will's wife.

 

Right? Yeah.

 

Ha ha.

 

There you go, she could be your hostage negotiator.

 

I'm gonna go.

 

We need to get rid of Kafka. What's your wife's name? Give her a call. See if she can make the case against Kafka.

 

Yeah, she could. That's going to be like your, you should probably make sure you've exhausted other possibilities before you call her in because she's persistent. We'll put it that way. Thank God she doesn't listen to this podcast. Or if she does,

 

I wonder

 

I'll

 

if any of the spouses

 

let you know.

 

do.

 

If she does, I guess Jillian, it'll just be you and me from now on.

 

Right? What happened to that other guy that

 

Right.

 

used to be on the podcast?

 

You haven't heard from him

 

What

 

in

 

happened

 

months.

 

to him?

 

What happened to that guy?

 

I wonder if any of the spouses do listen to the show, or if they're just like, oh, thank goodness they have somebody else to talk to about their nerd stuff, and I don't have to hear about it for a whole hour.

 

My wife reads my daily emails,

 

Oh, right on.

 

not all of them,

 

Oh, that's cute.

 

but I don't think she's ever listened. She's only listened to my own podcast when I was first doing it. I said, listen to this and tell me what you think in that mode, but otherwise she's never listened to anything that I've done.

 

I know my wife, whenever I first started my YouTube channel, hashtag shameless self plug devops for developers, she watched the videos whenever I first started that channel and offered some feedback. I know occasionally she stalks me on Twitter because she'll come into the office and just say, she'll look at me and say, really?

 

Hahaha

 

You really posted that?

 

That's about where it goes for me too. My wife, when she's bored, she'll hop on LinkedIn. I know because I get three likes on LinkedIn and then a lecture over dinner.

 

Alright.

 

It's a recognizable pattern for you. That's good though.

 

So getting back to topic, if that's okay. I also, I had a thought when you were setting up the premise, Will, about you're a junior, you've just joined a team and you don't have the authority yet to make decisions. I wanted to touch on that. I know this is a little bit of a tangent, but that kind of concerns me a little bit actually. Now I know that that's gonna be true in a lot of places. And if that's a place where you work and... You need to put food on the table, I understand. Do what you gotta do. So standard caveat, don't go bankrupt or let your kids starve by taking my advice. But find a place that values you. If they're gonna hire you, hopefully they trust you. That's why they hired you. Maybe during probation or something, you don't have the same freedom, but you should work on a team where people value your opinion, if at all possible.

 

Yeah, I agree and I think we all have a responsibility to make the team that way as well, you know, sometimes you enter a team and it doesn't operate that way, but that doesn't mean you can't influence it and steer it that way, assuming that everything else in that position lines up for you. And actually that's a topic in... foreshadow my pick. There's a book that I'm reading that will be my pick today and they talk specifically about that in the book that everyone on the team is a leader and part of your responsibility is to follow orders when being led and lead when there are no orders to follow. And I think that's a dynamic that everyone on the team has to take part of.

 

Yeah, I like that kind of dynamic. I mean, again, I'm a really big fan of the, like if it's somebody's responsibility on the team, you're responsible for this portion of the code base, you get to make, you know, most of the decisions within reason, I mean, sometimes you have to interact with other people and then compromises and that sort of thing to be made. But I don't know, just treat people with sort of a degree of... trust and respect and if you're not maybe you should be thinking about why not or if that's not sort of the culture of the team because I have I mean I have also definitely been on teams where people are afraid is too strong of a word but like there's not like an open dialogue kind of without judgment. I remember we had the the show a while back where we were sort of talking more about team culture and this kind of idea that people can just sort of you know raise their opinions or toss ideas back and forth without it immediately being like, you did something wrong or you made a poor decision or you wasted our time or like any of these kind of negative things, just hey, we're all in technology, it changes all the time. We pretty much almost constantly want to be like, reevaluating our options and seeing what else is out there and if we can improve and rework our solutions and all that.

 

For sure. Yeah, and if you're not the new member on the team, I think it's important to keep that perspective as well that ideally you brought this new person onto your team because of the skills and the resources that they'll add to you. So you might as well take advantage of them and set up an environment where they can contribute.

 

Yeah, I do also want to say I agree with Jonathan that like, at some point, if it's just if it's not a good fit, and you know, you're not kind of feeling like you're contributing or growing as a professional or whatever, it probably is time to just move on and get a new job. That was definitely something I wish I had learned like a lot younger because there were there were some jobs that I stayed in sort of well past maybe I should have and I do know. One of the kind of signs of burnout, or one of the precursors to burnout, is like you're working on something but you feel like you're just spinning your wheels and not actually making any actual progress. So like you go in, you know, you go into the office and you sit and you type for eight hours a day, but you're not actually doing it, or you don't feel like you're actually doing anything or making any forward progress. And a few years ago I would have told you like, oh burnout, that's, that's kind of a woo thing. Go have like a really crappy job flipping burgers or something like that. Which I have, I have had crappy jobs flipping burgers and being

 

Me too.

 

a line cook and all that kind of thing. So I was like, yeah, oh, being a tech person, that's so silly, you don't get burned out or anything like that, but you definitely can. And for the sort of longevity of your career, you should maybe watch out for that. And try to get yourself in the best positions that you possibly can. Build leverage, build leverage through your whole career so that you can make the best decisions for you and your family if you

 

You

 

have

 

know,

 

one.

 

when I flipped burgers, people said thank you to me about 50 times a day.

 

Hahaha!

 

I'd put

 

Yeah,

 

a burger

 

I got

 

in the window,

 

tips.

 

ring a bell, and the waitress would come by, thank you. I don't get that in tech

 

I got

 

very

 

snacks

 

often.

 

too. built-in snacks.

 

That wasn't good for

 

Well

 

my

 

yeah,

 

waistline.

 

because you're in a kitchen.

 

Don't all talk at once now.

 

I think I kind of ran out of things to say on this topic unless we sort of have a new

 

I've

 

spin

 

got one

 

on

 

more

 

it.

 

thing

 

I

 

to

 

mean...

 

say about how to convince people, I guess. If we want to go back to that now.

 

Yeah, bring it on.

 

Yeah.

 

One piece of advice I like to give is, so this is after you've done everything I already talked about, you've already done your demo, but you still have skeptics in the crowd, just make it an experiment if possible, you know, it depends on what you're trying to convince them of, but say, what if we tried this for a week or for a month, and if we don't like it, we'll re-evaluate after that point, and decide if we want to go forward, you know, this isn't permanent, we're just, it's an experimental thing. We're experimenting with a Kafka alternative or experimenting with this new way of doing Zoom meetings or whatever the thing it is you're trying to convince them of, right? Or we're gonna experiment with this new framework. We'll build one feature in this new framework and see what we think. Let's try this experiment, reevaluate. My advice, if you do this, is to set a deadline or it doesn't have to be calendar based, but a clear endpoint of the end of the experiment, a point where you're going to reevaluate. So it's not just like an ongoing experiment. We're gonna try. You know, Temple OS now instead of Linux as an experiment forever. And only if

 

Hey.

 

somebody screams

 

Hehehe

 

loud enough will we go back to Linux. You know, it's not like that. Make it clear to find, we'll try this project or we'll do it for a week or whatever. Try it for the duration, whatever you agree with your team, your colleagues. And then evaluate. Honestly evaluate and then make a decision. And the decision could go one of three ways typically. Abort the experiment, commit to it, you know, it's no longer experiment, now it's official, or prolong the experiment. You know, maybe the conclusion isn't obvious yet. Let's try it again for another iteration and see what we think.

 

Yeah, I'm glad you brought that up. That's a really good point. It should be a lot of things that we do should be sandboxed for a specific deliverable. And then I also advocate a lot fail fast, which I know a lot of us have heard Zuckerberg's quote of move fast and break things, which I actually disagree with because move fast and break things doesn't imply any feedback mechanism. I mean, I can log into our AWS account and just start terminating servers right now, and I'm moving fast and I'm breaking things. But really, is that doing anything valuable? That's why I prefer the term fail fast, because when you say fail fast, it implies that you're going to define the failure criteria. What does it mean to fail and how do we get there as soon as possible? So yeah, I agree with you. Sandbox it and then fail fast. Define what failure looks like and success looks like and your job is to hit one of those two points as quickly as possible.

 

I should also clarify a little bit. The ideal experiment isn't just, let's do this for two weeks and then see, but just like Will said, you define your success criteria. We believe that doing this thing will have this outcome. And then either it does or it doesn't, or in rare cases, it's unclear. But a good experiment isn't just throwing spaghetti on the wall and see if it sticks. It's like, I believe the spaghetti will stay on the wall when I throw it. Oh, it didn't stay on the wall. Okay, what can I do differently? You don't, you don't, don't. A lot of experimentation I see, especially on agile teams, scrum teams, aren't really experiments. It's just throwing caution to the wind and let's see what happens. And if we like something about it, then maybe we'll stick with it. And that's not really a good experiment.

 

That's what a lot of research is. That's what a whole lot of research is, especially medical research. Like what was it? I think penicillin was found by accident. Just

 

Which

 

some guys

 

one?

 

screwing around in the lab. I think I want to say it was penicillin. I know it was one of

 

Oh.

 

the antibiotics, like one of the first main ones that was found. A lot of things in science have been just discovered by accident.

 

But a lot of things are valid experiments too. And once it was discovered, I'm sure there were some valid experiments done to prove its efficacy and its safety and all that stuff.

 

Yeah,

 

It wasn't

 

yeah,

 

just,

 

of course.

 

oh look, I

 

Of

 

found

 

course

 

penicillin.

 

there were drug trials.

 

Here, you have some and you have some and you have some. Let's see what it does.

 

Hey!

 

I don't know, I'm not convinced. I think it was like that for a couple

 

I know,

 

years at least.

 

that awkward silence may be justified.

 

Hahahaha

 

All right, well, let's see if the FDA likes that approach these days.

 

Yeah. Yeah, boy, given my past options of working in medical and with the FDA, I should probably refrain from any further comment.

 

Ha ha ha.

 

You learn some wild things, like when you work in medical research, you're just like, ah, I don't, I don't know about any of this anymore. Like I was, okay, like I'm not, I'm not an anti-vaxxer, right? Like I'm vaccinated. My kids are vaccinated. I was a little bit worried about the COVID vaccine. I don't know if we're allowed to even say that on the show, but I really was. And my whole thing was like, I want millions of data points. Like my mom was like, would you feel better if I got it? And I was like, no, mom, I want, I want millions of data points, not

 

Right?

 

one.

 

Ha ha ha ha.

 

Many. I want many. Um. And it was, I don't know, I guess it was all fine. I got my millions of data points thanks to Israel. But, you know, that's what we have.

 

So are you convinced now, Will, that you know how to convince people?

 

I am convinced and. you know, then we always have the old trusty and reliable physical violence. So

 

Yeah,

 

Oh no!

 

right.

 

I'm just kidding. I'm totally

 

Hahahaha

 

kidding.

 

Before you go there, we'll start with threats of physical violence. You know, your cousin Bruno. You know, you don't have to bring out the club just yet.

 

Will just runs into the office with like, you know, like the foam, the foam, like noodles that the kids use at the pool, like, ah!

 

Right? Cheers!

 

This escalated very quickly.

 

Yeah.

 

Well, are we done? Because I have a pick that's actually on topic, so I think it's a great segue if we want to go that route.

 

Oh, there

 

I think is

 

was...

 

an excellent

 

Yeah,

 

segue

 

I think I'm done.

 

to picks because

 

Awesome.

 

Go ahead. Haha.

 

obviously my contributions are going down a not podcast sponsor friendly path.

 

Hmm

 

Does this show have any sponsors like this particular show?

 

Yeah, we do.

 

We do? Oh, okay. Are we supposed to say anything about him?

 

No,

 

No, it's pre-recorded.

 

they actually, the editors put in the

 

And

 

sponsor

 

the editor, please

 

parts.

 

take this part out so we don't

 

Right?

 

offend our sponsors.

 

I know, right? I was wondering if like, is it purposefully kept from us so we don't say anything to kind of put less faith into the into the spots? I'm sure the sponsors the show are wonderfully guys, they're great.

 

Yeah, I know Chuck records the sponsorship segments and then the editor patches them into the episode. And

 

Okay.

 

I only know that because I had to listen to some of the, I didn't have to, I listened to some of the finished episodes the last couple of weeks to create the show notes.

 

I've

 

So

 

listened

 

Top

 

to

 

End

 

other

 

Devs

 

shows

 

is

 

on

 

the

 

the

 

sponsor

 

dev chat.

 

of every episode. And I think we have other sponsors sometimes.

 

Yeah, yeah, we do. OK, editor, you can put us back on the record now.

 

Yeah.

 

Thank

 

Yeah.

 

you. We really do appreciate you saving our bacon and chopping that section out. So on to picks. Jonathan, what's your relevant pick for this topic?

 

Yeah, so I'm gonna pick a book that I read a few years ago, but it's a great book. And honestly, if you're struggling with this, this is the book in my opinion to go to. It's called Driving Technical Change. It's by Terrence Ryan. And it, I mean, a lot of the advice I gave you, I borrowed from the book, but it goes into much more detail. It really talks about know your audience and it goes into like personality types and it sort of categorizes some, you know, the technical. guru guy and the grumpy old admin guy who is all about compliance with this and whatever and how you can address each of their types of concerns. It's really about the soft skills of driving technical change and it doesn't require that you're a boss at all. It's about how to convince people that your ideas have merit. So I highly recommend the book, Driving Technical Change by Terence Ryan.

 

is the final chapter on resorting to physical violence.

 

I think that's

 

Probably

 

after

 

not.

 

the final chapter you have to order that separately. It's a

 

Okay,

 

separate volume.

 

okay, cool.

 

Yeah.

 

So it is a complete guide then.

 

Right.

 

Julian, what have you got for picks?

 

Oh, I don't know. Can you go next?

 

I can't. So my pick is along the same topic. I just started recently reading Leadership Strategy and Tactics by Jaco Willink and it addresses a lot of the things we've talked about in this podcast and how to implement change, how to be an instrument of change, how to work as part of a team and how to lead as a non-leader in the team and then he backs it up with some lessons that he's learned as well. And we were talking just before the recording started here. Jonathan looked it up. The audio book is actually narrated by Jaco himself. So as soon as we're done here, I'm going to go grab the audio book, because his voice, he's got such a great voice. It's just so authoritative. And so I'm actually looking forward to that. So Leadership Strategy and Tactics by Jaco Willink. Do I need to stall some more for you, Jillian?

 

No, I'm good. I'll

 

OK.

 

pick, um, I'll pick Graphics Audio. They are like a book dramatization company. They label themselves as a radio in your mind. And they used to be pretty pricey because like,

 

I already

 

you

 

have

 

know,

 

that.

 

any of the sort of

 

Right?

 

But this has like different voice actors. It's not just the

 

I have

 

voice

 

that

 

in

 

too.

 

your own head, Jonathan.

 

Yeah.

 

There's

 

I've

 

a whole

 

got so

 

cast.

 

many voices. All right,

 

So

 

sorry

 

many

 

to interrupt.

 

voices. Well, they could play nice with these other voices then. Yeah, just forgot

 

They've

 

where I

 

specifically

 

was going. Oh.

 

indicated that they don't like to play nice with other voices.

 

Hahaha If you guys ever read the Brandon Sanderson short story about the guy that, um, that's like his whole deal. He's like brilliant and he makes up all these characters in his head and then they just like go like way off the rails and do all kinds of crazy stuff. Maybe that's, I don't remember the title. I'll make that my pick next week.

 

Okay.

 

But yeah, I really like them, and they've started selling their books on Audible, which makes them a lot cheaper, because it used to be like five or six parts for a Brandon Sanderson book. So I've been listening to all these Stormlight archive books, but the graphic audio. dramatizations of them and they're really good. And besides that, my favorite is Warbreaker in graphic audio. So those are the pick. Graphic audio, specifically anything by Brandon Sanderson with graphic audio, and they are all on Audible or on their website too. They have like a website if you want to buy direct.

 

Right on, cool. I just read that Spotify is going to be doing audiobooks as well now.

 

They already have a lot of the like audio drama things, which I really like. And some of them are, you know, premium, like only on Spotify or, or maybe it's Apple podcasts that they're starting to have them premium where like you have to actually pay to have access and things. Yeah, there's a lot of those out.

 

Yeah, it'd be nice to have an alternative because just like Jonathan, I end up having to go buy audiobooks because I have credits that are about to expire.

 

How can you have credits about to expire? I have the opposite problem.

 

If you have an annual plan, then your credits last a year or 18 months or something like that. So

 

that

 

I had

 

night

 

eight

 

listened

 

that were gonna

 

to

 

expire

 

the same

 

this

 

books.

 

week. So last week I stocked up. I have now, I already had two books in my library I hadn't listened to, so now I have 10, I think. Plus

 

Wait till your

 

12

 

kids start

 

credits

 

to get

 

for

 

into

 

next

 

audiobooks.

 

year. Wait till what?

 

Your kids start to get into audiobooks, and then your credits will be gone. Be all gone.

 

I used to have that problem when I had a daily commute because I was listening to audiobooks

 

Right.

 

two or three hours a day.

 

Yep, same. And now that my commute is just down the hall,

 

Yeah,

 

my

 

I get

 

audio

 

about two

 

book

 

sentences

 

consumption.

 

in

 

All right.

 

and I'm there. And I was like,

 

Yeah. Yeah. Yeah.

 

not even worth.

 

Cool, well I think we have ourselves a podcast. Thank you both for joining us today. Thank you listeners

 

Thank

 

for

 

you.

 

listening in. Hope you found it helpful and we'll see you all next week.

 

Adios.

 

Bye.