How to build a strong engineering culture through engineering values

About Michaela Greiler
Dr. Michaela Greiler makes code reviews a team's superpower through her code review workshops. She has worked with teams from Microsoft, National Instruments, Metro Systems, Flutter, Wix and many more.

Read the whole episode "How to build a strong engineering culture through engineering values" (Transcript)

[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.]

Michaela: Hello, and welcome to the software engineering unlocked podcast. I'm your host, Dr. McKayla, and today I want to talk with you about engineering values and how you can use them to build a really strong engineering culture.

But before I start, I wanted to ask you for a small favor. My biggest goal this year is to grow the podcast.

I want to be able to spend more time on it so I can make it the best software engineering podcast that you listen to. But for that, it needs to be more visible and better known. So if you enjoy the podcast, please recommend it to a friend, send them an episode via Twitter, LinkedIn, WhatsApp, Signal, email...

Well, you get the idea. Or, you could also leave a rating on iTunes or your other favorite podcasting app. That would help me tremendously and mean really a lot to me. It also motivates me very much. But now back to engineering values. So actually I don't only want to talk about engineering values, I want to deep dive into what engineering's values mean to me and how you can leverage them.

I think that if you, if you care about engineering values, if you are really able to define them, to make them explicit that this will help your team tremendously. It will be a very competitive advantage. And so, what are engineering values? And maybe when I talk about engineering values, what comes to your mind are company values.

And company values are often a little bit fluff, right? They're a little bit like a marketing material but not for every company that has to be right. I think one of the very well known company values was, or is "Don't be evil". And while it's probably not really true and maybe the company did the [00:02:00] exact opposite sometimes, but atleast.

I don't have to really tell you which company I'm talking about and you know it right. So it, it definitely communicate something. And I think for a long time, actually, this was really something that was lived or believed by the staff of the company as well. Right. Don't be evil,

I think, especially companies that care very much about their culture, they work really hard to have company values that are meaningful and that reflect how people work and you know, what they value inside the company. And maybe a very good example of that is Amazon. its Probably not them. but the least evil company I can come up with, but it's a very, very successful company and they have 14 core principles that they work towards, or that, that are in their vision that are defining their decisions.

And. And it's sad that, you know, at least four of them, four of those core values are extremely important or are an extreme reason why Amazon was already in 2015 The company that reached the fastest 100 billion in annual sales rise faster than any other company in the world. And those four values were customer obsession.

Long-term thinking. Eagerness to invent and taking pride in operational excellence. And well as a customer back then at Emma's soon, I can definitely say that customer obsession was something that I definitely experienced. It was something why I was buying at Amazon and I knew that, you know, with prime the parcel will come really quickly that if I call, somebody will pick up the phone will be even friendly to me.

Right. And I haven't had that experience with many companies at that time. And only recently when Jeff Bezos actually get handed over his role to his successor, they added two new company values, core values, core principles. Do you know what they are? They are striving to be the Earth's best employer and success in scale brings broad responsibilities.

Well, maybe that rings a bell, right? I think it's Amazon's response to the strong and very persistent criticism against their workplace and employment circumstances. Right. And especially amongst the employees that work in the warehouses, for example, if the company will really live up to those principles is yet to be seen, I really hope so.

But we can see that. Company values. I think they are, they are a little bit marketing material, but I also think that when they are putting that out there, it's a statement, right? It's a statement saying, well, this is actually important to us. And so if you have to make decisions inside now, you don't have this 14 principles, but you have 16 principles,

And two of them. Are those well, how are we doing as an employer? We want to be the earth's best employer. I mean, this is bold, a bold goal, right? And the other is, well, our success brings also responsibility, so we have to act upon it. And I think it's a nice way to guide your decisions and to reflect on, you know, should we go this direction or that direction?

Well, what does it say to our company values? Right? Let's come back to engineering values, engineering values are derived from company values, right? So you have the company values and I see engineering values as something that's That we can break out from that.

