All Episodes

February 6, 2024 30 mins

On this week’s episode, host Conor Bronsdon sit down with Guilherme Sesterheim, SAP DevOps SRE Engineer at AWS. Guilherme delves into applying Chaos Engineering and DevOps principles to SAP, a domain traditionally seen as risk-averse and resistant to rapid innovation.

With expertise in both open-source technologies and SAP, Guilherme shares how he’s bringing modern practices to SAP environments at AWS. He explores how Chaos Engineering can be used to test and improve the resilience of SAP systems, focusing on HANA, SAP’s in-memory database. The discussion also touches on the challenges of integrating these practices within the SAP framework and the broader implications for SAP users and the tech industry.

Episode Highlights:

  • 00:20 What does it mean to apply chaos engineering to testing SAP installation
  • 04:05 What does it mean to have DevOps around SAP?
  • 05:58 Guilherme’s approach to DevOps practices around SAP
  • 10:01 The challenge of handling installation and migration
  • 11:50 How to Start Applying Chaos Engineering to Your SAP Instance
  • 16:57 The 12 Scenarios When You Inject Failures on SAP
  • 19:24 How Guilherme ended up at AWS working on SAP
  • 23:14 What’s Next in DevOps Guilherme is Excited About?

Show Notes:

Support the show:


Mark as Played

Episode Transcript

Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Guilherme Sesterheim (00:00):
Let's break the application.

Let's kill some process.
Let's see what happens.
You can inject failures on thenetwork, so let's add some
And wow, latency in the SAPworld is one of the hardest
things to spot.
Let's inject a system crash,let's inject some DNS failure,
some resolution failure, andlet's see what happens.
Is your engineering team focusedon efficiency, but struggling

with inaccessible or costly Dorametrics.
Insights into the health of yourengineering team, don't have to
be complicated or expensive.
That's why LinearB isintroducing free door metrics
for all.
Say goodbye to spreadsheets andmanual tracking or paying for
your door and metrics.
LinearB is giving away a free.
Comprehensive Dora dashboardpack the central insights,

including all Forkey Dorametrics tailored to your team's
Industry standard benchmarks forgauging performance and setting
data-driven goals.
Plus additional leading metrics,including emerge, frequency, and
pull request size.
Empower your team with themetrics they deserve.
Sign up for your free Doradashboard today at LinearB dot
IO slash Dora.
Or follow the link in the shownotes.

Conor Bronsdon (01:03):
Hey everyone, welcome back to day two of Dev
Interrupted at DevOps EnterpriseSummit.
I'm your co host Conor Bronsonand I'm joined by Gilerme
SAP DevOps, SRE, engineer atAmazon Web Services.
Gil, welcome to the podcast.

Guilherme Sesterheim (01:16):
Very nice to meet you guys.
Thank you for the introduction.

Conor Bronsdon (01:18):
All right.
It's a, it's a great pleasure tohave you with us.
I know you're, uh, a speakerhere at the, at the summit.
I know you had a reallyinteresting talk, on applying
chaos engineering techniques totesting SAP installation.
Can you dive into that?
Chaos engineering is afascinating topic.

Guilherme Sesterheim (01:31):
I come from a very strong open source
and DevOps culture.
So, I don't know, I'm prettycomfortable with regular
languages Terraform, Jenkins,Ansible.
So all of these open sourcetechnologies I'm very
comfortable with.
Around three or four years ago Ijoined AWS, I worked for the
professional services, and Ijoined an SAP team.

So I do have some SAP backgroundas well from, I don't know, the
very beginning of my profession,but then I bring in all this
load of knowledge andinformation around the open
source part into the SAP world.
I don't know if everyone isfamiliar with, so it's a huge
company, uh, yesterday I broughtone very nice number just to

show how big they are on thepresentation.
So basically if you look forthat on their website, they say
that 77 percent of world'stransaction revenue pass through
at least one SAP system.

