Embedding a Great Engineering Culture

How to Build a Great Engineering Culture: Article 3

Have you ever walked into a company and seen values plastered everywhere on their website, walls, drink bottles and T-shirts, but that’s where the values seem to end? Looking at the company closer, you realise they are not living the values. They have probably failed to embed the values in their day-to-day working.

The first article in this series explained the four-step framework for building a culture: Define, Embed, Embody, and elicit Feedback. This article focuses on the framework's “embed” step, where we take the values made in the “define” step (see the second article) and codify the values and culture into as much of the business as you can. Embedding it is about trying to make the culture as pervasive as possible in the company processes. In the hiring process, role descriptions, promotions, recognition, awards, team structure, etc. The more they are embedded into the day-to-day rituals and processes of the company, the more likely they are to succeed. This series's next (fourth) article will focus on embodying the values, which covers the people-behaviours needed to support the embedding in processes.

We will look at a few key areas that are key to embedding your culture into:

• Engineering Growth Framework

• Hiring

• Ways of working

• Team Structure

• Measures

For each of these areas, we will discuss how to use them to embed your values, and provide concrete examples of what they look like tied to the values that make up a great engineering culture described in detail in article 2. As a reminder, they are:

• Learning and Growth-mindset: Growth Mindset, Learning, Self-improvement, Bravery, Blameless Reflection

• People-centric: People-first, emotional intelligence, authenticity

• Low ego: Humility, internally collaborative, no politics

• Open and transparent communication: Feedback, showing vulnerability, transparency

• Collaborative and autonomous teams: Team outcomes over individual output, Symmathesy, Empowered teams

• Desire to deliver customer value: Customer focus, Understanding the why, focus on value, Accountability

Remember values are not one-size-fits-all. You will need to define the values that work in your context.

Engineering Growth Framework (job descriptions and promotions)

An Engineering Growth Framework (EGF) defines each engineering level's roles, responsibilities, and promotion criteria. If done well, it will articulate the expectations for each person at each level in the organisation (e.g., Software Engineer to Principal, and also management). It is a powerful tool to codify and enforce the culture, clarifying behavioural expectations aligned with values. It facilitates discussions that go along the lines of:

Employee: “Why aren’t I being promoted?”

Manager: “Well, it’s because you are not demonstrating these values”

Employee response A: “Oh, well I guess I better learn and develop that”

Employee response B: Or, “I disagree with that, I guess I better self-select out”

Both final responses from the employee are beneficial for the company. Either the employee starts aligning with the culture's values or leaves because they are misaligned.

Medium also developed an Engineering Growth Framework to codify expectations at each role level, ensuring promotions were based on demonstrated values, not just technical ability. Doing this strengthened their engineering culture, improved coaching & feedback and increased retention & engagement. There are many other Engineering Growth Frameworks for inspiration, such as the Buffer Engineering Career Framework, Camile Fournier's Engineering Ladder and Square's Growth Framework for Engineers.

The critical thing to do when using those as inspiration, is to customise them to the values that you are trying to embed. Here are some examples of specific criteria in the EGF that we used, and how they relate to the values mentioned above.

• Learning and Growth-mindset: “Their main focus should be learning.” (Junior)

• People-centric: “Takes a strong responsibility for the welfare and development of the people in their team and does this effectively, by coaching the people in their team towards team needs and also for their personal development towards their goals via one-on-ones and other forms.” (Engineering Manager)

• Low Ego: “Actively seeks to improve their leadership, Most likely, has switched their learning focus from technical to leadership.” (Engineering Manager)

• Collaborative teams: “Contributes beyond just individual contribution. Contributes to team performance, growth and learning by upskilling people around them and providing some guidance and direction during discussions.” (Senior)

• Open and Transparent Communication: “Regularly and effectively tailors their communication style to the needs of others in their team instead of just based on their preference. For example, in code, pairing, mobbing, code walkthroughs, presentations, diagrams, discussions.” (Staff)

• Desire to deliver customer value: “Always aware of the team's goals and actively steers the team towards those goals and away from lower priority work” (Senior)

Here is the complete framework, which contains more details beyond just culture to define what capabilities are required for each level and what is needed for promotion.

The examples show how the framework clearly defines behaviour expectations at each level and can be used as a cultural enforcer by preventing the promotion of people who are not values aligned.

Potential Challenges with the Engineering Growth Framework