Right. It gets more specific. A company values are about the whole company. What is everybody doing? Right. Is it administration or in the warehouse or in the, you know, in the logistics or whatnot.. But engineering values is really okay. As an engineering team, what are our goals?

What is our role to support the company? Okay. and act upon the values of the company and how can we transform that into our engineering core principles. And I think it's important to. Make sure that the engineering values are concrete enough, that they are actionable, that they are purposeful, that they are meaningful, but on the other hand, they should not be prescriptive.

Right. So you don't want to have an engineering values that tells you you should do code reviews three times a day or three times a week, right. This would be too prescriptive and it's too too rigid. It's too dogmatic. But the engineering value could, for example, be work together.We work often and frequently together.

And so as part of this value, your implementation or instantiation of this value could be well, let's have code reviews and think about how that actually fits into our engineering day to day work. And so what are other things that engineering values can do? Engineering values should really help you

define or answer some of the most difficult questions that we have as engineers that we face. Right. And this is not like oh should I use algorithm A or algorithm B it's more about what does quality actually mean to us or have we tested this enough.or how are we working in collaborating together? What engineering practices do we embrace?

What does success even mean to us? And also what does it mean for an engineer to strive in our organization, our team? What, what does, what does performance mean as an engineer in our organisation?

The challenge, as I said, comes from making them concrete enough that you can actually work with them in practice. I've seen so many really nicely formulated engineering practice, but they're very fluff. Do read nice, right? It's very motivational. The whole, we work well together, but then the company is failing to being specific what this means without being perscriptive again.

. So I think what's important to find this right level of, you know, being concrete and being understandable and not rigid. and, and, you know, prescriptive is to really reflect on why do we have engineering values? What are, what are the goals of having engineering values? And I see a couple of main goals and main benefits of having very crystal clear, meaningful well-defined explicit engineering values.

First of all, it's about. The existing team, the existing team, and it helps us to make decisions as i said, right? So we have to make so many decisions and there are so many trade-offs that we always have to juggle.

And it's really good to know your values. What's important to us and then align your decisions based on those goals. It also helps to prioritize our work. It also helps if you have newcomers in your team, right. New hires to tell them what you expect from them, how we work together. To clarify assumptions and expectations.

And also as hiring, it's a really wonderful hiring tool. Hiring is expensive, as you know, and with, with engineering values, you can really communicate what it is to work in your organization, in your team, in your, in your company. And this should help the person that's checking out. you know If there would be a good fit to really understand whether or not those values resonate with them.

And if they could strive in your environment, it also means that engineers can work well together. So it sets expectations on how things are working and what is expected, what kind of thoroughness or, you know rigor for example, is expected in code reviews. You can, you should be able to.

To get a sense of that based on your engineering values. And finally, it's really about if you have very well-defined engineering values, meaningful ones, it's about getting, or keeping people excited about the work that they're doing, right? Keeping them loyal to your team and your company.

But let's look at some specific engineering values. And for that, I pick the company that I think they did a really, really good job in formulating their engineering values, the core principles, and also communicating that outside. They are, they are made public and that's Figma. Figma is a collaboration tool for designers and web developers.

And I will link that in the show notes as well, and they have a document that outlines their engineering values. And so one of the first core values of figure figma is communicate early and often, but it doesn't stop there. Right. It doesn't stop it. You know, a couple of words, which sound really nice, but they really go into explaining what that means.

How can you put that in practice? What does communicate early and often mean in practice? And what's really, really rare is that we also discussed the trade-offs that you will face when you're following this engineering principle. Right? Because it's normally, it's not only, you know, it's not only light where light there is darkness.

Right. If I'm going in one direction I I'd probably have to, you know trade off something else. And I really like that. So I'm going to to read to you what it says on the website. Um, So under communicate early and often they talk about that. You know, you shouldn't be the genius that is the solo rockstar engineer who goes heads down and emerges days after the perfect solution. But in Figma we built an engineering team with huge depth and breadth of knowledge, right?