Conor Bronsdon (02:26):

Guilherme Sesterheim (02:26):
77 percent of everything, all the money,
that flows through this world,touches at least one.
That's incredible.
That's amazing.
I dunno, any company, any othercompany that has a, a, a metric
huge like that.
So SAP is this very, mature andalso, a risk adverse company.
Uh, so yes, they are slower thanother companies into like

modernizing their, are their,their, their applications.
So basically what we approachedyesterday was then how do we
bring some modern technologies,some modern practices actually
like the chaos engineering intothe SAP world.
So basically there are somestuff that we can do right now
Testing how resilient yourservers on SAP are.

Yesterday we focused 100 percenton HANA, which is the database
from SAP, and in memorydatabase.
So basically approaching someconcept of how do we inject
How do we check of, uh, howthat, how things went?
So did the database behaveexactly like I was expecting
before the failure injection, orI don't know did something go

wrong while I was doing that.
So there are some techniquessome things that we can do using
open source technology, into theSAP world without going inside
the SAP.
So that's when things get morestrict when we talk about SAP.
But when we are still talkingabout the server, there's a lot
we can do around the operationsalready.

Conor Bronsdon (03:49):
So it's more about using opensource techniques and chaos
engineering to extend SAP'scapabilities.

Guilherme Sesterheim (03:55):
Exactly, exactly.
So when we talk about DevOps forSAP, the most common question
that I have, questions that Iget, I can Uh, separate them
into two.
So DevOps inside SAP.
And yeah, that's very complex.
We don't have a lot to do there.
And frankly, it's hard, ofcourse, SAP has some offer

because it's a buzzword.
So it makes sense to talk aboutDevOps inside SAP, but honestly,
there's not much, in my opinion,not much value that is generated
by doing DevOps inside SAP,because of the limitations,

Conor Bronsdon (04:29):
you're just so limited on what you can do.

Guilherme Sesterheim (04:30):
So it's hard for, I dunno,automating tests.
So a very few, a very smallnumber of companies is already
using Git for SS a p, soEverybody's using it except, uh,
SAP, uh, except the, thedevelopers that go inside.
SAP, right?
And the second bucket.
So DevOps inside SAP?
Yeah, it's very shy.
It's, it's hard.
There's not much value added tothe companies that want to use

Of course, there are some thingsthat we can do, but again, not
much value added.
And on the second bucket we getthen the DevOps around SAP and
basically that's how I call itaround SAP because you're not
going inside, of course.
Then you can get the servers,you can interact with the
So I work for AWS my examples gointo the EC Choose and, and how
we do things inside AWS Yeah, sobasically when you install SAP

in a server, you have there,your easy choose is standing and
the regular procedure for, Idunno, any major application
inside big organizations, isthat okay, you installed
something, it's working, youleave it there, you don't touch
So that's the regular, howthings go, right?
Besides, I don't know, yourpatching windows, your security
maintenances, you don't touchthat very often.

So all the suggestion presentedyesterday was around, let's try
to shift that mindset a bit morefrom that famous analogy from
pets versus cattle, which ispretty famous for DevOps.
Extremely new when we go to SAP.
So let's try to shift that focusa bit more.
So there are companies that usedto do their high availability

testings every six months.
We can, yeah, so that's a lot.
And the majority of them,

Conor Bronsdon (06:03):
If you're not watching on YouTube here, my
eyes just got very big.

Guilherme Sesterheim (06:08):
But that's the typical.
So the majority of companies, atleast that I interact with, big
companies here in the States,they do like every six months.
Some of them, they do threemonths.
And I heard about one customerthat want to do that, uh, every
two weeks.
So that was the most aggressiveone I've ever heard.
So Yes, we can do some, we cancombine some of the DevOps

practices, some of the DevOpsnon technologies, so we can
speed that up, we can do thosetestings more often, and we can
be better prepared for, I don'tknow, failures and things that
typically happen.
And we are just waiting forthem, right?
So instead of just waiting here,seated at my chair, let's do
something more proactive.

