32: Large Versus Small Teams

[Music]

Welcome everybody to episode 32 of the Coffee Code Cast, a weekly live tech

podcast from Seattle's Pioneer Square District. I'm Kyle Johnson. And I'm Mike

Sheehan today on the cast. We're gonna do a redux on the Large versus Small

Teams debate that we did back in episode 27, I believe. We're gonna cover Alexa

enabled AirPod competitor that might be coming out here soon along with some

other tech news, hopefully non-Tesla related Kyle, I hope. No Tesla news today.

I hope maybe I didn't see unless you have a hidden script somewhere

I mean we could talk about the wreck that my wife almost had but we should talk about that

That'll be a little bit we'll cover that we're also gonna cover the negative side effects of limebike jousting. Oh boy

And also joining us today on the cast is Mike Davis. We know Mike Michael or Mikey Mike's fine Mike's fine

Yeah, Mike Davis recently joined the team from our Sacramento office

Welcome to the cast Mike. Thanks so much. We're glad to be here. Tell us tell us what you're doing up here in Seattle, man

Just coming up, meeting the team, trying to make a little,

put my little foot in the ground and hit the ball running

and doing one again.

- Yeah, absolutely, man.

Well, we're happy to have you here

and happy to have you as a guest on the show.

We were just kind of, we had a little team building,

I would, you'd say this week, Monday through Wednesday,

we had some guys up here from the Denver office,

guys up here from the Sacramento office,

And I think we're out playing at the old garage,

a little bowling and pool and we were talking

and we said, you know what, man,

this would be a good time to get a guest on the show.

And so here we are.

- Maybe a little alcohol.

We bribed him with some alcohol

or maybe he had alcohol in him to get him on the show.

- Could have been a little bit of both.

- A little bit of both.

- A little bit of both. (laughing)

Based on how that cider's going down,

I'd say that's probably the case.

If you need to step out and get a refill by all means,

just, you know.

- I'll let you know.

- Here's the good news is we had this problem

couple weeks ago where we ran out of beer. Yes. And there was nobody to go get it.

Unless one of us is going to ramble on for a few minutes. So now us two can ramble on

and you can go get a beer. No problem. I think it's a good reason to start having

the guests on the show regularly so that one of us can leave and beer runner, beer runner.

Yeah. Yeah, exactly. Yeah. If you need anything, I'll get you something.

I appreciate that. That's, you know, that's kind of the spirit. We've had a lot of relatively

new hires here within the last four weeks, three weeks. And we're talking about on the

way over here, but I like that's kind of the spirit that everybody's had on the energy

has been pretty high and and all the new guys have been very eager and willing and able

and it's been a fun energy around the office. That's for sure.

Especially with all the yeah, even with the new guys and the people from out of town.

Yeah.

Young and old, I guess you might say.

Young and old.

Seasoned and not.

Yeah, well, it's just cool to see how the team has really grown over the last several

years too because we have, the old stand up used to be about eight or nine people and

there was, that was everybody from the ops guy, the systems guy, the developers and the

product manager and now we, I think on our last Tuesday call had somewhere near 45 to

50 people on that team stand up.

Yeah, it's just a small little group.

Yeah, exactly.

How was it? How was our things this week for you, man?

Did you have a good trip up here? You're going back tomorrow, I think.

Yeah, leave tomorrow afternoon. It's been great. I mean, everyone here is fantastic.

The team is amazing. All the people here are great, fun to work with.

And, you know, I couldn't be happier to be here.

Where did you come from prior to here?

I don't think I've talked to you too much before about any of this or I'm not working

on the same team as you. So where did you come from?

Sure, I'm originally from Maryland actually. I moved out to California about three years ago, and now I'm living up in Vallejo, just a little town north of San Fran.

And in terms of work, what were you doing prior to coming here?

Before I was doing some dev up in Maryland, and then before that I was in a touring band doing the music gig.

So he's comfortable on the mic?

I would say so. I was a drummer. I didn't have a mic.

(laughing)

Fair enough.

- That's nice to have on, you know?

- Yeah, absolutely.

- Finally.

- We're really glad that the whole group could come up

and we've had a really good time.

So good in fact that we had to cancel happy hour last night.

We were all just a little too bushed.

I mean, we couldn't handle it.

We can believe that.

- I didn't know about a happy hour.

- Well, it was just gonna be for the touch point team.

- Oh, that was after the lunch

that I didn't get to go to either.

- Hey, I didn't send that invite out.

I know he was a little--

- Somehow you were invited about,

I don't know how that worked.

I got that text from you and you're like,

"Well, how the hell did you?"

I told Brad, I said, "Kyle was wondering why

he didn't get on the invite list for that lunch."

He didn't have anything good to say.

All right, well, let's move on, shall we?

A little follow up.

Got some of the feed issues finally resolved.

We had a ton of podcast feed problems

where various apps weren't updating,

primarily Pocket Cast, which is the one I use.

Tune in wasn't updating, Stitcher wasn't updating.

bunch of them. So worked this week a bunch with all of those

different providers. And I think we've got them all finally

squared away. So if you weren't getting any episodes, which you

wouldn't know because you weren't getting them, they should

show up now.

Well, I guess that's how you know is that for pretty

consistently now, this is the ninth or 10th installment of our

weekly live cast. Yeah. So you should see something every week.

If you're not getting something once a week, something could be

brought broken.

Probably on Thursday or Friday.

Right. Yeah. Yep. Do it live Wednesday, post it the next day or so.

Yeah. So the problem was we changed providers and so I had to change the

RSS feed links and that should be respected across all different applications,

but the problem is a lot of people hold on to the link and you can't change it.

So in the case of Pocketcast, they had our old link,

they're our old RSS feed set up and I had to force them to change it. So,

just a pain in the ass to go through all of them one by one,

but I think we're there and everything's updating finally.

And it has the updated art, which is another thing.

like tune in didn't have the updated art neither did it neither did itunes for that matter.

Okay. Yeah. Now we have the updated art on everything. Yeah.

Thanks for a buddy. Your name, gentle. I was just going to give him a shout out.

Exactly. Thank you. Yeah. And we got some stickers here. Yeah.

I need to give those out.

I should have brought some to the offsite and plastered them all over the bar that

we were at. Yeah.

And I just see that Mr. Pyle needs a sticker for his Kegorator.

We will absolutely do that for you, sir. That'll be on the way.

If you give me some more,

I can plaster them all over Sacramento and San Francisco.

Yes, we've got a whole stack.

