Welcome to Bytes in Balance, the podcast where we navigate the wild world of software engineering together. I'm Dan and this is Damian. We have been juggling code, teams and sanity for over 35 years combined. From junior devs to principal engineers, we have worn every hat in the industry. In this podcast, we're sharing our journey, lessons learned and mentoring tricks to help you find your own balance.
It's not just about the tech. We dive into people, psychology, communication, and all the messy bits in between. Think of it as group therapy for the digital age. We bend to swap word stories and share what we think is solid advice. Sometimes we even bring guests to shake things up. This podcast is our way of tackling the stress, burnout, and growth pains that come with the job. It's as much a balancing act for us as it is for you. Grab a seat and let's navigate this madness together.
You'll find some interesting links in the episode description if you want to learn more about us or the topics we discuss. All right, let's get started. Hey, Dan. Good to see you again. This is, what, the sixth episode at this point? Yeah, it is. It's getting up there. Yeah, we're moving forward. It is getting interesting. What are we talking today?
Yeah. So today we decided we're talking about changing culture. First, what is engineering culture? And then how do you influence it? How do you change it? Is there a motivation to talk about this topic? What do you think this is important?
Yeah, so I think this comes up a lot as people progress in their careers. You know, when you're a junior engineer, you're expected to pretty much influence just the code you write and maybe the team around you. And as you progress into a mid-level, into a senior, into a... principle, you're expected to exert influence in the right way on the wider team, on the wider organization, on the whole company, depending on the definition of these levels. And this is a really hard thing.
It's a lot easier to go and take a piece of technology, a piece of software that has a bug or is failing somehow and troubleshoot it and fix it, right? That's a very straightforward task. But how do you take an entire organization and fix the culture? figure out what's wrong with the culture and how do you define what to fix about it and then how do you do it those are hard ambiguous things
And ultimately, that's why senior and principal engineers get paid the big bucks. So let's talk about how do you make that happen? How do you identify what needs to change and how do you do it? For me, this came from a mentee and he is moving towards principal engineer. staff engineer from senior engineer and he's navigating right now an organization that doesn't have necessarily the best practices and then he's trying to figure it out what
What do I do right here? Do I even move on to another company or do I stay here? And if I stay here, do I try to change it? Do I just stay here and do my job and keep just... in the in that comfort zone and i was telling him like those are the growing pains of moving from senior engineer to principal to staff engineer and you obviously have a cultural problem and one of your possibilities is try to change that culture
And that's very different to what you've been doing about just coding and keeping systems up and running, right? It's a completely different game. So that's where it comes from me.
Yeah, yeah. So I was thinking the way we would start is by just talking in general. What do we mean by culture? What is that? What is engineering culture? Well, one of the definitions that I have found about culture is the way that... people does in an organization people does things without having to think about and I read that definition from this book that I treasure a lot that is called the manager's path Camille Fournier
And I think it's the most succinct definition that I have found about culture, right? If you think about this, how people in an organization does things achieve goals.
without having to think too much about it. Yeah, I like that. Because oftentimes when we're talking about changing the culture, we're talking about certain... best practices either that we want to implement or that the we think the organization is not implementing and it's harming the organization or whatever but if you take a step back it's about all of those automatic
things, whether or not there is low friction to those happening or whether it feels like you're swimming upstream. So some examples are like the business, you want to roll out some changes to your software and you want to make sure that those don't have bugs or don't introduce problems.
In a healthy organization with a good engineering culture, they're probably writing unit tests. They probably have good practices around deployments and things like that. Then in an organization that doesn't have that, those things just aren't automatic. When people... implement changes they don't automatically go write unit tests for them they don't automatically have an easy way to test them and sometimes it's a lack of knowledge more often it's just
the combination of the culture and the software systems that they have were not designed for that yeah in the case of engineering culture is gonna spill into practices right it's like what do we do what don't we do what do we believe in and what we don't believe in right what do we see value of doing and what we don't for example you could argue that there will be a team
that will just find a lot of value writing automated integration tests and they believe on integration tests and then they find value there and then they now have this protection network. helps them and there could be teams in which they just don't believe that that's valuable enough to actually put the effort in right and they think oh i can just deploy and manually test and that's fine i don't have to spend a lot of time writing automation for this thing so i think
There is a belief in what we value factor involved. Yeah, and so why does it matter? What's the impact of a good culture? What's the impact of a bad culture? I'm sure both of us have been on teams where we've observed both of those. Yeah, I think I want to add another thing to the definition.
culture because I suspect that's also going to be important with what does it matter and I think it's also a culture helps you define what is acceptable and what is not acceptable and if you think in terms for example of amazon and amazon culture high bar operational amazon culture it's like there are things that are definitely not acceptable and they are
obvious reasons and nobody's whenever even think about doing such things right it's like touching a prod database with our change management right it's like it's just simply not acceptable it's not conceivable yeah I have a good example of this actually the other day i was loading up a job
link that somebody had sent me. I think it was hosted on Workday. Workday is this big platform for doing all kinds of enterprisey crap. And when I loaded the link, it was late at night and I got a maintenance page. It's like, sorry, this website is down for maintenance for three hours from
here to this to this and I was thinking man at Amazon we had a culture of your services your applications need to be running 24 by 7. sure maybe they weren't always we definitely i had i worked on teams that had operational problems and struggled to achieve that but the culture the value of
Your software needs to operate 24 by 7. If you need to do maintenance, you figure out how to do that in a way that will not cause any downtime. I couldn't imagine being on a team where I was asked to implement a little website under maintenance splash screen. That would be unacceptable. You'd get laughed out of any design room.
an example. It's not about whether you always live up to that. It's about what you value, what you believe is important. Yeah, and I think we can circle that back to the impact of the culture. right? Because ultimately the culture is something that helps to achieve some result or to achieve some goal. You could argue I'm going to have the best engineering practices.
So I'm going to look for it, check all the boxes, and that's going to help me succeed. Then I'm going to hire some people that actually knows about those engineering practices, and that's going to help me succeed. And the answer is that that's not necessarily true. And you see a lot of this, for example, in startups, right? When you are starting a company like that, you actually need a very different culture than the one that you have in a well-established.
company like amazon yeah i think the term for this is cargo culting and it's essentially like following a bunch of practices without really understanding the outcome that you hope they're leading to and oftentimes they don't i've seen tons of this places where people just put stuff into place because they read
some blog and they think oh this is what the best practice is to give you an example right it's like a startup probably wants to iterate extremely fast right it may try to completely change what the product does three four five six months in like it's a 180 degree change
to some extent, a culture that actually is willing to support the type of scrappiness. And what you see in these companies is that once they have actually established a solid direction or a solid business, they sometimes struggle getting to the next level because this change of culture that
needs to happen, right? OK, you got out of scrappy mode. Now you have to get more into hyperability, reliability, et cetera. And those are different mindsets. Yeah, that's actually a great example. So when we talk about changing engineering culture, maybe we don't need to be talking about, oh, it's a bad culture.
and we're fixing it. There could be a perfectly healthy organization that goes through some growing pains as they literally grow and scale and the culture may need to change. And I think that is the other case. But sure, you have heavy cultural problems, right? And no matter where you are, that's gonna have a really bad impact in your capability to deliver.
What I'm trying to say is that we have to take this very careful because it's easy to just obsess on what should be the best culture and there may not be such a thing. Yeah, I think that's what to dive into next. How do you identify what are the things that need to be fixed or changed about the culture? You have to observe, you have to talk to people, and you have to understand how the people in the organization think.
you have to observe what's happening you have to observe what are the goals and where are those friction points to actually achieve those goals and when you start finding those friction points to actually achieve the goals then you start thinking okay are these technical problems is this the way things are being done and how can you have
impact on those things. What about you? Yeah, I think that makes a lot of sense. You start from looking at the problems that are happening. Maybe the teams have lots and lots of bugs or regressions. Maybe there's a lot of deployment failures. Oftentimes it's local.
to certain areas of the product or, oh, whenever we do this kind of thing, stuff breaks or whatever. It's good to always start from the concrete things that matter to the business, as opposed to, I think a lot of people start from kind of this emotional point of,
of, oh, all this code is spaghetti code and all of it is crap and it's just terrible. Maybe all those things are true, but it's always best to start from observable fact that you can go to the business, you can go to your boss, you can go to leadership and say, look. This is how many times we tried to deploy something and it broke this many times. Something needs to change.
You have mentioned a great point. You have to be very careful with this. It's very easy to fall into a very strong emotional reaction to things, right? As you say, oh, the code is... code is spaghetti, right? Or XYZ is kind of crap. And it's easy to, oh, we should drop this tag written in this language and rewrite it in this other language, right? Stuff like that. And that doesn't necessarily work. That actually creates a lot of trouble in there.
So I think that you nailed it when it's like, okay, what are the problems that are happening? What are the metrics? How can I measure these things? Why are they happening? And what is the smallest changes or the small mechanism that I can put to actually produce change and get buy-in from leadership? That makes sense. Yeah, it definitely does.
Before we move on to how to make the change, there's one other thing I wanted to talk about, which is something that I found really valuable in this context that you remember from Amazon, COE. What did it stand for?
Correction of errors? Correction of errors. Yes. Okay. So basically this is a report that a team would write up, usually one person, but the team would collaborate after some event. It's essentially a post-mortem. And when I say event, I mean some kind of a failure, some kind of a deployment failure.
bugs in production that affected customers, whatever. Every team would have different bars for when they would do one of these. But then they'd write this document and they'd all review it as a team. And they'd try to essentially come up with, what are we going to do to fix this? How are we going to prevent this from reoccurring? But the part that I liked...
And the part that I think is relevant here is a section that are called the five whys. It's not always five, but essentially there's this part of the document where you literally ask the question, why did this happen?
And then you answer it in plain language. And then you ask, you continue diving deeper and deeper until you find the root cause. And it's called five because oftentimes, you know, it takes five questions. Why did this page crash? Oh, because the backend service returned to 500. Why did the backend service? return a 500 because the database table wasn't created. Why wasn't the database table created? Because it wasn't...
code reviewed correctly. You ask the questions, you get down. Maybe there's multiple levels where there were failures occurred, but to some point you find, you know, here's the thing to fix. Oh, it wasn't code reviewed. This wasn't. And so. I think when you're changing the culture, it's often valuable to do this as well. And the point is to not stop at the surface level. You say, why did this failure happen? Oh, because it wasn't unit tested.
Do you end that and say, it was the failure of this one junior engineer who didn't write the test? No. You go, okay, well, why wasn't it unit tested? Oh, because it's hard to write unit tests because there aren't any right now because the unit tests are flaky and fail all the time. And so people skip them without verifying manually.
all these different things, but you have to go down that level to identify what needs to be fixed. Because I've seen people come in, they say, oh, the culture needs to be changed. You guys need to write more tests. And then they go around cracking the whip for a while on tests. you know, nothing really changes. The culture doesn't change. One of the things that I love from Amazon is this concept of mechanisms, you know, and good intentions doesn't work. And it's like, okay.
we need more unit tests right so you start preaching right we need more unit tests we need more unit tests we need more unit tests that just doesn't work right right people say people will say yeah we need more unit tests you know and maybe somebody will write one unit test and two months later you're gonna go be back exactly on the same spot that you were before you need some type of mechanism that actually
allows you to get there right and why is this interesting because i maybe i want to write unit tests i dealt with systems in amazon in which i wanted to write units you know but it was really hard it was extremely difficult because the way the architecture was done and the thing was architected made ridiculously difficult to do that all right i think at this point then we have talked about what's culture what's the impact and how to identify the need of changing culture what do you think about
actually making the change happen. Yeah. So like you said, this is predicated on you already identifying what needs to be changed. That thing needs to be something that is possible to change. And it can't be just, oh, everyone around me is stupid. It has to be this, oh, I want to make it easier for my organization to write unit tests. And so making the change, this is where... the ambiguity and the hard part of being a senior staff or whatever engineer is, is it's going to be a combination of.
Concrete things that you identify, maybe you do yourself, maybe you delegate to others. Those might be identifying, oh, our integration test framework sucks, or we don't even have one and it needs to be built, or our unit testing framework doesn't have good.
data mocking and that makes it really hard to write unit tests. You know, you identify some concrete things. Another thing is you have to, so I like to think about this as the bottom up and top down approach. You have to identify these specific concrete technical things that maybe you do, maybe other people do, whatever. Then you also have to change the culture from the top. You have to set this grand vision. You have to convince the business why it's important and why they care about it.
You have to get everybody on board. A lot of times, this is just small conversations in one-on-one meetings with people, slowly pushing the idea. You're in a meeting, maybe another team is planning out some work that they will do. And they're about to close. And then you say, OK, what's the plan for integration testing this? This is a strategy that I used a lot.
I'm not doing anything concrete. All I'm doing is raising a question. But basically now they have to sit there and think, oh yeah, this is going to be tricky. Well, maybe if we use this framework and we have some mock data here and whatever. But now they're thinking about it and now there's less friction for them to go actually implement it.
So again, that's kind of how I think about it. Top down, I'm talking with people, leaders, managers, business people, trying to make sure that they're on board. They have to be on board because some percentage of... engineering bandwidth is going to go to this initiative. And so the business has to believe that it's in their best interest. Yeah, I think
What you call tops-bottom, I call it the org level, right? And bottoms-up, I call it the individual level, at least in my mind a little bit. And I agree with you. Most of the... really meaningful and significant changes have to have organization and leadership support. And the way you get leadership support with concrete data about
What's happening? What's the impact of what's happening? What's the change that needs to be done? How much is the change going to cost? And how is this metric or the impact going to be solved or improved after the change? And those are hard conversations sometimes, because here you're talking about changing some type of best practices like, hey, we need automated deployments or we need to do some re-architecture here or there or something like that. And the org is thinking.
terms of business goals. And you need to make sure that you align those practices and that mindset that needs to be changed with those business goals, right? And you can actually show proof that this is going to be beneficial for those business goals.
in the short or in the mid or in the long term. There could be situations in which, you know, leadership in the short term doesn't want to do certain changes. It's okay the way things are happening because if I am struggling to getting customers, right, and if I don't know...
if this product is actually going to survive. What is the point of actually doing this incredibly culture shift? If you are a business leader at that point, you're trying to make this thing work and produce money in return of investment. Exactly. And that's a discussion that can happen between...
principal or staff engineer and a business leader, and they can decide, oh yeah, what trade-offs are we going to make? Is this okay? Is this not okay? Sometimes the decision is, we're not fixing this. Yeah. and that's totally acceptable if the right thought process is happening there. The other side that I think is that as an individual You also need to read the room. So it's not that you as an individual are disconnected of these business goals in our organization.
You need to also read the room and try to understand if doing certain things are worth it or not. But as an individual, I think you can become, you know, a champion of change, a beacon of light in the middle of an organization. It's like... you do your part you try to write your unit tests right or your intake tests whatever you're doing right or if you are launching a new service then you try to think in terms of how this service should look with all the best practices that we should be using
right and when you start doing that that starts also influencing other people and motivating other people and again you have to be careful because if you're trying to do that in an organization that is just gasping for air to survive and they don't know if they're going to be here months then probably you're going against the actual business goals instead of helping.
Yeah, you said something that's really interesting that I liked, and it was, you need to read the room. And here, I think you were talking about in terms of the business, making sure that what you're trying to do is aligned with what the business needs and prioritizes. But there's another aspect to this that I want to talk about, which is when you come into an organization,
and maybe you've been there for a long time or maybe you were new this can happen in either case but if you're trying to change the culture A lot of times you can ruffle people's feathers. You can piss people off because essentially you're coming in and saying, hey, all this stuff that you've been doing, the way you've been operating for years, maybe, is crap.
and doesn't work you know that's a really hard thing to do and if you say it like that even if you dress it up you're not gonna make progress i've seen people they have good ideas for what they want to do but it's too hard there's too much organizational momentum around doing it the old way
And too many people have their own egos wrapped up in that sometimes. It could be the fault of whoever's trying to make the change. You know, they're just blazing through and tearing stuff up and have no thought for how this makes people feel. But I think this is an important aspect is basically...
making sure that all the people in your organization that you need to get on board with this change, making sure that they don't feel like this is a big criticism of them, but rather this is an opportunity for them to get on board with something new and cool.
You know, the way people feel about your change matters a lot. If people feel like, oh, cool, we're finally going to have some modern engineering practices and I'm excited about this and this is going to make it a good place to work. People will get excited about this. If it's like. Oh, here's this asshole who's going to make us write unit tests all the time, and everything is just going to be a grind, and...
You know, he's going to sit there and criticize all this stuff that I built over the last couple of years and say it's crap. No, it doesn't matter if your ideas are good. Nobody's going to want to follow that. So I think it's important to read the room and make people feel like they are a part of the solution.
No, it is incredibly important. I remember several years ago, a mentor that I had, a principal engineer. Actually, he teached me something very interesting. He said, you influence by asking questions. You may know what is the answer of... the question but suppose you're in a design review and there is an obvious problem or an obvious mistake somewhere and you want to influence and that you're not going to say hey that's crap that's not going to work that's whatever right you basically say hey
What happens here if this piece of data comes here? What happens? You know that's going to crash the whole thing, right? But you don't say that. You don't say that, right? You let the other people say like, okay, no, if I get this piece of data and then I... Oh, right. And he would say you always want to influence the science by making the other people think that it was that idea. Yes, I was going to say the same thing. That's super important.
It's a completely different game and attitude, right, from the people you are working with. And I saw an example of what you are saying in one of my previous teams in Amazon. It's like we had this new hire. It was actually a boomerang. A great guy.
he just joined the team and one week after he was dismantling the whole thing and complaining around about practices whatever and very stressed and escalating and ruining all the alarms and then i had a conversation with him and everything that he said
was reasonable. It's not that it was not reasonable, right? I had a conversation with the senior engineer of that team and then I start understanding what was going on. It's not that the team was not thinking of these things, it's that the team was under a lot of pressure and they were consciously dropping certain things that it was a business decision to actually move forward.
Did they like it? Not necessarily, right? But it was the agreed business decision, right? And this person has just been there a week. So it took a while to align these people, right? So we've been thinking of bottoms up and tops down.
How do you actually make the change? Like suppose you have support from leadership, right? What are the things that you would do to drive that change? Yeah, so identifying concrete technical things that you can do and wherever you have influence pushing for those things. And then it's a combination of doing that and then lots of small interactions with other leaders. And these are in one-on-ones, planning meetings, retrospectives, whatever, wherever you have a chance to ask questions.
okay, what is your plan for unit testing this or integration testing this? What happens in this scenario? I guess those would be the aspects of the culture that you wish were automatic for the organization, but aren't yet. thinking about how are you going to roll this change out? So an example that came up in lots of teams is how do you how are you going to roll this change out without having any downtime?
I worked on some teams that originally did not have that practice and then slowly built up that practice and it's a combination of specific questions that you have to ask either yourself when you're writing the change or someone has to ask you if you're using a relational database have you made the database
changes yet have those been rolled out what happens if the new code rolls out and it talks to the old database tables or whatever what happens if you have a mixed fleet you have the old code and the new code is that going to work basically asking all those kinds of questions
And originally, it's a huge effort where you have to go and ask those questions every time. And maybe you have to do a lot of footwork and go around to lots of different design meetings and code reviews. And if you're a principal engineer that's responsible for a whole organization, this may be you bouncing around a lot. different teams. It's of course easier if this is a smaller scoped team, but it's lots and lots of those little things that over time you hope become more automatic.
influencing senior engineers. I think that's a key aspect of it. You need to start recruiting people in favor of the change. And then you need to start working closely with these people to actually start influencing the change and try to understand. That's a really good point. Usually when you're doing this, and if I'm thinking back, there's usually some early allies that you can identify.
are on board with the changes you want, that are immediately excited about it and have ideas and maybe have some influence themselves. But yeah, I think that's key, finding these allies and recruiting them early. Another aspect that I think is really important is trying to put together mechanisms in place. And I have a very simple example. I joined Amazon, one team in particular, because they had problems from the operational perspective.
When I joined the team, they did not have the book dashboards. They did not have proper top level dashboards. It had a lot of metrics, but they were not there. And then you know how in AWS it works. You have your own team Monday Ops meeting, and then you have the org level Tuesday Ops meeting, and then the Wednesday whole organization meeting.
And the Monday Ops meetings were really not useful. You would have these dashboards that were not showing all the information that needed to be shown, right? And when you start asking like, okay, what happened in this availability deep, you get answers like, oh, this was a 500. Like, I mean, sure it was.
500 what happened right what was the reality of it so the mechanism there was this monday ops meeting which you keep every monday hammering a bit you know and diving deep and pushing people one one inch forward every time right and and that's when you start looking for the why's right why are you not telling me
The reason of these 500, oh, because it takes me two hours to dive deep. And if I do that for every spike of availability that I have, I need to spend four days basically doing that thing. oh okay that doesn't make sense right so then you go to this technical change which is like okay how do we reduce these two hours to five minutes okay we need the book dashboards so the first thing it was like to put together some solid the book dashboards and then it's like okay we don't have a metric here
it doesn't matter just put the graph right and we need to figure it out in that metric and okay we need to add that metric so listening understanding and asking keeps you moving towards the wise and keeps you moving towards the what is what we don't have technically and allow us to get funding to actually get
those things and then once we have reduced from two hours to five minutes we started getting way more answers of what was happening right and and then just iterating and improving the system on its own but the point is that It took somewhere between eight months to a year, right, to get the whole team in the same page that, hey, this is the way we operate. It's a cultural thing, right? It's like not being able to answer what happened here. It's unacceptable.
what we were discussing at the beginning, what's acceptable and what is not acceptable. Because initially, the perception was, this is a waste of time, right? It's not worth doing it. It's a waste of time. One year later, one year and a bit later, the whole team was aligned in the sense that this is the way to do it. It's acceptable. It's actually good. It's helping us. It's helping me as a team. I love this example because it summarizes mechanisms.
summarizes diving deep, finding these root causes of problems, and keep iterating until you actually get people in the same page. Yeah, I think mechanisms is a super important thing to talk about. came up a lot out of COEs where people are thinking, okay, what are we going to do to make this better, to keep this from happening?
and you know everybody's like oh mechanisms that's the way well what is a mechanism yeah you know because people are like well we'll just try really hard you know and we'll do that all the time that's a mechanism well um you gave a great example A regular meeting that you hold every week, every Monday, that's an example of a mechanism. It's easy for the manager of the team to keep that going. Just schedule it every Monday.
You don't have to think about it. It just happens. Now, I would argue there's other mechanisms that you obviously had to do, because I've been on plenty of teams that had an ops meeting, but it was a waste of time. You had to go deeper. You had to say,
when there's an availability dip. We should be able to answer the question of what happened. And that means we need to be able to quickly troubleshoot and find the logs for that event or whatever. Those are the concrete things that need to change. But the mechanism is just... oh i know at this meeting we have every week that there's going to be somebody that
looks at our graphs and asks us questions about every dip so we need to make sure that we have answers for those you know that is essentially the mechanism that's the mechanism of the the wednesday the big aws wide one the mechanism was having charlie bell yell at you if you couldn't explain your dips and it was an effective mechanism frankly and that would drive general managers and senior managers to actually
It forced them to always be familiar with their own metrics and know how to explain things. And some of it was, to your point, fear-based, and that wasn't great. But... If you want an organization that cares deeply about operational excellence, that's a great mechanism. Yeah.
And ultimately, right? A little bit of healthy fear is not a bad thing necessarily. You are deploying something, you are definitely afraid that something's going to blow up, right? And that fear is going to drive whatever caution measures you do to prevent it. Yeah, yeah, yeah, for sure.
What do you think about the impact of kind of higher level... organizational tenants or leadership principles like amazon has the leadership principles you know what role does pleading to those organizational level tenants or organizational level leadership principles you know how do you fit those into your thoughts around changing the culture I think that if you can make people truly believe in them and live through them, I think the impact could be. One example was Amazon.
right it's like all organizations and big corporations have these leadership principles standards in one way or another etc and what you see in lots of them is that they are either non-practical
That's one possibility. Or they are there, as I would say, painted on the wall when nobody really cares much about them. Something that always impressed me about Amazon is that leadership principles are are believed it's an everyday thing and they are used in meetings and from the practical perspective they are no big deal is they are
a bunch of common sense. If you ask me, I remember the recruiter when I joined, like, oh, you know, this is for your interview or this leadership principle. And I'm reading them and it's like, okay, this is common sense. They mostly are. Yeah. So I think it's a very powerful tool.
also to call out bs and on people and so on and so forth right is it like ownership if you are developing the system maintaining it whatever you own it right which basically means if there is a operational failure on that system you own it right and go and fix that thing and that is to some extent what keeps you awake you know at 2 a.m in the morning after accept to a page or you have to spend an online there because something went wrong and it happens right or
I remember, for example, disagree and commit in meetings. It's like when somebody mentions in a meeting disagree and commit, it's that thing that normally stops the whole meeting room to reconsider.
And if after reconsidering, we still move into this direction, it makes sense. But it's a warning bell that, hey, I really think there is something wrong here. If we are going to go that way, I disagree and comply. And I am also saying that I'm going to comply. If we decide going to that direction, I'm going to push this.
as i can but yeah those are great examples i think essentially what you're doing is you're taking the culture that you're in amazon here specifically has some shared definition of what it means by the word ownership, you know, and it's not literally just that word. It's a whole bunch of stuff. It's about, oh yeah, I have my software. And if something is broken, even if it's not my particular job or my niche, I care about it and I'm going to go try to fix it. And I dive deep into things.
I don't just look at something in the surface level and... you know, dust off my hands and say, it's fine. I dive deep and make sure that it's fixed or make sure that I've solved the root problem or whatever. You're leveraging the fact that everyone else has a shared definition of that and knows what you mean by that. And you can quickly refer to that in a meeting. And those are great examples.
show some ownership here. A related thing is a lot of times when you're pushing a culture change, it's helpful to have a sort of short catchy way to describe this change that you want. There was one team that I was on where we were currently really dependent on this external team's platform for doing our royalty calculations. And it caused us all kinds of problems. And so at the very high level...
The change I wanted to make, and I called it, we need to control our own destiny. We need to build our own tool that's going to do these for us and not be subject to all these problems that we're facing with integrating with this external team. And that was a phrase that I could use. in meetings and in leadership hey we need to control our own destiny here and yeah it's kind of wishy-washy and meaningless but it meant a whole bunch of things
that I could expand on if needed. It was a pithy way to refer to this. Hey, I think this is a way which we can control our own destiny. There was another initiative. This wasn't mine, but somewhere else in Amazon. Ultimately, we were trying to make code changes cheaper and they called it do more with less you know again pithy cheesy slogan whatever but
having some simple way to refer to this initiative that you're talking about, to get it to stick in people's minds, I think it's a similar concept. You're using some phrase that has some cultural meaning and then leveraging it to get people to... get on board with what you're trying to do i remember having this conversation with my first manager on amazon and he's saying talking about leadership principles and say like yeah you know i teach those to my sons to my kids right and
I get it. It makes sense. And the way I think about this is that they are behavioral drivers, right? These things that drive certain behavior and drive certain change, right? It is like, maybe I want to... also be laying down in the coach right and then you have this word in your head that is don't be lazy right and then that don't be lazy is what gets you up of the coach and actually makes you
you know, doing this, right? I think it's short words that have a strong meaning that actually helps you make decisions without thinking and coming, circling back to the definition of culture, doing things without thinking, right? There's one more thing that I want to talk about here, and it's related to our previous topic. We talked about burnout, right? And essentially, the definition I like of burnout is when you start to realize that the actions that you want to take.
now to influence things in the future aren't worth it or you start to believe that you start to feel like oh what's the point of going to all this effort because it won't have the impact that i want it's kind of this long-term accumulation of that well when you're trying to change the culture um
What if it's impossible? Or what if you face so much headwind, so much opposition that you can't? Ultimately, I think it's good to acknowledge that it's not always your entire responsibility to fix and change the culture. Sometimes you have to look for ways in which you can be effective. and be cognizant of how much energy you're putting in if it's not achieving the results. Yeah, I agree. It could be extremely frustrating to be in a culture that doesn't align with your values.
right i think a lot of burnout comes from lack of alignment between your values and the values where you are the organization you are interacting with and there is only so much you can do to change it right you can be this become of positive light you can talk to business to leadership identify problems show metrics etc and you know it may just not change it may not change because it's a transient thing because they are trying to
keep this business afloat and they don't know if it's going to survive right but it could be that the mindset just doesn't align which is the worst case scenario so i think when you do get to that point you need to figure it out your personal approach and individual decisions. You know, what are you going to do? Are you going to figure it out a way to stay there and try to do what helps the best organization?
and be okay with that. Do whatever small changes you can do as an individual and acknowledging that they may not be impactful. you also own your career you can also try to figure it out and move on to a different organization right yeah yeah definitely and if you do choose to take that that second approach where you say i'm going to move on it's always good to think about oh i could have done this differently or i could have done
this better or whatever. But it's also good not to look at it as a failure. Sometimes the culture is too ingrained and it's not worth it or it's not possible. So I think that's a good balance to have. Alright folks, we are getting to the end of this episode. Through the episode today, we talk about the definition of culture.
We talk about how that connects to engineering culture and what is the impact of a good or a bad culture. We don't pretend to talk about this as authorities on the topic, but we are talking from our experiences. as engineers in different companies and in different teams and environments.
And I hope some of these ideas could help. There is definitely not one path or not one ambition. That's all definitely true. There's not one way. There's not one correct approach. There's something that just popped into my head that I realized we hadn't really talked about, which is how fulfilling it is when you're
able to actually change a culture. It may not be something huge, but if you work somewhere for a couple of years, you do lots of these little tiny incremental changes that we're talking about. For me, I find that it's basically invisible as I'm doing it. And it's not until the end and I step back and I go, whoa, you know, look at where this team was two and a half years ago. And now look at where it is now. That's a really good feeling. So I want to call that out. And I think it's good.
emphasize and kind of lean into that because this is a really hard thing. And so celebrating your wins and appreciating the change is also really important. Absolutely. And it's a very hard, so it's a hard thing to do.
And I think it's a different mindset from the regular software developing, engineering, et cetera, mindset, which also makes some folks have problems approaching towards this. Yeah, it's a social problem, not a technical problem, right? It's a social problem, not a technical problem, right?
moves at a different speed, and even triggers imposter syndrome, right? Because, you know, I'm not delivering code. No, you're not delivering code, but you're changing the culture of the whole organization. And that's a huge thing. So I think, again, there is a lot to talk about this. If you folks... you know, are listening, have ideas, stories, anecdotes. Don't hesitate in reaching out and we're happy to have a conversation in future episodes or offline.
And that's it for this episode of Bytes in Balance. We hope you enjoyed our deep dive into the world of software engineering. Thanks for tuning in. We would love to hear your thoughts, so don't hesitate to reach out. Connect with us on LinkedIn to continue the conversation or simply follow our updates.
you'll find the links in the episode description. We aim to release at least one episode a month, but with our busy lives, it might vary. Subscribe to stay updated, and you might catch some surprise episodes when we're feeling extra chatty. If you are enjoying the show, please rate, review, and share it with your friends and colleagues.
It really helps us reach more people in the community. To learn more about the podcast, check out our website. The link is in the episode description. And if you're looking for more personalized guidance, we're available for mentoring through mentor crews. And there's a link for that too. That's all for now. Until next time, keep coding, stay sane, and remember, even when it feels like a total shit show, you got this. Thanks again for listening, and we'll catch you on the next episode.
Thank you.