Conor Bronsdon (06:47):
Let's try to go ahead and solve the problem in
It makes total sense.
Like, you've talked about acouple of examples here of how
you're leveraging DevOpspractices to extend SAP's
capabilities, and enhance theapproaches you can take around
automated testing and otherthings.
Are there different categoriesof DevOps practices that you're
Is it mostly around testing?
What's your approach?

Guilherme Sesterheim (07:07):
Yeah, so what I've seen and the
opportunities, so I come from avery strong SAP, again
professional services insideAWS.
So we interact with biggestcompanies here in the states,
like huge shops of SAP.
So we try to focus more on theopportunities and the struggles
we see, like on the market.
This is very nice because weinteract and we learn a lot

every single day, whenever wetalk to a new customer or an
existing customer about thestruggles that they are having.
So what I.
What I guess that all of theautomations and all of these
improvements we've been workingfor the last two or three years,
I guess they kind ofcategorizing something around
the operations part.
'cause again, we cannot goinside SAP, right?
We do, but it's not very muchnice.

Uh, but then we go into theoperations.
So again, automating this, uh,chaos engineering part, um,
automating the, the auto-scalingfor SAP.
So again, auto-scaling issomething very.
usual, I can say.
But that's pretty tricky whenyou go to SAP and you cannot do
all the scaling in the majorityof the servers, so you do all

the scaling in just one or twoof them.
So even that.
The automation is not like astreamline, it's not a simple
flow like we have for with otherapplications.
Uh, so you have to have astrategy of how do you want to,
to autoscale and also the limitof your out scaling.
So I can summarize that into theoperations part.

Conor Bronsdon (08:32):
I'd love to understand the, thestrategy piece.
What's the, what's maybe atypical or example strategy that
you would take to, toimplementing this?

Guilherme Sesterheim (08:40):
So, a typical SAP landscape, you have
the database, so let's use Hannahere as a, as the example,
So, uh, the in-memory databasefrom SAP, you have an A SCS and
ERS and I'm sorry, I don'tremember all the, what, the,
what does that mean?

Conor Bronsdon (08:54):
We're gonna use a lot of acronyms.
That's okay.

Guilherme Sesterheim (08:55):
But basically that's an in Q server.
So that guy centralizes all therequests between the platform
internally, so it's prettyimportant.
And here we already start seeingsome stuff so different.
names that SAP gives to commonthings that the open source
world knows.
So, D A S C S is always theprimary one.

And A S C S is always working.
If that guy goes down, E R Stakes up.
Which is basically the samesoftware, the same software
installed, but once A SES isprimary and ERS is secondary.
That's the rule.
So it's not the same applicationthat you're deploying to
different servers.
So they are differentapplications, but they work in a
high availability scenario.

Now getting to your question,the third layer of this, of
database, q server, and then thethird layer is actually where
your users connect to.
So that is the PAS primaryapplication server, something
like that.
That one I remembered.
And when you want to auto scaleSAP, so you don't talk about
database, you don't talk aboutthe NQ server, you just talk

about where your users connect.
And if you have just one serverright now, and the database is
working fine with that oneserver, that same database will
have to handle well if you have10 servers.
So that's a struggle in planningfrom the very beginning.
So that is the only guy, thePAS, that you can auto scale.
I don't know, 1, 2, 3, 6, 10,20, I don't know, 30 servers for

the biggest shops out there.
Then your users will connectthere, and again, your database
has to handle that.
So you have to have a verypowerful, big instance.
Because again, just one of them,even though you have two
databases, let's say, for highavailability.
Uh, two Q servers.
Only one of them is always theprimary, and the other one is
just idle waiting for somethingto happen.

