32: Large Versus Small Teams
This week we have a special guest join us on the podcast. Mike Davis from our Sacramento office is in town and he joins us to talk about our recent tech team team-building outing, meeting the new team, and discussing splitting your organization into large or small teams.
We also get the latest update on Mike’s perpetually delayed Spins Coffee maker and talk a little bit about Kickstarter projects.
- Theme Music
- Show News & Follow Up
- Podcast feeds all updated and working
- Lime bike jousting
- Large Versus Small Teams
- Clear Capacity
- Create Focus
- Remove Silo’s
- Prevent Burnout
- Moment Of Opportunity
- Spinn Coffee Update
- Kickstarter Projects
- Theme 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.
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.
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.
- That's nice to have on, you know?
- Yeah, absolutely.
- 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
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.
Oh, that's sweet, man.
That'd be awesome.
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
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.
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.
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
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.
- 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.
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.
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.
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?
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.
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.
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.
- 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.
- 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.
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.
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.
- Or creating work to do, which wouldn't be helpful.
- And investing in that extra time, you know,
helps flush things out and that prevents scope creep,
which makes sure that things stay on.
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.
And then you prove that you can do it.
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.
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.
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.
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
Then you would go to another project, probably some
large scale project.
So you're getting a new project every six months
- 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.
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.
There you go.
Oh, here's another cider for you there, a virtual cider
for you, sir.
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
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.
And that's partially why I built this list.
- 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.
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.
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.
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?
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.
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?
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.
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?
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. You're the orchestrator.
Oh, I like that title actually, the orchestrator.
Yeah, tech orchestrator.
I kind of like the professor.
Well, professor does a lot of professing.
Like the orchestrator is a little bit of professing,
but has to go back and do other things too.
That's all I got to say about that.
How are we doing on time there?
We're about 50 minutes.
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--
--running my mouth.
So sorry about that.
Well, let me get you another beer so you can calm down.
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?
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.
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.
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.
That would be cool.
We could just have that ready to go and then.
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.
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.
It's got like a battery pack in it, speakers, like all kinds of stuff.
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.
- 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.
Did you get your money back on Kickstarter?
I've heard that's a thing.
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.
Oh, we're at the end of the hour already.
We're already done.
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.
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.
We'll see you here next week, same time, same place.