It can be hard to balance between setting clear, values-aligned criteria and being inclusive. When we first made our EGF, we ran into some issues where people could not be promoted because their behaviours did not meet the criteria for the next level on the EGF. As we assessed that, in some cases we thought that the EGF was working as expected, and stopping values misaligned people from being promoted. In other cases, the people were worthy of promotion, meaning the EGF was too restrictive. The particular value that people were clashing against was collaboration. As a result, we revised the EGF to keep the essence of the value the same but changed the criteria to be broader, allowing different types of collaboration. We also set up a regular process to analyse and reassess the EGF and update it. As you embed your EGF and the company grows, do the same and adjust it to compensate accordingly (either tightening or loosening it as required).

Hiring

Building a strong culture requires a critical mass of individuals who understand and embody it. Changing the culture can be exceedingly difficult if the initial group is entirely against the culture and there's no opportunity to bring in new talent. Hiring new individuals is crucial for shaping this culture, particularly the first few hires, who must embody and be able to teach these values. As Laszlo Bock states in Work Rules, “Refocusing your resources on hiring better will have a higher return than almost any training program you can develop”.

The Engineering Growth Framework (EGF) is also a valuable tool for hiring. I have asked candidates to read the requirements for each level and self-assess if they meet those capabilities, to see if they align and want to work for a company that requires particular behaviours to reach certain levels.

Interviewing is a key opportunity to assess if the candidate exhibits or is willing to learn the right behaviours, and is also a good opportunity to demonstrate the values in action to the candidate. It’s important not to hire only for “Cultural Fit” but to look for “Cultural Add”. This article explains the concepts in detail, but ultimately, you should look for “cultural contributors” who reflect and share your core values, but still have something new to offer.

Here are some examples of how to align questions to your desired values:

• Learning and Growth Mindset: “What are you currently learning or focusing on growing?”. Firstly, look at whether the candidate has anything they are consciously learning. Then, probe to determine if regular learning is part of their daily life.

• Low Ego: “In what areas do you need help?” Are they open and transparent about areas they need help in, or do they claim they are great at everything? Probe as necessary.

• Collaborative teams (and people-centric): “What are the characteristics of great teams? In your experience, what makes a team work well?” Probe until they delve into some of the details of a good team. Do they understand what great collaboration looks like? Do they value and understand teamwork? How do they talk about things like vulnerability and communication?

• Transparency and open communication: At the end of each interview, I would ask the following, “I’d like to give you some feedback. Firstly, it is a chance for you to get feedback, but secondly, it is a chance for you to correct any misunderstandings I may have about you. Is that ok with you?” Then, I would go into great detail about my thoughts and give them a chance to discuss any places where they disagree with my assessment.

• Desire to deliver customer value: “What are the core 1-3 things you focus on to improve the team’s delivery?” How well do they understand things that affect delivery, small increments of value, lowering Work in Process, focusing on flow, etc?

You need to create your questions based on the culture you are making. The questions must also assess technical and delivery capability (out of scope for this article). However, focusing on and understanding their ability to learn and adapt is critical in hiring and building a great team.

Hiring challenges as the team grows

As the engineering team grows, it becomes increasingly challenging for you as the peak engineering leader to be involved in all hiring. Opinions vary on the level of involvement required; on one hand, your direct participation helps instill the desired culture, as you best understand it. However, being involved in every interview is time-consuming and limits your leaders' autonomy in hiring based on their specific needs. Your level of involvement should depend on the company's growth stage. Your participation is crucial in the early stages of building a new culture. Once the culture is solid and you have confidence in your engineering leadership, you can step back from hiring, though it's still vital to engage in interviews for key leadership positions.

As your involvement decreases, it’s crucial to codify the process more thoroughly by specifying the questions to ask and the criteria for assessing alignment with your initial intentions. Subtle deviations may occur over time, so you must maintain enough oversight to detect and correct them. For instance, occasionally participating in interviews or discussing hiring processes and decisions with your leadership group can help ensure alignment.

Ways of working

Finding a balance between alignment and autonomy is essential when defining ways of working. This balance involves determining how much freedom teams have to develop their rituals versus how much is dictated from the top. While we won't explore achieving this balance, we'll focus on how ways of working and rituals align with your culture. Effective ways of working will require some top-down direction through guidelines and guardrails, as well as bottom-up input, either by granting teams full autonomy or allowing rituals to evolve organically over time. This process necessitates coaching, guidance, and influence for improvement.

Ultimately, your ways of working need to allow your culture to flourish, not actively prevent your desired culture from working effectively. Here are a few examples.

Learning and Growth-mindset:

• Teams could have dedicated learning time as a ritual — one week every few weeks, one day per sprint, or even regular hackathons.

• Regular knowledge sharing across the engineering department can be valuable. For example, a regular engineering meeting with a rotating chairperson lets anyone present recent lessons to the broader team.

• Rituals like Guilds & Communities of Practice, Lunch & Learns and others help create a learning culture.