Conor Bronsdon (10:37):
So, I mean, this is intriguing.
Obviously there's a massivescale.
This, as you mentioned, 77% ofworldwide monetary transactions
have at least one SAP connectionin them.
There's clearly some distinctchallenges that you're facing in
trying to extend thecapabilities of DevOps to SAP
because of, to your point, how,conservative they are about what
moving forward.

Are there other challenges you'dlike to highlight, that maybe we
haven't dug into so far?
Areas you want to dive intomore?

Guilherme Sesterheim (11:04):
Well, I guess that one of the biggest
challenges, uh, we see out thereis still this huge complex, uh,
installation and migrationprocess.
And that's understandable,right?
Because this is usually thespine of every organization is
an SAT server, right?
So if you are doing anything, Idunno, your your orders system,
your, online cards.

So all of that is working in adifferent layer.
And after that, that's pushingdata inside SAP.
So SAP is usually the spine ofevery organization.
So we are very much used to, Idunno, talk about integrations
on SAP as well.
One of the biggest challenges westill see, and honestly I dunno
very much about how SAP's visionfor that, for the future, how
they're investing on that isstill so breaking these huge I

cannot say single, but fewpoints of failure.
So still, if you want an SAP,you have to go under a complex
project some months for sure.
Installing things.
And so you cannot do SAP insideKubernetes.
That is one example.
So these common stack, I toldyou, of course there are
examples, hybrids, which isSAP's, e-commerce runs on

That's nice.
That's not as simple as, Idunno, installing SonarCube or
uh, Atlassian Totally.
Or these other guys.
So those guys are pretty sosimple.
You just.
Connect there and

Conor Bronsdon (12:19):
plug and play to some extent.

Guilherme Sesterheim (12:20):
Yeah, so they're very simple.
So SAP doesn't work that way.
So this is, I guess, the mainchallenge that still blocks a
lot of things from, I dunno, foreven modernizing even more.
So you don't, still don't talkabout microservices on SAP and
it's a long journey to get tothere.
So for me, this is the biggestchallenge because since we have
so few big points, so many few,that's nice to say, so many, few

big points of failure, breakingthose should be simpler, I don't
know, for further modernization.

Conor Bronsdon (12:52):
Right, yeah, and it's interesting to talk about
this in a chaos engineeringcontext, because it really
limits the potential of thetesting you can do.
What advice would you have forpeople who either listen to your
talk or listen to this podcast,but how to start approaching
this and saying, Okay, I want toapply chaos engineering
techniques to my SAP instance.
I want to start trying to extendthis.

How would you recommend they getstarted?

Guilherme Sesterheim (13:16):
So this is kind of the mindsetthat I've been applying since I
started to interact with SAPagain.
So again, I mentioned that I didhave some SAPs experience, then
I shifted into the open source,and now I am, I am an SAP folk
What I've been doing is, everytime that you, talk to an SAP
expert, you're gonna say, Hey, Iwanna do chaos engineering for

He's gonna laugh.
He is gonna say, yeah.
Are you nuts?
What is chaos engineering, firstof all, what is chaos
The same subjects.
They don't flow with the, theSAP totally world as well.

Conor Bronsdon (13:47):
Do you wanna do a brief definition for folks?
I, we've had episodes on thisbefore, but I wanna make sure
everyone here has a definitionof chaos engineering, just to
make sure they have something intheir head.

Guilherme Sesterheim (13:54):
So basically chaos engineer is, is
you injecting failures in yourservers, in your applications.
Not just, not just the serverson purpose in a controlled
environment, in a controlledway, so that you can prepare for
the worst scenario.
Some examples you can injectfailures inside your servers.
Like I said, I dunno.
Let's break the application.
Let's kill some process.
Let's see what happens.

You can inject failures on thenetwork, so let's add some
And wow, latency in the SAPworld is one of the hardest
things to spot.
Let's inject.
I dunno, a system crash, let'sinject, uh, some DNS failure,
some resolution failure, andlet's see what happens.
So case engineering goes allaround that, injecting things,
errors on purpose, and hey,let's see what happens.