So they have a whole team and we don't want to throw that expertise away. Hence our first value communicate early and often, right? So we want people to come together. They said we build a great team. So let them also have a say in what you're doing. Communicating early and often ensures that work isn't done in a vacuum by sharing design documents, product specs, or even rough architectural drawings.

And then they say usually in you guessed it Figma. We ensure that ideas are vetted early and issues can be spotted and resolved before we invest too much time in solutions that aren't right. So they get very specific about what communicate early and often mean and why it's a value to them? . Why is it important?

Well, because we have a lot of very smart people on the team and we want them to have a say and they also get a little bit specific about, well, you guessed it, do it in Figma. It makes sense as they have a tool that communication and collaboration tool. So to get specific about it, but it's also not dogmatic as its usually in, right.

So it could be also that you're using other channels. And I guess they probably have also other communication channels that they're using for this communicate early and often goal. But when they describe the value and how it's . They also described the challenges and the skills that go along with them.

So they, for example, talk about being receptive to input slash feedback, ? Being able to, to hear the feedback, to really receive the feedback and act upon it. In addition to describing it by living this value. We trade off the risk of slow decision-making due to a large number of voices in the room.

Right? So they say, we know actually by, you know, inviting others to have a say, we are slowing down. Maybe decision-making it's not always easy for a large group of people discussing to have equal, say in making these decisions, that's what they're saying. So they also described the challenges that are coming with it and prepare somehow work fast.

To understand that. Well, if you're, if you're seeing that pain point we are well aware of it. Right. It's it's comes along with the value that we share. So what do you think, do you think you get a tiny bit of an idea of how, how working with Figma looks like, but I think I did. Right. And while I only mentioned one engineering value here for you, I think I got a sense, a little bit of the culture there and.

It's also interesting that on one hand it's it's concrete, but it still doesn't tell me. Well, you have to share 10 times a day, one time a day, what you're doing, right. It leaves still enough room. For making your own decisions and reacting to the situation at the context.

but let's look at the other example and another example that I want to bring in. That the engineering principles of Lula bot. And they're talking about learning and sharing, So they say one of our principles is learn and share. And it says we find our work fulfilling because we are always given the opportunity to learn something new.

We like to work on new unsolved problems over applying the same solution to the same problems. I think this gives us a very concrete vibe and at least when I start there and if it really reflects how they work, I have a good idea that, that i'll be able to try out new things and to experiment in this organization. So let's have a look at what this means for decision-making. For example, let's imagine we are given a new project and now we want to use, you know, remix instead of Drupal because we've all heard the good things about the scalability.

And it's new and shiny. And well, it hasn't been that long around like Drupal and but we are very excited about it. We think this could, you know, bring along the whole organization. What do you think are the chances to be able to work on this project? Despite its read our experimental nature, you know, jumping from Drupal to, to remix.

Sure we can really say from one engineering value alone, right? You would have to consider many, many factors about the project who else works on it. Do they want to work on something new? What's the size, what's the timeframe, right? Who will maintain it. But still, I think the engineering value gives us some hinge on whether or not we're able to pull something off in this direction.

If you compare it to another company for example, a yap stone talks about. Always learning, always growing as an engineering value, but they describe it a little bit different.

They say we value continuous learning and growth for individuals and the team. We are more productive as individuals when we are empowered to work on various products and platforms and have input into product directions. And I think this is, it gives off a complete different vibe, right? We are also learning we are growing, but in a very different setup.

And I think I would be more hesitant to, to to say, well, let's drop drip all, and let's go to remix um, in this setting.

But I don't think it's a bad thing. I think it's a good thing. And especially if we dig deeper if you look at Lulabop right, if you see that it's a web development agency and they provide strategy design and development services for publishers for large publishers.

So yes, in this setting, I think I can really see how they can be more flexible with a solution approaches with learning, with experimenting, right. They have several clients and for each of them, they want to create a great you know, consistent experience. But between clients they can actually experiment learning.