We'll give you a fat stack to bring back.

No problem.

Oh, that's sweet, man.

That'd be awesome.

Thank you.

Definitely.

Yeah, that'd be good.

It'd be good to get some more regulars outside of the--

we've got a good group in the Midwest, respectively,

we're from Nebraska and Iowa, and a good crew here in Seattle,

and a few people sprinkled other places, too.

But it'd be nice to get some more over there.

I know Lyman was listening in Denver a little bit.

it. So, and we can bring you on if you want to come back on later. We have a lot of different

ways we can bring people on through this board. Sure. Yeah, exactly. Oh, no way.

Your Lex Ann said she saw a sticker in Iowa on Saturday. Well, there you go. That's my

sister. She's listening. Listening live. Listening live. It's eight o'clock two over in the central

district, central time zone. Central district. That's where you live, central district. It

gets changes over there a couple of blocks out. Oh, funny. Well, yeah. So what do we got

But here, dealing with injury, yeah, we can jump into that really quick if you want.

Yeah, I've seen you walking around the office a little bit gingerly this last couple days.

Yeah, well that was what I was talking about earlier when I mentioned the negative side

effects of line bike jousting.

So I don't know if everybody knows what line bike is.

Most people out here do, but we have these battery powered bicycles that are just littered

across the sidewalks and streets and you can scan a barcode and unlock the thing for a

$1.00 and a few cents a minute and so yeah during some

shenanigans on Saturday

I took one with a buddy of mine and we were cruising down ox in my defense like Occidental is a really shitty street like ever

Go you're walking to the baseball stadium

There's potholes and there's brick. It's just a very mixed

It's not a great street. I wrote down it today. Yeah, it's a little bumpy, right?

And it kind of weaves a little bit. It's not it's not a smooth trail or anything by any means

Anyway, we were doing that on Saturday and trying to get around some people and I

Wasn't quite paying attention

I was messing around with my buddy and hit a pothole and lost control of the bike and at decent speed

Just like went right into the curb and my ribs took the impact

It's interesting these say that's on Occidental because I ride my bike in pretty regularly

and there was one morning where I was coming in and

Occidental has some parts of it where it's not a road. It's just a big walkway pedestrian walkway

But there's a couple gutters that they've kind of built into the brick. Yeah, and

There was somebody in my way as I was coming on and so I had kind of tried to go across the the gutter

And it was slick that day wet

So the brick and being wet like Mike the bike just went like straight out from under me

And I crashed into the into the gutter and that that hurt pretty bad and was embarrassing because it's right in front

Of the person that I was trying to avoid. There's tons of people there

Yeah, that's problematic too because yeah, the way they slope that and if there is water in there, it's terrible because you're not

Unless you're going perpendicular to it

You're kind of taking it at an angle and then it's just like that momentum getting up there will just kick out

Yep, and especially on a bike like mine at the road bike, but the tires are super skinny

So there's like no grip there whatsoever versus like a line bike. I think the tires are much thicker. Yeah, it's more of a

Yeah, the handlebars that are awkward for me on the line bike. Yeah, they're so close together. Oh

Oh, having a little more. Yeah. Yeah. Yeah. Interesting. Yeah, it wasn't

pleasant and I didn't like the first day it was okay. But then like

Sunday night, Monday night, like the last three nights, I haven't gotten any sleep. I've been up every few hours and it just really hard to like

I'm a side sleeper. And so it's hard to sleep side like on your side with a rib

injury of any sort. But no bruising. You're not seeing any bruising. No, it's got to be all internal or deep.

I don't know. It's just yeah, there's no nothing yet on the surface. It's interesting because it's not yet

That's a sign. I

Mean it's better during the day and then at night

It's really it's like a cold or anything else like a two in the morning. It'll just feel like I just did it again

I had a similar experience and I think I talked to you about this already

But I I was learning to snowboard and I was pretty bad at it. I'm still not great at it

but I was pretty bad at it and

Did a thing where I caught the front edge and it slammed me down on my face

And I didn't even have enough time to get like my hands away from to put them out or anything like that

And so I ended up landing like on my fist kind of same scenario

So right into the side of the ribs and yeah, they ached for like probably a week and a half

Mm-hmm never went to the ER or anything because I think I came across the same type of articles that you'd had mentioned where basically

They said if you broke a rib like tough it out because there's nothing they can do about it

That's right. Everybody I've talked to and all the reason I've been researching at the last couple days

Should I go into an urgent care or go get an x-ray done and they say well you could but it's not gonna matter

It's just gonna you have to deal with it. Maybe they'll maybe they'll wrap it or something

But yeah, it's not gonna do anything. Yeah, and there's even been some there's something some things out there saying you shouldn't do that either

Like that is not always a good

recommendation of course you'll find contradictory info on the internet about everything but

I'm just dealing with it, and I don't have any fancy drugs either

Maybe a couple Advil if it gets really bad

Diagnosis is the best way at least that's what I found. No, yeah. Yeah, so

There you go

We're dealing with it deal with injury, but you know what that's not stopping us from putting out episode number 32 today

That's for damn sure. That's right. I didn't think you were gonna be here. Yeah. Well, I was I slept in this morning

So I took the morning off and then did a little bit of work this afternoon and got my ass over here for the for the podcast

Right on boom

Well

Yeah transitioning into that

Like I said in the intro our topic is about

Kind of going back to the discussion we had on team structure and how you organize your teams a while ago

And I thought this was a good topic Kyle. Thanks for bringing it up again because we've kind of done some stuff at the office since then

-

I don't get that never mind

We've done a few things with the teams here and we have a little experience now with

with different team structure.

And I think it'd be fun to talk about that a bit.

And yeah, why don't you take it off from there?

- Well, so if you didn't partake in episode,

what was that, I say, 27?

- Yeah, 27.

- Don't rip my nuts off episode?

- I know, it had nothing to do with teams,

it's from the title.

(laughing)

That was a little tale from back in the day,

with the college story.

- Right, so I shared a little bit about an idea I had

and was sharing around the office,

of splitting up the teams into kind of two larger teams

instead of currently in the Seattle office,

at least we have a whole bunch of onesy, twoz teams,

probably five of them maybe.

- Which now, to be fair,

like they're probably more three to four now, right?

But yes, like still, we've had very siloed.

- Yeah, traditionally, we've had only a couple of people,

maybe even one in a lot of cases working on a project

and a lot of projects going at the same time.

So what I was trying to advocate for

was basically to divide the teams up into just two, maybe three, with much larger groups