People-centric:

• Different types of retrospectives such as an Appreciative Retrospective can help keep a people-focus.

• Kudo Cards can also be used to allow people to show appreciation to other people in the team.

Low Ego:

• Retrospectives and incident Post Mortems are a good way to encourage learning and growth. If they are blameless retrospectives, that helps remove ego and focus on learning.

• Having a place or ritual where people call out failures they learnt from can help reduce ego (e.g., a Slack channel, a regular segment in a town hall, etc).

Open and transparent communication:

• Department-level update meetings can be more intimate and frequent than whole-company town halls. In addition to the regular engineering meetings (mentioned above), we hosted a consistent Product & Engineering update where leaders openly discussed successes and challenges, fostering a safe space for contributions from others.

Collaborative and autonomous teams:

• Pairing (where two people work together at one “keyboard”) and mobbing (where multiple people work together on the one problem) are both rituals that can encourage collaboration.

• Ensuring that teams have clear goals, and are actively working towards those goals (e.g. every sprint).

Desire to deliver customer value:

• Having a regular ritual where the whole team has customer time (e.g. weekly, or getting involved in customer interviews, etc) helps keep customer focus

• Rituals which celebrate value delivery (such as demos or sprint reviews) also help keep the focus on delivering customer value.

The important thing is to ensure that your ways of working actively encourage your culture to thrive, and do not fight against your desired culture.

Challenges with Ways of Working

Some examples where rituals may clash against desired culture:

• Task allocation: Suppose you want high collaboration as part of your culture, and autonomous teams work towards a common goal. In that case, you can’t have someone playing the role of task-allocator, who gives work to individuals who don’t need to collaborate or without them having to think about the customer need, and then expect the culture to grow the way you want.

• Standup questions: If you have daily stand-ups and they ask the questions (which are pretty typical) "What did you do yesterday?", "What will you do today?" and "Are impediments blocking your progress?" Then, you may end up with a culture that focuses on individuals working in parallel rather than a team progressing together. Instead, consider focusing standups on walking the board”, which gets the team to think about how they get work done, limit work in process, and move towards the sprint goal, increasing collaboration.

• Pull Requests (PRs): How PRs are managed can be a significant topic and often challenges collaborative cultures if done poorly. Firstly, there is the option to do Trunk Based Development (but at the risk of starting a religious war, let’s move on from that quickly). More generally, PRs are late in the development process, and often too late to help facilitate effective collaboration. Many teams inadvertently rely on them to be places to do architecture reviews, suggest complete rewrites, or teach developers lessons, which end up being expensive (and frustrating for developers) since these issues should have been picked up much earlier in the process. Also, when PRs are given low priority compared to other work, people can end up being blocked waiting for PRs to be reviewed, which slows progress, restricts collaboration and impedes delivery. Instead, find ways to collaborate and review earlier and more regularly in the process, instead of having PRs be the sole place for this.

• Goal definitions: Clear medium- or long-term customer-outcome-based goals help unify the team, allowing autonomy and collaboration. Many teams often work off a prioritised backlog of unrelated tasks, which can encourage individuals to mindlessly pick up and work on the next task, without collaborating or considering how the work will help the team or customer.

Team Structure and Composition

Team composition can clash with cultures. I've observed instances where dedicated roles lead team members to disengage from specific responsibilities. For example, when I asked a team about the reasoning behind a feature, they replied, “I don’t know, ask the Business Analyst.” This answer shows how completely delegating customer understanding to a single role can hinder the team's grasp of the "why" behind their work. Similarly, having dedicated Quality Assurance personnel can create silos, as teams may throw their work “over the fence” without collaboration, leading to inefficiencies and heightened blame, or if the team delegates all delivery thinking to a Scrum Master. These risks don’t mean that having these roles on teams is explicitly problematic, but having the roles executed poorly can be troublesome for growing your culture.

When a team comprises too many specialists who lack cross-functional skills, inefficiencies can arise. For instance, if a team consists only of dedicated frontend, backend, and database specialists (who don’t know any other area), the lack of versatility leads to increased handovers and fragmented backlogs. This division stifles collaboration and fosters silos, ultimately hindering delivery.

Team identity and boundaries can also conflict with your culture. For example, suppose you have dedicated front-end and backend teams (instead of cross-functional teams). In that case, creating a culture of autonomy and customer understanding can become challenging when dependencies impede delivery.

As an example of using team structure to support culture, Spotify uses its squad model to give teams ownership and autonomy, reduce dependencies, and encourage innovation. Guilds and chapters enable cross-team knowledge sharing without hierarchy. This model works for Spotify and their values, but you must find a structure that supports your values.

