Speaker 1: Yeah, they changed the goal life button.
Speaker 2: It's just.
Speaker 3: I know the UI designers feel like.
Speaker 1: They're contributing, but sometimes, man, sometimes I question it.
Speaker 4: Where we have some on the show.
Speaker 1: If you're a UI designer and you swapped the order
Speaker 1: of the okay and cancel buttons, give me a call.
Speaker 1: You can talk.
Speaker 3: Anyway, Warren. What's going on?
Speaker 2: Man?
Speaker 4: Well, you know, thanks for welcoming back.
Speaker 5: I know the last couple of weeks I've been actually
Speaker 5: out of commission traveling in Berlin.
Speaker 4: But I have an interesting.
Speaker 5: Fact for today the Adventures of DeVos, and that's in
Speaker 5: the last three weeks there have been two different TOTP
Speaker 5: mobile app providers who have both.
Speaker 4: Been popped in some way and significant vulnerability has been discovered.
Speaker 5: One of them just straight out sold to a let's
Speaker 5: just third party. So it's a good reminder that passwords
Speaker 5: are always insecure and mobile apps don't make it any
Speaker 5: more secure.
Speaker 4: It's really amazing.
Speaker 1: Actually, I'm just going to say, a revenue stream is
Speaker 1: a revenue stream is a revenue.
Speaker 3: Stream, right on? Yeah, I agree. I wish that more
Speaker 3: more providers supported.
Speaker 1: Ub keys because I don't like those a lot, and
Speaker 1: I hate the ones that say hey, we'll text you
Speaker 1: a code. My great, that's not secure at all, but
Speaker 1: thanks for making it harder.
Speaker 3: To use your app anyway.
Speaker 1: Joining us today, Marcus Thurner, Marcus, how are you man?
Speaker 2: Yeah, thanks a lot for having me. Exciting to be
Speaker 2: in a podcast.
Speaker 1: Yeah, it's going to be an excellent podcast as I
Speaker 1: understand it. And you are the director of technology at
Speaker 1: Vista right, yes.
Speaker 2: One of them. I'm booking in order.
Speaker 3: Management right on.
Speaker 1: And then we're just going to completely bypass that and
Speaker 1: derail the show entirely because it says on your LinkedIn
Speaker 1: profile you are a professional chocolate taster.
Speaker 3: Is that a real thing?
Speaker 2: That was a real thing. It's not a thing anymore.
Speaker 2: It's just like, yeah, my wife had a startup for
Speaker 2: four years in that being to bar chocolate making business,
Speaker 2: and you gotta do what you gotta do as a
Speaker 2: husband and taste chocolate and enjoy their mind. It was
Speaker 2: a good time. But I think it's still good to
Speaker 2: keep some fun stuff on a LinkedIn profile instead of
Speaker 2: like it starts to be too serious O advice.
Speaker 3: Right, Oh, I agree one hundred percent.
Speaker 1: There was a time early on in LinkedIn days where
Speaker 1: you could just indorse anyone for anything, And so some
Speaker 1: of my friends endorsed me for professional gift expert or
Speaker 1: something like that, because about ninety percent of the time
Speaker 1: I'll reply with a gift or a meme instead of
Speaker 1: actual text. And so for long, the longest time, I
Speaker 1: was endorsed for that on LinkedIn, and then they decided
Speaker 1: to take that seriously and removed it. And now you
Speaker 1: can only get endorsed for authorized roles, but no professional Yeah, right,
Speaker 1: like professional chocolate taster.
Speaker 3: I mean I like the fact that it was.
Speaker 1: For your wife because your vowels were for better or
Speaker 1: for worse, and I mean that's just the job.
Speaker 2: Absolutely absolutely.
Speaker 5: I wonder if there's a connection though, like have you
Speaker 5: been able to find a way to take the lessons
Speaker 5: learned from startup chocolate making to back to the technology world.
Speaker 4: Has there been any overlaps?
Speaker 2: I think I think yes. I mean running a business
Speaker 2: is actually you learn a lot more than you're a
Speaker 2: single woman or you know, just a very tiny business
Speaker 2: just trying to survive. You do everything right, you do
Speaker 2: everything for your customers, you do everything for every cent.
Speaker 2: And I think you know, I didn't live it personally.
Speaker 2: I've worked in a tiny company before, so I did
Speaker 2: a lot of that myself, so but I think that
Speaker 2: is what comes daily into a software engineer's job. I mean,
Speaker 2: you're not nestily getting tasked of, right these three functions.
Speaker 2: You gain tasks of solving a specific problem and then
Speaker 2: it comes in and sometimes the problem is solved by
Speaker 2: writing an email and not writing any code. So so
Speaker 2: there is this sense of I want to do something
Speaker 2: good for the customer and for the business or ideally
Speaker 2: the mix of both. And yeah, and I think it's
Speaker 2: a different drive what you have and what type of
Speaker 2: skills at what you learn. And I think it goes
Speaker 2: back to university projects where everyone does it in some
Speaker 2: form or shape, and you know, motivation there and just
Speaker 2: trying to be trying to make it the best what
Speaker 2: you can at that point. But this older naivity what
Speaker 2: you have, I don't know, fifteen year old in school
Speaker 2: or twenty five year old in university. And so.
Speaker 1: Yeah, I think there's a tangential relationship there to freelancing
Speaker 1: as well, because I did freelancing for a number of
Speaker 1: years and I talk with a lot of people who
Speaker 1: look at the rates that freelancers charge and they're like,
Speaker 1: oh my god, that's amazing, and so I try to
Speaker 1: caution everyone and say, okay, that's that number is big,
Speaker 1: but you're not always going to bill forty hours a
Speaker 1: week like you would, So like divide that number by three,
Speaker 1: because for every hour that you work billing a client,
Speaker 1: you have another hour of work for accounting and bookkeeping
Speaker 1: and all of the stuff with running your business. And
Speaker 1: then there's an additional hour on top of that where
Speaker 1: you need to do sales and marketing and prospecting and
Speaker 1: finding your next gig. So even though that hourly rate
Speaker 1: looks big, you have to divide it by three to
Speaker 1: realistically put it into.
Speaker 3: Scope of what your actual job is.
Speaker 5: I think you're under selling the stress that comes along
Speaker 5: with it as well. Right, you're not just doing those
Speaker 5: parts of the job that you normally think about. There's
Speaker 5: every other aspect of it. And then there's getting away
Speaker 5: from it and going back quote unquote home and still
Speaker 5: thinking about your business because it's your livelihood, and how
Speaker 5: to market in sales outside of that even when you're
Speaker 5: not making anything for that particular customer. So I can
Speaker 5: imagine there's a lot that goes into that for a
Speaker 5: very small startup, especially one in the chocolate tearing space.
Speaker 2: I think it definitely also depends on even though now
Speaker 2: in software engineering or some technology aspect is I you
Speaker 2: more into short term projects. There's just like a lot
Speaker 2: of noise and overhead and phone calls to just make
Speaker 2: I don't know this week, this week's gig works worth
Speaker 2: it and that as much be Oh, I'm basically just
Speaker 2: like a loaner and heavier project assignment. There is you know,
Speaker 2: the economics change, but also you get a lower rate.
Speaker 2: So I think in the end then market tries to
Speaker 2: optimize for that. But like, yeah, you definitely learn also
Speaker 2: back to those skill sets and this drive too. I
Speaker 2: need to justify that hour, right, And I think that's
Speaker 2: the beauty of external people. They show up, they need
Speaker 2: to justify every single hour. And if external people are
Speaker 2: used the right way, independent on whether they come from
Speaker 2: a big company type of consultancy or as a one
Speaker 2: person is they don't have the ow ahead of a company, right,
Speaker 2: And that's that's I think important as you collaborate with
Speaker 2: those external people and making sure this hour needs to
Speaker 2: value differently than an internal one. The internal one you
Speaker 2: train that person to be excited in five years to
Speaker 2: grow internally versus for the other one like, this is
Speaker 2: the task in a week you on, this is how
Speaker 2: I can can actually get the value out of it,
Speaker 2: and also, hey, I paid you that, but you also delivered.
Speaker 2: I think that's really interesting dynamics, but often an oversight
Speaker 2: for those who are on the other hand, so not
Speaker 2: the freelancer, but actually receiving the freelance work and actually
Speaker 2: make that, make that a thing, and make make it
Speaker 2: work and make it valuable.
Speaker 3: For sure.
Speaker 1: So let's shift gears a little bit and talk about
Speaker 1: engineering excellence because that is our topic for the day.
Speaker 1: So Marcus, give us, like your your high level thoughts
Speaker 1: on what is engineering excellence and why it's important to you?
Speaker 2: Mm hm. So I think it potentially builds up a
Speaker 2: little bit on where you started us here on you're
Speaker 2: just just having to drive on figuring out what's best
Speaker 2: for the business and the customer in the end, right,
Speaker 2: and you just like it's not fulfilling a chop description,
Speaker 2: but it's just whatever needs to get done. But that said,
Speaker 2: let's let's focus more on the excellence part of the
Speaker 2: engineering part and probably start with what is excellent, right,
Speaker 2: there's probably variety of definitions when you look up on
Speaker 2: the dictionaries and like it's wake, but some of those
Speaker 2: sentence has definitely resonated to see you it's something like
Speaker 2: greatness or being the very best, and you know there's
Speaker 2: millions of soft engineers in the world. Not everyone can
Speaker 2: be the very best. Not everyone can be you know,
Speaker 2: these star singers or star sports and athletes and so on.
Speaker 2: But nevertheless, you know, look, look look at other disciplines
Speaker 2: like sports. You might not become, you know, the next
Speaker 2: world champion of whatever sports, but you can look at them,
Speaker 2: you learn from them, and you kind of strive to
Speaker 2: do better even if you know you're never getting there.
Speaker 2: You know, you might have your lab times on money
Speaker 2: and then you just might want to be ten seconds
Speaker 2: faster in half a year and you're proud of that
Speaker 2: and you're striving for this incremental improvement. So anyway, so excellence,
Speaker 2: I think it obviously depends on where you're coming from,
Speaker 2: but generally it is about the relentless drive to become
Speaker 2: to envision that greatness and embrace it and make iterations
Speaker 2: towards that. And I think it's a little bit harder
Speaker 2: to find what does this mean in a job that's
Speaker 2: not so you know, you don't get so many medals
Speaker 2: by being the best. You don't get you know, you're
Speaker 2: not this key champion who is the fastest. You're not
Speaker 2: the golf of who uses the least amount of things.
Speaker 2: You're not now in the you know, Couper America and
Speaker 2: the European World CHAMPIONIP, there's just one team winning it.
Speaker 2: But nevertheless, those who are already out of the race,
Speaker 2: they they're part of the excellent strive as well, So
Speaker 2: let's not forget that. So it's definitely very inclusive of
Speaker 2: a lot of people here. But nevertheless, I think all
Speaker 2: of those who are on that playing field, they are
Speaker 2: they're just like doing one more thing than anyone else.
Speaker 2: So anyway, so how does that translate a little bit
Speaker 2: into engineering? And I think one of the interesting talks
Speaker 2: probably that that many might know is Lenis Tobo's defining
Speaker 2: good taste software. And he did that in a TED
Speaker 2: talk something like ten years ago and showed like, hey,
Speaker 2: this is how computer science teaches you to remove an
Speaker 2: item of a single lecklist or something like that, and
Speaker 2: it had this if condition in it. He must not
Speaker 2: lessly water by what he is taught by computer science,
Speaker 2: But why these if conditions. It's just like there might
Speaker 2: be a bug in this thing, and there's another if
Speaker 2: condition added, and it just adds this complexity versus really
Speaker 2: trying three layers deep of what's the thing, how can
Speaker 2: you solve it? And how can you solve it in
Speaker 2: a way that is just like, that's the thing, what
Speaker 2: it does. There's no discussions about it. There's basically no
Speaker 2: way of an alternative pass if the first one and
Speaker 2: the last one or the middle one and so on,
Speaker 2: Like all of a sudden, you get into no, that's
Speaker 2: the thing, no matter which item in the in this
Speaker 2: list it is. And I think that one is an
Speaker 2: interesting one in writing code and and I think now
Speaker 2: these days is a lot of that is a lot
Speaker 2: of us are working in the cloud or in some
Speaker 2: other form of you know, computing environment. And I think
Speaker 2: one of the interesting phase one I want to put
Speaker 2: out here, and it's well, let let's let's start go first,
Speaker 2: one step back. I think there are are two different things.
Speaker 2: One is kind of on agreed baseline, and you can
Speaker 2: set that in your company or for yourself. You can
Speaker 2: set that at whatever level you actually want. Hopefully that
Speaker 2: level of that baseline increases over time. But I think
Speaker 2: those are you know, you can look at classical engineering
Speaker 2: KPIs how quick are you to recover from a failure
Speaker 2: in production? How quick are you able to in what's
Speaker 2: the velocity in the team, what's the error rate? You know,
Speaker 2: there's the Dora metrics out there, there's a bunch of
Speaker 2: other ways to measure that. Whether you really measure that
Speaker 2: or just like gut feeling type of measurement almost doesn't matter.
Speaker 2: But like, that's the baseline security Laaren. You had an
Speaker 2: example at the beginning, like you know, okay, how do
Speaker 2: we you know, instead of increasing your password rotations, can
Speaker 2: we actually decrease the amount of passwords we have in
Speaker 2: our systems? Right, It's a different type of approach. How
Speaker 2: you can think of that, And that's I think there
Speaker 2: is I don't think there is a standard in the world,
Speaker 2: but there's agreement of those argued things, right, And I
Speaker 2: think then there's this other part which is not this baseline.
Speaker 2: It's it's very drives innovation. They drive to try out
Speaker 2: something new, and trying out something new in your environment
Speaker 2: might be I've never worked in a cloud, but let's
Speaker 2: run the first service in the cloud. Even though that's
Speaker 2: a ten plus year old saying it might be oh,
Speaker 2: this is how we do things here on running a
Speaker 2: specifically workflow, and let's try and alternative way. You're not
Speaker 2: getting into childscript front and frameworks because you try another
Speaker 2: one every other week. I'm still ten years ago. Who still?
Speaker 4: I mean, you be careful.
Speaker 5: You gotta be careful there because I'm sure someone's still
Speaker 5: using like ember or knockout or something like that.
Speaker 4: That's that's still around.
Speaker 5: I mean, there's an interesting question here of of how
Speaker 5: do you even measure an engineer to be better and
Speaker 5: whether or not the ext whence happens at an individual
Speaker 5: level or at a team level. You know, I know
Speaker 5: that I am a terrible individual software engineer, and I
Speaker 5: shut her to think that someone will be evaluating me
Speaker 5: on like the number of lines of code that I
Speaker 5: turn out, because I know that number is incredibly small.
Speaker 3: Yeah, and even if that's the right metric.
Speaker 1: So I think that's one of the things that I
Speaker 1: think about when I think about engineering excellence is defining
Speaker 1: how we're going to define excellent because I think it
Speaker 1: varies from team to team. You know, each team is
Speaker 1: going to consider different things important, and you can't have
Speaker 1: everything important. So I think everyone just has to have
Speaker 1: that conversation, you know, to say, these are the things
Speaker 1: that we're going to consider important. And you know, maybe
Speaker 1: that's going to change over time, but this is where
Speaker 1: we're going to start, and everyone's on the same page.
Speaker 2: There.
Speaker 5: There is this underlying assumption though, that it's somehow not
Speaker 5: directly related to the business, right because you know, otherwise
Speaker 5: you would say somehow engineering excellence means delivering the right
Speaker 5: business outcome or I mean maybe there's some business.
Speaker 4: Metrics already, you know, why not use that term?
Speaker 5: So I don't know, at least for me, it does
Speaker 5: sort of spark this idea of what are we innovating,
Speaker 5: what are we what are we improving.
Speaker 4: In some way?
Speaker 5: What is that really? You know, what is the meaningful outcome?
Speaker 5: And I think the linus forbodes coding good taste is
Speaker 5: an interesting aspect here because how you write that function?
Speaker 4: How does it impact the business? Does it?
Speaker 5: I mean maybe it does, maybe it doesn't. So what
Speaker 5: are we even evaluating there and how do we even
Speaker 5: do that?
Speaker 2: Absolutely? And I think you know, going to the invo
Speaker 2: versus team, in the end, it counts what the team delivers, right,
Speaker 2: it's the same. But you have a team sports, you
Speaker 2: can have the start plays and one star player often
Speaker 2: can have a pretty bad team because everyone cages around
Speaker 2: that star player and typically doesn't have much of a
Speaker 2: chance against the team that's just very cohesive, especially I
Speaker 2: mean catering for the start player as a cohesive team
Speaker 2: that's very strong. But if they are fights behind the
Speaker 2: scenes doesn't work anyway. So that sets back to the
Speaker 2: sports andology. But I think it's it's really what is
Speaker 2: the team coming out in terms of and I think
Speaker 2: will do To your point, I think there's a few
Speaker 2: things that are true almost no matter where you are.
Speaker 2: I think you don't necessarily want to ship bugs to production, right,
Speaker 2: so less bugs and production is probably a metric that
Speaker 2: everyone agrease.
Speaker 5: Controversial thought there. I don't want bugs of production. Tho's
Speaker 5: got to disagree with you somewhere, Marcus, I'm sure.
Speaker 2: And to be honest, I think what is a challenge
Speaker 2: if you're and think of my role, I mean this
Speaker 2: is this the print is a sizeable business, and you
Speaker 2: know order management. You don't necessarily want to give away
Speaker 2: or just for free because your payment didn't work, or
Speaker 2: you want to block things that check out. So it's
Speaker 2: a serious thing. You need to move very slow at
Speaker 2: some point. And for example, for mine team, it is
Speaker 2: like an interesting thing. Oh this is a new thing.
Speaker 2: Don't work like you work in your usual environment. Just
Speaker 2: like have a hecka on type of experience, or have
Speaker 2: one person go off on basically an island for we
Speaker 2: can come back and have this zero to eighty percent
Speaker 2: solution out there. You're not going to break anything in code,
Speaker 2: you're not going to make any customers unhappy. But it
Speaker 2: allows you to move fast. So basically a little bit
Speaker 2: of an unconventional approach. So yeah, shipping bugs into production,
Speaker 2: it might actually there might be some use cases around
Speaker 2: you know, prototypes, early things. Then you haven't figured out
Speaker 2: the exact park market fit. That's it. I still argue
Speaker 2: that you always scale down on features and have the
Speaker 2: right quality because otherwise, when you ship something of these
Speaker 2: little features that are all buggy, you're not going to
Speaker 2: make product market fit.
Speaker 5: So you're as a director of engineering, you've got like
Speaker 5: four or five ten teams reporting to you. I'm not
Speaker 5: sure that number is totally relevant. So when you're saying
Speaker 5: sharing excellence, like you're actually putting these expectations on your
Speaker 5: individual teams too.
Speaker 4: Is it deliver faster?
Speaker 5: Is it to deliver more of the right thing related
Speaker 5: to the business, Like, how are you actually evaluating your
Speaker 5: teams on this? Is it a metric you're even using
Speaker 5: to evaluate or is it just is it some idea?
Speaker 4: What is that for you?
Speaker 2: I'm definitely the person who is more in the idea
Speaker 2: than I mean, I'm very much data driven in terms
Speaker 2: of wants to figure something out. I want to want
Speaker 2: to chase that metric, and obviously, you know, I think
Speaker 2: reasons because like chasing one metric, you're ignoring the other ones,
Speaker 2: so you always need to counterbalance. But you know, there's
Speaker 2: this this interesting discussions of not sure if I want
Speaker 2: to go there, but like if you're doing the second
Speaker 2: or third like even when you run AWDs elastic kumunated service,
Speaker 2: but then you need the kuminat is out of lifetime, right,
Speaker 2: they need to move to the next version. You can
Speaker 2: close your eyes and hit that upgrade button in place
Speaker 2: upgrade and hope for the best and you might be lucky.
Speaker 2: But it's a little bit like I don't feel confident.
Speaker 2: You know, there's there's order is coming in every other second, right,
Speaker 2: I mean, this is is not something what you want
Speaker 2: to play with. And once you have start having those discussions,
Speaker 2: like there's other solutions out in the world where you're
Speaker 2: not even in that problem, those other solutions might or
Speaker 2: might not be a fit for the team. Right. It's
Speaker 2: not saying we should go elsewhere, but we're definitely having
Speaker 2: active discussions around that because we're our customers are not
Speaker 2: not buying a comment adies upgrade from us. You're buying
Speaker 2: business cards, bottles, t shirts, all those type of things
Speaker 2: in our case or in other cases might be different things.
Speaker 2: And and so it needs to come with this reality
Speaker 2: check on you know what's I mean, what's this total
Speaker 2: cost of ownership? Is the old style version of saying
Speaker 2: it probably or very mechanical way and then it come
Speaker 2: up with your business cases. But I think this is
Speaker 2: things come up constantly, and that could be this service
Speaker 2: is constantly making problems and creating noise. You want to
Speaker 2: dive deep. Is it engineering excellence? It could also be
Speaker 2: that other partners in the business are you know, not
Speaker 2: aware of what they're causing. Like you know, think of
Speaker 2: some configuration elsewhere three layers down in the system and
Speaker 2: you have no idea, or they might be disconnected from
Speaker 2: what actually that is causing. It might call cause customer
Speaker 2: complaints and it's very very indirect and very very slow
Speaker 2: feedback loop. And so sometimes it's not you know, the
Speaker 2: problem might not be technical, it might be a process problem.
Speaker 2: But generally this is also part of excellence, but they'll
Speaker 2: be getting a little bit further into excellence of a team,
Speaker 2: excellence of a pride team, excellence of an organization. And
Speaker 2: I think, you know, yeah, I'm definitely more qualified to
Speaker 2: talk about engineering excellence.
Speaker 4: I mean, I like the Kobrinties example.
Speaker 5: So if we say bad engineering excellence is just closing
Speaker 5: your eyes and clicking the upgrade button, or maybe closing
Speaker 5: your eyes and just letting a WUS charges more money
Speaker 5: because it's on the extended lifetime support strategy, what what
Speaker 5: is good engineering excellence in that in that situation? Like
Speaker 5: what would you expect there on that spectrum?
Speaker 2: Generally, I think, you know, maintenance should be low or
Speaker 2: reasonable for the value you create as a business or
Speaker 2: as a team. And you know, what's the value what
Speaker 2: you create? Sometimes it is more tied to a revenue
Speaker 2: stream and other times it's more tied to something a
Speaker 2: little bit that decided. You know, it doesn't necessarily be
Speaker 2: a dollar metric, but it needs to you know, not
Speaker 2: not sure what would other companies and teams generally have
Speaker 2: in their mind, but I would argue, you know, thirty
Speaker 2: percent is stuff that engineers need to do to maintain
Speaker 2: their status core and then you know there's this admin overhead,
Speaker 2: but then the majority of it should be to move
Speaker 2: the product forward, to move the projects forward. That comes
Speaker 2: with coding, that comes up with his non coding activities,
Speaker 2: and really doing good for the customer. You want to
Speaker 2: increase that share of the you know, the maintenance activity.
Speaker 2: So maintenance comes with there certain you know, in my
Speaker 2: environment's a little bit of large companies, certain things that
Speaker 2: are must do by a given date, certain upgrades, certain
Speaker 2: compliance aspects and so on, and those you know, those
Speaker 2: covering you know, ten inch percent, and they might come
Speaker 2: up with some spikes and some lows and so on,
Speaker 2: and the rest is I'm interested in the team rather
Speaker 2: spending this thirty percent time in figuring out a new
Speaker 2: service or new workload version to run, or a new
Speaker 2: technique or documentation other thing versus. Yeah, this is what
Speaker 2: we do. Twice a year. We just do it right
Speaker 2: and think, think of something simpler than thencuminated is password rotation.
Speaker 2: Probably want to get into rhythm or rotating your password.
Speaker 2: Initially you pro might say, yeah, it's just three, let's
Speaker 2: do it manually. And at some point you have fifty
Speaker 2: and some point like, oh, this is a problem, right,
Speaker 2: and sure give this too. Junior person to onboard to
Speaker 2: launder systems and they go into fifty places and update those.
Speaker 2: At some point someone comes in and does some automation
Speaker 2: around this, and at some point you think, why do
Speaker 2: I even have those passwords? So I'm so there is
Speaker 2: very Yes, I'm going a little bit by feeling it
Speaker 2: by noise, but then I'm fortunately have to have access
Speaker 2: to a lot of data of thinking how many what's
Speaker 2: the average password age, what's the rotation of it, what's
Speaker 2: it over the timeline, and the timeline is very strong,
Speaker 2: like if it goes up and you actually want to
Speaker 2: go it down or the other way around, like you
Speaker 2: can still acting before it explodes. And I think that's
Speaker 2: a really really important thing. So thinking of you know,
Speaker 2: this cuminating thing, it's not the worst thing what I
Speaker 2: have in my team by far not. It's actually serving
Speaker 2: a lot of value work. Those were things right from
Speaker 2: a real engineering perspective, right, But nevertheless, it is distractions
Speaker 2: and you're having you know, fifty plus seventy plus services
Speaker 2: and each of that needs kind of a redeployment to
Speaker 2: a new cluster if you want to move it over.
Speaker 2: And then like even if you bring down the hour,
Speaker 2: like let's just assume one hour per service, that's fifty
Speaker 2: seventy hours per year, which is a week, giving you
Speaker 2: thirty plus engineers working on the whole thing for the
Speaker 2: year and doing that once or twice a week, it's
Speaker 2: an okay thing. But not having that in the first place,
Speaker 2: that's an even better thing. With thirty hours, you can
Speaker 2: do quite a bit of other things that might actually
Speaker 2: drive forward. So that is, for example, we have not
Speaker 2: yet decided whether we want to get off of it
Speaker 2: or not. But what I'm excited about the team now
Speaker 2: looks at should we do something else, And very specifically,
Speaker 2: a is ECS is a very you know, natural follow
Speaker 2: up in staying on a WS. But you know, different
Speaker 2: cloud providers will have very similar real cloud and options
Speaker 2: and more managed versus less managed services.
Speaker 5: Maybe this is an unfair interpretation of engineering excellence, and
Speaker 5: maybe will we'll give me a thumbs up here or
Speaker 5: down on how oft I am. I think maybe another
Speaker 5: way of looking at this is challenging the status quo
Speaker 5: in a way which may identify that what we have
Speaker 5: could be categorized as tech debt. And I don't like
Speaker 5: the word tech debt a lot, but maybe what you're
Speaker 5: saying is, you know, what do we have right now?
Speaker 5: Is it actually the systems that we want in play?
Speaker 5: Actually the technology we want to be using? The stack,
Speaker 5: the programming language frameworks, you know, are they actually the
Speaker 5: thing that we want to be using or should it
Speaker 5: be something else? And I think the point you made,
Speaker 5: Marcus is that none of these things have anything to
Speaker 5: do with delivering the business value on a short term timescale.
Speaker 5: But there's like a long term implication here and an
Speaker 5: expectation that the teams are asking themselves, Hey, you know
Speaker 5: this technology you're using, should you even have to rotate passwords?
Speaker 5: You know, this thing that you're doing constantly that you
Speaker 5: may be baked into tradition doesn't necessarily make sense.
Speaker 4: I don't know.
Speaker 2: I don't know if I'm right there absolutely, And I
Speaker 2: think this is I think challenge status crul of what
Speaker 2: you're doing constantly. I mean, look look at look at
Speaker 2: the world what it was ten years ago, and what
Speaker 2: services did your favorite cloud provider have out there? I mean,
Speaker 2: by now, you're just exploding in services. And sometimes it's
Speaker 2: just like kind of a fake service on top of
Speaker 2: three of their other services. But all services are also
Speaker 2: getting better, right, so I think that is and they
Speaker 2: find their very own product market fit. And just look
Speaker 2: at something like S three what you were able to
Speaker 2: do ten years ago versus now, how much of an
Speaker 2: important pillar that is, for example for data lakes and
Speaker 2: other things like who would have put the data and
Speaker 2: do sequel statements on top of a three bucket? Nobody?
Speaker 2: But today that that that's how the big data warehouses
Speaker 2: actually make money, right and and like this this is
Speaker 2: how technology was look at you know, we may chat
Speaker 2: jokes about front and frameworks, look at where they where
Speaker 2: they came from, and what are they doing today and
Speaker 2: like including things like you know those server side versions
Speaker 2: of it on how you can ventor things, and and
Speaker 2: I think it's it's we should challenge basically every day,
Speaker 2: what are we doing is this really necessarily and think
Speaker 2: of how could we do things differently at the same time,
Speaker 2: I think there is a beauty of not classifying something
Speaker 2: just because it's old as tech dev but saying, look
Speaker 2: at you're milking the cout here right, You haven't invested much,
Speaker 2: but it still works and and I think there might
Speaker 2: there might be a servileized function out there. Yes, you
Speaker 2: might need to upgrade I don't know the library version
Speaker 2: once a year, but it still does this thing. It's
Speaker 2: not massive tech there. Would you would you design the
Speaker 2: system exactly like that from scratch? Potentially not because the
Speaker 2: world has changed, but it's still good enough and not
Speaker 2: worth changing. Like you know, identifying those tipping points when
Speaker 2: is it actually a value or an asset and one
Speaker 2: when does it start to become a liability is an
Speaker 2: interesting thing to think of. But I would not classify
Speaker 2: any programming language or any past decisions as lessli tech there.
Speaker 2: But you know, when you think of where's the world
Speaker 2: going in terms of you know, relational databases were that thing,
Speaker 2: and yeah, ten years ago it was still their thing.
Speaker 2: No sequels started to be other things. But these days
Speaker 2: when you hire someone off the university, they don't know
Speaker 2: how to write sequel statements anymore because that's not being
Speaker 2: taught in school they only learn no sequels and blog
Speaker 2: storage and all those things. I think it's the right
Speaker 2: thing to teach to them. But knowing sequel it's actually
Speaker 2: good skill to have. So, you know, does my team
Speaker 2: have a bunch of relational database yes? Is it worthwhile
Speaker 2: changing that? I don't think so it is it worthwhile
Speaker 2: maintaining it to something? Very say? No, you are satisfied.
Speaker 2: Is the cost, performance, backup failures, all the whole criteria. Yes, absolutely,
Speaker 2: we need to tame the beast if you want right,
Speaker 2: but not all workloads require things on you know this
Speaker 2: horizontal scalability and other effects. What you can actually get
Speaker 2: out of no sequel databases. So that doesn't mean just
Speaker 2: because you have this and you need to get off
Speaker 2: of it, but you need to identify at some point
Speaker 2: it might be, oh, now it's the right time to move.
Speaker 2: It might come as a project, it might come with.
Speaker 5: Something I'm wondering about, the who who who spends the
Speaker 5: effort doing this? And I think maybe this is where
Speaker 5: maybe the sort of thing that drove forward the mindset
Speaker 5: in the first place, the movement towards DevOps uh, the
Speaker 5: idea that more attention needs to be on evaluating the
Speaker 5: excellence of our of the engineering that we're doing, and
Speaker 5: maybe there's a cultural component to it that not everyone
Speaker 5: is has the sort of mindset to look at what
Speaker 5: we're doing today and actually improve it or fundamentally having
Speaker 5: to change what we're doing. Uh that that can be
Speaker 5: scary for lots of people as well. So I feel
Speaker 5: like there's an aspect there which could have driven the
Speaker 5: DevOps mindset, which was maybe a different team is responsible
Speaker 5: for infrastructure, and maybe the sort of product teams say, hey,
Speaker 5: other teams in our company are fundamentally responsible for doing
Speaker 5: this innovation, deciding which version of Kubernetes, or whether or
Speaker 5: not we're using Cerblus functions, et cetera. Ah Is is
Speaker 5: there an aspect where every team should be doing something
Speaker 5: in their own domain or do we think we've moved
Speaker 5: the industry has moved in a direction where a lot
Speaker 5: of these decisions are we've already identified which team is
Speaker 5: fundamentally responsible for making them.
Speaker 2: Well, I think I think it's at the engineer's hard
Speaker 2: to actually make improvements in their own realm, right. I
Speaker 2: think there's companies that say, heybe have a central team
Speaker 2: that you know, manageerain things like but we provide a
Speaker 2: link to a get up repository and magic happens, right,
Speaker 2: And this is this is the script what you need
Speaker 2: to put there, and here's some conflict what you can
Speaker 2: you know, how it scales. That's a very valuable approach
Speaker 2: to do it. And I think the approach today will
Speaker 2: also be different than the approaches were done you know
Speaker 2: ten years ago. Is basically sis ops and database ops
Speaker 2: and managing deployments manually and sailors and you know, local
Speaker 2: local things versus cloud cloud versions and son uh and
Speaker 2: there is that. The way is your your ability to
Speaker 2: run it as a basically as a Pride team or
Speaker 2: as a small development team of you know, two pizza
Speaker 2: teams type of size, right the Tannish people in total ah,
Speaker 2: But no matter what model you are, you have different
Speaker 2: responses with your task is really going into these whole
Speaker 2: depthops from from you know, prop typing to delivering testing
Speaker 2: to also running it production including your you know, on
Speaker 2: call schedule, or it's a little bit more you only
Speaker 2: you know you depending there might be some handover for
Speaker 2: for monitoring. But in both ways you have areas where
Speaker 2: I wanted to improve it could be on you should
Speaker 2: definitely be interested, like when we look at very technical
Speaker 2: metrics error rate, response rate, latencies, certain things. You might
Speaker 2: have a little bit more leverage in one model versus
Speaker 2: the other, but you should be interesting to understanding your craft,
Speaker 2: which is in the end it is could be two ways, right,
Speaker 2: One is really just writing the code and writing that
Speaker 2: in a way that scales in terms of features, but
Speaker 2: also in terms of performance and probably many many other angles,
Speaker 2: right and you know, not testability and all sorts of things.
Speaker 2: So that that's definitely want to but there is I
Speaker 2: think when we go a little bit you a build it,
Speaker 2: you run it model, you also have this you architect
Speaker 2: potentially differently because running workloads in the cloud, especially when
Speaker 2: you go into a little bit more of these ACYNC
Speaker 2: processing type of things. Right, do you have an event
Speaker 2: and something can happen in the back background, So think
Speaker 2: of an order being taken in into the systems. A
Speaker 2: bunch of things that are happening, but the customers don't
Speaker 2: need to wait for that. They you don't need to
Speaker 2: wait until this thing get shipped out while the browser
Speaker 2: spends for two weeks. That's not really really right. So
Speaker 2: there is a lot of these aspects, but like, how
Speaker 2: would you architect something from scratch given the latest accourages
Speaker 2: that the cloud providers provide. That requires constant challenging because
Speaker 2: like five plus years ago it was SNS and SQS
Speaker 2: on Amazon, but now with a vent bridge, it's just
Speaker 2: like so many more features. And then how do you
Speaker 2: do that between teams? Do you still go through either
Speaker 2: arrest or graph Well or so API or do you
Speaker 2: actually hook up some teams internally through some of those
Speaker 2: you know, cloud native event systems. There's many ways to
Speaker 2: get there, and like always can lead to excellence in
Speaker 2: the very context. But I think just saying yeah, we
Speaker 2: made this decision five plus years ago is yes, but
Speaker 2: you're missing out on you can delete these three services
Speaker 2: then just moving data around, which is solved by this
Speaker 2: configuration over here in the cloud provider now. So I
Speaker 2: think if you're not doing these type of things and
Speaker 2: then assuming cloud deployment now and not any other type
Speaker 2: of deployments, like yes, it keeps your team busy, it
Speaker 2: keeps potentially team efficient. They might even have engineering excellence
Speaker 2: within that code, but not owning that code at all,
Speaker 2: but moving that to configuration and let Amazon who is
Speaker 2: or Google cloud or asia scale that for you and
Speaker 2: manage that for you. That's really where scalability and excellence
Speaker 2: also it definitely comes in.
Speaker 5: You said something really interesting about the amount of time
Speaker 5: a team should be dedicated to engineering excellence.
Speaker 4: I think you just sort of dropped it in there.
Speaker 4: That's thirty percent number.
Speaker 5: And I'm curious, you know, as another perspective here, maybe
Speaker 5: will you've got one like how much time do you
Speaker 5: do teams feel like in and around you, how much
Speaker 5: time they actually have to invest in this? Because I know,
Speaker 5: even at smaller company scale or larger ones, I know
Speaker 5: there's like some expectations that go around, but then you
Speaker 5: have maybe some product managers that come in and say, no,
Speaker 5: we have to just deliver.
Speaker 4: You know, how do you do do do.
Speaker 5: Teams actually get that time to do this or is
Speaker 5: it about cutting out that time and actually saying no, right,
Speaker 5: you know, even though we have all this feature work
Speaker 5: to do, we still need to spend this amount of
Speaker 5: time really looking at what we've got in questioning our
Speaker 5: status quo, like our engineer is actually being given that
Speaker 5: capability or is this just you know a nice thing
Speaker 5: to say and doesn't happen in practice.
Speaker 2: Yeah, it definitely happens in practice for my environment. It's
Speaker 2: more or less depending on teams. And I think it's
Speaker 2: you know, to response to my direct responsibility to enable
Speaker 2: that in the team. And you know you're working with
Speaker 2: you know, alongside product and alongside ux, so it's it's
Speaker 2: it's my thing to defend that time, right Otherwise, I mean,
Speaker 2: it's just one part of my job. But you know,
Speaker 2: the company also values engineering practices a lot, so there
Speaker 2: is a bunch of that filter filmed by already central things, right,
Speaker 2: mandatory upgrades, mandatory things. Also, what we're doing as part
Speaker 2: of quarterly planning is you're showing, Okay, how much do
Speaker 2: you spend on things that someone else tells you to
Speaker 2: do on the feature side, things that you actually want
Speaker 2: to do for your customer because you understood that problem
Speaker 2: really trying to do that, and then things basically in
Speaker 2: this whole engineering excellence it's on even so I think
Speaker 2: that it's probably the wrong world we want to call that,
Speaker 2: you know, this maintenance moving forward. So I think there
Speaker 2: is this excellent part which I think isn't is not
Speaker 2: necessarily reported out there, but I think that is something
Speaker 2: as the engineering leaders they are definitely responsible to get
Speaker 2: that into the teams and the mindset of the teams
Speaker 2: and the inn wilds right every individual there's forty hours
Speaker 2: a week. Sometimes it can be someone is passionate about
Speaker 2: the following block podcast like this one, and it comes
Speaker 2: out with a cool idea to actually start. Others are following,
Speaker 2: you know, some news, and others are actually interested in
Speaker 2: reading the documentation on the cloud provider or SaaS provided
Speaker 2: whatever and saying hey, there's a new technique, let's try
Speaker 2: it out. I encourage really everyone to do that. That's
Speaker 2: way harder to do and get that into the mindset
Speaker 2: of everyone versus the otis is a lot of more,
Speaker 2: you know, leadership driven and saying hey, by the way,
Speaker 2: we need to do this for the long term health.
Speaker 2: And it comes a little bit as yeah, the expectation
Speaker 2: is that you're looking to that promise space.
Speaker 1: I think that there's a lot of so let me
Speaker 1: say this, if your definition of excellence is defined correctly,
Speaker 1: I think a lot of the time and effort it
Speaker 1: takes to achieve excellence just happens natively. And I use
Speaker 1: an example of like a sports team. You know, every
Speaker 1: member of a sports team has a different definition of excellence,
Speaker 1: but each each team member's definition of excellence supports the
Speaker 1: definition of excellence above that. So if you start it
Speaker 1: like the franchise owner, their definition of excellence is to
Speaker 1: sell as many tickets to their games as possible.
Speaker 3: But then you get down to the coach, and the coach's.
Speaker 1: Definition of excellence is to hire the best quality of
Speaker 1: players for the team that creates a well performing team
Speaker 1: that sells the most number of tickets possible. And when
Speaker 1: you get to an individual team player, that person's job
Speaker 1: maybe to you know, catch the ball and move the
Speaker 1: ball down field, or to defend against the ball being moved,
Speaker 1: or whatever their specific role is for that sport so
Speaker 1: that their team performs better, so that they have the
Speaker 1: support of the fans, so that they sell more tickets
Speaker 1: to the games. And so each one of those people
Speaker 1: have has a different definition of excellence, but they all
Speaker 1: support each other going all the way up. And then
Speaker 1: whenever you get down to that individual team player, they
Speaker 1: know that they have to catch the ball or defend
Speaker 1: the ball or whatever, and that's their metric that they
Speaker 1: measure against. And so it's easy for them to make
Speaker 1: decisions that either support or don't support that definition of
Speaker 1: excellence because it's clearly defined with what they do and
Speaker 1: how that supports the overall organization.
Speaker 5: I mean, I feel like you too, just keep picking
Speaker 5: up the football analogy and just the ticket in me
Speaker 5: because both my teams have been kicked out of their
Speaker 5: associated competitions. Right.
Speaker 1: Well, I'll be honest, I'm a Dallas Cowboys fan for
Speaker 1: American football, So I have no idea how to define
Speaker 1: excellence because clearly I don't understan and the game.
Speaker 2: So I think where you were going to is to me,
Speaker 2: it's a little bit the business metrics, right Basically, the
Speaker 2: KPIs that are are very outcome driven, and I think
Speaker 2: the excellent part in that relation to sports will be
Speaker 2: how how do people show up day to day on
Speaker 2: that training, not leastly on the match, but almost more
Speaker 2: on the training. How do they challenge each other to
Speaker 2: become better? What's the unique training plan that they have
Speaker 2: that is or it could be also you know they
Speaker 2: bring into college and say, by the way, now we
Speaker 2: know what the competing team does, so we can actually
Speaker 2: outperform them through through the brain instead of through the body. Basically,
Speaker 2: so I think that is that to me, their verre
Speaker 2: it starts to be really, yes, everyone does that. Everyone
Speaker 2: wants to sell more tickets, Everyone wants to have the
Speaker 2: best coach, everyone wants to have the best players and
Speaker 2: basically get the best performance out of the value invested.
Speaker 2: But I think this the excellence is not achieved by that.
Speaker 2: That's really achieving it by management, by you know, there
Speaker 2: is a lot of value and that's needed in a corporation.
Speaker 2: That's needed in the corporational e sports and a corporation,
Speaker 2: you know, like this brand, but this excellence around like
Speaker 2: how can I how can it be innovative in my training?
Speaker 2: How can I be innovative in my nutrition? How can
Speaker 2: I be innovative in in the tactics during the game.
Speaker 2: That's I think where versus the next level? And and
Speaker 2: also you can follow schoolbooks, you need to come up
Speaker 2: with your own approaches and more un convention or buttn't
Speaker 2: you're not necessarily your own, but at least you need
Speaker 2: to read through those unconventional approaches, try them out, and
Speaker 2: adopt them to your needs. So that that's a little
Speaker 2: bit this type of how I would distinguish that where
Speaker 2: it's engineering excellence, This is I think I was conflating
Speaker 2: those a little bit before as I went to do
Speaker 2: the other topic. But I think there's very good like
Speaker 2: to draw a line on their excellent starts and they're
Speaker 2: you know, engineering practices or you know, other things are
Speaker 2: there to just like establish the baseline.
Speaker 5: I think you really touched on an interesting aspect here
Speaker 5: because I do remember reading a paper about how in
Speaker 5: order to actually get better, we need to do that
Speaker 5: thing called practice. And if we only do the execute
Speaker 5: production thing, you know, show up to the games all
Speaker 5: the time, we won't get.
Speaker 4: That practice then.
Speaker 5: And the practice is where we have the opportunity to
Speaker 5: really change up what we're doing or learn more.
Speaker 4: And I do see the industry moving sort of at
Speaker 4: the moment more away from that and forgetting that we
Speaker 4: need to do the practice.
Speaker 5: Maybe the engineering excellence really is what do you do
Speaker 5: during your software development your engineering practice sessions?
Speaker 4: You know, what are you doing there? How are you evaluating?
Speaker 5: And there was a bunch of years ago there was
Speaker 5: actually a documentary soccer documentary that was recording neymar and
Speaker 5: the Brazilian soccer player, and they used.
Speaker 4: Brain diodes to.
Speaker 5: Identify how much he's thinking during a game versus practice.
Speaker 5: And the interesting thing was that the actual amount that
Speaker 5: you're thinking during production is very low, like almost no
Speaker 5: brain activity at all when measured, whereas during practice there's
Speaker 5: a lot of thought that goes into it into that practice.
Speaker 4: And I don't know if there's a direct.
Speaker 5: Corollary here, but I mean it really made me think
Speaker 5: of this that maybe the engineering excellence is challenging how
Speaker 5: we're practicing day to day so that we're ready to
Speaker 5: do the actual production work.
Speaker 4: And what does that even look like in the software
Speaker 4: engineering domain.
Speaker 2: I don't know that. I think you have the production right, yeah,
Speaker 2: but it's like the deploduct production button is such a thing.
Speaker 2: Can you do that? Calm me? Or can you only
Speaker 2: do that you know under stress? Right? And that the
Speaker 2: practice in.
Speaker 4: This case, I mean, that's always stressful for.
Speaker 2: Me, testing the automation, the error detection, the roullterback you have,
Speaker 2: but the actual the result is that you have come
Speaker 2: when you pushed it button.
Speaker 1: Yeah, that's really that's a that's got that's got me
Speaker 1: thinking a lot Warren where it feels like in some circumstances,
Speaker 1: like our job, every day we're showing up to game
Speaker 1: day and there is no training time.
Speaker 4: Doesn't it.
Speaker 1: Yeah, So it's like, how and I'm thinking about that
Speaker 1: twofold like one, Yeah, it would be super cool to
Speaker 1: have training time too, just like at a very fundamental level,
Speaker 1: go do a test to compare E C S T
Speaker 1: e KS.
Speaker 2: And like.
Speaker 1: Get enough experience to have an informed opinion as to
Speaker 1: war or not. We should be making that migration between
Speaker 1: the two. But from a business perspective. From a business perspective,
Speaker 1: you know, do I want to fund my business in
Speaker 1: such a way so that my employees have time to
Speaker 1: go and do that stuff, or do I want them
Speaker 1: gain day every day? Like if I'm just purely focused
Speaker 1: on the numbers of my business, I want them I
Speaker 1: want every day to be game day, regardless of the
Speaker 1: implications on them for that. So there's like a there's
Speaker 1: a trade off there that I can't quite wrap my
Speaker 1: head around at the moment.
Speaker 5: There was this joke, I don't know how based in reality.
Speaker 5: It was about a manager talking to the I don't
Speaker 5: know head of engineering saying, hey, you know, our engineers
Speaker 5: need to be trained better.
Speaker 4: You know that takes a lot of money and effort
Speaker 4: and time. You know, can we just utilize them? What
Speaker 4: if they're not good enough?
Speaker 3: Right?
Speaker 4: You know what I mean, No one's perfect.
Speaker 5: As we pointed out, they don't maximize the number of
Speaker 5: lines of code or business value, and so we do
Speaker 5: need to train them.
Speaker 4: And the concern is what if we train them and
Speaker 4: they leave?
Speaker 5: And the manager's response is what if we don't train
Speaker 5: them and they stay? Right, Marcus, you're gonna say.
Speaker 2: Something absolutely, But I think, I mean, training is a
Speaker 2: hard one to really make. You know, there's some people
Speaker 2: who are just like embracing it, uh, and others it's
Speaker 2: just like hard. And also I see it in my
Speaker 2: daily schedule. It's really very hard to get it in.
Speaker 2: I mean, what works well for me is going running
Speaker 2: over lunch and listening into a podcast. That's one form
Speaker 2: of media consumption that works. And it's not just like
Speaker 2: the doom scrawling type of value, but it's actually you know,
Speaker 2: building up some some more thoughts and it's also have
Speaker 2: to space time there. But I think, you know, in
Speaker 2: terms of where you you might have been build is
Speaker 2: I think there is a space where it's just like
Speaker 2: there's constantly noise around a team. That's when you will
Speaker 2: potentially even management will come in and they typically send
Speaker 2: That's when the consultants show up, and when management shows
Speaker 2: up and you know, weird reporting and someone looks at
Speaker 2: how many metro crasts did they do yesterday, that's a
Speaker 2: really bad sign. That's when you have underinvested. I think
Speaker 2: there I'm talking to is already like, yes, you're bringing
Speaker 2: up the point. Does is it valuable to do this
Speaker 2: or not? Right? So we tried to sneak in those
Speaker 2: type of things at the side a little bit. I
Speaker 2: think there's certain things that are definitely of high value
Speaker 2: of you know, think of not having passwords or it's
Speaker 2: just like way simpler to manage, and it's also possible today.
Speaker 2: Five plus years ago it was very very hard to
Speaker 2: do and these days the systems have evolve. So I
Speaker 2: think this is again like adjusting to huries the world
Speaker 2: today and you know, the world has just innovated AI
Speaker 2: in the last I don't know, it feels like cloud
Speaker 2: three days and there's this whole whole hype cycle. Yeah,
Speaker 2: the world is moving fairly fast, right, or you know
Speaker 2: the cloud didn't exist ten years ago, that's only a
Speaker 2: decade well, or you know, depending on what's the starting
Speaker 2: point of the cloud, that's probably IBM saying the cloud
Speaker 2: exists for the last forty years and their own world
Speaker 2: did this different definition of that. But it's really really
Speaker 2: moving fast, right and and not keeping up with that
Speaker 2: is I think it gets you into a situation where
Speaker 2: at some point a company might say, we need to
Speaker 2: stop and we need a year to overhaul our accounting infrastructure.
Speaker 2: And that's a really really hard job to do from
Speaker 2: a team perspective, from a moral perspective, from actually can
Speaker 2: you achieve that outcome? And you know, how can you
Speaker 2: keep the customers happy? And so I think this is
Speaker 2: the balance of that. Nevertheless, I think after that, even
Speaker 2: if you don't, if you say, okay, scale down on
Speaker 2: this bucket of making things better for the sake of
Speaker 2: making it better is I think as an engineer, you
Speaker 2: just want to have that. You want to have this drive,
Speaker 2: you want to show off. And I think this is
Speaker 2: also the opportunities that in the worlds have in corporations,
Speaker 2: no matter what role they have and what level it is,
Speaker 2: to showing off and saying I understand this technique, here's
Speaker 2: a documentation, and you know it might become the de
Speaker 2: factors standard how things are being done in the company
Speaker 2: because it comes with the context of the company. It
Speaker 2: comes with that. This is how we do deployments, this
Speaker 2: is how we run things, this is the responsibility. These
Speaker 2: are in the incentives. And if someone is able to
Speaker 2: document it in a way or to create a create
Speaker 2: some shared code that's easy to reuse and so on,
Speaker 2: I think that's really really powerful and allows also the
Speaker 2: junior engineers to shine. They might they might actually the
Speaker 2: biggest druggle for them might be to put it out
Speaker 2: into the world. Especially when it's an internal world. It's
Speaker 2: almost harder and putting out there in the world and
Speaker 2: nobody might see it, that's easy. But putting it out
Speaker 2: internally and you have an intelligent purpose for that, it's
Speaker 2: like you need you need some cheerleading from you know,
Speaker 2: the basically the directors of engineering or you know, your
Speaker 2: team lead to others to actually put it into a
Speaker 2: shape that is not going to annoy the others, but
Speaker 2: it's actually being appreciated. And that is really company and
Speaker 2: political context that you need to fully understand to make
Speaker 2: sure that you can do that. But it's I think
Speaker 2: it's a big opportunity for everyone, and especially for more
Speaker 2: junior or just like very technical savvy person who don't
Speaker 2: want to deal with that, but actually would be interesting
Speaker 2: to have that better excellence across all the teams and
Speaker 2: not just for themselves.
Speaker 1: So is that part of your definition of engineering excellence
Speaker 1: is promoting promoting internal things within the teams and supporting
Speaker 1: them and like mandating that feedback loop to encourage excellence.
Speaker 2: Not necessarily mandating, but this is what I encourage you
Speaker 2: to do this damage. Yeah, right, yeah, I think I
Speaker 2: think I ut put that in and here we go.
Speaker 2: Letten to the excellence part to go more into how
Speaker 2: do you manage the people and how do you grow
Speaker 2: the people? Is I want to encourage everyone on the
Speaker 2: opportunities are endless, and yes, day to day this hard
Speaker 2: first to identify the right thing for the right person
Speaker 2: and so on, but like just simply the topics that
Speaker 2: are on my plate. It's around security, it's about infrastructure.
Speaker 2: It's about front and parts, it's about back in parts.
Speaker 2: It's about you know, potentially libraries, it's about upgrades, about
Speaker 2: deployment techniques. It's about challenging how we do run things
Speaker 2: in the cloud. It might be a SaaS provided you're
Speaker 2: using and oh be using that suboptimal and so on.
Speaker 2: It is endless, and I think as you're an engineer.
Speaker 2: You are seeing these things and I'm here, I'm not
Speaker 2: even talking about the bugs you're seeing in your own
Speaker 2: system and the and the error reports and other things. Right,
Speaker 2: this is another part where you hopefully, hopefully that's your
Speaker 2: first home. We'll just try make sure that the customers
Speaker 2: are happy. Right, That's that's the first part where you
Speaker 2: want to use the the data in terms of oh,
Speaker 2: we had forty seven errors in this timeframe, we should
Speaker 2: probably bring it down or no, this is really kind
Speaker 2: of the maximum. How we like we just decided in
Speaker 2: the team with with you know, senior input to know
Speaker 2: this this this is good. Right, this is really world
Speaker 2: class where you can be. But then all the other
Speaker 2: topics it is just as you and you will be
Speaker 2: welcome because a lot of those topics might not be
Speaker 2: so passionately done by many much best female as an
Speaker 2: admin task or I do the minimum versus those are
Speaker 2: really unbound and you can have an impact that is
Speaker 2: way across teams, way outside of your sphere of directly
Speaker 2: influencing day to day. So it's both in the day
Speaker 2: to day and how do you make yourself and your
Speaker 2: team better and your softly you're directly supporting, as well
Speaker 2: as the opportunity out there of if you do things
Speaker 2: slightly more generic, share it slightly further, or you know,
Speaker 2: raise your arm on you know, becoming you know, the
Speaker 2: security expert in your team, and you'll learn all that,
Speaker 2: and then you start looking at the data yourself and
Speaker 2: to start crashing why are you doing it this way?
Speaker 2: Start improving it into your own team, then starting sharing, Hey,
Speaker 2: this is what it is. Those are the three steps.
Speaker 2: It's that easy, Like, oh, once it's easy, others will
Speaker 2: also do it. Versus this neverless thing of you know,
Speaker 2: we might need to invest some technical spike time at
Speaker 2: some point and it's in the backlog or the back
Speaker 2: of our minds of people and it's never getting to
Speaker 2: versus simplifying it, paving the path so others can just
Speaker 2: walk it, and then hopefully if they're paved path, you're
Speaker 2: not trying to reinvent the bill. You're just walking there
Speaker 2: because you trust your colleagues. And the combination of those
Speaker 2: also like appreciating this is one way of doing it
Speaker 2: might not be the perfect way, but it helps you accelerate.
Speaker 2: So it's both ways. It's not only sharing, it's also
Speaker 2: taking what's there.
Speaker 4: It's weird.
Speaker 5: I think that we put so much emphasis on needing
Speaker 5: to train up sort of inexperienced or junior engineers, but
Speaker 5: then when it comes to the teams as a whole
Speaker 5: or more senior engineers, I think there's a tendency to
Speaker 5: forget that there's an opportunity there to spend time actually
Speaker 5: reviewing what we're doing and like how we're working or
Speaker 5: how we're doing it effectively, even at an individual level.
Speaker 5: And I'm not really sure where that comes from. Maybe
Speaker 5: it's like once you reach senior engineer like that's it.
Speaker 5: You know, companies like that's it. You know you're as
Speaker 5: successful as you need to be for us, and junior
Speaker 5: engineers as long as you learn our systems, you're as
Speaker 5: successful as you need to be for us. But there
Speaker 5: is still that learning aspect there, and I'm wondering if
Speaker 5: it's enough to just say, spend take thirty percent of
Speaker 5: your time to learn new things, to listen to the
Speaker 5: Adventures in DevOps podcast, or you know, use new technologies
Speaker 5: and new UI frameworks, or whether or not there's something
Speaker 5: that we need to directly encourage to make that happen effectively.
Speaker 1: I think it has to be a much more active role,
Speaker 1: because it's far too easy for individuals, especially junior individuals,
Speaker 1: to see tickets in their backlog or work that's assigned
Speaker 1: to them and prioritize that over learning and education. Even
Speaker 1: whenever we say, hey, you should be spending time on
Speaker 1: learning and education, I don't think you can take a
Speaker 1: passive role in just telling them that and then assuming
Speaker 1: that they're doing it. I think it's something that you
Speaker 1: have to actively manage and track. Whether that's you know,
Speaker 1: telling them, hey, open a ticket and log your time
Speaker 1: when you're listening to the podcast or you know, or
Speaker 1: whatever the metric is. I think it has to be
Speaker 1: something that's that's active and measurable.
Speaker 5: I mean, they're not actually gonna know either, right Like
Speaker 5: they're in a you're in a spot, your team is
Speaker 5: in a spot where even if you said, hey, you know,
Speaker 5: spend a lot of your time on this, like what
Speaker 5: is the right activities that you should be doing or
Speaker 5: the right knowledge you should be gaining?
Speaker 2: Uh?
Speaker 5: And maybe that's why we I think as an industry,
Speaker 5: we fall back into like watch these YouTube videos or
Speaker 5: go to some conferences as if that's you know, the
Speaker 5: right way to just automatically make this happen. But I
Speaker 5: feel like that maybe even a little bit too passive
Speaker 5: as well. Right, you know, there's a lot of information
Speaker 5: floating around that doesn't necessarily convert into actual con crete
Speaker 5: learning that can be applied back into what we're doing
Speaker 5: day to day.
Speaker 3: Yeah, for sure.
Speaker 1: I think from my perspective, like whenever I first started
Speaker 1: going to conferences, I was like, oh my god, this
Speaker 1: is going to be amazing.
Speaker 3: I'm going to learn so much.
Speaker 1: And now I look at conferences as a way to
Speaker 1: completely screw up my inbox where I'll never get a
Speaker 1: valid email again because of all the mailing lists I
Speaker 1: get subscribed to by going to the conference.
Speaker 5: Minor LinkedIn connections are totally like I just got back
Speaker 5: from Germany last week, and like, I don't know who
Speaker 5: these people are that are connected with me.
Speaker 4: Like I try to, you know, approve all of them,
Speaker 4: and I'm like, I don't remember you. I'm sorry.
Speaker 5: Sure I did learn something though, as a speaker, I
Speaker 5: actually learned something really interesting, and that's it amazes me
Speaker 5: how many companies have on premise data centers or they're
Speaker 5: renting a data center from a third party provider where
Speaker 5: they're pretty much getting bare metal that they're putting stuff on,
Speaker 5: and they don't have a need for this, like they're
Speaker 5: not at a.
Speaker 4: Level or scale or industry that requires it.
Speaker 5: It's really quite amazing that there's just still so many
Speaker 5: in this field, and I wonder if it's a lack
Speaker 5: of engineering excellence that has left them there.
Speaker 2: Is the thing, right, right?
Speaker 1: Yeah, I think there's been a resurgence in going to
Speaker 1: the data center over the last few years, and I've
Speaker 1: known quite a few people who are using the cost
Speaker 1: of AWS and GCP as the driver for that, But
Speaker 1: I'm not convenient completely convinced on that. For like, if
Speaker 1: you know what your workload is and it's pretty consistent
Speaker 1: and well defined, I think if you had a good
Speaker 1: data center provider that could send someone out to swap
Speaker 1: failed hard drives and replaced nick cards.
Speaker 3: And all that kind of stuff, it might work. But
Speaker 3: I don't know. That's I mean a lot of faith
Speaker 3: and there.
Speaker 4: I mean for sure.
Speaker 5: I mean you're in an interesting area though, Will, because
Speaker 5: like I feel like you deal with a lot of
Speaker 5: companies at Polagon that are in this weird domain that
Speaker 5: aren't necessarily cloud cloudish public cloudish optimized, right I mean
Speaker 5: consensus networks and cryptocurrency companies, et cetera.
Speaker 4: Like I get that, but there are just so many like.
Speaker 5: Companies out there that are startups or even larger companies
Speaker 5: that are spending sixty million plus dollars euros francs a year.
Speaker 4: Who thinks there are a benefit there? Marcus, you we're
Speaker 4: going to say something.
Speaker 2: Yeah, I think, I think you. It's a nice segue
Speaker 2: to one of the thoughts I haven't. And I was
Speaker 2: talking about, Hey, there's this baseline, but then comes to
Speaker 2: innovation in it, and innovation is a lot of different things,
Speaker 2: Like we talked about education, we talked about you know,
Speaker 2: you know, figuring out and taking on additional responsibilitiness on
Speaker 2: But one of those odds that have is basically, and
Speaker 2: it comes exactly where it's, oh my god, cloud is
Speaker 2: so Expensive's cost per compute is kind of a term
Speaker 2: that I came up and made up myself, but it's like,
Speaker 2: what's the cost you're spending for the compute you're using?
Speaker 2: And you know, basically, even in the cloud, you run
Speaker 2: things on a virtual machine. By definition, you don't want
Speaker 2: this to be more than ten or twenty percent CPU,
Speaker 2: and you want to have at least I don't know,
Speaker 2: fifty percent memory free. So you're paying paying the money
Speaker 2: what you should have in your pocket, and you do
Speaker 2: your team's bonuses into the bonuses of the cloud providers. Right.
Speaker 2: This is they're charging for CPU which they are actually
Speaker 2: not using. It's all these shared hosting environments. So that's
Speaker 2: their game, right, and that's their margin. And yet it
Speaker 2: is relatively attractive. So I think this is also very
Speaker 2: this innovation comes in. So how do you actually bring
Speaker 2: I think if you optimize cost per compute, so not
Speaker 2: purely cost, because purely cost of organization is just like
Speaker 2: turn everything off and you're done right of the business.
Speaker 2: You will never ever have costs again. And I think
Speaker 2: the alternative if it's just like run everything on AWS,
Speaker 2: LANDA or whatever your serverlized function is, might also not
Speaker 2: be the answer. That also doesn't say you cannot use
Speaker 2: relation database. You must use down B or Mango, the
Speaker 2: B or whatever it might be. It comes way more nuanced,
Speaker 2: but cenarly, if you look at your cloud spend, cloud
Speaker 2: spend is very easy because you get your statistics over
Speaker 2: time and everything. You can analyze and tag things and sounds,
Speaker 2: so it's quite you can have this this engineering hard
Speaker 2: and start with the data and be data driven. Just
Speaker 2: trying to iterate there. But look at the top five.
Speaker 2: They're probably consuming fifty eight percent of of your money. Right.
Speaker 2: Some of that is justified because that's actually the workload
Speaker 2: that's running there. Others such just like wait a bit,
Speaker 2: you know it's waiting. It's it's mostly the margin on
Speaker 2: over provisioning. This is you know, relation databases you need.
Speaker 2: There's no way to scale up and scale down at
Speaker 2: least not you know, there is a way hope. By
Speaker 2: the way, we have a peak season for two months,
Speaker 2: so we scale up for the next instant and scale
Speaker 2: down again or increase the distance. So slow moving scalability
Speaker 2: can do. But those even during the days are very
Speaker 2: hard to do and if it's more spiky, almost impossible
Speaker 2: to do. But you're paying for your for your risk.
Speaker 2: And got feeling a little bit almost like I mean,
Speaker 2: obviously hopefully you look at data, look at some requests
Speaker 2: died some low testing and everything, but like, yeah, there
Speaker 2: might be this one customer coming along and put some
Speaker 2: load on it. It's like I want to be prepared
Speaker 2: for that, right, and you need to be prepared as
Speaker 2: a business for that, and you need to be over
Speaker 2: provisioned versus the more you go to basically really pay
Speaker 2: per use. If there's nobody coming, it's zero cost. If
Speaker 2: someone is coming, when you pay what you use. This
Speaker 2: again has at some point it has a limit, and
Speaker 2: it might be do my own thing is cheaper, right,
Speaker 2: So at some point, you know, running certain things on
Speaker 2: a huge scale is a central team that's expertise there
Speaker 2: might be the better thing for some companies or running
Speaker 2: again back to bear Metal, I mean there's just a
Speaker 2: little bit of a hype of all we run this
Speaker 2: thing on bear Metal. There are those workloads, but they
Speaker 2: typically don't come from a startup. They don't come from
Speaker 2: you know, smallish two pizza sized teams running their own thing,
Speaker 2: even if they have a lot of requests. Those recreess
Speaker 2: are typically you know, request then do some processing, call
Speaker 2: of database, return the thing. And and like I think
Speaker 2: cost per compute is a nice proxy to say, do
Speaker 2: I have a spot where my top five or top
Speaker 2: three things? And that's just looking at the pure costs,
Speaker 2: right there comes to operational costs and other things that
Speaker 2: you need to encounter. But at least this is hard data.
Speaker 2: What you can look at and trying to optimize for
Speaker 2: that and some point I'm good, Now I feel like
Speaker 2: the costs spent these lum and I think, you know
Speaker 2: a lot of companies might not have done that or
Speaker 2: might not have incentivized the team, and so oh my
Speaker 2: cloud costs are so expensive. But then you know, really
Speaker 2: running that very same workload, it's the very same properties.
Speaker 2: People can just spin up things and other things. You
Speaker 2: paint that on the rack. Now, I mean community serves
Speaker 2: need to have in there to actually have for those spikes,
Speaker 2: because like scaling up and down doesn't make sense anymore.
Speaker 2: Just like put it on full load and that's what
Speaker 2: you're what you're you're having in there.
Speaker 5: I think there's some inspiration from the web three space
Speaker 5: that sort of coin the term gas fee, right, the
Speaker 5: the actual cost of that execution compute to the line
Speaker 5: of execution for per instruction. I don't I don't know
Speaker 5: what that means, but I mean, I think there is
Speaker 5: an interesting aspect here where when we deal with the
Speaker 5: physical goods and we have a capital expenditure, you buy
Speaker 5: a thing and then you depreciate the value over time
Speaker 5: because the metal rusts or the components get out of
Speaker 5: date or you know, whatever it is about those, however
Speaker 5: it's manufactured or being consumed.
Speaker 4: We sort of lost that as we switch to from
Speaker 4: capital or cap.
Speaker 5: X expenditures to operational expenditures, which I think we're rewarded
Speaker 5: for having. Hey, you know, don't upfront by this, because
Speaker 5: there's you know, it's going to depreciate over time. You know,
Speaker 5: take a car for instance, you buy a car, it
Speaker 5: gets worse over time, It's worth nothing after you drive
Speaker 5: it off for the lot, and then you drive for
Speaker 5: another ten years and then it rusts and it's gone right.
Speaker 5: Whereas you know, if you're renting the car, you always
Speaker 5: get the newest, latest version, and if you never drive anywhere,
Speaker 5: then it's you don't pay anything, you know, conceivably. But
Speaker 5: I feel like there is a middle ground here where
Speaker 5: a lot of companies end up in and they forget that,
Speaker 5: even things like easy Too or Kubernetes.
Speaker 4: There there is a capital expenditure.
Speaker 5: It's just not on the bar metal, it's not on
Speaker 5: the virtual machine potentially, it's it's this other aspect. You know,
Speaker 5: it's slightly higher. It's not all all backs or all
Speaker 5: cap backs, but somewhere in between and because we've gotten
Speaker 5: away from that. I feel like we've lost people paying
Speaker 5: attention to how much we're actually expending on the part
Speaker 5: that's not fully operational, that that's fully Like you said,
Speaker 5: the total cost of ownership is one aspect to pull
Speaker 5: on here. And I mean, I don't know if there's
Speaker 5: a question here, just sort of an interesting tangent.
Speaker 4: I guess no.
Speaker 2: I think you know, just paying one thousand dollars every
Speaker 2: month is yeah, relatively easy to understand and beta, wait,
Speaker 2: this is what my business costs versus every three years
Speaker 2: paying thirty thousand, fifty thousands, Like, wait a bit, I'm
Speaker 2: not spending that money, right, there's projects undying on just
Speaker 2: like trying to do that, right, that's just like the
Speaker 2: small numbers now, but now, and I think you of
Speaker 2: not using one thousand but using a million, right, A
Speaker 2: million a month is one thing to pay, but then
Speaker 2: have this fifty million dollar built every three four years
Speaker 2: is a different type of discussion. And and I think
Speaker 2: this is as you're optimizing the cost, you're not bringing
Speaker 2: the cost down by ten dollars, one hundred dollars, one
Speaker 2: thousand dollars, ten thousand dollars, whatever your workload might be
Speaker 2: you're bringing that down multiplied by I just multiply the
Speaker 2: to a year, right and look at the yearly cost, right,
Speaker 2: because at some point, you know, things change so much
Speaker 2: that it's very hard to for long over the long term.
Speaker 2: I think it's probably basic finance here, but also it's
Speaker 2: important that numbers team members understand, like, no, you're not
Speaker 2: bringing down this workload. You know, fixing a bug for
Speaker 2: one user. No, you're fixing a bug for one user
Speaker 2: day which is tween a sixty five users a year,
Speaker 2: or you buy I don't know whatever it is, and
Speaker 2: it's like, no, this is This is a little bit
Speaker 2: where capital investment in terms of software engineering comes in.
Speaker 2: And you know, some of that is on a product side,
Speaker 2: but I would argue some of that is on engineering
Speaker 2: side of saying if we fix these three things, that's
Speaker 2: the impact you have to the customers, to the business,
Speaker 2: to the cost to whatever. And that's you know, if
Speaker 2: you invest an hour, now like you can basically count
Speaker 2: how many days or how many weeks it takes until
Speaker 2: the return of investment is There are very simple things
Speaker 2: and there's very more complicated models. But like get the
Speaker 2: back of the Napkain calculation into everyone's head, like just like, yeah,
Speaker 2: make those decisions based on that. And if you're really
Speaker 2: good at this type of investing your time where there
Speaker 2: is a return, and preferably return is on better customer
Speaker 2: service and better customer value because that really feels your business, right,
Speaker 2: So like old engineering excellence aside, but where you can
Speaker 2: invest and you know, prove improved things from an engineering side.
Speaker 2: And it has also either direct so sometimes it's indirection.
Speaker 2: How do you measure downtime? Right? If the team was
Speaker 2: down once and once a month is pretty bad, right, Uh,
Speaker 2: all of a sudden it's not down anymore. It's probably
Speaker 2: a good thing that happened. I don't know X months
Speaker 2: in the past, but it probably didn't happen or the
Speaker 2: work change incidentally, right, it probably happened because someone's yeah,
Speaker 2: right the thing.
Speaker 3: Mm hmm.
Speaker 5: I mean, I you come for the engineering excellence and
Speaker 5: get the uh you know x maybe startup entrepreneur here
Speaker 5: giving you financial advice on how to run your cloud.
Speaker 4: I mean, I I love the topic. I feel I
Speaker 4: fear it's a it's another whole hour, uh which you're
Speaker 4: going off which no, I mean it's super interesting. I
Speaker 4: mean I I I really love the idea.
Speaker 5: I actually, you know, I'm hoping maybe we can find
Speaker 5: someone to come on to actually uh discuss that in detail,
Speaker 5: because I think there's, as you pointed out, really interesting
Speaker 5: overlap with uh, the complexity of managing cloud resources or
Speaker 5: I'm sorry, if you're on prem.
Speaker 1: If they're on prem, they'd never heard the podcast because
Speaker 1: they're crawling underneath the floor running network cables or something.
Speaker 1: Actually I am curious about that's if that's still a thing,
Speaker 1: like if you are running on prem, are you still
Speaker 1: for people who are running on prem or they still
Speaker 1: jumping in the car driving out to the data center
Speaker 1: swapping hard drives, racking servers.
Speaker 4: I mean, I can imagine it's a separate job.
Speaker 5: And there are the third party bare metal providers out
Speaker 5: there that are trying to sell that. So I think
Speaker 5: something that the even larger cloud providers offer or how
Speaker 5: they work is they end up renting like locked in
Speaker 5: space inside physical buildings that.
Speaker 4: Are called cages that you can't get in.
Speaker 5: So who's doing that activity though, I'm that is a
Speaker 5: good question, right, I mean, because you don't want the
Speaker 5: data center owner to be accessing your physical machines and
Speaker 5: you know, pulling out the HSM that you've got installed there,
Speaker 5: like that's that's a security vulnerability. So you've got to
Speaker 5: have your own operation engineers that you're employing to perform
Speaker 5: that activity. Otherwise, you know, you might as well be
Speaker 5: using a public cloud. But you know, if someone knows,
Speaker 5: I think they should ping us on discord and actually,
Speaker 5: you know, give us a topic of conversation here. I
Speaker 5: think that'd be super interesting to have someone with an
Speaker 5: expertise in on premise data center management.
Speaker 3: Oh absolutely, I'm one hundred percent on that one.
Speaker 2: I think that woo especially interesting for those that are
Speaker 2: you know, medium company size, not those very big players.
Speaker 2: They might have other economics and other reasons to do.
Speaker 4: That, yeah for sure.
Speaker 2: Also not those who have to do it for compliant reasons,
Speaker 2: because they're because it's the thing and that's the reason
Speaker 2: why we do it. But really, like you know, those
Speaker 2: have a decent engineering team, but those are not super
Speaker 2: so so I think a lot of people could actually
Speaker 2: relate and so, so, yes, would be a fantastic topic.
Speaker 1: Yeah, I would like to have somebody from well, yeah,
Speaker 1: because there's the email provider hey dot com that was
Speaker 1: started by I don't remember what his full name is.
Speaker 1: He goes by the initials Dha. She's like the founder
Speaker 1: of Rubion Rails or something. But they have left the
Speaker 1: cloud completely operate all their own physical hardware and then
Speaker 1: just recently announced that they're ditching Kubernetes for their own
Speaker 1: orchestration platform that they have created, and like they're just
Speaker 1: like completely going off and inventing their own stuff. And
Speaker 1: I think that would be a really cool conversation to
Speaker 1: have and say, just you know, how's that working out
Speaker 1: for you?
Speaker 2: Yeah? I think I think what's interesting is is you
Speaker 2: know where there's the value of kuman it is or
Speaker 2: these type of things, right, these big frameworks in these
Speaker 2: solve I mean kum that came out of this Google project, right,
Speaker 2: and they run a few more service than I do, right,
Speaker 2: and and and I think it goes down a little
Speaker 2: bit too often many companies do either Hey, they have
Speaker 2: just like say, some CP needs, or they have classical
Speaker 2: that break cress type of needs to the database, or
Speaker 2: they have some aazing processing kind of these servilized pipeline
Speaker 2: type of needs. I feel like if they were running
Speaker 2: and I'm guessing here is krumen it is really in
Speaker 2: the cloud in terms of how potential is a cloud
Speaker 2: provide to sell it and the potentially the options that
Speaker 2: were there. I think that happened a three years ago
Speaker 2: when they announced it. It's different than oh, like you
Speaker 2: go all in on the cloud and figure out how
Speaker 2: can you you know, costper compute, how like cost per
Speaker 2: compute we're not good for them? How can you squeeze
Speaker 2: it out? I think there might have been a cloud
Speaker 2: way to do it. And those are you know, top
Speaker 2: notche engineers. I'm pretty sure they looked at a bunch
Speaker 2: of things. But this is also one of the arguments
Speaker 2: like why you know, I was you know, looking at
Speaker 2: I don't want the krumanides upgrade a year, but if
Speaker 2: it's there, it's not the worst thing, right, But there
Speaker 2: are other things like kumunides. You know a lot of
Speaker 2: people put the stamp on a LinkedIn profile because they
Speaker 2: want to have the stamp. It's the wrong incentive, right,
Speaker 2: and it's but it's also a huge complexity to learn.
Speaker 2: I mean, learning cumanities is equally challenging us learning ITWS
Speaker 2: and learning Google Cloud or whatever it is. Right, It's
Speaker 2: a huge thing and really really mastering that and then
Speaker 2: scaling it to your needs and getting the right cost
Speaker 2: performance security profile. That's another undertaking versus most teams might
Speaker 2: actually just like, yeah, we have the kubanities in the
Speaker 2: cloud and fully managed and these are the seven settings
Speaker 2: we're looking at. And if you're doing that, it's probably
Speaker 2: like something like you know, a more cloud native saying
Speaker 2: that it is more or higher higher managed service like
Speaker 2: NAS has easy as it's just a cluster, has a name.
Speaker 2: That's all you can configure, and then you'll say, oh,
Speaker 2: here's this service, here's the doctor instance, and that's giving
Speaker 2: me so much CPU and memory and then hopefully that
Speaker 2: matches the wallet you have and the workload you're thrown against.
Speaker 2: It has the lot of right balance, but it managed
Speaker 2: this deal all the scaling for you, Like okay, you
Speaker 2: need to configure that right, but it's like it does
Speaker 2: all the magic and the nine thing about it. In
Speaker 2: five years, if you never touch the code, okay, your
Speaker 2: own code might run into security volunabarities, but the underlying
Speaker 2: hardware has changed seven times, runs faster by then, has
Speaker 2: been gone through innovation cycles by the cloud provider, and
Speaker 2: while doing nothing, so your code gets more secure and
Speaker 2: faster while doing nothing. This is a really really beautiful
Speaker 2: thing to have then using managed services, and I think
Speaker 2: that's something that's undervalued. And often like you know this
Speaker 2: on ITA, that's not sure how much we can go
Speaker 2: deep there versus out like there is you back it
Speaker 2: by your own virtual machine and you're only easy to
Speaker 2: instance versus by fargate, which is basically easy to fleet
Speaker 2: managed by WS so you don't see them is looking
Speaker 2: at a one to one comparison. Obviously back by easy
Speaker 2: two is cheaper because you manage it, you have the responsibility.
Speaker 2: But they also know there's so much free capacity there
Speaker 2: what they can basically what they are charging you because
Speaker 2: you have to manage the capacity versus you're really only
Speaker 2: paying what you're needing. So again it's yet one level higher.
Speaker 2: So depending on where you are on the managed services,
Speaker 2: go one level higher and you get a bunch of
Speaker 2: things for free on maintenance, security, upgrades, maintainability and like
Speaker 2: again strive there, like what's your next player? Then after that?
Speaker 2: What's your next player? After that? At some point I
Speaker 2: think there are two stopping points. Some point Okay, I
Speaker 2: don't understand this thing anymore because it's too abstract. There's
Speaker 2: services out there, drop this thing, and we kind of
Speaker 2: run it right, and you want to have a little
Speaker 2: bit more control depending on your needs. Great for startups,
Speaker 2: great for prototypes, great for the amoor wasn't great for
Speaker 2: certain workloads, but not lessening everything. So that's one stopping point.
Speaker 2: And I think the other stopping point is when you
Speaker 2: don't it's not a managed service, but the manage service
Speaker 2: manages you kind of think it is. At one point,
Speaker 2: at some workflow characteristics, they might become expensive. A very
Speaker 2: classical one is the NAT Gateway. Just put it up.
Speaker 2: It's very cheap, but once you actually hits traffic at
Speaker 2: some point you think, should have run my own, right,
Speaker 2: And those are things that I you know, I'm there
Speaker 2: going back to the Hay conversation, is my yeah, should
Speaker 2: I run not their mental arcy, but should I run
Speaker 2: my own here? And it's a slippery slope, right, I
Speaker 2: mean it's from a cost performance cost professor, absolutely, it's
Speaker 2: probably also not that hard to run it. But then
Speaker 2: comes the whole security maintenance, and nobody will have a
Speaker 2: clue of how this works because there you need to
Speaker 2: go deeper into networking and to routing tables and all
Speaker 2: the other things. What you need to understand. I don't
Speaker 2: necessarily want to spend that time there, but I fully
Speaker 2: understand companies that don't run this nap game because it's
Speaker 2: just like hitting a limit where they want to spend
Speaker 2: the money. Yeah. So it's just one example, right, So,
Speaker 2: so I think even managed services they are not this
Speaker 2: is the way to go. There is orders, what you
Speaker 2: need to set and hate by they here's here's where
Speaker 2: we stop or here. Excellence actually means not doing the
Speaker 2: thing that sound.
Speaker 5: Yeah, no, I think that's a good a good Uh,
Speaker 5: you know, circle back around to the beginning of the
Speaker 5: conversation really, like, you know, figuring out what decisions you
Speaker 5: want to make, uh, and even what the is to
Speaker 5: make those decisions is.
Speaker 4: What we're calling excellent, our engineering excellence.
Speaker 3: I fear that.
Speaker 5: We may be taking up too much of your time,
Speaker 5: and I have this thought that maybe we should move
Speaker 5: on to picks.
Speaker 4: If there is no one last thing that you wanted
Speaker 4: to share.
Speaker 2: Oh, I feel like I've talked so much. Thanks for
Speaker 2: having me, so just go on. Yeah.
Speaker 1: I do want to chime in with one last thing
Speaker 1: and say that I think that net Gateways is an
Speaker 1: individual line item on Amazon profit and lost balance sheet.
Speaker 2: It is it is right, it's not storage. Storage is
Speaker 2: not a one.
Speaker 1: Yeah, Like, we sold five hundred million coffeemakers last year
Speaker 1: and it almost made us as much money as net gateways.
Speaker 2: Something like that. Oh my god, you could go into
Speaker 2: that direction. But let's let's.
Speaker 3: Right cool, let's do picks. Warren to bring a pick
Speaker 3: this week.
Speaker 2: I did.
Speaker 5: I know, usually it's a book, but I just bought
Speaker 5: this thing. It's a Legion from Lenovo. It's a tablet.
Speaker 5: I loved my Google Nexus for forever. I think I
Speaker 5: had it like ten years or so. Never let me
Speaker 5: down up until last year, where I just totally froze.
Speaker 5: For the most part, I blame the apps that I
Speaker 5: have to run, like they just take up more and
Speaker 5: more memory and upgrades from Google. But this thing a
Speaker 5: little pricey, but still, I mean it's it's been perfect.
Speaker 5: It's been absolutely fantastic. Everything I want in a tablet
Speaker 5: for going on vacation with.
Speaker 3: So what are the common things you do with your
Speaker 3: tablet that make this a great tablet?
Speaker 2: Oh?
Speaker 5: Yeah, I mean I'm not a gamer, but it's a
Speaker 5: gaming tablet, which means the battery life is incredibly great,
Speaker 5: and so I get on like fourteen hour flights when
Speaker 5: I'm going to conferences on the other side of the world,
Speaker 5: and so I needed to last that long. So content
Speaker 5: for uh, you know, watching movies, et cetera. I read
Speaker 5: a lot of books. So storage space it has a
Speaker 5: removable flash drive, making it really easy to transfer stuff
Speaker 5: from my desktop. You know, those are really my core ones.
Speaker 5: I mean, every once in a while I need a
Speaker 5: game to actually entertain me on a fourteen plus hour flight,
Speaker 5: which I don't recommend to anyone unless there's something really
Speaker 5: good in it for you. So that that's really my
Speaker 5: my core requirement there, which is why I've gone for
Speaker 5: this instead of something with like E yanch or some
Speaker 5: or on that approach.
Speaker 3: Right now, cool, all right, Marcus, would you bring for
Speaker 3: a pick?
Speaker 2: I thought of bringing that podcast, like a little bit
Speaker 2: of competition to you. I do a little bit of sports,
Speaker 2: and it's one of the way off of actually getting
Speaker 2: some information. But it's it's Farnham straight Shane Perrish, and
Speaker 2: he interviews just like top business leaders, top sports and
Speaker 2: coaches and other things. And I've gone through wellow one
Speaker 2: hundred series of I think he's at a one hundred
Speaker 2: and ninety podcast by now does it every week or
Speaker 2: every second week. I think every second week, and I'm
Speaker 2: following along almost everything, and I think it's it's just inspirational.
Speaker 2: What you know, talk about engineering excellence. It is what
Speaker 2: are other disciplines doing right? Sometimes it's someone in psychology
Speaker 2: some other science feels investing sports everything and like just
Speaker 2: gives you a different perspective learning from the best. What
Speaker 2: they have already figured out is what his tagline is.
Speaker 2: And I think I really really like that. And I
Speaker 2: can only recommend if you are short of time. I
Speaker 2: don't know how much I should go into recommend recommending
Speaker 2: other people here, but it's clear. Thinking is the book
Speaker 2: Shane Heart brought up half a year ago. It's summarizing
Speaker 2: about the whole community what he has built up over
Speaker 2: the years and the consistency definitely worth a read right on.
Speaker 3: Very cool cool.
Speaker 1: So my pick for the week is there's a song
Speaker 1: that's actually an older song now from a band called Metallica.
Speaker 1: The song is called one, And it feels so weird
Speaker 1: to say that that's an old song now because that
Speaker 1: just reminds me that I am old now. But there's
Speaker 1: you know, there's a lot of people who haven't heard it,
Speaker 1: And so there's a YouTube reaction video from.
Speaker 3: A YouTuber called the Vocalist. She's like a.
Speaker 1: Classically trained vocal instructor, and so she watches the music
Speaker 1: video for Metallica's song one and reacts to it. And
Speaker 1: it's cool because there's just a lot of layers into this.
Speaker 1: The song one itself is about a movie from nineteen
Speaker 1: seventy three called Johnny Got His Gun, about a soldier
Speaker 1: who's injured in World War One, and.
Speaker 3: So the song is about that.
Speaker 1: And then so there's clips from the movie in the
Speaker 1: music video. But then the orchestration of the song itself
Speaker 1: is just really well done. And then her reaction to
Speaker 1: that as she watches it and she's trying to comprehend
Speaker 1: the movie that the song is about, plus the orchestration
Speaker 1: and the instrumental work of the song, Like it's just
Speaker 1: all these layers in one short video. That's super cool,
Speaker 1: definitely worth checking out, whether you are a Metallica fan
Speaker 1: or not. It's just there's entertainment there for people of
Speaker 1: all types. So that is YouTuber The Vocalist and her
Speaker 1: reaction of Metallica song one, and that's all we have
Speaker 1: for the podcast.
Speaker 3: So for everyone listening to the podcasting, thank you for listening.
Speaker 1: For all the people watching the live streams on twitch,
Speaker 1: YouTube or whatever other streaming platforms we're on, thank you
Speaker 1: for watching. And Marcus, thanks for joining us. This has
Speaker 1: been a cool conversation.
Speaker 2: Thanks a lot for having me. Was an honor and
Speaker 2: was also a fun conversation. Definitely some challenging ideas and
Speaker 2: thoughts right on.
Speaker 1: Warren, as always, thanks for joining me and co hosting
Speaker 1: the show.
Speaker 3: We'll see everyone next week.