working on a given project.

So today I brought that up in our tech management meeting and got a question.

It was not a major, it wasn't a big deal.

It was just, I got questioned on it and didn't really have a clear response.

It kind of caught me off guard.

So I basically wrote out a more clear and concise reason as to what it exactly it is

I'm trying to accomplish and why I'm proposing this.

Yeah.

And so that was basically why I thought maybe it'd be interesting to revisit this because

I have better thought it through, I guess.

Yeah, that sounds great.

So the first one is to kind of make more clear the capacity that we have available at Quotewizard

in terms of a tech team.

So today, if you look down on the tech team from the executive level, you would see five

teams, right?

Or however many teams with one or two people on a team, and you'd be like, "Who's available?

I have no idea. What are they working on? Right? You have only a,

you have just kind of a weird dynamic with how many different teams there are

and how few people are on the,

what are the teams? Where's the project at? Right.

How far along is it? What's left to do? Yeah.

Whereas if I think if you have two, it's much more clear.

I have these two teams, they can handle one or two projects each.

Those are in flight. That's what we have capacity for, right?

So I feel like it just makes much more,

much more clear the ability to push projects into the funnel.

It also makes it come to a much more fine point.

Right, you can't have seven projects running at one time.

You can have two to four.

- Right. - Right.

- I'm curious to know your experience, Mike,

when you were working at your previous places out East,

big team, small teams?

- I would say teams of five to eight.

- So a little bit like mid-sized,

mid or larger team size.

- Yeah, it's interesting his comments

because my last job, or two jobs ago,

I should say we had three teams

and it wasn't project oriented actually,

it was one team would work on bugs for a quarter,

one team would work on features,

one team would work on performance enhancements.

- Interesting.

- Random other things.

And then we'd rotate every quarter.

And I think we had probably seven to 10 projects,

but it would get funneled down to two to four.

We'd work on X number of features and those two

and then kind of push forward that way.

- And what was the team makeup?

Like, was it all developers?

Was there an architect?

Was there a manager?

Like, how did the team get made up?

- So we had a central DBA who kind of handled

all the projects at once, which, you know,

they were a separate, I guess, group at the company.

And then each team was like a team lead

and then a various number from senior to junior.

We wanted the juniors to get experience so that they could move on to other projects and

enhance their careers and get more experience across the board.

Yeah.

And everyone there was full stack.

It wasn't just like we had front ends and back ends.

It was all across the board.

So it really blended to that and gave us a lot of experience.

And I think that's the approach that we're looking to do.

I was also advocating that you'd have a PM potentially on each team, architect on each

team, maybe that's also the lead, I don't know, up for debate a little bit. But yeah,

it sounds like a very similar structure, a similar number of people, kind of what we

were talking about or what I was proposing. Yeah, we usually had, aside from the devs,

we would have two QA on each team and then a PM for each team too. Okay. We don't have

any QA here. We did. Now the devs are QA now. That's right. Or those unit tests that we're

right and right. Yeah, end to end test that don't exist.

Well, that's interesting. Okay, so I think that, well, my

experience before had been really small teams. I mean, I've

been at places where I was like a team of one, or just a couple

people working on stuff. So it's nice to hear other

experiences there. And I think, lend some credibility to what

you're trying to say here, like why it makes more sense to have

larger, more focused teams.

And it's funny to hear you say, we say that we refer to like five to eight as being a large team, like I think anywhere else in the universe, that would be a pretty small team.

Probably.

Yeah. So I think we're, we're talking a little different than what most people would experience.

Yeah, that's fair.

- Yeah, that's fair.

- I think if you have more developers than that,

the communication and just giving them

the certain things to work on,

just spread yourself really thin in terms of,

there's only so much that so many developers

can work on at a time without being blocked

by someone else, you know?

- Right, and that's an interesting point too,

because with Everest Project,

there was a point where even they were thinking

about storing you on it, and I was like,

well, there comes a point here somewhere

where like more bodies doesn't help.

- Right. (laughs)

It gives you another set of problems now.

You've got people working and doing the work,

but now it's about finding the work or,

I don't know if that's even fair to say finding it,

but just making sure there's enough shovel-ready work

to keep everybody going.

- Or you end up taking a drain on the people

that are experienced on the project, right?

Because now those kind of senior people have to

be like spread super thin with all the new people

trying to get the knowledge out to them

and help them to understand the project

and so on and so forth.

So eventually you get diminishing returns.

- Yeah, for sure.

- Adding someone new to the project,

you basically lose one other person on top of it

because they have to give the other person,

the new guy the experience

so that they can actually do something.

- Although it'll be fair and to your credit,

I've heard good things about you.

Like everybody that joined the team,

like they were super eager to go

and were self starters and just jumped in

and didn't really require a ton of guidance.

It was pretty nice and surprising from my perspective.

Yeah, I think that's-- it's been the smoothest hiring cycle

that we've had here before.

Probably the most talented group that we've

hired on in one round before.

So I think that helps for sure.

But yeah, I think that we've--

it's taken some overhead to get everybody going,

but it hasn't been as problematic as other times

in the past where I feel like maybe I'm

spending half of my day or something

like that, working with the guys to get into the system

or all kinds of stuff.

It used to be the case too.

It would take a couple of days to get the machine up

and running, and it seems like now that we've

been able to get around that, and it's pretty quick.

Right.

All right, so let's move to the next one.

So the next one is kind of to create focus, which I think

we've touched on off and on a little bit here.

But it's mainly like the idea that we used to shuffle

projects quite a lot.

You would go from one to the other to the other and back.

And now we have, or in this scenario,

the work would hopefully be queued up way ahead of time.

So you'd be working on a concrete number of tickets.

There'd be no change to that sprint, ideally.

And there'd be focus on just that particular project

or that sprint that you're working on

and getting that work out versus the randomization,

as we like to say here a lot.

So it gives developer focus,

gives them more time to create,

More time to be kind of in the zone, so to speak.

So yeah, to your point too, like I did it outline here

as well that you may have, let's say if you go

with the two team approach, you have one,

you have team A working on a full project.

Maybe team B is working on a small project

that doesn't require a full team,

plus maybe bug fixes or something like that.

So you can divide it up, what makes logical sense,

but that would be up to kind of PM and the business

to figure out what needs priority, right?

- Yep.

anything else? No, why don't you crack a beer for me there please? You got it. There we go.

Now I'm feeling better. Now that rib pain is going away. That's excellent. Alright, so the