On the other hand, the app stone is a complete payment solution for marketplaces and platforms. So I guess my desire to bring in a new, completely new technology into the mix is much harder and also more counterproductive for the longterm vision of the company. Well, to be fair, if you take a closer look to Lulabot I would probably also not come forward in my idea of using remix as their specialty onstead of Lulabot in development.

Right. So I can imagine it gets a little bit hairy, a little bit tricky, but who knows? Right? Maybe they also say, well, let's try it out. This is our mentality, right? This is our value. Let's try it. And see if you love it so much. And you're exceeding all our expectations in terms of how fast you can run and how with how quality you can run.

This it's a project or something. Right?

So now I want to go a little bit away from engineering values and go even one step deeper and say, well, engineering values are still similar to, you know, company values on a higher level, but we can break them down. And I think it's so important that we actually do that. I call them code review values.

You can definitely have different values as well, but I think code review values is so important. And so what our code review values. With them, we define a common understanding of how we do code reviews and what we value doing cultural years. . So they can be seen as a more concrete instantiation of your, of your engineering values.

And they should help to give you answers for questions, like what to look for in code reviews, when to do code reviews, when is code good enough? Right? What do we value from, from our reviewers? And.

A great starting point for defining your code review values is by reflecting on what feedback you and your team really value during code review. And so questions are how important are readability issues for us? What about spelling mistakes? How perfect should the code base be or the code change to be accepted during code review?

And for that I want to to introduce to you that code review pyramid of needs, Code review pyramid of needs is similar to Maslow's pyramid of need, which maybe you're familiar with, The Maslow pyramid of needs. States five category of needs that every human faces, but they're not equally important.

They are a pyramid. Right. And so the basis is the foundation. It's like the foundation of the house. If you don't have it, the house will fall down. So the foundation in Maslow's pyramid of need would be water, food shelter. Right. Everybody needs that. But then on top of that, we have, for example, another need it's the safety need, which is ability to have employment. Do I feel secure and so on? And then on top of that, we have like friendships and, you know, and, and we can only satisfy one need if you have set aside the foundation of it down there. So if you think about code reviews, the code review pyramid of need would look like, well, the base for it.

Yeah. Correctness of the code, right? So we are looking for correctness first and foremost, then we look at the security of the code, right? Then we look at the readability of the code and only then, when we have satisfied those needs for our code, we look at elegance and inspiration, right? How elegant, how inspiring is our, our code.

So the pyramid not only tells us what to look for, but also in which. The only problem is that not everybody agrees and rightfully so, right. Not everybody agrees that. Well, the most important thing for code during code review is correctness. And I agreed to her, you can actually flip it around and say, well, actually the most important thing for code reviews is readability.

Not correctness.

And there, there are many reasons for that, right? First of all, code reviews are not the most effective tool to find bugs. Right. I wrote a paper on that and maybe I will also link that there write code reviews do find bugs. Yes. Did you, but Testing is actually much more effective of really finding bugs.

So doing code reviews, we can, obviously we are looking for bugs, but it shouldn't be our specific focus to, to, you know, go through motion of the code and have different inputs there. We should maybe look for are the tests do that, right? Are the tests meaningful? Are they, you know, covering enough?

Did the tests cover the most important cases and so on? And for that reason why maybe readability should mean our main focus for code reviews is that code is never bug free. Right? We know that if you have a large enough code base we cannot guarantee that it's bug free. And very, very likely if you're having a little bit of experience, we know there will be a lot of bugs.

So what we know is that we have to go into the code again and change it. So. What, what does the code have to look like? Right. It has to be understandable. We have to, it has to be maintainable. We have to go in and be able to change it after a while. And so this is why readability, at least in my view comes first.

And then we have maybe correctness security, and then we have elegance and inspiring. Right. During my quarterly workshops, I love to engage with teams in this discussion and, and help them, you know, and guide them through this discussion around the pyramid of needs for code reviews and really unpack their assumptions.