Choosing team structure and composition is crucial to enhance your culture and not stifle it. The book Team Topologies is a helpful resource for structuring and composing teams.

Measuring the Culture

Measuring cultural strength can be challenging. A few metrics can be helpful to get a feel for how things are going, which mainly revolve around data from surveying people.

In the past, we used a health check, a customised version of the Spotify Health Check for each product-engineering team, to measure culture and help address any issues. The health check had questions around value, speed, mission, releasability, process, quality, fun, learning, support, autonomy, teamwork and focus. Each team would regularly run the check as a retrospective, and they were helpful for teams to reflect and learn and for insights. Team-level insights provide direction for where the team leader may need to support the team. Department-level insights help identify systemic issues across multiple teams, allowing leadership to help. The image below shows the output of the Health Check across various teams, including the questions we asked.

In the example above, we wanted to focus on the issues around “pawns or players” (autonomy). We spoke to the team members to understand what the cause was. It turned out to be around a lack of clarity in the team's product roadmap, making them feel like work was being thrust upon them rather than having autonomy around input into prioritisation and how to work. Providing more information around the roadmap and ways for teams to have more input into the process and a clearer understanding of customer context helped improve this.

Another tool can be a lightweight, asynchronous pulse check to ask each team member questions to see if you are balancing the competing forces that pull against your culture. See this article for more details about the framework, which would centre around value, quality, speed, consistency, quantity and resilience. The diagram below shows the output of that.

Lyssa Adkins has a High Performance Tree tool, which can also help track team performance over time (including its culture).

These metrics are valuable as learning tools and indicate how your culture is going, but are far from definitive and should not be used as the sole measure of culture. They indicate what work leadership needs to do to support teams and help them improve. Augmenting them with other data points (described below) and deep probing in one-on-ones will help you understand how the culture performs.

Indirect cultural measures

Many quantitative metrics help measure engineering performance. From a cultural point of view, the important thing is to ensure that the things that are measured do not adversely affect your culture. As Eliyahu Goldratt says: “Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way…do not complain about illogical behavior.” What you measure needs to work with your culture and be well balanced across the different areas of your culture.

Outcome-based metrics like OKRs can be valuable to measure. If done well, they will measure valuable outcomes for customers and the business, creating alignment within and across teams toward a common purpose. If done poorly, for example, by defining features to be built or tasks to be done, the culture may struggle to grow in delivering customer value or collaboration.

Earlier lead measures can be helpful, but also need to align well with your culture. For example, suppose you measure throughput (number of items delivered over time) and cycle time (when an item was picked up to when it is in the customer’s hands). In that case, you must ensure that each item that gets measured delivers customer value, or run the risk of a culture focusing on busy-work, rather than customer value. Similar for DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service), which can be helpful to measure, but must also be balanced with measures for customer value delivery (e.g. outcome metrics).

But watch for measures that can erode your culture, either because they directly or inadvertently encourage misaligned behaviours (if implemented incorrectly). For example, measuring the performance of individual developers (lines of code, pull-requests made, bugs fixed, etc) may encourage competition or result in people trying to gameify their statistics, stifling collaboration and productivity. Another example could be measuring Story Points per sprint (velocity), which could encourage teams to adjust their estimates to game the system rather than focus on value delivery.

Many other possible measures are helpful to track, but the important thing is to ensure that those measures (and how you track those measures) still align with your culture.

Embedding culture at the company level

Although this article focuses on embedding a great engineering culture, some things can be done at the company level to help embed the company values.

• Growth frameworks can be done across the whole company.

• Performance evaluations are a great place to firmly embed the values by having them as part of the evaluation criteria.

• Company-wide meetings like all-hands are a great way to embed values. Allowing people to ask questions (particularly if anonymously) helps create safety and transparency. Other items can be added to embed the culture, like introductions for new team members, sharing customer moments, values-related shout-outs, and many more.

• This HBR article explains how Netflix enforces transparency through direct feedback, open Q&A sessions, and continuous performance discussions. Employees are encouraged to challenge decisions, and leadership ensures no critical information is hidden. This transparency improved their decision-speed, performance and accountability, talent retention and alignment.

• Management 3.0 has several valuable practices, such as Moving Motivators or Personal Maps to understand your team, Delegation Poker to help with autonomy, and many more.

• More measures can be done at the company level, such as engagement surveys, Organisational Culture Inventory, Lencioni Team Assessment and retention statistics.

Summary

Slogans and policies don’t bring a culture to life. That’s done by solidly embedding your culture. By integrating values into hiring, promotions, daily rituals, and measurement, you can ensure your culture isn’t just something that dies on the office wall, but something that everybody lives every day.