third one is to remove silos. So this is a big problem that we suffer from here and I think a

lot of people can, what's, well, a lot of people can identify with this I think because basically

we have a lot of knowledge holders that have been here for a very long time.

They've been on the same exact product for a very long time and the knowledge has not spread.

I mean it has some but it hasn't spread effectively to other members of the team.

So we need to get kind of cross-pollination as we like to say

to other developers so that they can learn the products more quickly and if we lose

one of these knowledge holders that we don't lose, you know, ten years worth of information.

Well, that's part of the problem if you're always on the same project for 15 years or 10 years or five years anymore then

And you're gonna burn out, you know, like for some of these guys

I know that you know are stuck on some corner of the legacy application because they're the only ones that understand it and only

One's comfortable enough to deploy it

That's that's great. But then you know those guys are pretty tired of dealing with it

Want to do some fun stuff one who advanced their careers and so yeah, like you're gonna you're gonna lose them to burn out or or

Or in order to prevent that, you got to keep them fresh,

keep them on new teams, move them around.

Not even circles right back to our last topic.

All the more reason to make bigger teams.

Maybe even just have a team where it's just nothing but knowledge

transfer from executive people to the new guys.

And then now your executive people

can go work on other projects.

And the new guys can maybe take over the old ones.

Yep, absolutely.

I mean, we've done a little bit of that

we've brought in some of the newer guys to work alongside some of them those guys on

rewriting our legacy applications and that's been pretty good but then we still need to

keep that process going like now I think we had you know the thinking of our our distribution

project and so we've got a very senior guy that's been around forever that knows how

it works a couple guys actually and and one of the newer guys stepped up to take that

on and has done really well but it's been a lot for him and I know that he has aspirations to

other things besides just back end coding and so it's like what do you do there like he's got the

knowledge now but you also want to even make it more broad than just one person one or two people

right and I think we've done this pretty well with all the new guys that have come on like they're

all learning from some of the people that have been here for a good amount of time so we are

getting some knowledge transferred there it could be it could be greatly increased and I think that's

kind of the vision and the goal. But it also creates problems because you get your business

stakeholders who are like, "Oh, well, this is going to slow the project down." That's valid.

It certainly can and will. To give you an example, when I was talking about the two-team

approach, I was like, "Well, you could kind of like back on the old high school playground,

you can just kind of like one, two, one, two, one, two, number everybody off, right, team by team."

So ideally, then you have two teams that are pretty cross-functional. They have a member

of every product on each team. So somebody who can help spread that knowledge and transfer

that knowledge amongst the team. Or there's the approach like you mentioned where you

could just have one team that's kind of focused on that specifically.

Yeah, to add to that, I think you mentioned that it might slow down the project. I think,

you know, if you're looking short term, yeah, but long term, you know, after they learn

it, I think it's really going to enhance the amount of time.

Absolutely. I would totally agree with that.

Right.

So it's a question of investment.

Are you willing to make the short-term investment for the long-term gain?

And if so, then that makes a lot of sense.

And I like that idea of the bug team because that's something that I thought about the

other day when we were talking about this is even on the current project, the Everest

project. Once that's across the finish line, it's never really over. There's going to be subsequent

work, maybe new features, but then also maintenance and bug fixes and that sort of thing. And so you

kind of get stuck. I know that our Denver guys ran into that after they came in. Big team had all

the right players, got to do a big green field development. And they did and they kicked ass and

got it done early in the head of schedule and under budget, right? But then it was like, okay,

time for the next project and they're like, well, we can't all go over there because we're still

doing maintenance and new features. So I think that model that you're talking about seems to

make a lot of sense because you're always addressing those things just going to fall on a different

group. Right. And then that even lends to, you know, all right, stick the new guys on bugs. And

then now they're learning the project slowly, but they're learning, you know, because they're

working on the bugs, you know, and they're hopefully not a little more time, but yes. And it's,

it's a good comfort level too. You're not getting way out over your skis like, hey, we need you to

to architect this thing, you know, welcome to the team.

- Right.

- Do you guys label your bugs from like P1 to P5

and all that?

- Ooh, I don't know about that.

- In terms of how serious they are.

- I don't know that we have a SEV system anywhere.

I think that's been talked about,

but I don't know if we've actually ever implemented that.

- Yeah.

- We did that at my last company, you know,

new guys would get the P5s to P3s

'cause that's the easy stuff that, you know.

- Oh, I like that a lot.

- It's like, kill them.

- That's a cool idea.

- And they're still learning.

- Yeah.

No, that might be something to consider though,

because we are going through this process revolution here where we didn't have any and now we're

getting a little more mature and that would be a good thing for us to have.

And then you don't have to really necessarily take the seniors off the project.

They can still work on whatever they need to.

You might have a question.

The new guys might have a question or two and they can learn their knowledge.

We had two levels of bug type stuff.

We had the bug and the hot quick one.

HqO the HqO which were never hot or quick nothing nothing like yeah, the name was very misleading

It was some it was a sneaky way to get tickets in the door to break a sprint open

Well sprint would be a yeah, that wasn't really a word. We just had

Look over here look over here. Yeah over here. It was a way to crack into the waterfall. Yeah of development, right?

It was like, hey, we we know the regular tickets are just this is just a graveyard for ideas

Here's some scope creep.

So yeah, we'll throw it into an HQO and all of a sudden it's got everyone's attention and my stuff's getting done now.

So something you said that was interesting too, you mentioned the Denver office.

This whole idea actually was kind of founded on the idea of the Denver team.

So I had been in Denver for a quick, I don't know, just...

You were there about a month ago, I believe.

Right. And just kind of seeing how their process worked and how they did things and that sort of thing.

And even before that, you know, they were kind of here, portrayed as kind of the rock star team, right?

They got Delty out with no problem. It was super quick, super efficient, super organized, yada, yada, yada, right?

So I was kind of looking at them like, what do they do differently than we do?

So that's partially where some of this comes from and watching their process, watching their standups, watching them interact and seeing how like much

collaboration and communication they have was really inspiring.

And to that end, like the Everest team, my team, uh, this, the last couple

weeks, it's been really, really awesome to see them do the same type of thing.

Like the team got bigger.

There's tons of communication happening between, you know, everybody, new guys,

old guys, cross between the two.

Got the stand up on teams on the, yeah, online.

And there's a positive energy.

I think it's, it's been really energizing.

Like you said earlier on in the, in the beginning of the show, uh, provides a

lot of energy, which is really cool.

Well, it's the right size.