What does high quality code mean to them? What actually really matters during code reviews. Thinking about readability and correctness, can we trade them off or not? Right. And I think the most important part here is also to think about well, risk associated with code to code change, right? So maybe if I'm changing something, you know, in the payment section, in the transaction section where I'm really getting the money from the credit card, maybe their correctness and security is more important.

For me in this, in this instance for this code review, then when I know I'm changing something. On the internal backside.

It's really good to, to have discussions really, dig deep around engineering culture. What do we value? What's important to us and, and have your engineers share their beliefs with others and be explicit about it. Right. And the first step is not all of us should.

come together and we agree on one thing, but it's really about listening and being open, being aware and understanding what others are thinking.

What's also really important is that this is not about conformity in general. Yes, we want conformity and consistency in our code base, we don't want, you know you know, 10,000 different ways for the architecture and everybody does their own thing.

But the goal for our engineering values is to create a shared mindset. The mindset of togetherness, of alignness of belonging, right. Something that's extremely, extremely crucial in our research and developer experience, belonging and shared values came up as very strong indicators for developer experience and success.

But please do not mistake that. Right. Having shared values as something that shuts down different opinions or perspectives it doesn't mean that everything or every one needs to be uniformed, right? It doesn't mean that if you have shared core principles, that controversial opinions can't be voiced. I think the exact opposite is true.

If you have meaningful values Then those values create a very safe environment in which opposing thoughts can be more openly discussed and investigated much more than in an organization where everything is implicit, where we just assume that, you know, what we value or what's important, or how to do things.

In, in the implicit setting, When engineering values are not clear, it's risky to discuss new ideas and being open-minded because in such a setting, the one with the most influence or the most power gets his or her way, right. Every idea we engage with in such a setting, in an implicit setting, we risk to sink the ship, right.

To bring restlessness to our engineers or create confusion. That's why I think in a explicit setting where we know our values. Is much better, ? We are not in danger. If you engage actively and listen actively to new ideas, instead, we can really take the time to Examine new ideas reflect on them. See how well that goes with our values that we have.

And it's also important that values are also not set in stones, right? Values can evolve and they should evolve Friday. You know, values should probably be different if you have like 10 engineers, then if you have hundred engineers, maybe depending on your project and so on. You don't want to change them every week.

Right. If you're doing that, then you know that something is going wrong, right? You're not, they are not representative of your culture or, you know, there's a cultural turbulence. Maybe you have to discuss more and really think and work deeply.

So in my country, we have workshops. We really work on engineering values. And this is one of my favorite exercises that I do with my engineers that I work with. But of course you can also do that yourself. So you are some of your colleagues. You can do that together, but give it a dedicated space, give it some time, give it, you know, run it as a workshop.

You should not, you know, have these thoughts and this discussion linger around and being brought up all the time, you know? Instead really have like a fixed time ,date. you know where you have like three hours end to end where you can unpack all of the Advair, you have that and have somebody really guide this discussion and make sure people are a little bit prepared.

What they would think about, what will they argue about and also set the right expectation for outcomes, right? We don't want to, you know, go in, have a two, two hour meeting and we're coming out with a list of set in stone values, right? This is probably not the right thing, but first it's really about active listening.

What has everybody in this room to say, and can I try to understand as much as possible opposing views, contrarian ideas, right. And then only if we are slowly settling here, we can, you know, come together to have shared values

To give you a headstart, right? If you want to, discuss a little bit engineering values, I started to create a list of companies that share the engineering values. I will link that below as well. And so I think you can look in those engineering values document and, you know, compare that with the ones that you have, or also get that as an inspiration.

You know, if you haven't had if you haven't formulated your engineering values yet, maybe those can give you a headstart to, to really think about them. And then also if you know, company values, right, if you know, companies that Formulated and wrote down their engineering values, engineering principles, please contribute by adding them to my list.

And, yeah, so, well, this brings me really to the end of the episode. I hope you enjoyed it. If you did, please do not forget to share it with a friend or two and also leave a good review on your favorite podcasting site. That would be wonderful. And thank you. Bye.