And once we see what happened,let's come up with a plan so
that thing doesn't happen forreal when a real scenario is

Conor Bronsdon (14:43):
The, thing I really love aboutChaos Engineering is it's, it's
such an iterative way to drivecontinuous learning and to
prepare your, your company, yourteam, your technology.
for a worst case scenario.
And particularly when we'rethinking about something like
SAP that is so integral to theway the world works with
payments, uh, it seems likehaving that injection of failure

so you can understand how toimprove it and make it safer,
uh, would be crucial.
To your point, you've kind ofalluded to this, like it's a
little concerning that it's sohard to test failure because
that means in a worst casescenario, which they do happen,
even to companies like SAP,there is so much potential for
us not to be prepared.

Guilherme Sesterheim (15:23):
So even on the newest releases of SS a P,
which are, which is called BTP,uh, I guess it's business
technology platform, which islike the very, very new, I dunno
if it was released still in 2022or 2021.
I don't remember.
But for SAP, that's extremelynew, so a very few number of
customers are already usingthat.
So that guy's supposed to havemicroservices and a more modern

approach, but again, it'sextremely new for SAP users, and
it's still blurry exactly whatyou can do.
So I've been talking to some ofmy personal friends that work on
They told me, okay, yeah, youcan do this, you can do that.

Conor Bronsdon (16:06):
So there's potential, that's great to hear.
So I sidetracked you a littlebit, but I was wondering about
the strategy that you'drecommend to folks who are
trying to extend, uh, thecapabilities of SAP and start
doing some of this chaosengineering testing.

Guilherme Sesterheim (16:18):
Oh, yeah.
So, so that's basically whatI've been doing for the last
three to four years.
If you go to an SAP four and yousay, Hey, let's do chaos
engineering, SAP P Oh, wow.
Who's gonna laugh?
Uh, if you're gonna go, if youwanna talk to them and say,
let's do unit testing, they justsay, why?
So they don't get the importanceof that.
So basically what I've beendoing, I've been trying to ask

the right questions on and, andtrying to engage just on the
right battles because everythingthat I've been here for, for
this operation side, again, sonot talking about DevOps inside
SAP about this operation side,chaos engineering, out scaling,
as I said, so some more regularmaintenance operations that we
Whenever I ask a question andthey say, yeah, that's not
possible, I ask why.

So far, always the response isvague.
So basically it's because Idon't know, or I'm not sure.
Yeah, in theory that can work,but I don't know.
SAP is not gonna support that.
Things like that.
So SAP not supporting stuff is,is also another big blocker for
Uh, but again, so my suggestionis.
Let's, let's try to, to, to, tochallenge those, those common

nouns, that are out there.
So usually SAP folks have beenworking for organizations, I
don't know, for 20 years, 30years.
So they are very, um, uh, again,conservative on what, on the
practices that they apply.
And sometimes they don't know.
What they don't know.
So if they're not sim uh, uh,familiar with the chaos
engineering concept, they arenot sure, how can you tell me?

We cannot do chaos engineeringfor SAP.
So my suggestion is let'schallenge those things that we
don't know.
And because many of them so farper my, uh, researchers, my work
with customers, uh, they arepossible.
We just are short of peopleimplementing them.

Conor Bronsdon (18:00):
And my understanding is you have 12
scenarios of failure that you'veidentified in particular.

Guilherme Sesterheim (18:05):
Basically, so these are 12 scenarios where
you inject failures on SAP andthe example of yesterday was
this Hanna database, uh, toagain, see what happens.
So basically there are somecommands specifically to, to
SAP, like HDB stop pacemaker.
So pacemaker is a library thatyou used to put the, the nodes
in synchronization.
So it's a cluster, uh, toolclustering into, so basically

you inject errors.
Each one of these 12 items, it'sone error that you inject on the
So first one I said, HDB stop.
It's not actually an error, butit's an unexpected behavior for
the cluster.
So you're basically, you havetwo servers running and you're
going to go there into theprimary and you're going to say,
Hey, stop.
Let's see what happens.