It is sized appropriately because even though there's

a couple guys I know that are more senior on the team

and on the project in terms of just longevity that are

getting squeezed, I think that there's a lot of momentum still.

And I think if the team size is too small

and you're trying to do this, then you're squeezing the guy

and there's no momentum.

And maybe on the flip side, like you were saying,

if it's too big, then there's also no momentum at first,

just because there's too much knowledge transfer occurring.

But this seems to be the sweet spot

where we're taking a little bit of time from the guys to get education, but then running away with some things and getting stuff done.

Moving along.

Yeah, I would agree with that. I don't it's hard to gauge exactly like what what obviously the manpower helped. Like I'm not going to try and discount that at all. But we also kind of cracked over a major piece of the project at the time that those people came on. So I think both of those helped immensely to propel the the velocity forward, which has been really, really great. But before that, definitely felt like we were just kind of like barely slogging through and just

not making any progress, at least not quickly.

And now it's a much faster direction.

- The other thing I would say too,

is that what's made this successful

is the amount of legwork that went into

teeing up this project.

I mean, you guys spent more time than any project

I'm aware of here in this office anyway, in Seattle,

getting it ready.

And so whether it was that process you guys had with,

I think you had the external UX guys

that we're working on the prototypes earlier,

the wireframes, but you had a lot of this stuff already

and Jira already in ticket form ready to go.

- So the tickets are there,

I wouldn't say they're completely flushed out,

but in terms of this company,

there's a lot more planning that went into this project

that I've seen of any other project

and that's a testament to Ali Gress, not to myself.

I had nothing to do with any of that.

- Oh, right.

- So kudos to her and kudos to all the time she spent

creating tickets with the stakeholders and that sort of thing.

So, but yes, it's a new leaf for this company to be organized,

which I don't even know that I would consider us that organized

at this point, but it's much better than it was.

- Well, I think it's easy to make the argument

why you need to have more PMs,

which we've, I think to their credit,

they have done a good job of bringing people on.

I appreciate that because I think there was a time

when it was hard to convince that that was a value add.

And if we didn't have her work and her time on it,

we would have be out of tickets

and there'd be nine guys looking for work to do.

- Absolutely.

- Or creating work to do, which wouldn't be helpful.

So.

- And investing in that extra time, you know,

helps flush things out and that prevents scope creep,

which makes sure that things stay on.

- Yeah.

- Right.

And I don't know how many times

people will come to me looking for work

and I'll be like, well, maybe Ali has something for you.

Like, if I didn't have her on the project,

I would be buried.

So, yeah, I think PM,

The PM team has proven their worth many, many times over in the short amount of time that

we've kind of put them back in place here at Quotelizard.

No, she's a rock star, man.

I can see it with you guys, and I've always envied the team from afar because I was doing

other things and I just thought, man, the way they're setting this up is it's going

to be successful and what a fun team to work on, too.

So the next item on the list here is I had, and I think we alluded to this already once

before, is preventing burnout, which is a big one because we have people that remain on

projects for years, many, many years, oftentimes.

I'm all too familiar with that.

Oh, tell me, tell me more.

You know, just being stuck on projects for nine months a year by yourself, you're

burnt out when you're, especially when you're working, you know, 60 hours a week,

just trying to get it done.

It's a blessing and a curse, right?

Because you want to prove yourself and like, Hey, I'm here, like, give me stuff.

And so it's like, okay.

Right.

And then you prove that you can do it.

Right.

And they're like, cool, man, stick with that.

And then they just want to keep throwing more and more at you.

Like, Oh, you did that.

A cool, let's add this to it.

You know, yeah.

And there's no exit strategy.

It's just, Oh, our plan is to keep him busy as long as he'll say yes.

Right.

And it's a little unfortunate too, because as the more you hop projects and the

more you kind of work with other people, the more you learn, like, uh, if you're

stuck on the same project all the time, you're probably not unless you're a very

good, like self-starter, self-learner and are able to implement those things into

an already existing project, you're probably not getting deflects that creative muscle.

Right. I think that's like the biggest thing of why people probably get burnt out. It's

mundane, it's redundant, you're not doing anything new. It's not helping your career for sure.

Well, and especially, I think we talk about this a lot on the show, but with how often things change

now, it is a risk because if you're doing something in the back end for very long, then by the time

you get back up to the front end again, you've missed out on a couple cycles of change.

Right. This frame works out, this one's in, the versions have changed. It's crazy. I'm

working on a little side project that has some code in it that's from, that I had written

back in the day, it was an app that I had written back in 2013. And I'm trying to work

with it now and there's a couple problems, like one that's like a .NET MVC app that's

no longer supported because now everything's going to dotnet core.

And, you know, so like that's one problem is that it's hard to get support on this stuff.

It's kind of end of life.

And the other thing is like even just simple things like the CSS framework,

I was using an earlier version of Bootstrap, like Bootstrap three,

which now what like four is out and five is on the way.

And so like even just within that, because it's a few versions out of date,

trying to update that to the newest version breaks a lot of code.

because, oh, we don't call it the same thing anymore.

There were breaking changes that happened.

And so, yeah, there's just a constant evolution.

And if you take too much time off as my point,

then you're just going to be so far.

It's going to be so hard to catch back up.

Right.

And then again, that circles back to why the big teams are

good, because then people are constantly learning.

You might come off.

You might not.

Now you need some knowledge transferring.

They can provide that.

You're right back in it.

Absolutely.

And so I think, yeah, we have people here

that I already know, I can tell you for sure,

are burned out, right?

There's a number of people even on my own team

that have expressed interest in moving to other teams

are tired of working on the product.

So I mean, I know this is a problem here.

It's been told to me by a number of people.

So I think it's something we need to address.

And I think this could help.

- This is, I mean, this topic on burnout

is probably the biggest reason for cycling teams like this.

- Well, and the other thing is you're completing projects

at a much faster rate, so you will also be moving on

to other projects, right?

In addition to, you know, maybe you work on multiple

projects during a sprint, but also you're, you know,

in the case of Everest, right?

We're gonna pump that out, and let's say that the team

continued, right?

Then you would go to another project, probably some

large scale project.

So you're getting a new project every six months

or sooner.

- Right, that's exciting.

It's something to look forward to.

I know for me, if I can have some kind of short term

window, six months, even nine months or something to say,

OK, you know what, maybe it's a little tough,

maybe I'm kind of tired of this piece,

but I know that in a few more months, it'll be over.

I can move on to something else.

That's cool.

