Engineering culture is tricky to build up the right way. It’s intangible, so you can’t just go through a checklist. It’s also a lot of work to build or change, so you can’t have it down by next week from zero.
But engineering culture is extremely valuable. It can keep your developers around, and if word gets out, it’ll make new talent want to work with you, easing your recruitment pain.
Fanni Karolina Tóth from Coding Sans interviewed Sally Lait, Senior Engineering Manager at Monzo on how they handle engineering culture in episode 11 of the Level-up Engineering podcast. Monzo is all about the culture, so she delivers invaluable insight into that well-oiled cultural machine.
This post covers:
Sally Lait is currently a Senior Engineering Manager at Monzo, an exclusively digital bank. Monzo is an incredibly fast-growing FinTech company. They started in 2019 with 1.3 million customers, and by the end of the year, they had reached 3.6 million.
Her role is to sit on the leadership team representing engineering and operations. She’s also responsible for the web as a discipline at Monzo. Alongside that, she works on initiatives for management like progression framework. She manages engineers and managers as well.
Engineering culture is influenced by a lot of things. You've got your overall company culture, and on top of that, you have aspects specific to engineering. Having a great culture means to me that people are happy and healthy, they're doing meaningful work, and they can grow as individuals.
Many things contribute to this. The factors I care about the most are having a diverse team, seeing yourself represented in others, having psychological safety, showing respect to one another, being kind, and having autonomy so you can make a difference to the team.
Companies that embrace these values tend to do well.
In terms of engineering culture, we have more particular values. We are hard on the problems, not the people. For example, if you break something in production, we focus on fixing the process that lets you get to that point, rather than blaming the person.
We want people to ask questions and grow as engineers, because technology changes so fast; it's impossible to know everything. An important aspect of engineering culture is to embrace that.
It’s fantastic to be passionate about your work, to have a sense of purpose, and to buy into the mission. But you should be able to go home and enjoy life as well. A common perception is that engineers should always be coding, and not do anything else, but it can be too much.
You want to avoid burning out. Your work needs to be part of your life, not your entire life.
It’s genuinely the best place and the best engineering culture I've worked with. When I was running a consultancy business, I experienced different types of engineering cultures. Monzo has the kindest, most empathetic and smartest team of engineers I've ever worked with. Everybody is trying to leave everything better than they found it.
My favourite thing in the culture here is that defaulting to transparency is a key value for us. It doesn’t mean everything is transparent, but we keep as much in the open as possible. This includes engineering proposals as well.
When somebody is looking to make a change to the architecture or to the culture, they write a proposal, and anybody in the company is free to comment and to share their views. This way, everyone can see what's going on. Everything goes through Slack, so everything is visible.
Slack is an important tool from a cultural point of view as well. One of our senior engineers built the Guys bot, which pings up on Slack if anybody uses the word “guys.” It’s not an inclusive phrase.
We've built these things into our wider culture by using our engineering skills to create tools. I love how these gently nudge people to live out the key company values.
It’s great when senior engineers share their knowledge, experience, and make everyone feel safe along with them. A great example is when one of the senior engineers gave a talk about everything they broke at production at our very first lightning talk session. The ultimate message was how it can happen to anyone, and we fix the root causes, rather than make people feel guilty about it.
The people around me every day are the best part of our engineering culture at Monzo.
The problem is that cultural fit is intangible. People often talk about cultural fit without being able to define how somebody could fit into it. You can easily end up with a homogenous group of people who all have similar strengths and weaknesses.
We think of cultural fit in terms of alignment with values. We put out our values and our personality on social media and on other channels. Most people who come to work for us have a good sense of what we stand for and what we expect.
In the interview phase, we check if our values are aligned, and we try to understand what a candidate could bring to our culture that may challenge us in a positive way. Obviously, we’re looking out for dangerous misalignments, and naturally, we look at technical qualifications too. We have different types of interviews.
Cultural fit is not a one-way process; it has to work for both parties. You need to make sure your candidate has an opportunity to buy into your engineering culture and to make sure it's right both for them and for you.
It’s a subject of constant change. As the company has grown, we’ve had to formalize this, because having 20 engineers is different from having 200.
We use a tool to survey everybody in the company every month. We ask questions like how they feel about the office, the level of management spot they’re getting, happiness with the type of work or their pay. It gives us a picture of how happy everybody is, so we can drill down into certain areas to see if we need to fix them.
We started doing squad health checks recently. We get the people who work together in a room, and we go through a set of questions to see what aspects of their work they consider healthy or unhealthy. It’s interesting to work out how different factors play a part in people's happiness and in the culture.
We have a strong feedback culture. Some of the information we get is anonymous and it's aggregated; we encourage people to give direct feedback, and we have tools for that. Plus, we’re trying to build great manager relationships, so if people have concerns, they have channels to go through.
We try to measure it, and as managers, we have a general awareness on the state of our engineering culture. We frequently discuss this on our weekly all hands with executive level managers. We’re vocal about the cultural aspects of working at Monzo and how we can improve it.
So, everybody is bought into it.
For context, our tech leads are individual contributors, not managers. They work to foster collaboration between our product managers, our designers, and our engineers. We don't always have one in every squad.
In our model, we have squads, teams, and even larger units called collectives. We have leads at a collective level; they are responsible for all the squads within their collective. Managing system design, architecture and results on a technical side is their job.
They also drive forward goals, for the squad’s delivery and everything else. They work closely with engineering managers to find opportunities for their reports. They play an important role in culture. They can promote the values, and they can put forward learning opportunities for others.
Engineering managers handle engineers’ progression, performance, well-being and growth. Tech leads can lead by example; they can come at these conversations from another angle.
So, tech leaders have an important part to play in creating a positive engineering culture.
We’ve been working to empower everybody to realize they can be a leader when it comes to culture, even if they don't consider themselves leaders.
We introduced this system in 2019, because we needed to refine the engineering structure as we grew. We loosely based collectives on the Spotify model, they're similar to their tribes, but we gave it a new name.
Squads are smaller groups of people working on specific problems. Their sizes vary, but we stick to small squads and use the pizza rule as a baseline. Squads are cross functional as well, so they might have a product manager, back-end engineers, web UI people, or mobile engineers with a mixture of designers, user researchers, etc.
The point is that they're formed to solve a problem.
They work alongside others within a similar problem space; it’s what we call a collective. Within the ops collective, the main domain is customer support. We build our customer support software in-house.
We have several squads working on that, and we’re building systems that can facilitate all of them getting the help they need. We have other squads working on things like scheduling or machine learning, and so on.
For me, it’s what we discussed as the positive aspects of engineering culture but flipped on its head.
Off the top of my head I’d say having a homogeneous team, as I consider the lack of diversity dangerous. Diversity can help you make better product decisions and make better decisions for everybody.
If people don't feel safe, they start pointing fingers and throwing blame over things going wrong. It may be about making mistakes, not finishing on time, or anything else. It leads to people trying to cover their backs, and you end up having a culture that doesn’t facilitate great work.
We've seen many different viewpoints, especially on social media, about what it means to work hard, to be successful and how much of yourself you should give. We don’t stop anybody if they want to put in long hours, but we’re careful not to make anybody feel like they have to work every minute of the day. Nobody should feel like work is more important than their life.
In a bad culture, you end up dictating how people should operate. In a great culture, people have the autonomy to do a good job and to stop whenever they need to.
Engineering managers should be careful with the brilliant jerk behavior. They’re developers who are fantastic at their job but completely unable to work with others. They may bring a lot of negativity and have a negative impact on the culture.
On one hand, they’re fantastic engineers; on the other hand, they are a cultural drain. If you're not careful with managing this situation, that becomes the norm. You can’t just let it go because they deliver great code.
It’s a tough one to manage. The important thing is to work out your company values. If your view as a manager isn’t in line with the company values, you have a wider problem to solve. But if you’re addressing this with a person, you need to have conversations about what's important to them.
These conversations should be the starting point, because often people don’t consider this. Don’t just jump to the conclusion that they’re bad people.
An engineering culture can always evolve, even if you feel like you've got a great one. It’s easy to get complacent and recruit new engineers, and things change. You need to mindfully keep building your culture, or it’ll fall apart.
Culture can be influenced from different dimensions.
The impact you have one on one, talking to others directly, whether they are your peers or reports, has a big role in that. You can also influence it on a group level, and you can look on an even wider scale, like disciplines across the company. At Monzo, engineering is a discipline and design is another.
The first thing is to see where you stand, and how people feel. You may be at a good place, moving in the right direction, or there may be challenges. Then you should look at the practical things you can do and prioritize which aspects have the most impact.
It’s a key point to communicate what you're doing. Make sure people understand the reason behind your suggestions, ask for their opinion, and change your tactics if they feel strongly against them.
You should clear your expectations towards people about what they should do. You may want to communicate the company values, the engineering standards and all the principles you expect people to follow.
We have an engineering progression framework, basically a software engineer career ladder; I'm currently helping to create its second version. This gives people a shared set of expectations about what it means to be a level 1 or level 2 engineer. It keeps pay fair and helps in setting goals for progression.
Within that, we break it down into different areas. The first is “mastery,” which is the technical skills we expect of engineers at certain stages in their career. We talk about the scale of impact they should have. We also explain communication expectations, or the influence on their peers and leadership.
We’re trying to bring in the cultural aspect of our company values and what we encourage people towards. We’re explicit about what is and isn't okay on these fronts, and it helps a lot.
This depends on the type of change you're trying to make.
If it's a low level, foundational thing, the change will take a while, and you take everyone for a journey to get to the result. These are about talking, listening, communicating the benefits and getting people to buy in. Some people may not agree, but you’ll have an opportunity to listen to them and tweak things as you need to.
It’s different if you suddenly need to make a big cultural change.
For instance, if you were to decide people aren’t allowed to work from home anymore, their situations, their workflow, and their lives would be disrupted. It’s not a realistic example, but it illustrates the point well.
Clearly communicating the decision-making process and the reason why it’s important for the business is essential. You can’t make a decision like this lightly, so you need strong reasons to not make it a conversation. You better have your engineering culture and trust built up enough to be able to pull something like this.
Your people need to have enough support mechanisms around them, so whatever change you need to make without asking them, they’ll still feel comfortable and safe. It comes down to the trust and relationships you've built up. That’ll allow you to make hard things happen at the right time.
As your team grows, you need to become more explicit. The things you naturally do, the unspoken rules and expectations, work well with a team of 5 where you all know each other. With 500 people, you likely haven’t even met everyone, let alone gotten on the same page about cultural expectations.
The first point is acknowledging that your culture will change as you scale engineering. We've had to get explicit about defining the culture we want.
It's about how you can build processes and what tools you need to support them. We have our feedback tools, monitoring tools and so on. We also have simple things like posters on every toilet door saying, “It's okay to have a tough day at work. It's okay to cry. It's okay to ask for help.”
It's important for people to share these messages at scale.
The main thing for me is to be mindful of the culture you want. In engineering, it's very easy to measure output in the amount of code delivered and in how much work we're getting through. But taking a step back to look at the culture, to look at the role it plays, and to look at how you can grow people around you is important for your toolbox.
We found that people buy into this, and they want to join Monzo for the culture. For me, it's been fantastic to join an amazing team, to keep building it, and to have brilliant people around to make it happen.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.