So the first thing that it'sgoing to tell is if your high
availability is set up properlyfor this scenario, okay?
Because this is just one of thescenarios.
So all of the 12 go aroundsomething like this.
The one that I find moreinteresting is the one that I
guess it's So closer to what wehear from Netflix practices.
So what do they do for injectingfailures on their application?

So one of the last one of these12 is basically you go, they are
into the Linux server, and youinject an error.
You basically echo somethinginto a very specific process
that happens in Linux, andthat's going to make the
instance crash.
So first the instance freezes,and again, so that's the
Scenario I like the most becausethe instance freezes.

So the instance doesn't tell itspeer.
Hey, I'm gonna go down theinstance doesn't tell AWS, hey,
I'm gonna go down So basicallythe instance freezes after two
or three minutes AWS realizesthat the instance finish Froze
then AWS stops the instance andthen yeah, there you go.
So this is unexpected.
So nobody ever told anyone that,hey, I'm going down, the first


Conor Bronsdon (19:54):
Decent bit of lag time built in there.

Guilherme Sesterheim (19:56):
Yes, exactly.
So let's monitor if the secondone is going to pick up from
there, like expected.
And so this is my favoritescenario so far of these 12 you

Conor Bronsdon (20:05):
Uh, it's interesting youmentioned Netflix.
Obviously, they do a fantasticjob of approaching chaos
Um, I'll shout out that we hadNora Jones, formerly of
Netflix's chaos engineeringteam.
Uh, on the podcast earlier thisyear, great episode.
If you're looking for someone tofollow up on this and learn more
about chaos engineering, thesetwo will fit really well
I'd love to dive into how yougot here at Guilherme.

How did you decide that this isthe, this is what you wanted to
work on next?
How did you end up at AWS doingthis?

Guilherme Sesterheim (20:33):
I like to say that no knowledge that we
ever got it throughout our, ourentire life is, is useless.
So when I started there with my17 eighteens, yeah, I was an ab
app developer.
AB app is the language that weused to develop inside SAP.
It's proprietary for SAP.
So I started like that in soworked like three years doing

After that, my career just.
shifted focus into more the opensource area, which, When I
started learning Pro programmingcoding, I was in love with Java,
so I always loved the opensource part.
Uh, so I saw some opportunitiesback at the company that I was,
I was an web developer, but, butI was seeing like this big team
working in Java and they weredoing great stuff, amazing

So things that were new, Idunno, 10 years ago that we are
talking about.
Nowadays like, I don't know,Service Smash, where load
balancers were extremelyexpensive, right?
There was no cloud, still.
But the adoption was not as itis today.
So I was seeing those guys doingthis amazing stuff.

100% the open source part.
And when I saw this opportunityat AWS, I always loved the
company because when we startedworking with the cloud, AWS,
it's the main player so far.
And I, Hey, I, I wanna work onAWS one of these days,

Conor Bronsdon (22:02):
Here you are.

Guilherme Sesterheim (22:03):
So when I saw the listing forsome DevOps inside SAP.
DevOps sAP engineer or DevOps,SRE engineer.
Maybe that's something thatwould be interesting.
So I applied myself, I discussedwith my, uh, previous manager,
uh, and he said, yeah, that'sbasically what you're looking
for, the questions I made,right?

So we were basically looking formore automations and doing
things for our customers faster.
That's when I landed AWS andit's been great.

Conor Bronsdon (22:33):
Are there other things happening at AWS that you
wanna mention as far as.
You know, exciting work beingdone, things that you see coming
down the horizon.

Guilherme Sesterheim (22:40):
Yeah, so my team works directly, so I'm
not from a services team, soeverything that I do, you won't
find in the co console, likelooking for, I dunno, RDS or EC2
i, I don't do that.
So basically I support customersthat are doing, uh, I dunno,
they are migrating or they areevolving there, they're doing
something inside the WS.
Let's say you are a customer,you are looking to, again,
migrate or evolve or dosomething inside the WS and you