Yeah.

And I think one of the things that you alluded to earlier

too is the speed.

There'd be that initial slowdown.

And that is true.

But the other thing to mention here

is that as a team becomes cohesive and people work

together more and more and more and we figure out

how to build products together, that team

is going to just accelerate and the velocity is going to go like super, super quick,

even comparatively to what they do today. So like, yes,

there's going to be a temporary loss at the beginning,

but your speed at the end is going to be probably a scale factor bigger.

Yup. Not there, but then you, the team gets stronger.

Everyone trusts everyone more. Everyone knows that everyone can do their job.

You know, it's, it's like a 10 fold thing. It's not just, you know,

I'm learning something new. It's immensely going to help the company.

He said the team gets drunker.

I hope I didn't say that.

I need to go get another one.

Yeah, man.

There you go.

Oh, here's another cider for you there, a virtual cider

for you, sir.

Thank you.

Yeah, I agree with that.

I think there's another component

that we haven't discussed that I don't see on the notes,

but I think it could come into play here, too.

And that's just some of the interaction across team.

Not only does it help foster better relationships

on the tech floor, but then developers aren't always

interfacing with the business.

But sometimes you do, and if you're on a project,

there's a chance at some point you're

going to have a meeting or some other thing like that.

And this would be a great way to get

to meet people that are not on the tech floor.

Because I think we're not great all the time as developers

to go initiate those types of contact.

And if we're just stuck on one aspect of the company,

then there's some people that we never

would have to come into contact with.

This would be a great way to kind of build those relationships.

- Yeah, that definitely helped at my last company,

rotating the teams every time we were,

okay, now we're on new QA people, new PM,

so it just helped build those relationships

and ensure that across the board, everyone trusted us.

A PM was never worried like,

I don't know if this developer's gonna be able

to get this done in the time.

- Well, I think that's a good point

because we've had a lot of that in the past too,

where it's a NUS versus them kind of a thing.

We're always fighting that,

trying to break the barriers down to say,

look, you know, we're all after the same goal. Right. And if it

does help, if you have a relationship, then it's like,

okay, they're not just out to screw me, or they're just trying

to do the pursue their own interests. So man, we're not

we're come up with a lot of negatives here, Kyle.

Yeah. So we'll move on to the last one here. And the last one is

just that it's a moment of opportunity. So we have two very

large scale projects that are kind of running together. And in

theory will come to a head kind of at the same time, you know, in a couple months will

be completed and launched.

So in theory, this isn't going to happen, but in theory, all these resources are now

free to go to other projects, right?

So this would be in theory, a pretty good opportunity or a pretty good time to test

the waters for this kind of idea.

So suddenly you have all these resources available, you could try splitting them into

those teams and start that process.

So it's just a good, it feels like a very natural point in time to do it if you were

going to do it.

What kind of reception have you gotten thus far?

Can you talk about that a little bit?

So I would say it's been mixed.

I think there's been, you know, some people that think it's a really pretty good idea

in terms of, like I said, the numbers, learning from other people, the things that we've talked

about here.

The negatives are mostly how to portray to the business side, because in their eyes they're

are losing a resource potentially.

- Have them listen to this episode.

- There you go.

Yeah.

And that's partially why I built this list.

- Yeah.

- But it's a valid concern, right?

Traditionally, resources have kind of been bound

to a business owner in this company.

So in their eyes, like, okay,

now I'm losing my five developers or whatever, right?

Like they're being allocated to somebody else.

So that is hard to deal with.

We just have to portray it in a way that makes sense.

The other thing is we have to, and I think Tom Nash has been working on this really hard.

We have to come to much more of a fine point, which we talked about earlier also about what

projects that we're going to ingest and pass to the tech team.

And they need to be vetted and prioritized against each other and then well fleshed out

with tickets and so on and so forth.

And then those are the things that come to the team and the business owners prioritize them

against each other.

Like it's not a resource game anymore.

Like you can have more resources if your thing gets vetted above somebody else, right?

Well, here's been the problem with that in the past because I would argue that we haven't really been tied to business units in a proper fashion

I'm not challenging you, but I'm just saying that like this idea that somehow like dev resources belong to a particular

group a functional group in the business

Hasn't really been fully baked. I feel like there's two ways you do that like one way you do that as you say look

you know what business unit if you're responsible for widgets and you know and and there's another part of the business

It's doing some kind of service thing. Okay fine like the widgets group they get to hire their own

Resources and it's gonna go against their cost center and it's gonna if they're making money

Then they can get budget for that and if they're not then they might have to lose something

But we don't do that we say oh tech, you know, you're just overhead and your kind of this internal resource

you're kind of this internal drain.

- OPEX costs.

- You're an OPEX, exactly.

And so then you have people saying,

well, that's my guy, this is my guy,

but it gets diluted because you're not 100% one person's guy

and you're kind of seen as a cost

instead of part of that team.

So my feeling is if you're gonna go that route

and you go all in on it and you say,

look, we're gonna have each team have their own resources

and be responsible for that.

showing that it's working out, that it's profitable, right? And I'm not, I don't think that's where

we want to go. I think we're better off staying kind of centralized because we're still pretty

nimble that way and we can get a lot done. And for what we're trying to accomplish as a company,

I think we do a lot better that way than we do when we're spread out. And so yeah, like for that

reason then let's take full advantage of being a centralized tech resource and

have some real firepower and momentum and get stuff done through the door.

And that's how you do it. You have a couple large teams that focus, have to

have some tough conversations upstairs, but if it gets the green light then you

know what? We're gonna get it done, we're gonna get it done right quickly with a

lot of people, a lot of focus. Yeah, I think we're a resource of the company,

right? Not of a particular team. And so it should be on the business to

kind of identify what it is that they want to shoot down our direction and how they want

us to work on it. And yeah, exactly to your point, like the larger teams that we have

that work together the longer, the product's going to be far better. It's going to be far

more consistent, better thought out, so on and so forth. So it's just going to be a better

product overall. Yeah. Yeah.

That's good. Well, I'm excited for the conversation here anyway, see where it goes. And curiosity.

does dev play much part in helping build out, you know,

initial requirements and things like that

with the PMs or anything?

- Hmm, you take that one because you've been on this project

for, I feel like that's the best example is your project.

- Currently, I think probably it is,

at least from the Seattle standpoint,

I can't speak for Denver or how Sacramento works.

But during the process for Everest,

the tickets were created and then any question marks

that came through usually were involved.

I was involved or somebody from the team was involved