want an expert to know how tobest run E-R-S-A-P inside the
WS, that's when my team comesin.

Conor Bronsdon (23:09):

Guilherme Sesterheim (23:09):
So the things that we do there the
most, so again, we try tomodernize and to acceler.
It's the journey of customers togo into AWS.
Because again, these projectsfor migrating stuff, they take
years, so they are veryexpensive.
And this is what we've beenfocusing a lot.
So nowadays we have tremendouslevels of automations and we can

have, I don't know, just newjoiners, guys that have just
joined the organization.
We have like this huge set ofautomations, Terraform,
CloudFormation, Ansible, Bash,whatever, to help them to be
Faster and to provision thingsfaster and to help the customers
So this is something that we arealways looking for because this
is what customers, I dunno, aremost talking about.

So AWS is just very customerobsessed company as everybody
And, and, and, yeah.
So we like to keep hearing whatour, what our customers tell us
and then invest on that.
So again, shortening the timeto, to, to, to deploy stuff or
to modernize right now.
Uh, so just from, from someexperience, I'm working on this
project where we are, uh,migrating, some applications

into Kubernetes.
So a few of them that SAPallows.
That's, that's really nice.

Conor Bronsdon (24:17):
I, I'm also curious, given thatwe're here at DevOps Enterprise
Summit, what are the things thatare happening in DevOps and
around the industry that youthink are gonna be kind of the
next applications of techniquesor, or strategy that you see

Guilherme Sesterheim (24:31):
For me, and I heard that yesterday in,
in many different ways from manydifferent speakers here at the
conference, and this issomething that for me is.
It's, it's great to hear becauseit's something that I believe a
So something that we were notused to here like 10 years ago
was this psychology part,getting more into organizations.

So when I, whenever we talk thatdevelopers have to be happier to
be more, productive whenever wetalk that managers, they have to
be happier or, I dunno, happieris not the word, but more
comfortable, more, moreempowered, more.

Conor Bronsdon (25:11):
There's research that shows that when teams feel
empowered and that their work isimpactful, they are happier and
they perform better.
And we're seeing more and moresigns of that, to your point,
like, with, like, happinessbeing such a predictor of
retention and success onproductivity.

Guilherme Sesterheim (25:26):
And so this is something that I believe
and I keep following, so lookingfor the stuff that I'm reading
and I'm learning, I'm studyingabout.
So this entire, let me use,again, the psychology world work
here for the organizations.
So we are taking better care ofpeople, we are taking better
care of managers, of individualcon contributors.
Uh, so the entire organizationsare talking about that right

And this is like a greatbeginning.
I'm not saying that we are justin the beginning, but this is
something already, if we take alook like 10 years ago.
It was just like you do as Isay.
So we are shifting this mindsetand when this happens, and it's
just not it, right?
It's for the entire, I dunno,any other industry, when folks

are more comfortable and whenthey, I dunno, they trust their
They do their jobs better.
They're delivering bettersoftware, higher quality
products, absolutely higherquality.
And more than that, what catchesme the most is that we are
investing in that folks, onthose folks lives.
Because if you're happy, I dunnoabout you.
I spend, I dunno, eight, 10hours a day in my work every

So if I'm awake.
WorkerB, WorkerB, WorkerB,WorkerB, WorkerB, So if you're
happy at work, you will be verymore, very much likely to be

happier, I don't know, with yourspouse, with your children, with
your family.
And then you start like thinkingbroadly, you, you won't care
just about yourself.
You care about, I don't know,the environment, you help your
community, you have yourneighborhood.

Conor Bronsdon (27:07):
So great perspective.

Guilherme Sesterheim (27:08):