to help get better understand how that might work

if there was any questions.

But most of it was just user stories

with the business stakeholder

that or quite a number of business stakeholders.

- Okay.

And my sense in Denver in the beginning at least

was that you had certain players.

So maybe not all the developers were kind of

huddled around the table,

but you had a few key people or a lead

along with some of their guys kind of facilitating that.

- Okay.

That's how we did it at my last company.

It believes maybe some senior people would sit in

and flesh out all the requirements.

Mainly to make sure there's not gonna be any scope creep.

You know, they can add their two cents.

The PM might not fully understand the nitty gritty stuff

that's gonna go into it.

And so they can learn their knowledge and say,

hey, that's actually gonna take 10 times longer

than you think it might.

- Yep, yep, exactly.

Yeah, just to kind of vet it a little bit.

So yeah, that shouldn't be a problem.

It's kind of a smoke test.

Yeah.

And that was another one of the things that came up too

that's kind of been a, how do we handle this?

Is we don't really have tech leads.

I mean, you maybe could consider me a lead.

I don't know.

I'm titled a manager.

You could consider Rain a lead, but he's titled an architect,

I believe, or a senior.

I don't remember what his title is.

I mean, I technically am.

Do you have a lead title?

No.

Yeah.

So is this a matter of like, who are they?

Who are these people and do we have people

that wanna step up into those roles

if that becomes a thing?

So is this more of a question of like personnel?

Do we have the right personalities

that are here to do that?

If not, do we have to hire them?

How do you accommodate that?

- The way it's worked in the past

is that your senior guys that have some experience

in the area would kind of just rise to the occasion

and do it, I think.

It's been informal though.

It hasn't been a title or a job description.

- With what you guys say you have going on here,

doesn't really make sense to have leads unless you switch to the new model and

split it up into three big teams where you do need some kind of authority

figure to facilitate what's going on in each team.

Right.

And that was the hypothetical question is, okay, we go down this road.

Who are the leads?

Do we have people that want to do it?

Like, yes, you could take the traditionally senior people, but is that

something they want to do?

Right?

Is that the career path they want to go?

Or are you just going to force that upon them, which isn't fair either?

No, don't do that.

Yeah.

And then we have multiple types of career passion now, right?

We have like the management career path and we have the tech career path.

So, you know, which way do you want to go there?

Like there's just a bunch of different questions that popped up as a result of that as well.

Well, I would say to that, I mean, it's not a simple solution, but really like the management

track is pretty clearly defined where you can go with that.

The tech path is pretty clearly defined because you're going to be an architect of some sort,

right, of some level or staff engineer, I think is another.

The lead one is kind of a hybrid a little bit because I think you're doing a little

bit of both, right?

Yeah.

And even a little bit of like almost PM work in there as well.

So I think that's, I think that role makes sense if you're going to have these strong

team structures set up, more formally defined structures, that makes sense.

Maybe I'm more of a hybrid role like, hey, you know, get in here and tackle this.

Really like, I think you're just kind of the, at that point, you're kind of the grease

on the wheel a little bit, just making sure things keep moving.

I mean, I think that'll maybe make management a little more comfortable.

You go to them and say, hey, how much if we do do this and we do get leads,

how what's the percent that you want them coding?

What's the percent you want to managing?

And that might make them feel a little more comfortable in terms of knowing what they're getting up front.

They were not creating another layer of hierarchy.

It's really just like, no, this is really to keep things moving.

Yeah.

Yeah. You're the orchestrator.

Yeah.

Oh, I like that title actually, the orchestrator.

Yeah, tech orchestrator.

I kind of like the professor.

The professor.

Well, professor does a lot of professing.

All right.

Like the orchestrator is a little bit of professing,

but has to go back and do other things too.

OK.

OK.

That's all I got to say about that.

How are we doing on time there?

We're about 50 minutes.

Oh, good.

Because I know we got started on this really early.

We didn't even get to play our little bumper,

because I was just running my--

Oh.

--running my mouth.

So sorry about that.

Well, let me get you another beer so you can calm down.

Another-- oh.

Another rock star, Pure Zero.

It's all I'm drinking today, buddy.

What else are we gonna talk about anybody got any topics they want to bring up?

Um

Gomer's got something for us. I can see him. Oh boy. I can see him scribbling something on slack over here. I

Don't know what to talk about usually we have so much to talk about oh boy. No, we're not gonna do that

How about a coffee from a machine that spins? Oh, yeah, what's the spin update?

Yeah, it's a sad update actually there was a lot before we go down this route

We should probably inform our new cast member here what the deal with spin is I'll tell you dude

So Mike I like took in 2016 in

December so god that was a long time ago. Well, I believe that was like one of the first episodes we ever did

We talked about spin, right? Yeah. Yeah, because that and we would have our first one that we did would have been

Maybe I got yeah, it was around the same time that I got it

but there was a Kickstarter in 2016 late 2016 for this

awesome Alexa enabled coffee machine, okay, and I bid on it and I

pre-ordered one and

You know, it's amazing. It's like it's like the best end-all be all coffee maker all in once

You dump a bag of beans on top when the beans run low it orders you new ones

Okay, and you can have the coffee maker whoever makes the beans can put their own recipes in there to make it a certain way certain temperature

It's got a little centrifuge and so it sucks all the water out

Okay, and no waste like you get a little tray of like dried coffee beans in the back that once a week

You just go throw in your garden or whatever right now the promise was great

And and so I sound good. I jumped in on it. It's Alexa enabled

I figured you know I could be in bed telling the thing to make me coffee right sounds great

So fast forward it's now what is it April 2019? They haven't delivered it yet. They're still working on it

Still in progress

Yeah, they did have an update last week and

The problem is now is that they've gotten away from providing timelines like about a year and a half ago

They stopped doing that that doesn't sound too pretty and so what they're trying to do instead is just like be very informative

Now about what's being done and so like with each successive month that it's not delivered like there's a bigger

email update that goes out to the backers. And it's just like, here's Jim, like,

tweaking the sound on the, you know, centrifuge, because they would like to

knock it down 3 dBs, you know? And they have like, you know, 10 or 12 of these

type updates that are very in the minutiae. And they don't really tell you

like where it's at, just when it's gonna be done, just like, yeah, he's working on

this, like, we're gonna give you this. For us, it's quality first above all. And so

we're gonna get this thing down by three more DB's and we're working on that this month. So

it was one of those type updates and people now are just like, look, you know, like,

we've been sticking with you guys long enough. Like we just want some idea, estimated timeline,