Conor Bronsdon (27:09):
I think there's, there's toomany folks, particularly years
ago who kind of took thisperspective of like, We're going
to, like, use folks up in a way.
We're going to use theirefforts.
We're going to push through it.
And I think what we'vediscovered is, like, creating a
more sustainable socialcircuitry that really programs
teams to be more successful andhappier is more sustainable for

the team.
It's better, to your point, forthe individual and, I'm sure,
their community.
And it's also better for thecompany because it lets them be
more customer obsessed.
It lets them dive into theirwork more and be passionate.
They're going to spend thatextra care to understand and
dive into it.
And so I think it's a reallywonderful thing we're seeing.
And on that note, I'd love toask you.

You're very clearly passionateabout chaos engineering, about
the work you're doing at AWS.
Are there any closing thoughtsyou want to share with us?

Guilherme Sesterheim (27:59):
Yeah, so loving the conference.
So this is a very nice, um, Idon't know, set number of talks
here, speeches we've beenhearing.
And again, I love to hear thatwe are investing more and more
with this, uh, culture thing.
So just, just about the bookthey, they released yesterday,
uh, I was watching thepresentation where they

mentioned briefly what thebook's gonna, uh, and,

Conor Bronsdon (28:23):
And just to clarify, this is Wiring the
Winning organization by Dr.
Steve Spear and Jean Kim.
We interviewed, uh, Dr.
Spear on the podcast.
I'm not sure if it's gonna beout already by the time we
release this, but definitelycheck it out if it is.
It's great.
Great talk.

Guilherme Sesterheim (28:35):
Yeah, so basically that book,from what I understood of their
speech, introducing the book,they're basically, Approaching
same culture, same, uh, conceptsthat we are used to know, but in
a different way.

Conor Bronsdon (28:48):
And I love that.
And we program high performanceteams.
'cause there are exactlyconsistent, like there's
consistent high performanceacross different companies,
Like companies with the sameresources, the same initial
approach, build better teams andare more successful.
Like, uh, the, the example Dr.
Spear used on the podcast wasToyota, which is like vastly
outperformed in what employeesare capable of because they've

intentionally built these happy,high performing teams that are,
you know, cut down on frictionpoints and are set up for
That's a great highlight.
I really appreciate you bringingthat up, Guillermay, and thank
you so much for coming on theIt's been a fantastic pleasure
chatting with you, getting toknow you a little bit.
Hope to talk to you again soon.

Guilherme Sesterheim (29:25):
Thank you very much.
Thank you for the invitation aswell.
It's been great.
Thank you for the, I dunno, thepartnership here in the

Conor Bronsdon (29:30):
Our pleasure.

Guilherme Sesterheim (29:30):
That's awesome.

Conor Bronsdon (29:31):
If you want to hear more thoughts from
incredible leaders like Gil, me,check out our substack devon
We put out articles everyThursday, deep dives into
concepts like Chaos Engineeringon SAP and also, uh, our Tuesday
editions include articles fromour community.
our partners, and of course ourpodcasts.
I hope to talk to you all soonand thanks for listening.
Advertise With Us

Popular Podcasts

1. Start Here
2. Dateline NBC

2. Dateline NBC

Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations.

3. Amy and T.J. Podcast

3. Amy and T.J. Podcast

"Amy and T.J." is hosted by renowned television news anchors Amy Robach and T. J. Holmes. Hosts and executive producers Robach and Holmes are a formidable broadcasting team with decades of experience delivering headline news and captivating viewers nationwide. Now, the duo will get behind the microphone to explore meaningful conversations about current events, pop culture and everything in between. Nothing is off limits. “Amy & T.J.” is guaranteed to be informative, entertaining and above all, authentic. It marks the first time Robach and Holmes speak publicly since their own names became a part of the headlines. Follow @ajrobach, and @officialtjholmes on Instagram for updates.

Music, radio and podcasts, all free. Listen online or download the iHeart App.


© 2024 iHeartMedia, Inc.