December 2019 or December 2021, like when, what year could it be done?

That's what we're down to is what year, what century, you know, like,

How, how, uh, well, my kids still be in the house.

Like there was some story, some anecdote.

This guy said on the forum, he's like, look, I got this thing.

I ordered it for my daughter, you know, to go to college or something like that.

And I don't know, like it's been what, she's like, she's going to be a senior

this year and she's the lizard.

Yeah.

Like she already graduated and she stopped drinking coffee and she's a vegan now

and doesn't do that.

I don't know.

It's just been funny to see like the comments.

So yeah, that's kind of the update on that.

There's, it's, you know, it's in progress.

There's a lot of people doing a lot of things with no end in sight.

The update is there is no update.

Yeah, there's not.

It's the same thing.

Yeah.

Yeah.

The funny thing about spin is that is the number one keyword that the coffee

code cast comes up for in Google search.

I find that fascinating.

You've mentioned this before.

So because we talk about it, because we talk about it.

Everybody wants updates.

That in the show notes around the website then, like because that's in

there, it shows up in the search results. We are your spin information source.

Well, that's one way to, they can hear about us this way. And right.

We will sponsor you down the line. Yeah. If there's ever a machine, right?

Something to sponsor. Here, I would love them to sponsor one of the noisy prototypes

that they don't want, you know, like the noisy one that they're going to knock

down by some decibels, send it over here. Like we don't give a shit. Like there's

no, we don't have any babies and cribs or anything like that.

Like we'll just fire it up in the studio.

We can make coffee during the show.

We can even just put one of these mics right up to it.

Yeah.

That would be cool.

We could just have that ready to go and then.

Great advertising.

There's no way for you to communicate to them.

Oh, I'm sure we could taking so long.

No, there is.

I mean, the forums for sure, but they're just not.

They'll answer questions about what they're working on, but they're,

they're very reluctant at this point to give a date because they've, those

So dates have come and gone so many times.

So they speak like a true tech company.

You don't give out dates.

You don't give out dates.

So they just learned that after the fact.

But that's where they're at right now.

I did see two today, and I don't know the details of it.

I didn't read the article.

But it did say that Kickstarter and what is it, Indiegogo,

or whatever the other one is, are

going to have to change something in their policy

or how they do business.

Because so many of these projects have failed.

And people are kind of coming down on them about that.

I'll have to find the details and share that out.

But because some cases are legitimate.

Some cases are becoming fraudulent though, where it's like, okay,

we get the money regardless and then nothing ever happens.

Well, and then you have instances like my good friend Aaron who ordered.

What was it?

The coolest cooler with the blender on top.

Yeah.

Do you ever that Mike?

Remember that cooler?

It was like a done Kickstarter actually.

Oh, this was like huge in the news, man.

It was like an orange cooler.

I actually think I do know what you're talking about.

Yeah.

Yeah.

It's got like a battery pack in it, speakers, like all kinds of stuff.

Yes.

Built in.

I think it had an iPhone dock at one point in time.

- This thing I think on Kickstarter was what?

- I feel like I saw a commercial for this on TV.

- Yes, well, there's a number of them now.

- Oh, okay.

- But I think this thing was like $300 or $400, maybe five.

It was an expensive cooler.

- It was an expensive cooler, yeah.

It was like the Yeti of Cooler

is before Yeti was making coolers.

(laughing)

- And she ordered one of these.

She was one of the early adopters on the Kickstarter program.

So she waited and she waited and she waited

much like the spin coffee maker.

And then come to find out, like they're just like,

Well, we're not going to deliver to our original backers.

What we're going to do is we're going to sell this thing on Amazon.

So if you want one, you can buy one on Amazon, but we're not going to deliver to the backers.

And so that was pretty messed up.

She still doesn't have one to this day.

She never got her money back.

Nope.

Wow.

Did you get your money back on Kickstarter?

I've heard that's a thing.

You.

Yeah.

I don't think so.

I think I don't, huh.

I've heard pretty mixed reviews on that.

I don't know which one does what because there's some right, there's somewhere like

that you only get the funds if the goal is reached. So if you ever hit it, then you don't get it. But

once you hit the goal, I don't know that there's any obligation to give you the product. It's kind

of just one of those things that people should know that, and assume I think a lot of regular

backers just say, well, we're trying to support the company. And hopefully it works out. Right.

And I think it matters a lot. Like you mentioned, I think earlier, based on fraud. So like I

supported an Indiegogo once upon a time. So I wear a hearing aid in this year. I am partially deaf

due to like a birth abnormality. And so they had a hearing aid that was supposed to be

this fancy new thing. Like it was wireless charging. So you could just set it on a little

matte boom charging like no time flat sounded really great. Should have known it was too

good to be true type of thing. But I was like, whatever, I'll plunk down $300. If it's not

true, whatever. Right. And it ended up being a fraudulent thing. Luckily, I used an MX

card. And MX will let you reverse a charge like a really long time later. Like I want

say it was like 12 months. Wow, that's impressive. So basically,

once I knew it was fraud, they wouldn't give me my money back.

But because because it was fully funded. And so I just went

onto my MX and I was able to reverse the or dispute the

charge and get the money back from it.

Well, that's a good thing to have the MX for that. Right?

Instead of putting on the old debit card.

Putting it on your visa gift card, not getting that money back.

Yeah.

Oh, we're at the end of the hour already.

We're already done.

Oh, man.

Do you have something else you want to talk about?

I think we're cool, man.

I just really appreciate Mike jumping in last minute on the cast here.

Thanks, man.

Really appreciate you guys having me out.

Hopefully I can come back out soon.

We'll do it again.

We'll get you back out here.

Yeah, we'd love to have you on again.

You can, uh, the coffee code cast is recorded live from Seattle, Washington every

Wednesday, 9pm Eastern, 6pm Pacific.

Join us live at www.coffeecodecast.com/live.

The podcast artwork is provided by Gernay, the Gentle Giant.

Check out more of his illustrations at coffeecodecast.com/gentlegiant.

The podcast is available from iTunes, Spotify, TuneIn, Stitcher, Google Play Music,

and now Radio Public.

Yeah, that's a new one.

It's a new podcast player.

You can get that app from all of them, from all the different platforms,

or you can get it wherever you get your podcasts.

And you can find all of this and more on the website at www.coffeecodecast.com.

Thanks everybody for listening.

Thanks for joining.

Thank you.

We'll see you here next week, same time, same place.

Bye.

[Music]