“Am I the only one who cares about what we are doing here?”

I’m sure you’ve met a few people who like to “tell it like it is”. They seem to need to state the unfiltered truth at all costs, regardless of the consequences. Dropping truth bombs everywhere and often mistake blast radius for impact. It often comes from a good place, driven by a high value on integrity, and usually with the intent of doing things for the greater good. Although others use “I’m just telling it like it is” to rationalise behaviour that is simply abrasive. This article is for the first group, and for people trying to help them.

The desire to speak the truth is generally what drives this behaviour. But often the way it is executed can be at best ineffective, and worst have negative impacts even if they have positive intent.

Over the years I’ve seen many people with this behaviour struggle to improve on it. Often any attempt to explain to the Truth Bomber that they need to rein in their communication, or find ways to communicate the same message that don’t offend people, is not only met with resistance, but seems to grind against the internal values of the Truth Bomber. The internal monologue goes something along the lines of one or more of the following:

• If I water down my message, then I’m not being fully honest

• People should care only about the content of the message, not the way in which it is delivered

• If they are getting upset about my message, it’s because they don’t want to learn how to improve

Rewriting Survival Rules

One way of understanding this behaviour is through Gerald Weinberg’s concept of survival rules (described in his book Becoming a Technical Leader). These survival rules can block them from seeing a problem, so modifying them can be a key way to overcome the blocker.

As an example, he originally had a Survival Rule:

“Don’t trust people who say they want to help you”.

Over time, he gradually transformed that to:

“You can trust some people who say they want to help you, because even if you trust someone by mistake, you can probably take care of yourself and survive”

The transformation unblocked and enabled him to be more effective.

We can use his six-step process to help unblock Truth Bombers to communicate more effectively.

Step 1: State the rule clearly and explicitly.

I must always speak up and state the truth completely unfiltered.

Note that the above rule is not the absolute rule for all Truth Bombers. So, you will need to work out the specific rule for that person.

Step 2: Acknowledge the rule’s survival value

Being fact-based and speaking the truth has helped me grow as an engineer, but I can evolve to be just as truthful but communicate differently.

Step 3: Give yourself a choice, Step 4: Change from certainty to possibility, Step 5: Change from totality to non-totality

I must can always sometimes speak up and state the truth my opinion completely unfiltered (if I choose to).

A key thing here is that the term “the truth” may be what the Truth Bomber feels, but often what they are stating is an opinion. It may be an opinion based on a set of facts, but it is still an opinion. The Truth Bomber often isn’t actually saying: “I have facts”; they are saying: “I have facts + an interpretation + a conclusion, and I’ve collapsed all three into ‘the truth’.”

Step 6: Change from general to particular

Here you can add caveats to the rule about how and when to apply it.

I can speak up and state my opinion when:

• There will be something catastrophically bad if I don’t

• The other speaker has asked for people’s thoughts

• It is for the benefit of the other speaker, and they seem ready to receive it.

I can speak up and state my opinion in a way that:

• Gives the recipient a reason to engage with it

• Acknowledges their point of view

• Maintains their dignity even when the message is uncomfortable

So in the end you may go from:

I must always speak up and state the truth completely unfiltered.

To:

I can speak up and state my opinion directly when there’s a clear need to raise the issue, while choosing how I communicate it based on what will make the conversation most productive.

This rewriting enables you to still honour the intent of the original survival rule, but not be blocked by it. Now that the blockage is removed and we are in a position to help the Truth Bomber to evolve, we need some techniques to do this.

Radical Candour is good (but not enough)

Kim Scott introduces a concept called Radical Candour. Radical Candour combines Caring Personally with Challenging Directly. Truth Bombers often have the second part but neglect the first.

Many Truth Bombers’ Bombs fall into what she calls Obnoxious Aggression: they Challenge Directly, but don’t always demonstrate that they Care Personally.

The example that Kim Scott gives is after a presentation, her boss came to her, and after trying a few times to get her to understand that saying “um” in the presentation too many times was problematic, she eventually said, “You are one of the smartest people I know, but saying ‘um’ so much makes you sound stupid”. She showed that she cared personally, but then challenged her directly.

But Radical Candour is not enough.

One of my biggest career failures was when I applied Radical Candour.

An Example: My Radical Candour Failure

A senior leader (let’s call them Buck) I worked with was really struggling with their team, but had refused to acknowledge it. I had heard many complaints from the team members, peers, etc about them. Most of those people had mentioned to me that they had already given Buck feedback, as had I. All with no significant impact on Buck’s behaviour.

I decided I needed to do something more impactful to get the message through to Buck. Just giving feedback wasn’t enough. Much like Kim Scott’s manager, I wanted Buck to have an epiphany. A metaphorical slap in the face.

So I did that. I did my Radically Candid intro to ensure that I was Caring Personally:

“In general, I think you are a great person, with great empathy, and so many great leadership qualities. You have such incredible influence and have done, and can continue to do, great things at our company. I want you to continue to succeed and to help you go to the next level as a leader. I care about you and the company, and I really want us to succeed, which is why I’m having this tough conversation with you, rather than just living with these concerns and then just moving on.”

Then I Challenged Directly by calling out Buck’s problematic behaviours. I went into detail explaining his biases towards some people over others, how he didn’t put enough stock into what the experts around him were saying, and how he was disempowering his team by being in too many of the details in a way that didn’t scale. The feedback was harsher and more direct than I would often do, but still constructive and behaviour-based. But, in delivering it, I became the Truth Bomber, dropping bombs on Buck.

Unfortunately, I did not succeed in giving Buck the epiphany. He argued almost all of the points and did not change his behaviour. Worst of all, it created a rift between us.

Radical Candour gave me a useful answer to one question: “Am I caring personally while challenging directly?” But it didn’t force me to ask another question that turned out to matter just as much: “Does the other person feel safe enough to participate in this conversation?” And as a result, I could have approached it differently.

Crucial Conversations for the Win

Crucial Conversations: Tools for Talking When Stakes Are High provides a framework for this: make it safe for both people to stay in dialogue. Part of that starts with being honest about your own motivations: feedback often comes from wanting someone’s behaviour to change because it affects you. That doesn’t make the feedback illegitimate, but it does mean establishing that you care about their goals as well as your own. Two key elements of doing this are Mutual Purpose and Mutual Respect.

Mutual Purpose: Both people believe the conversation is aimed at something they genuinely care about. Ask yourself: What do I want for me? What do I want for them? What do I want for the relationship?

Mutual Respect: Both people believe the other respects their basic worth and dignity, even when they disagree. Once someone feels disrespected, the conversation can quickly become about defending themselves rather than solving the original problem.

Mutual Respect doesn’t mean you have to respect every element of another person’s character before we can talk. It means finding a way to honour and regard another person’s basic humanity.

Fixing the Example

I can’t know if this would have worked, but here’s how I’d approach it differently.

In my example, my preamble tried to establish a mutual purpose by explaining that I was trying to help him succeed, his team succeed, and the company succeed. But the purpose wasn’t really mutual. Looking back, I’d had the wrong objective. I wanted Buck to accept my conclusion. I’d confused directness with certainty. I was so sure I was right that I stopped being curious about whether I might be missing something. The goal shouldn’t be making someone see things exactly as you do. It should be creating enough safety that both people can contribute what they know and work out what is actually happening.

I could have started with something like this:

“I want to talk about some concerns I have about how your team is operating. My goal isn’t to criticise you or tell you how to run your team. I want you to be successful, I want your team to be successful, and I think some things are getting in the way of that. I also want to understand your perspective, because I may not be seeing the whole picture.”

That last sentence changes the nature of the conversation. I’m no longer presenting a completed case for Buck to accept or reject. I’m inviting him to help work out what is actually happening.

The same applies for Mutual Respect. I told Buck that I respected him, cared about him, and wanted him to succeed. But telling someone you respect them isn’t the same as making them feel respected.

My intent was: “I respect you enough to tell you something very uncomfortable.” But my approach was closer to: “I’ve already decided what’s wrong with you, and I’m now going to explain it to you.”

The harder I pushed for an epiphany, the more likely Buck was to experience the conversation as an attack on his competence and dignity. And once that happens, the conversation stops being about the original issue, causing Buck to defend himself.

Therefore, the message I delivered after the preamble could have gone something like this:

“I’ve had concerns raised with me by a number of people about how your team is operating, and I’ve noticed some of the same things myself. I don’t want to make this about who has said what; I’d rather focus on the things I’ve actually observed and hear your perspective on them. There’s a pattern of three things: you’re deeply involved in the details, some people get more of your attention and influence than others, and you’re sometimes dismissing advice from people with relevant expertise. I want to walk through each of these and hear your take as we go, rather than just handing you my full assessment.”

Then, for each point individually: state the specific observation, give the concrete example, and stop. “Here’s what I’ve seen on the details side. Does that match what you’re seeing?” Let Buck respond before moving to the next point.

This changes the mechanics without changing the substance. In my actual delivery, all three points were laid out in full before Buck had any opening to respond. By the time he got a turn, he was replying to a completed case, not participating in building one. Breaking it into three checkpoints keeps the same content and the same directness, but turns three accusations into three discussions.

The more threatening the message is to someone’s identity, status or competence, the more important safety becomes. The important distinction is that safety doesn’t mean making the message softer. It means making the conversation safe enough for the other person to disagree with you. A person can feel uncomfortable, embarrassed, challenged and even angry while still feeling respected and genuinely listened to.

There’s no guarantee that this approach would have changed the outcome. But it would have given us a better chance of discovering whether my assessment was right, rather than simply trying to convince Buck that it was.

In Conclusion

When the cost of silence is immediate and severe (for example, a safety violation about to occur, or a critical bug about to ship), directness is the correct tool, and there’s no time to build Mutual Purpose and Mutual Respect first. This is the “catastrophically bad” condition from Step 6 of rewriting survival rules. The skill isn’t choosing safety over directness. It’s recognising what level of safety is appropriate to apply for the situation.

Not every piece of feedback deserves a Crucial Conversation. Radical Candour and other feedback frameworks are a good starting point for most situations. But when the stakes are high, take the time to create enough safety for both people to stay in dialogue. The test is: Does the other person believe I care about their goals, and do they believe I respect them? Answering that honestly requires the shift this article is really asking for: not from blunt to soft, but from certain to curious, while staying just as direct.

• If you were an animal, what animal would you be?

• How would you work out how many glass windows there are in the city?

• What is the volume of water that flows through a cylinder with a radius of x, and the water is y high (asked, oddly, of someone interviewing to manage software engineers, not pipes).

What these have in common isn’t just that they are stupid questions, it’s that they are one-directional. The candidate performs, the interviewer judges, and that judgment never makes it back to the candidate.

To be fair, I’ve probably asked my share of bad questions as an interviewer. But over time (and I’ve probably interviewed more than a thousand people), I’ve settled on this as my favourite and most valuable question to ask at the end of an interview:

“I’d like to give you some feedback. First, so you can get some feedback on the interview, but also so you have the chance to correct anything that I have misinterpreted. Is that ok with you?”

Ok. It’s not really a question. The ‘is that ok’ isn’t really seeking permission; it’s giving the candidate a few seconds to prepare for what’s coming. As in, “I’m about to shift from interview mode to feedback mode, here’s a moment to reset.” The valuable bit isn’t asking that question; it’s what happens next that’s valuable. From there, I go into depth with feedback (also inviting the other interviewers to do the same).

So, regardless of what else you ask in the interview, this question makes the interview two-way instead of one-way.

The Feedback

The feedback I give is then highly opinionated, direct and transparent about what I’m thinking. I will talk about both what was positive and my concerns.

On the positive side, I have said things like:

• “Your architecture walkthrough was clear. You explained the context well, clearly stepped into each level of the architecture and explained the tradeoffs well, showing us that you are senior and have a solid grasp of architecture concepts”

• “Your explanation about how you go about forming a new team and creating psychological safety was deep and had some great examples of how you’ve done this in the past, demonstrating deep knowledge of how to do this effectively”

• “You seemed quite nervous when answering questions about the projects that you worked on, but I’m not too worried about how you interview, more about how well you understand the topics, which you showed you understand very well. Well done. For any future interviews you do, it’s probably worth brushing up on those projects so you can speak with more confidence”

You can see that these examples are specific enough that the candidate can actually take something away from them.

On the constructive side, I have said things like:

• “When you explained to me how to get a team to deliver effectively, you described how you have worked in the past, and the mechanics involved there, but when I pressed for more on how you’d get a team delivering effectively, I didn’t get much beyond what you’d already described. I’m not worried about whether you could work effectively within a team using those practices. You demonstrated that well. But not getting further than that initial description makes me concerned you might not have the depth in the underlying principles to uplift a team’s practices if that was needed.”

• “Looking at your background, you’ve had much more senior roles in the past. That makes me concerned about retention. About whether this role would hold your interest for long enough. I’d be interested to hear what’s drawing you to this role.”

• “You explained the concepts of what makes a good team, but no matter how much I probed, I couldn’t get anything concrete from you about how to actually build a team. Neither examples of how you would go about doing it. Not being able to get past the concepts into specifics is what makes me concerned about whether you’ve put this into practice yourself, or that you only understand it at a high level.”

There are many other examples, but you see that the key thing is to actually go into depth and state what you think. Doing this allows the candidate not only to receive feedback but also a chance to correct any misunderstandings. It’s important to note that the feedback needs to be about capabilities, which they can act on, not their personality traits, which gives them nothing but the feeling of being judged.

The challenge when doing this is to synthesise your thoughts concisely and quickly enough to play them back at the end of the interview. This takes some practice, but also a bit of courage to just say what you are thinking.

After I give that feedback, I ask the candidate what they think and allow them to correct any misunderstanding I may have (which I’ll cover in more detail later)

Responses to the Feedback

There are a few different categories of responses to the feedback, but what is common in almost all of them is simply gratitude for actually receiving feedback. I can’t tell genuine gratitude from a candidate who is performing it for someone who holds the decision, so I don’t read it as proof the feedback was right, only that candidates value getting any feedback at all.

Responses That Correct Misunderstandings

My absolute favourite type of response is where I have genuinely misunderstood something, or I had a concern that they can alleviate. Some examples:

• I gave one candidate feedback along the lines of “when you explained the app that you built, you talked about the testing that you did at only a very high level, so I’m worried about your depth of testing knowledge, particularly around Test Driven Development (TDD)”. The response was along the lines of “Oh. You’re right. I didn’t really delve into detail, but here’s how I went about doing the testing and here is my general approach in other examples”. The candidate then went into significant depth explaining how they had done TDD over the last 10 years, which clearly demonstrated their understanding and maturity of the practice. Misunderstanding corrected.

• The candidate that I was worried about being too senior for the role explained to me why he was after this particular role. Explaining the burnout experienced in the previous role, and that he was now looking for something more sustainable and looking to get closer to the team. Again, I voiced the concern, and he alleviated it.

These clarifications happen occasionally, maybe one interview in five (not always such a large correction, sometimes just a minor correction).

Responses That Try to Correct Misunderstandings, but Don’t

Sometimes people disagree with what I have said and try to correct my misunderstanding, but only manage to confirm my thoughts more strongly. As in, the candidate will try to explain why they have deeper knowledge in an area I said they didn’t, or more depth of experience than I implied. But when they try to correct, they give more examples or go into more depth and only expose their weakness further, failing to add any more detail and succeeding in confirming it.

For example, in one interview, I explained to a candidate that his answers to the technology questions lacked depth and didn’t give me confidence that he understood the concepts at the level of a Senior Engineer. He then explained the concepts in more depth, but the deeper he went, the less clear his descriptions were and the more mistakes he made.

Two things could undermine this category. First, by voicing the concern, I tell the candidate exactly what to address, which risks letting a shallow candidate aim a clean-sounding answer at the gap. But I’m not testing for that. When I probe, I’m looking for application, not just “what makes a good team” but “how have you built one” and “how would you build one here”, and rote answers don’t survive that. You can’t improvise experience you don’t have. Second, once I’ve voiced a doubt, I’m partly invested in it, so I can’t fully rule out that some of these were candidates who were right and lost me early. Both are reasons I treat a confirmed concern as a flag to check against the earlier stages, not a verdict.

When this happens, I simply thank them for their input and continue the process. If they disagree but can’t demonstrate effectively why that is the case, there’s no point arguing with them. It would turn the feedback experience into a negative one instead of a positive one, and most of the candidates in this case still respond positively to the feedback.

This occurrence is uncommon, though not as rare as outright negative responses.

Responses That Accept the Feedback

The vast majority of responses simply accept the feedback gratefully. There is such a lack of feedback on most interviews that people are generally extremely appreciative of receiving any feedback. Even for candidates for whom my feedback was scathing, they are still generally positive about the experience. Quite often, candidates will state that they agree with most of the feedback. This may be due to most of my interviews being for technology roles, and anecdotally, they tend to be quite introspective.

This happens the majority of the time.

Negative Responses

On the very rare occasion, the candidate will respond negatively. On one occasion, I explained to a candidate that his answers to questions were very confident, which was good, but some of the discussion might feel arrogant to the team, and I was concerned about how he would get on with the team. He did not take the feedback well, and his response was to criticise all of the things he saw wrong with the company and interviews, in a less-than-constructive way.

Looking back, the problem was how I delivered the feedback, not that I gave it. The feedback I gave was about personality rather than capability. Capability feedback gives the candidate something to address, whereas telling someone they come across as arrogant gives them nothing to act on except the feeling of being judged. I still think giving him the feedback was necessary because I had major concerns about his ability to fit in the team, but I should have given feedback on what he said or did, rather than his personality. For example, “when I tried to probe deeply for alternative answers to some of the questions, you dismissed them as unnecessary because your first answer was good enough, which makes me concerned about how you will accept alternative suggestions from the team.”

This type of negative response is very rare.

In Summary

Interview candidates are so starved of feedback that giving them feedback right there in the interview is usually a positive experience for them. It demonstrates a level of transparency that will (hopefully) align with your company’s values and thereby demonstrate that value in action. Importantly, it allows the candidate to correct any misunderstandings, which gives you better information for your hiring decision.

My experience is mostly (but far from solely) with technology roles, and the response rates I’ve described may well differ in other fields. I think the core of it, forming your opinion during the interview and being open with your thoughts and concerns rather than keeping them for the debrief, isn’t specific to tech. So next time you interview, try it. Against the alternative, staying silent until the debrief, I think it’s a better way to interview, and most candidates will at least appreciate that you tried.

How did it get this way without your knowledge, and what could you have done to prevent it? One answer is to have skip-level one-on-ones and know how to get the right information from them. Regular one-on-ones with your direct reports are a well-accepted way to coach and guide your teams, but one of the key things (that is well-known, but not actually well adopted) to building a great culture is having regular one-on-ones with the people reporting to your direct reports (your skip-levels). But skip-level one-on-ones that just go through the motions are not enough. You have to probe deeply in them, often by actually questioning potential issues without waiting for your skip-levels to proactively raise them. While the example above is an extreme case, the same structural gap exists in subtler forms, and skip-level one-on-ones are designed to catch both.

“I sometimes feel like I’m the only Engineering Manager that gives a s**t,” one of my Engineering Managers (EM) said to me.

“What do you mean?” I asked.

What followed was an in-depth discussion, which led to the point that the EM wasn’t happy with the performance of one of the other EMs (not all the other EMs, which his initial statement suggested). He thought that the other EM hadn’t taken enough ownership of the team’s delivery and that the team was struggling. This was a valuable discussion that helped me understand the EM’s concerns about the other EM, which I then needed to validate. I was fortunate that the EM was willing to open up about his concerns, but most of the time, your reports will not be so willing to raise these sorts of issues (and even less likely with your skip-level reports).

I then went to my skip-level reports (the ones that reported into the potentially problematic EM) to try to understand the situation deeper. Asking some high-level questions about how the team was going yielded a few concerns about developer experience (DevEx), but not any information about the EM themself. It wasn’t until I said something like “I’m a bit worried that your EM hasn’t supported the team enough to uplift their DevEx, which has contributed to the team’s problems”. Once I said that, the skip-levels opened up, and I understood deeply what the problems were, which allowed me to support the EM to resolve the issues.

Probing deeply in one-on-ones: How to actually get useful information.

Skip-level one-on-ones can be a valuable source of information for you, but in order to effectively get information from them, there are a couple of ingredients needed. Firstly, the person needs to trust you enough to be willing to open up and provide valuable information (otherwise, you run the risk of getting superficial information that is unlikely to help), and the other is that you need to be able to probe effectively enough to ensure you are eliciting valuable information. We won’t delve into building up trust in this article beyond that it takes time and requires you to be authentic, show vulnerability and listen deeply, but we will look a bit more at how to probe. When asking questions initially, start broad (like “what’s on your mind”), and then escalate if that doesn’t yield anything.

If you have a suspicion that an issue exists (cultural, people-related or something else), then there is a technique that can help gain information that may not be forthcoming. If, after starting broadly and then probing, they still do not give any information about your concern, it may be because they do not want to throw their colleagues or boss under the bus, or because of the power differential between you and your skip-level. As in, they may not want to be the person in the team who exposes a concern. This can be highly problematic. I’ve had times when almost everyone in a team has the same concern, but nobody is willing to raise it because of that fear. For example, everyone in the team has a concern about one particular team member, but to each individual, it doesn’t feel like a huge concern. But when everyone has the same concern, it can be problematic.

A way to help them open up is to state your concern directly to the person. As in, for you to be the one who raises the issue so that they don’t have to. After that, there is usually a sigh of relief. Having to raise the issue themselves creates a significant amount of social risk for them. They may be worried about: being seen as political, being identified as disloyal, damaging relationships, retaliation, being wrong, becoming “the difficult person”, or creating conflict they then have to live with. You raising the issue transfers that risk away from them completely. They gain confidence that you are already aware of the issue, and they no longer need to tiptoe around it and can open up.

Some examples of ways to do this.

• If, after asking “how do you think the team is going with delivery?” you don’t receive much of an answer, perhaps follow up with “I’m a bit worried about the team’s delivery, particularly with release x, what are your thoughts?”

• If, after asking “how is your team doing with planning and clarity of work coming up?” you don’t receive much of an answer, perhaps follow up with “some people have raised concerns with sprint planning, and feel like the work isn’t clear enough to execute on, what do you think?”

• If after asking “how is person x going, what are they doing well and what are they struggling with?” you don’t receive much of an answer, perhaps follow up with “Person x is halfway through their probation and I’d like to ensure I have some constructive things for them to work on, do you have any more detailed constructive feedback for them?”, or “I think person x has done well in the past when you work working on Y, but seems to be struggling a bit with Z, what do you think?”, or even “I’m worried about how person X is going, particularly around breaking down technical tasks for the team, what do you think?”

One time, I had a new Engineering Manager (EM) join the company. After a couple of months, a Senior Engineer in that team (my skip-level) raised a concern that he felt micromanaged by the new EM. The Senior Engineer had been quite a high performer in previous teams but had an issue with taking on too much work themselves, so (after encouraging the Senior Engineer to raise the issue directly with the EM), I wanted to validate the concern with other people in that team. In my one-on-ones with the other engineers in that team, I asked about the new EM with questions like “How do you think the EM is going? What is the EM doing well, and what areas concern you?” For some of them, that was enough for them to raise concerns about micromanagement. For others, that wasn’t enough so I probed deeper with questions like “How do you think the EM is going with managing work across the team and individuals?” and if still no answer, “I ask, because I’m a bit worried that the EM may be managing a bit closely and potentially frustrating people as a result. Is that something you have noticed at all?”. From the discussions with my skip-levels, I was able to diagnose the problem, which was around the delivery of the message that came across as micro-management, but that wasn’t the intent. We worked on how to use questions to get the information she needed and determine if people were already on the right track, and only providing direction if they were off track, rather than constantly providing direction, which came across as orders.

Probing a topic like this is a great way to get detailed information, but it must be done very carefully since it can potentially exacerbate issues or undermine people. You need to be genuinely curious about what people are going to say, ask questions and don’t assume that your assumption is correct until you have validated it. More often than not, it helps uncover useful information, and will build credibility with your skip-levels because it will show them that you are already aware of an issue that they are worried about, and now things will be done about it.

This technique is not your first go-to technique but more of a last resort. It should be reserved for situations where you have strong prior evidence from outside the skip-level conversations (e.g. metrics, direct observation, exit interviews).

Not undermining your direct reports

The above example shows how things can go well when you raise the issue first, but things can also go wrong if you do this ineffectively. There is a very fine line to walk, as you run the risk of creating confirmation bias and potentially undermining people, so the way you raise the issue will be highly context sensitive and also based on the maturity of the person you are talking to. Senior leaders have disproportionate influence over how problems are framed, so the moment you name a concern, people can unconsciously anchor on it and reinterpret ambiguous experiences through that lens. That means you need to introduce concerns tentatively, stay genuinely curious, and actively look for disconfirming evidence rather than treating early signals as validation. To avoid reinforcing false assumptions, I try to validate concerns across multiple independent conversations, look for concrete examples rather than emotional agreement, and pay particular attention to evidence that contradicts my initial suspicion.

I once had concerns that a Staff Engineer (Tech Lead) in a team wasn’t providing sufficient tech direction (and what he was providing wasn’t good direction for the team). I initially probed the skip-levels to get their thoughts. “What do you think about the tech direction of the team?” That didn’t yield much. “I am a bit worried that the Staff Engineer may not be providing enough tech direction for you, and perhaps direction that isn’t appropriate right now”. (Noting that I only said that to the more senior members of the team). To that, I got responses that indicated the team was happy with the direction being provided.

A few weeks later, in subsequent skip-level one-on-ones, one of the senior engineers said, “You know how you were worried about the direction from the Staff Engineer? Well, I think it is an issue now”.

I was a bit worried now. Had I seeded this concern with the Senior Engineer with my probing a few weeks ago, thereby undermining the Staff Engineer, or was it genuinely a concern that I had just seen earlier, and now the Senior Engineer was seeing it too? Fortunately, when I initially raised it, and over the course of time, I saw enough other data points to validate that there was an issue, and I am confident that I triggered the concern myself. But really, there is no way to be sure of this. I may have undermined my Staff Engineer and created an issue that never existed. So this sort of probing does run the risk of seeding concerns that may not exist, or undermining your report in other ways.

To help manage this, the first thing that needs to happen is that your direct reports need to be aware of and understand the intent of the skip-level one-on-ones (particularly since it isn’t necessarily common practice).

Next, the key thing that needs to occur is transparency and overcommunication. Any key insights that are raised by your skip-level need to be communicated back to your direct report. Any significant misalignment or gaps (signal loss) in the broader context that the skip-levels understand need to be highlighted and corrected with your direct report (particularly if it is systemic).

When skip-level concerns point to correctable behaviour, the path is simply to raise it with the direct report as a coaching conversation. When it points to character or competence concerns, the same principle applies: raise it directly with the manager, but with the recognition that the conversation shifts from coaching toward performance management. The transparency obligation doesn’t change.

What you should provide in one-on-ones

The first bit of value from skip-level one-on-ones is the coaching you can give to them. Even though the team member should be getting coaching and guidance from their manager, I find that because the tone of skip-level one-on-ones is quite different from direct one-on-ones, which can often be more operational, it allows your skip-levels to think more expansively. The coaching can be around longer-term career thinking, as well as additional ideas for operational concerns.

The other thing that you can provide in skip-level one-on-ones is a broader context around the work the team member is doing, or around your work as a senior leader. For example, how their work aligns with broader business goals and why it is important, or broader engineering concerns.

Ideally, their manager should be providing the broader context to the team member, but there can be signal loss in the communication, meaning that the skip-level one-on-one is a great opportunity to prevent that signal loss by providing context and allowing the team member to ask questions.

The dual-purpose nature of the one-on-ones (getting honest information, but also providing information such as context, coaching, etc) can create a tension, which is most acute before trust is established. As a result, in the earlier period before trust exists, the leader should lean toward the developmental framing explicitly, letting the skip-level dictate the direction of the meeting and allowing the diagnostic value to emerge rather than pursuing it directly.

Cadence

A common concern I hear is that having skip-level one-on-ones will take up too much time. But firstly, not having them can be costly because of the information you miss, and secondly, it doesn’t need to actually take that much time.

Let’s say you have six teams of six people each. If you are having weekly one-on-ones with your direct reports, that’s six hours a week. I like to have 45-minute skip-level one-on-ones, meaning that if you have them quarterly (every 12 weeks), then you end up spending 3 (48 people * 0.75 hours / 12 weeks) hours a week. If you take good notes during the meeting, and minimise or have no prep time (since it is largely a reactive meeting), then these 3 hours become the sum total time. This is not a huge amount of time investment for the value you can gain from them.

This becomes your base-level maintenance cadence. It is quarterly, which helps preserve relationships, and interlacing across your teams so that you are catching up with a different person from the one team every week or two.

In addition to the maintenance cadence, there is also an investigative cadence which is triggered when concerns need deeper probing. That requires ad-hoc one-on-ones to be scheduled with higher frequency to get the necessary information quickly.

In Summary

This article is part 5 of the series on how to build a great Engineering culture. The focus of this article was on how to get feedback on your engineering culture via one-on-ones (specifically looking at how to probe effectively in one-on-ones and how to use skip-level one-on-ones). Article one of this series looked at what an Engineering culture is, article two looked at how to define and articulate the culture, article three looked at how to embed and codify the culture, and article four looked at how to embody and champion your values.

Skip-level one-on-ones are a high-leverage activity to embed and grow your culture, from coaching, mentoring and providing additional context for your skip-level to learning about any cultural or other blindspots you may have.

• Raising your own concern first transfers the social risk of disclosure away from your skip-levels entirely, which is what unlocks honesty.

• Probing can create the problem you’re investigating. To mitigate this, validate across independent conversations and look for disconfirming evidence, not just confirmation.

• Skip-levels tell you things your direct reports structurally cannot. Not because direct reports are dishonest, but because they are too close to their own performance to see it clearly, and too incentivised to manage upward.

People are hard. Change is hard. Changing people’s behaviour can be very hard. Every step up until now in this framework of building an engineering culture (see article one for background) has been about creating clarity around expectations: the Define Step (article two) explained how to clarify the values themselves, and the Embed Step (article three) described how to clarify how the rituals and ways of working can embed the values well. This article focuses on changing people's behaviours to align with their values. Changing behaviours requires you and your leadership group to embody the values deeply, ensuring that aligned values are acknowledged and misaligned values are consistently addressed and corrected, creating an inclusive and safe environment in which the values can flourish.

I’ll share a bit of a dirty secret. Although I have explained how to define and embed a culture, I have previously built engineering cultures without following those steps in detail. Instead, I focused purely on changing behaviours by embodying and championing them. In this article, we’ll look at exactly how to do this. This article focuses on engineering cultures, but its principles apply to any culture.

Embodying the values yourself

To truly build a culture, you, as the leader in the business, need to embody the values yourself. People need to look at you and see, through your actions, what “great” for the values looks like. You and your leaders must consciously strive to go above and beyond to ensure that you live the values. At this point, many readers will probably be thinking, “Thanks, Captain Obvious. What a surprise that the leaders need to embody the culture themselves”, but doing this requires a significant amount of self-awareness to determine if you are truly living the values well, and hard work to ensure that you continue to improve and overtly demonstrate the values well enough for people to see and follow.

For example, if one of your values emphasises openness and transparency, your direct reports and their teams should experience clear and transparent communication. A sign of success is that people are not taken by surprise.

Real-world example: planning a restructure. For instance, when planning to restructure the engineering department, rather than announcing the final structure to everyone unexpectedly, we opted for transparency. Shortly after deciding on the restructuring, we informed the team about the potential changes, the reasons behind them, and our objectives. I collaborated with leaders and teams to explore options, seeking input from various individuals at different stages of the process. I held follow-up sessions with the entire department to share our current thoughts and solicit additional feedback. Ultimately, we reached a final decision involving individuals either directly or through team leads. This process exemplifies transparent communication and embodies our core values.

Stamping out behaviour misaligned with values

One of the most important things to do to embed a culture and ensure it flourishes is to stamp out any behaviours that are grossly counter to the culture and values.

Whether it is done publicly or privately depends a lot on the context. For example, for someone new to the company whose violation of the culture isn’t particularly egregious, it is probably best to pull them aside and let them know what they did, why it is against the culture, and what needs to change. More apparent violations need to be publicly called out.

Real-world example: Asynchronous discussions that went too far. I’ve had multiple occasions where Slack discussions or pull request threads have gone too far. On one occasion, someone stated that they did not feel safe continuing the debate. On that occasion, I had to write a Slack post about what safety entails and requires, as well as how to be more considerate when communicating asynchronously. I also raised it in the following wider engineering forum, advising people to get on a call before it reaches that point. I also brought the two people involved together and mediated a discussion between them on how they should proceed. The first couple of escalation points in Slack and wider Engineering Team meeting show the group what behaviour will be tolerated and what won’t be. Mediation helps solve the specific issue.

Change is hard for people, so stamping it out once is unlikely to change behaviour. It needs to be called out every time. Every time someone exhibits significantly misaligned behaviour, I will have a one-on-one conversation with the violator and explain the behaviour and why it is a problem. This repetition can be tedious and challenging for some people, but it is necessary to affect cultural change. Some people are grateful and respond well, gradually changing over time. Some people don’t, and then you have a tough decision about whether they should remain at the company. But to change the behaviour, it needs to be called out every time.

Acknowledging behaviour aligned with values

Positive acknowledgement of aligned behaviour is as essential as stamping out misaligned behaviour. People should be called out explicitly when they demonstrate behaviours aligned with your culture. Public or private depends on the context and the individual's preference for acknowledgement. However, the default should be public acknowledgement, as it sets an example for others to follow. When acknowledging the behaviour, it’s essential to be clear and explicit about why it aligns with the value and why it was important (i.e., why it benefited the company).

What you acknowledge will also depend on the context and the individual. For people generally aligned with your values and doing well, you may publicly call out behaviours with a bigger impact or greater effort (privately, you can continue to acknowledge as much as you want). For people whose behaviours are generally not as aligned with your desired culture, you may choose to acknowledge even minor changes in behaviour that are more aligned with your culture. They may be behaviours that other people do every day, but for those whose behaviours are misaligned, they may be a big effort.

Real-world example: Acknowledging effort to improve. I had someone who repeatedly struggled with his communication. He was a direct communicator, but he did not consider how he delivered his message, which often came across as rude and aggressive. He had been working hard on his communication and had a run of delivering messages that would have previously been aggressive but had done well to deliver them more constructively. In a public forum, I acknowledged him, but it was about the effort he had put into improving his communication to align with our values. Essentially I was acknowledging that he was less of a dickhead, which is what almost everyone else successfully does all the time, but for him, it was a big step forward, so worth acknowledging.

Creating an environment where the values can flourish

Simply embodying the values and calling out violations isn't enough. You and your leaders must foster an environment where others can live the values, encouraging the culture to flourish. This doesn't come naturally, and early leaders often struggle, as it may require stepping back from familiar behaviours to create the necessary space for others. A few examples can clarify this.

Example one: Teaching leaders how to be less direct to allow others to be more direct. One company I worked for had a Value around direct and open communication. It was about Radical Candour: Communicating openly and directly but with care and compassion. In an engineering-wide meeting (at the time, there were approximately 10 people, including engineering leaders and junior staff), one of the juniors raised a problem (as a gripe) that he had observed. In response, one of the senior engineers, an Engineering Manager (EM), spoke up, stating that he would be direct and open, sharing his opinion: “I get frustrated when people just raise problems and complaints without identifying a solution”. In his mind, the EM was being open and direct by stating how he was feeling, which was him trying to embody the value. However, the result was that he reduced openness and directness across the business, as junior developers would now think twice and be less likely to voice their concerns in the future.

After that event, at the next engineering leadership meeting (which only included senior engineering leaders), I brought up the event and explained the points I had just raised above. I then mentioned that to create an environment where the value of openness and directness can flourish, the EM needs to encourage junior engineers to raise their concerns rather than discourage them, which means the EM should be less direct, thereby allowing the value to flourish within the company.

Example two: Managers must challenge more inclusively. Another company had a value of “Challenge what’s accepted”. The intent behind this value is for people not to merely accept the status quo or what leaders say but to think critically and challenge conventional ideas.

At that time, I was an Engineering Manager, and my team had a proposal for addressing a particular problem that was somewhat unconventional. They were excited by it and presented it to a senior manager. The senior manager was a bit sceptical about the approach and started grilling it. He dug into it, trying to tear the idea apart. After a while of interrogation and criticism of the idea, he announced that he was simply “challenging what was accepted.”

Once again, he did not understand that his leadership position imposes a different need to allow the value to flourish. His action reduced that value in the organisation. He thought he was “challenging what was accepted,” but given his senior leadership position, whatever he says is already what is accepted. His actions meant that the team was demoralised and less likely to proactively present innovative ideas that challenge what is accepted.

Instead, he needed to bite his tongue a bit, listen to what was being presented, and try to understand why it was innovative and different. He could have asked a similar set of questions but had he approached it from a perspective of curiosity and encouragement rather than interrogation and discouragement, then the value would have flourished.

So, as a leader, this concept needs to be embedded into the leadership. The concept of allowing values to flourish requires understanding: Leaders have different expectations for living values than non-leaders. And when I say leaders, I don’t just mean people leaders; I mean people who have significant influence in the organisation and other people look up to.

Creating an inclusive environment

A thriving culture also requires diversity. Many studies demonstrate that having diversity across various dimensions (gender, socio-economic status, race, religion, neurodiversity, etc.) yields a diversity of thought, which results in greater creativity, innovation, and better teams (see this HBR article as a starting point). To create this diversity, you need to cater for many different needs. For example, people who are introverts versus extroverts, neurodivergent versus neurotypical, have different cultural contexts (requiring different levels of support, different power dynamics, etc.) and exhibit different communication styles.

Trying to cater for all of these different needs can feel daunting. However, in the vast majority of cases, the things that will help include a minority perspective are usually common-sense ideas that also benefit people who are not part of that minority group.

For example, introverts often need time to process information before responding to a question, whereas extroverts tend to “think aloud” to process their ideas. If you let workshops and discussions be free-for-all, then extroverts may dominate at the expense of introverts. The simple idea of brainwriting, such as giving the team some time to silently put their ideas on post-its first, helps enable this. Not only does it create a more inclusive environment for introverts, but it also fosters a fairer environment for everyone, ensuring that quieter voices are not overshadowed by the loudest ones.

People with ADHD will often feel pulled in many directions when trying to prioritise and decide what work to do. One way to help with this is to ensure that the team's goals and priorities are clear to everyone, which benefits everyone, not just individuals with ADHD.

People with ASD tend to take longer to context switch and move onto a new task (but when they do, they can often have a much deeper focus than neurotypicals). To set clear context and reduce surprises and context switches, it is essential to ensure that the team is clear on their current work and how it aligns with the goals, as well as provide some indication of upcoming work. Additionally, maintaining a consistent context throughout a piece of work allows for a depth of context and productivity to occur. Again, all of these benefits will also extend to neurotypical individuals.

Being vulnerable

Being a leader is hard. There is an imbalance that needs to be addressed between the leader and their team, which is crucial for effective leadership. Not all information can flow from leaders to their team members. Some issues may be commercially sensitive, financially sensitive, or people-sensitive that cannot always be shared with your team. Similarly, there may be disagreements, tensions, and pressures exist in the leadership team that you don’t want to pass down unfiltered to your team. You still need to be a calming and positive influence on your team.

Striking the right balance between shielding your team and being transparent and vulnerable can be challenging, and I think most people tend to err on the side of hiding too much. One of the key ways to create trust and psychological safety is by being vulnerable. It also helps to create an environment in which values and culture can flourish.

Sometimes, you do need to let the team know that you are struggling, feeling flat, or need help. Not only does it make you seem more human, but it sets an example that leadership isn’t about being perfect. For example, I’ve had meetings with my engineering managers where I’ve expressed feeling flat and explained why. On other occasions, I have explained that I’m having trouble explaining a particular concept to the leadership team and need help to convey the message effectively. Not only does this demonstrate vulnerability, but it also provides an opportunity for people to step up and help achieve better results.

Overcoming Change Challenges

The primary challenge in building culture is often resistance to change. The approach to overcoming this resistance is by having people experience what success feels like within the new culture, making them more receptive to change. We will focus on a lack of capability, scepticism, and buy-in as examples of the sources of resistance.

Example: Uplifting capability to overcome resistance. Resistance can stem from a lack of capability to adapt to new ways of working. One team struggled to collaborate towards a common goal due to difficulties in visualising their work, leading to independent efforts. I introduced some key rituals and guided them in visualising their work more effectively, which helped them collaborate closely and achieve success. Once they understood how to thrive within the new culture and built the necessary skills, it became easier for that culture to take root.

Example: Overcoming scepticism. Scepticism about new cultural aspects can trigger resistance. When I introduced Test-Driven Development (TDD)—a practice where developers write tests before implementing functionality—some team members were initially doubtful of its value and hesitant to adopt it. A poorly written piece of code that the team had repeatedly complained about became the perfect opportunity to demonstrate the value of TDD. I organised a game to see who could refactor the code quickest, having pre-written tests for the functionality. After each attempt, I ran their code through my tests and highlighted any failures, prompting them to fix any bugs in their work. This iterative process demonstrated the speed and quality benefits of TDD. We also conducted a similar workshop to showcase the value of pair programming, which fosters collaboration. Experiencing success helped alleviate their scepticism.

Example: Getting buy-in. A lack of buy-in and involvement can cause resistance. To overcome this, we involve the team as much as possible when rolling out new processes. For instance, when introducing the Engineering Growth Framework, I solicited input on the criteria for each level through discussions and workshops. After defining the criteria, we conducted an exercise where team members assessed each other's levels to test alignment. After hearing their input, the team felt more bought in and less resistant. This involvement requires a delicate balance as a leader: encouraging participation while guiding the outcome. If the team's feedback risked deviating from the desired culture, I would have redirected it to align with our goals.

In Summary

As mentioned in previous articles of the series, there are multiple steps to building a great engineering culture; however, the most important part of building a culture is influencing people’s behaviour to ensure that everyone embodies the culture, which is done by:

So, take a moment to look around. What’s one thing you can do this week to help embody the culture more deeply? The way that you and those around you behave is what creates your culture.

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.

The first article in this series examined what an engineering culture is and why a strong one is essential for business success. It covered the four-step framework for building a culture: Define, Embed, Embody, and elicit Feedback.

This article focuses on the framework's “define” step. It examines the properties of a great culture, how to determine what your engineering culture should be, and how to define and articulate it effectively.

The key steps to follow for defining an engineering culture are:

1. Start with the company culture: ensuring it is clearly defined.

2. Define your engineering values: building off the company culture.

3. Deal with cultural misalignment at the company, engineering or personal level.

Start with the Company Culture

Engineering culture does not exist independently but lives within the company's context. Therefore, a clearly defined company culture is the foundation for a thriving Engineering Culture.

If the company culture and values are not articulated anywhere, work with senior stakeholders to define the company culture. In his book ‘The Advantage: Why Organizational Health Trumps Everything Else in Business’, Patrick Lencioni offers a framework for defining company values, including Core Values, Aspirational Values, Permission-to-play Values, and Accidental Values. His framework can help define company values (and potentially engineering values). See this video for a high-level overview of Lencioni’s approach. At the company level, those values will likely be documented as unique and simple words or phrases that people can easily remember.

Once the company culture is defined, sharing and articulating it is important. A document like a culture deck is a great way to do this. It can take many forms and shapes, but in general, it will express the essence of the company culture by describing the following: the values in detail, the company’s ways of working, some of the team (often with personal anecdotes), company history, and various other ways to convey what it is like to be part of the company. If done well, this can be a powerful recruiting tool. Having a captivating articulation of the culture will draw people to the company. It becomes a self-fulfilling prophecy where people who share similar values to you are taken in by the articulation and then more likely to apply, whereas those who don’t will self-select out. This article has a list of great culture decks.

If the company culture is not already defined, and you do not have the influence to work with senior company stakeholders to define it, then you can still go ahead and define your Engineering Culture. In doing so, you should document the Engineering values more explicitly than you would otherwise since the company values are not already documented. From there, you can go through the rest of the framework of creating the culture by embedding, embodying, and getting feedback. Once the culture is well established in engineering, use that as a successful exemplar to push back into the broader organisation.

Define the Engineering Values

Once company values are defined, you can build the engineering values on the company ones, reflecting their meaning in an engineering context. Unlike company values, the engineering ones don’t need to be framed as catchphrases. If a culture deck exists, expand it to clarify how company values apply to engineering, including relevant behaviours and practices. When you document your engineering values, ensure they do not conflict with the company values or dilute their meaning or importance.

The most important thing is for you and your engineering leadership team to be clear on the values of your engineering culture when you try to embed them. The following article in the series explains embedding and codifying the values in detail. Still, at a high level, it is about clearly articulating the values and making them as pervasive as possible in things like the hiring process, role descriptions, promotions, recognition and shout-outs, awards, etc.

What makes a great engineering culture

To make this concrete, here are the properties of a strong engineering culture.

Learning and Growth-mindset:

• Growth mindset: In Mindset: The New Psychology of Success, Carol Dwek defines this as “the belief that your basic qualities are things you can cultivate through your efforts” instead of believing that your intelligence or aptitude is fixed and cannot be changed. She found that students and employees with a growth mindset achieve higher performance and resilience. From a cultural point of view, this means trying to find people who subscribe to this or are willing to.

• Learning and self-improvement: People who are focused on learning and growing themselves are essential in knowledge work, such as technology. This is especially true since the technology landscape changes so quickly. So, it is essential to look for signs that people are trying to grow and evolve themselves. DORA’s State of DevOps Report (2021) states that continuous learning correlates with higher software delivery performance. Microsoft CEO Satya Nadella transformed Microsoft's culture by emphasising a learning mindset, leading to increased innovation and financial success.

• Bravery: One of the best ways to learn is from failure. Creating an environment where people can do this requires bravery. Be brave enough to try new, risky, and uncertain things that may fail, and admit that you are unsure of what you are trying.

• Blameless reflection: Accountability is essential, but there is a difference between holding people accountable and blaming them. A focus on blame decreases the ability to learn and improve. Instead, you need a culture that carefully examines and understands why things could be better, then learns from that and improves. DORA’s State of DevOps Report (2022) says that high-trust, low-blame cultures are 1.6x more likely to perform better.

People-centric:

• People-first: People need to care about people. As a leader, it’s important to understand what drives each person in your team: their motivations, strengths, likes and dislikes, and what’s affecting them outside of work. Look for people who care about the people they work with. Google’s Project Oxygen found that developing people is one of the key pillars of being a great manager, and Gallup found that employee engagement yields 23% higher profitability.

• Emotional Intelligence: There is a limiting belief among many engineers that the path to optimal decision-making is to ignore emotions completely. But everyone is human, and trying to ignore our humanity makes our decisions and actions much worse. Emotions affect actions, decisions and other people. So when you hire, look for people with emotional intelligence or who are at least willing to learn and improve. TalentSmart says that “90% of top performers are also high in emotional intelligence”, and Daniel Goleman’s On Emotional Intelligence explains that leaders with high EI are more effective at resolving conflicts and building cohesive teams, leading to better organisational outcomes.

• Authenticity: While bringing one's whole self to work is a commendable goal, expecting everyone to do so often reflects privilege. Many minority groups fear discrimination if they do so. Instead, focus on finding individuals willing to be true to themselves and align their actions with personal values. A lot of this comes down to creating an environment where authenticity is possible, but trying to find authentic people helps create a people-first culture.

Low ego:

• Humility goes hand in hand with a growth mindset. It involves recognising that you don’t have all the answers. You need to rely on the people around you and the expertise, knowledge, and ideas that they bring. Even those with less experience may offer valid perspectives worth listening to and learning from. In Good to Great, Jim Collins found that companies led by humble leaders significantly outperformed competitors, prioritising organisational success over personal glory. The Journal of Management shows that humble leaders build high-performing teams by admitting mistakes and learning from others, fostering a culture of continuous improvement.

• Internally collaborative: Competition is okay, but if people are competitive, they should be externally competitive (i.e., want the company to win) but internally collaborative. Competing with others in the company doesn’t yield a better overall result.

• No politics: People must be transparent about their motivations. Trust erodes when people play political games for personal gain, and the work environment becomes hostile. Manipulative individuals can exploit values like vulnerability, transparency, and authenticity, hindering these values from flourishing and quickly damaging the culture. While influence is necessary, it should benefit the company rather than serve personal interests.

Open and transparent communication

• Feedback is necessary for growth. People must be able to give feedback to everyone they work with (subordinates, peers, managers). They must learn to give affirmative and constructive feedback on performance and behaviour in a productive way. People also need to know how to receive feedback by being curious, open to learning and change, and not defensive and closed. Research by Gallup shows that employees who receive regular feedback are 3.6 times more likely to be motivated to do outstanding work.

• Showing vulnerability: Leaders must show vulnerability to help the culture flourish. Leaders who admit mistakes and show that they don’t know everything allow more input from those around them. Vulnerability is essential for creating a psychologically safe environment. Brené Brown, in “Dare to Lead: Brave Work. Tough Conversations. Whole Hearts”, highlights that vulnerability is a key driver of trust and connection. Google’s Project Aristotle found that psychological safety was the most important factor in high-performing teams.

• Transparency: Ideally, everyone in the company has visibility into its inner workings, and very little is kept secret. When changes are planned, the teams know that something is happening and are involved in the discussion. Slack’s study shows transparency attracts premium talent, builds trust, generates better performance, improves efficiency and strengthens business accountability.

Collaborative and autonomous teams

• Team outcomes over individual output: Many software development teams don’t necessarily collaborate effectively in their teams. They are more like a set of developers working independently and in parallel, usually towards an independent goal for each developer. Engineers then measure their value based on how much code they produce or how many features they write. Ideally, teams should focus on the outcomes (changes in customer behaviour, etc.) as a team rather than what an individual produces. They should collaborate towards a common goal using techniques like pairing, swarming or mobbing when applicable. A study by Jamal M. Assbeihat emphasises that collaborative efforts among team members significantly boost overall productivity and team outcomes compared to individual work. Charles Duhigg’s studies in What Google Learned From Its Quest to Build the Perfect Team revealed that teams focused on shared goals and mutual support outperform those driven by individual competition.

• Symmathesy means interacting with multiple variables to produce a mutual learning context. People who genuinely collaborate learn from each other and the systems they work within. They become generative, and the team's value exceeds the sum of its parts.

• Empowered teams: Having a team that is empowered means delegating some of the decisions to the team. The team needs to understand and be aligned with the company's direction to determine what they will work on and how they will work on it. It can be hard to balance alignment and autonomy, and often, to begin with, alignment trumps autonomy. But the goal is to get to the point where the team is empowered. A study by Vorecol indicates that teams characterised by high levels of autonomy can boost performance by over 20%.

Desire to deliver customer value:

• Customer Focus: Building a team focused on customers and solving customer problems is crucial. Understanding the customer helps the team determine more effective solutions from a quality, experience, and outcome perspective. It is a key driver of business success. A Deloitte study shows that “client-centric companies are 60% more profitable compared to companies not focused on the customer.”

• Understanding the why: Teams that understand their customers tend to deliver better. People who want to understand their customers and the “why” behind their work are likelier to deliver something worthwhile. A Visual Capitalist article shows that employees who understand customer needs, exhibit passion for the company's purpose, and demonstrate accountability contribute to stronger business performance.

• Focus on value: Some developers can fall into the trap of exploring technology for the sake of it rather than to deliver something. Learning and exploring are essential, but if there is too much bias toward them and no bias toward actually delivering value, then that can have severe consequences for the company.

• Accountability is an essential value for leaders but can be challenging to achieve. However, to deliver customer value, leaders need to hold their teams accountable. Trust quickly erodes when people say they will do things but don’t, so building a culture where this is called out is essential.

Alternative cultures

Although the above values are of a great engineering culture, culture is not one-size-fits-all. Engineering values must align with a company's stage, goals, and structure. Here’s how culture might differ in different contexts:

• If you were in a smaller-stage startup or a company looking to maintain a fairly small engineering team, you might be biased toward individual contribution and rapid delivery and less focused on collaboration and quality.

• If the company were a larger enterprise, it may focus less on rapid delivery and more on quality and efficiency.

• If the company had a more open-source style of contribution where the collaboration tends to be more asynchronous, then the collaboration values may be different.

This does imply that the engineering values need to be refreshed and revisited over time as the business context changes, but it should not imply that they would completely change. The whole reason for articulating values is to define the type of company you are trying to build, and the core of that should not change significantly.

Dealing with misalignment

Once you've defined your engineering values, the next challenge is handling any misalignment between that desired culture and the company's current context, which could hinder cultural growth. This misalignment can occur with:

• The company culture (defined or actual),

• The existing engineering culture, or even

• Yourself

Misalignment with the company culture

If engineering values clash with company culture, leaders have three options:

• Change the company culture by influencing leadership.

• Shield engineering teams from cultural dysfunctions to preserve a strong subculture.

• Acknowledge misalignment openly with teams while working toward gradual change.

Changing the company culture

Your first port of call should be to try to affect the company culture. Collaborate with company leadership to gradually change the written culture or their behaviours. Affecting actual behaviours should be your priority, as they can clash with or enhance the desired culture. Show the company leadership the impact of their behaviours, and what better looks like. If you have an open team, this may be successful, but it will likely take a lot of time and effort (and may still not be successful).

An effective way to change the company culture is to demonstrate the desired culture in practice (as described in this HBR article), by focusing on building an effective Engineering culture and using that as a case study or exemplar to take root in the broader organisation. Doing that requires the techniques described below to shield the engineering teams or acknowledge the misalignment to create space for the engineering culture to grow.

Shielding the engineering teams

Sometimes, you can shield the team from dysfunctions in the culture outside of engineering so that the engineering department remains safe. You will unlikely shield the team completely, but you can offer some dampening to reduce the adverse impact. Shielding the team requires you (the engineering leader) to live in two worlds: the current company culture and the engineering culture you want to create.

Example 1: If leadership constantly changes priorities, it can be helpful to create a buffer before those changes reach the team. For example, you can introduce a rule allowing the team to pivot only at certain times (e.g., during quarter or mid-quarter planning) or after a certain period.

Example 2: The go-to-market leader's directive reduced cross-team collaboration by limiting Slack communication with their team. To shield the team from this dysfunctional request, we established regular rituals for structured collaboration, which helped dampen the negative culture's effect.

Example 3: I encountered a cultural mismatch when the company leadership team had a blame culture, contrasting the blameless learning culture I was fostering in Engineering. During an outage affecting a significant customer, they sought to pinpoint and blame the individual responsible. To shield the team, I proposed a Post-Incident Review to identify the root cause and implement preventive measures rather than assigning blame to a specific person.

There is a fine line between shielding the team and being transparent. Transparency is usually the best default, but if there are cultural mismatches, shielding the team by not passing on the message, or at least dampening it, can be the most effective approach.

Acknowledging the misalignment

Sometimes, it can be helpful to acknowledge to the engineering team that there is a cultural gap and be clear that you are working on changing things, but the gap needs to be accepted. This level of transparency can help build trust with the team and get their support for cultural change.

I once had a team frustrated with being treated like a feature factory. They wanted to prioritise customer behaviours and business outcomes over timely delivery, but they were struggling to meet deadlines at the time. I acknowledged the cultural gap and noted that while we ideally should focus on outcomes, we weren't mature enough yet. Therefore, we needed to start delivering regularly and on time to build trust within the business, which would help me shift the broader culture toward their desired state.

If the gap is too large

Sometimes, the gap between the company culture and the desired culture is too large, or the inertia to change is too great for your desired culture to work effectively. From there, you can live with a watered-down version of your desired culture. This option may still be feasible if that version is close enough or if you are willing to live with the gap. If not, you should find a company that is more amenable to your desired culture.

Misalignment with the current Engineering department

Misalignment with the current engineering culture is expected since you are trying to create a new culture different from the existing one. The subsequent articles of this series will delve into great detail about how to build your desired engineering culture. As a starting point, it is worth building a clear picture of the current Engineering culture and how far it needs to change to reach the desired state, which means auditing and understanding:

• What (if anything) is documented about the current culture

• The people in the engineering leadership group, their values and how they work

• The people in the engineering group as a whole

• The practices, behaviours and rituals of the engineering group

Misalignment with yourself

Being able to see if there is a misalignment between yourself and the desired values is hard (for you) to see. It can be easy to get into a trap of defining your ideal set of values but not realise that you don’t embody that value set. As a concrete example, I’ve seen a few times where there is a desired value around team autonomy, but the leader strongly needed to understand and control low-level details. They weren’t aware that they were doing that, which prevented that value from ever taking root in the company.

If there is misalignment between the desired culture and yourself, you have two options: change your desired engineering culture to be more in line with your actual behaviours or change yourself to be more aligned with your desired culture.

In Summary

Defining your desired engineering values is the first step in building a culture. To do this, you must build on your company culture and clearly define your engineering values so you and your engineering leadership team can effectively embed them.

Although there is no one-size-fits-all approach to values, which must match the organisational context, in general, great engineering cultures are built around:

• Learning and growth-mindset

• People-centric

• Low ego

• Open and transparent communication

• Collaborative and autonomous teams

• Desire to deliver customer value

If there is misalignment at the company level, work to change the company culture, shield engineering from it, or acknowledge the gap.

Your engineering culture already exists, whether you’ve defined it or not. The question is if it's intentional or evolving by default. Defining your values is the first step toward building a high-performing engineering culture.

In the next article, we’ll explore how to embed these values into your hiring, decision-making, and team rituals, ensuring that your defined culture becomes a reality.

When I joined a tech scaleup, I noticed the lack of a strong engineering culture. Individually, most of the people were capable, but together they were not working effectively. Engineers were working in isolation without any concept of a team, let alone high-performing teams. Communication had undertones of aggression, and quality issues meant half of the team was allocated to fixing bugs. Across the eight engineers, there were six different titles without any clear progression path or promotion consistency. Crafting an engineering culture that fit with the company values, where the company was on a significant growth journey, was key.

The next few years were a wild ride. We built and released new products, improved the platform's reliability, security, and quality, drastically increased our customer base, and nearly tripled revenue. We also significantly scaled the engineering team while embedding the new culture.

Reflecting on my experiences there, it was humbling to hear the lasting impact that this carefully crafted culture – centred around people, customer focus, growth, humility, collaboration, and transparency – has had since I left. Team members at all levels told me that the culture was the highlight of their experience, with many joining because of it. There is recognition from all levels of seniority across the company that these cultures don’t just happen - it takes an engineering leader who is passionate and cares about people, understands how to build high-performing teams and, importantly, can drive necessary change through the business.

I’ve had the privilege of being part of multiple other strong engineering cultures. Every time, building it was intentional, requiring deliberate effort from many people, as well as careful planning and execution over time. I have also worked in or seen many other companies that haven’t managed this. One of the common things that I experienced was that most people working in sub-par engineering cultures did not recognise that they were. They did not understand how bad the culture was, how much it cost them or how much better they could be.

I’ve written this series of articles to share what I learnt about building an engineering culture. To explain the benefits of having a great engineering culture and the concrete things you need to do to build one. This first article will help explain what an engineering culture is and its importance, as well as provide a summary of the series. Subsequent articles will explore the topics in more detail.

This series is intended for engineering leaders looking to build an engineering culture from scratch or strengthen an existing culture. It will also be valuable for engineers at all levels looking to understand how to influence their engineering culture, as well as other senior stakeholders wanting to understand the different facets of a strong engineering culture.

What is an Engineering Culture, and why is it important

Engineering culture refers to the shared values, behaviours, and practices that shape how engineers work and make decisions. It influences their performance and, ultimately, the company’s success.

A strong engineering culture is the backbone of any successful technology-driven company. When done well, it fosters innovation, productivity, and alignment with business goals. It attracts and retains talent by offering growth, belonging, and meaningful contributions, creating a career-defining workplace. Weak cultures can cause low morale, higher turnover, slower decisions, and inefficiency, threatening team and company success.

Multiple studies show the significant impact of strong engineering cultures: Glassdoor found that over half of workers prioritise culture over salary, McKinsey linked strong cultures with 4-5x faster revenue growth, and Harvard Business Review reported companies with strong engineering cultures had 2.5 times the revenue growth compared to weaker ones.

A strong engineering culture significantly enhances the potential for success of the engineering team within the company; however, it is not a guarantee of success on its own. To have a successful engineering department, one needs to consider the following areas:

• People

• Product

• Technology

• Delivery

Engineering culture does relate to all of these areas but mostly applies to the people area, so as we delve into these articles, we won’t delve into all of the details of Product, Technology and Delivery in depth (we’ll cover the aspects of them that relate to culture).

How much can a poor engineering culture cost

The impact of poor engineering cultures goes far beyond the engineering team – it affects the entire company. In a great culture, the team produces results greater than the sum of its parts. Engineers collaborate, learn from each other, and thrive, creating a multiplier effect that drives the department, and the business, forward.

But in a poor culture, the opposite happens. The team detracts from individual contributions, creating inefficiencies that ripple through the organisation, as illustrated by the image below. Even highly capable individuals may struggle and fail in a weak culture.

A Detailed Example: Slow Progress on Too Many Projects

At one startup I joined, twelve engineers struggled across ten projects under a single task allocator lacking clear prioritisation. Engineers worked in isolation, without collaboration, unified vision or customer focus, and the excessive concurrent work resulted in a lack of traction on any of the projects.

This inefficiency had real business consequences: Due to slow progress, the company struggled to win and retain clients, and frustrated engineers began to leave, creating a vicious cycle of attrition, delays, and the costly process of hiring and onboarding replacements.

Another Example: Poor Engineering Practices

At an earlier-stage startup, progress had ground to a halt. Features that once took days to develop were now taking weeks, and quality had plummeted. Major bugs were introduced with every release, and performance issues slowed the entire system.

The root cause was a lack of engineering fundamentals like testing, configuration management, and continuous integration. These gaps led to significant outages when a high-profile customer joined, damaging the company’s reputation. Over time, the inability to deliver on commitments forced the company to downsize its engineering team, a painful decision that could have been avoided with a stronger culture.

Other symptoms of a poor engineering culture

Beyond those specific examples above, poor engineering cultures often have other symptoms:

• Pull Request (PR) Ping Pong: Teams bogged down in PR disputes and don’t prioritise reviewing PRs, delaying delivery.

• Toxicity: Blame culture or interpersonal conflicts prevent meaningful discussions and buy-in, leading to frustration and high turnover.

• Internal Competition: Hoarding information and political maneuvering replace collaboration and trust, stifling innovation and progress.

• Hero Culture: Where the company relies on the heroics of key individuals to make the majority of progress, preventing knowledge transfer and collaboration, as well as creating single points of failure for the business.

• Technology for Technology's Sake: Also known as resume-driven development, where a lack of customer focus and governance results in developers focusing purely on the technology instead of customer outcomes.

• Ignoring Technology: Engineering decisions are dictated solely by non-technical stakeholders, ignoring technical debt or feasibility, frustrating developers, slowing progress over time and leading to unachievable commitments.

• Copying-and-pasting Processes: When people force processes from different contexts onto their new context (e.g., “Let’s install the Spotify Model”), this often results in inappropriate, heavyweight, and unnecessary processes, which in turn results in overhead, bureaucracy, and slowdown.

• Just Tell Me What to Build: Engineers want to be directed on what to do without understanding the ‘why’ or the customer, often leading to suboptimal solutions.

• And many more.

In many cases, the individuals in these environments were talented and capable, yet the culture held them back. A poor culture doesn’t just waste potential – it actively erodes it.

How to build a great engineering culture

A good framework to use to build a great engineering culture involves the following steps

1. Define and articulate the culture

2. Embed and codify the values

3. Embody and champion the values

4. Elicit feedback on the culture and course-correct

Subsequent articles in this series will cover each of those steps in more detail, but below is a high-level overview.

How to define a great engineering culture

Great cultures are generally centred around a growth mindset, people-centricity, humility, transparent communication, collaboration, and a desire to deliver customer value. However, there isn’t a one-size-fits-all approach, so defining your desired culture is essential. You need to have strong enough self-awareness to understand the current organisational context and define an aspirational culture that can succeed. The second article of this series will cover how to define your culture in detail based on your context, what makes a great culture, and why.

How to embed and codify the values and culture

Embedding is about making the culture as pervasive as possible in the company processes. In the hiring process, role descriptions, promotions, recognition, awards, ways of working, and other rituals. Engineering Growth Frameworks (which define how engineers can grow and progress in their careers) can be strong cultural enforcers. Refine your hiring process to help establish your new culture by building a critical mass of values-aligned people. Structure your Ways of Working and rituals to help embed your values and allow them to flourish. Using surveys like Health Checks can help measure the progress and success of your cultural change. The third article of this series will take a deeper dive into how to use your rituals to embed and codify your values.

How to embody and champion the values

Getting your values to take root requires everyone to embody the values strongly. It requires leaders to be walking the talk in everything they do. Team members need to live the values too, which requires the leaders to stamp out behaviours that are misaligned with the desired values and acknowledge aligned behaviours. Leaders need to create an environment where the values can flourish by creating a safe, inclusive environment that caters to diverse needs, fosters greater diversity, involves more team members in discussions and decision-making and ultimately improves performance. In the fourth article of this series, we will cover how to embody and champion values in more detail, as well as how to overcome some key resistances to change stemming from scepticism, low buy-in and involvement, or lack of capability.

How to get feedback on your culture and course-correct

Implementing your desired culture requires a clear picture of what is happening in your engineering department. One-on-ones (1:1s) are a key way to get this information and also course-correct. You need to have effective 1:1s with your direct reports and skip-level reports, create a safe space in those 1:1s, and probe into details to preempt any blindspots that you may have around your culture. Once you build trust, you can then ask detailed questions about the other people (including leaders) of the team, any concerns, frustrations, and even questions about ways of working and rituals to help you build up a picture of each product-engineering team, and also any systematic issues across the engineering department. The fifth article of this series will cover how to use 1:1s to further embed and solidify culture.

In Summary

A strong engineering culture requires conscious definition and consistent nurturing to drive success. To do this effectively, you can follow the framework:

1. Define

2. Embed

3. Embody

4. Feedback

So, think about your engineering culture. Is it pushing your company forward and helping it succeed, or is it holding your company back from success? Do the engineers care about their team and customers, grow, have humility, are transparent, and collaborate effectively together? If not, you probably do not have a great engineering culture and need to spend time building a great one.

Stay tuned for the next article of this series, which will delve into the details of how to define and articulate a great engineering culture.

The question comes in different formats, but I was often asked when applying for software leadership roles. That type of question is trying to get an indication of how the candidate thinks about leadership. I struggled the first few times I was asked that question because although I had been leading for a while, I had never explicitly articulated my process for leadership.

Going through the act of articulating my approach to leadership was quite useful, in that it helps answer interview questions like the ones above, but it also helps put an organised framework around what I do when I try to build a team. This article is intended as a high-level answer to the question of “How do you lead”, not an in-depth tutorial, although there are some references and examples throughout. The domain I work in is software engineering, and so that domain will be used throughout this article, but the concepts explained apply to most industries that are centred around knowledge workers.

Purpose, Autonomy and Mastery

Dan Pink, in his book “Drive, the Surprising Truth About What Motivates Us” mentions that people need 3 key things to be motivated:

• Purpose

• Autonomy

• Mastery

This forms a good framework for how to think about what a good leader needs to focus on to ensure that the team is performing at its peak and the individuals within the team are motivated and working at their best.

Purpose

Alignment and the “why”.

Alignment: The first thing is to ensure that the team is aligned about their purpose. Without this, the individuals in the team may be pulling in opposing directions, or the team may be pulling in an opposing direction from the rest of the company. To align the team around a common purpose, the team’s vision needs to be clear, as well as how that vision fits within the company’s vision. So as a leader, my role is to provide that clarity by working with the wider business to ensure that the vision is clear, documenting and displaying that direction, and ensuring the team understands it. If the company’s direction is out of the leader’s sphere of influence, the leader should push for that clarity as high up as possible.

In the past, to help clarify the vision and direction of the team, I’ve used Team Canvases or Team Working Agreements, and using OKRs (Objectives and Key Results) is useful for alignment across the company, as well as within the team.

The “why”: People perform best when they understand and are bought into the purpose of their work and the problems they aim to solve, enabling them to prioritise effectively and devise better solutions. They need to understand the “why”.

Building a Shared Understanding can help the team focus on the “why”. Also, getting the team closer to the customer is a great way for them to understand the why. One way to achieve this is by setting a goal for the team around customer contact time per month (e.g. in customer interviews, help calls, etc).

Autonomy

Owning the problem, safety, feedback and disagreement.

Often when people think about autonomy, they consider it from an individual perspective. As in, do I as an individual have the ability to make decisions about what work I do? To facilitate that autonomy at the individual level, we need to create autonomy at the team level.

Owning the problem: If the alignment of the purpose and vision is clear from before, and the team understands the “why”, then the team can own the problems and opportunities before them. Understanding the problems the team needs to solve enables team autonomy by allowing them to determine their own solutions to problems (as opposed to being given a solution to implement). This team autonomy then facilitates individuals to have autonomy. This can only happen after the purpose is clear. From there the team can self-organise to determine what each person will work on. Without team ownership (autonomy), individuals can’t have their autonomy because they will require a leader who needs to allocate work to them. With team ownership, the team is empowered to decide what to work on, and then each individual within the team is empowered to have autonomy.

Building a Problem Roadmap rather than a feature roadmap helps the team understand and own the problem. Ensuring that any Product Management frameworks and templates are Problem-Focussed is also helpful.

Safety: So how do you build an autonomous team? Team members need to be able to raise their points and know that they are being heard, which requires psychological safety (the belief that there won’t be negative consequences for speaking up with ideas, questions, concerns, or mistakes). The leader must create this safety by showing vulnerability and fostering a culture of deep listening, open communication and honest feedback. Then people will know that their input will be heard which allows them to express their disagreement but commit to whatever decision is made. Psychological safety not only fosters autonomy but also lays the foundation for experimentation and learning, which is essential for mastery.

It is important to understand what psychological safety is. Then lead by example to show vulnerability and create a space where people will be heard. This will then allow people to properly disagree and commit.

Mastery

Experimentation, failure, continuous improvement and learning environments

Experimentation and failure: Now that the team can own the problem, they will feel safe to investigate whatever options they need to implement their solution. The leader must create an environment where people feel safe to fail, which will allow them to experiment and learn new things as they try to find new solutions. Safety to fail is essential for teams to innovate in both what and how they build. Without this, their improvement will be stunted.

Foster a culture of experimentation by introducing language around failure and learning, and lead by example by showing vulnerability in your own failures. You can use Celebration Grids as a tool to help with this.

Continuous improvement: The leader must create a learning environment where people invest time in improvement. There is always a delivery pressure. Possibly this is a failure on me, but I have never worked in a company where the rest of the business has said to the eng team “No thank you, I don’t want you to build things faster”, or “Slow down, we can’t keep up”. There will always be delivery pressure so the leader must create slack in the system for the team to address challenges, reflect, learn, and improve (e.g. via retrospectives). Without time for continuous improvement, unresolved issues pile up, lowering morale and slowing progress. Over time, teams begin to fight against their processes and technology rather than getting the most from them, which causes the slowdown.

Retrospectives are essential to start to create a culture of Continuous Improvement. Creating time for improvement can be done in many ways, such as setting aside a percentage of time each period for improvement, picking the top one or two items from each retrospective to ensure it gets prioritised and actioned, limiting Work In Process to ensure the team is focussed and not overworked, maintaining an improvement backlog.

Learning Environment: For people to embrace mastery and learning, a growth mindset needs to be embedded into the culture. Embedding a growth mindset involves more than promoting learning opportunities; it requires consistent reinforcement through coaching, recognition of progress, and fostering curiosity across the team. People need to have the desire to learn and grow both as individuals and as part of the team.

There are many ways to create a learning environment. As a start, the leader can demonstrate learning behaviour by sharing interesting things with the team and encouraging them to try new solutions. But they should go further by setting up frameworks to allow learning such as introducing Guilds / Communities of Practice (groups with a shared interest who deepen their knowledge in certain areas by regularly collaborating) and Brown Bag Lunches, creating Team Competency Matrices to help guide whom to go to to learn a new skill, creating forums to share knowledge such as solutions to complex problems, as well as mentoring and coaching in one-on-ones.

Putting it together

You can go into a lot more detail when answering the question of “How do you lead”, but we just covered a simple structure for thinking about leadership and answering that question using Purpose, Autonomy and Mastery.

Purpose:

• Ensure there is alignment by making the vision and direction clear

• Ensure that the team understands the problem and the “why” behind the work they are doing

Autonomy:

• Help the team own the problems they are solving

• Create a safe environment with open communication

• Then people can give honest feedback and input

• Allowing them to disagree and commit

Mastery:

• Encourage people to experiment and fail

• Create a learning environment where people grow, improve, and learn from each other.

How Do You Lead? was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the first things I did when I started at EstimateOne 9 months ago was to survey our entire Software Engineering team. The conversations were worth their weight in gold, however, one key theme I found was that the team was unsure what they needed to do in order to get promoted.

Since growth is a proxy for happiness at work, it was clear this was an issue that needed solving. We needed to make sure the team knew that EstimateOne was a place for growth and development (and not just the development of code).

So what did we do

It was important to me that our final answer was to be more about looking forward than reviewing the past. We already have a non-evaluative feedback process which we use to help people pulse check their own performances. Our end of year salary evaluations as well is used as a time to reflect on performance, not so much capability.

We decided we wanted to base our framework of these key principles:

• A focus on behaviours you can observe, teach and learn

• Conversations about growth should be ongoing

• Growth is more important than levels or categorisation

• We should incentivise the kinds of behaviours that we want to see in the team, and recognise the different kinds of value that people add

• The framework should be as objective as possible but not complete algorithmic calculations. I.e. aspirational goals that may be somewhat subjective but ring true

• The purpose is about clarification around expectations — not to add a stressful evaluation process.

After much research, coupled with plenty of interviews from the team, we created a framework with 13 different levels. The framework begins with Software Engineer 1 and diverges into two paths as the employee moves up the ranks. Those who select the Technical path will peak at Principal Software Engineer 2 and those who go down the Leadership Path will peak at Senior Engineering manager 2. This separation is important because, in many organisations, developers are forced into leadership positions as the only option to progress, whereas we wanted to provide a non-leadership progression path too.

So what does it look like?

It’s probably easiest if we just show you the framework.

So what are the skills and capabilities Engineers need to grow in order to get promoted?

When creating the structure, we broke down the skills required into 5 categories. We also mapped them to our company values — which are held in pretty high regard at EstimateOne. The values we mapped them to were Authentic Ambition (AA), Enabled Expertise (EE), Forthright and Frank (FF) and Cranes before Code (CC).

You can read about our values in our company handbook, but the TLDR is;

• Authentic Ambition — we are ambitious in our work and constantly look where we can add value, whether it be shareholder, industry or team value.

• Enabled Expertise — we look for where we can impart our own expertise to others and where we can leverage the expertise of others.

• Forthright and Frank — we’re straight talkers and constantly look for opportunities to give caring and empathetic feedback

• Cranes before Code — we try to understand our customers and their problems (Cranes) before coming up with solutions (Code).

The five categories where we look to identify growth are;

Technical Capability:

• (EE) Craft: The ability to write clean, maintainable, well-tested and secure code.

• (EE) Depth and breadth: An understanding to how to contribute to end-to-end solution development (e.g. front-end, back-end, DevOps)

• (EE) Individual learning: Demonstrating a growth mindset, actively seeking to improve in all areas of software development.

Execution:

• (AA) Delivery: Contribution to the team’s delivery

• (AA) Impact: The influence had on the codebase / the organisation as a whole

• (AA) Initiative: Demonstration of initiative

• (AA) Promotes team ownership: e.g. scout ownership (leaving the place cleaner than when arrived)

Communication and collaboration:

• (FF) Support for the team: Showing care about the welfare and wellbeing of other people in the team

• (FF) Transparency: Clear communication of progress, blockers and information that team members will care about

• (EE) Shared learning: The entire system (people, software, infrastructure, etc) learns from everything else in that system. High performing teamwork requires nurturing of the entire system, both teaching and learning from all other parts of the system. Building mental models of the system and sharing that with others

• (EE) Generativity: A focus on team outcomes rather than individual output

• (EE) Pairing, swarming and mobbing!

Ways of working:

• (CC) Striving to improve ways of working: Collaborate, Deliver (small increments and learn), Reflect (on collaboration and deliveries), Improve (ideas, technical implementation and processes) and Iterate regularly.

• (CC) Contributes to value: Understanding of the problem being solved and being involved in the solution. Ensuring what we’re building helps contribute to customer and business value.

• (CC) Contributes to quality: Quality assurance, performance and usability.

Strengthening:
(These are points worked on in the more senior levels)

• (EE) Mentorship: Supporting colleagues, spreading knowledge and developing beyond expectations of regular team interactions

• (AA) Recruiting: Strengthening the team by assisting with bringing in great staff members.

• (AA) Evangelism: Promoting EstimateOne to the outside world

• (AA) Community: Builds community internally, gives to the team, and champions and extols company and engineering values

How the reviewing process works

Each quarter, we expect every Engineer to go through the process of reviewing where they sit within the framework.

We start with an initial discussion between the reviewer and reviewee. The reviewer will differ depending on the level of the reviewee, but will either be a leader within the team or the head of Engineering.

Before they kick off, they’ll be asked to do a quick self-assessment where they’ll mark off their progress against the capabilities. (you can see an example here). During the discussion with the reviewer, both parties should reach a consensus on how they meet the criteria. The focus of the discussion should be forward-looking around what the reviewee needs to do to grow to the next level, not backwards looking constructive feedback (which we do in our formal feedback process), or a box-ticking exercise. As a result, the review becomes a regular growth discussion for the reviewee which is usually a positive experience for them.

Once consensus is reached, the reviewer will present the reviewee to a panel, which helps ensure objectivity and consistency. After that (hoping all goes well) we’ll decide on the promotions! Keeping with our Forthright and Frank value, we’ll also make sure there is plenty of room for feedback (both on the discussions and the process) after all is said and done.

And that’s it! A (very) quick guide to how Engineering growth works within EstimateOne.

EstimateOne Engineering Growth Framework was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why?

Firstly, there are many who argue that estimation is not a good practice to apply in software development since it often doesn’t end up affecting prioritisation, moves the focus away from iteration, and is essentially guesswork applied to unpredictable and non-repetitive work and more. The key point is that not only does estimation not offer a good return on investment but that by doing it, the team shifts the focus away from better practices. Therefore, the very first question to ask is, “should we actually be estimating?”

Although the answer to this question may often be “no”, the perceived need for it may be too high in your organisation to not do it, or simply not a battle that you want to fight. If you do decide to use estimation, the key is to ensure the process is as valuable as possible. To understand that, let’s examine what parts of estimation are less valuable or not valuable at all.

• Not valuable: time spent estimating things that never get done. Time spent estimating things that are less likely to get done (a long way in the future, or are extremely low priority) is wasteful.

• Not valuable: Time spent arguing about a number. There are some valuable parts of the estimation discussion, but the part where people are just debating about numbers, and not clarifying scope or understanding, is just wasteful.

Ok, but what is valuable?

• Valuable: Refining, clarifying and getting a common understanding of the scope of a piece of work (that is likely to be done).

• Valuable: Uncovering that a piece of work is too big and then splitting it up into smaller increments, each of which delivers customer or business value. “Too big” is something that gets refined over time, and initially starts at “bigger than one sprint” and slowly reduces to “small enough that we don’t have wild variation when implementing stories of that size” and ideally reduces to “all our stories are roughly the same size when we implement them”.

• Valuable: Providing sizing information that affects the priority of work, and hence what work can be deferred.

But what about other reasons? Well there are other reasons that people use to argue for estimation, but whether or not they add value is less clear:

• Debatable: Planning the timing of a roadmap or releases. Unfortunately doing this often shifts the focus away from iteration. That is, the more the business focuses on dates and deadlines of features, the less likely they are to iterate over those features (return to those features and refine them) as doing that affects future deadlines that have been set.

• Debatable: Determining how much should go in a sprint. Does this give us a lot? I’ve seen many places where teams just keep working and finish as much as they can in a sprint, regardless of how much they forecast could be done in the sprint. Also, ideas like Kanban don’t even have a timeboxed time.

Therefore if you decide to estimate, it is important to focus on the value-add parts of the process.

When?

So now, understanding what is valuable and not valuable about estimation, when do we actually estimate? Should we estimate things in the current sprint, things one sprint ahead, the whole backlog?

There is a general concept usually applied: “Boulders, rocks, pebbles”. The idea is that things that are a long way in the future (therefore less likely to be worked on), should be left as a boulder size estimate — a larger and unrefined estimate since you don’t want to spend much time on it. Things that are not as far in the future, should be estimated at rock sizes. And things that will be done (current sprint or so), should be well defined and understood, and hence estimated at the size of a pebble. Distant future work should not be refined to pebble level of estimates, and boulders shouldn’t be attempted in a current sprint because the work is unlikely to be clearly understood.

What?

So what should we estimate? Absolute metrics like duration or effort? Or relative estimates (tasks relative to other tasks)?

Generally, teams tend to be more successful with relative estimates because it can be done quicker than absolute estimates, people tend to be better at estimating relatively, and it is more team focussed. The example often given is if you have a group of people estimate the height of a building in metres, they will often be wildly off, but if you have them estimate the height of one building relative to another, they tend to be much more accurate.

So what are we actually estimating? It’s not just about the effort (or how long it will take), it’s a combination of complexity, risk (uncertainty) and effort. All of those need to be factored in when estimating. For example, if something is a very minor change, but may catastrophically break your system, it will require significant testing and planning, making it a high relative estimate.

For more information, have a look at this article by Mike Cohn and this article by Ryan Key.

Then there’s the measurement. Often this is done in “velocity”, which is the number of story points per sprint. It is one of those unfortunately named things in Agile. A better name for it is stability. The goal is to get that number to be as stable as possible. If you can get that number to be fairly constant, then you are better able to predict your work. It is not something that you want to try to increase or use to measure productivity or compare between teams.

How?

Prior to doing any relative estimation, a baseline needs to be established (what are we estimating relative to). Usually, that involves picking a story which is clearly defined and assigning it a 2, then picking another story, which is approximately 4 times the size of the first story, and assigning it an 8. Those two will be the baseline stories against which others are estimated.

One way to do the estimation is to use a technique called planning poker. This is where each person in the team will silently declare their estimate for a story, and then if everyone estimates the same or similar number move onto the next story. But if estimates differ between people, a discussion is had to help clarify the scope, before more silent estimation occurs.

Another way to estimate, which is particularly effective when there are a significant number of stories to estimate is to use Affinity Estimation. This is where the team tries to quickly group many stories into buckets all at once, rather than focusing on each story at a time.

Who?

The people involved in taking the work and implementing it. But who exactly is that? Does it include product managers, product designers, etc. That usually depends on your entry criteria or “Definition of Ready”. If your Definition of Ready states that a story must have its scope clearly defined, designs complete, and Acceptance Criteria written, then the estimate applies to just the developers, testers, etc who will take the story from that point to delivery (or whatever your “Definition of Done” is). If your Definition of Done does not include the design, then whoever is involved in iterating that design should be included in that estimation. Rarely should the Product Manager be involved in estimation. Their goal should be to provide as much clarification as needed for the rest of the team to estimate.

The other part of the who should do the estimation is the team that does the actual work. It is generally not useful to try to standardise across multiple teams. This tends to be very time consuming and usually slowly gets out of sync. Also, often each team will be doing different types of work in different contexts, which means there is little value to standardising between teams.

Conclusion

Firstly, consider If you should be estimating at all. If you do decide to estimate (or cannot win the argument not to estimate), focus on the value-adding aspects of estimation which is about helping clarify the scope of work, and splitting up work into smaller increments. Then focus on a short time horizon and use relative estimates to size those stories.

Agile Estimation: All Your Questions Answered was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here are some things you might get out of this article:

• A way to identify high and low performing software engineering teams.

• An understanding that although the task of building a high-performing software engineering team may seem like it is the responsibility of the people that make up that team, all other parts of the company can help or hinder the performance of that team. That is, you can have the highest performing software engineers in the world, but if they are constantly building the wrong thing, they may be next to useless.

• An understanding of the types of things that help or hinder building high performing teams at every level of the organisation.

• Some techniques for growing your high performing team (marked in bold).

• A sense of frustration, since most of the secret sauce of how to build high performing teams is highly context sensitive and therefore there aren’t many one-size-fits-all solutions. In addition to the techniques described throughout the document, there is a final section which covers some general principles to apply at every level for how to do better.

Level 1: An individual developer

The most important ingredient for a high performing individual developer is a willingness (passion) to learn. Someone who is striving to master their craft. She has faith that there is always a better way to solve a problem and strives to uncover that better way. In doing so she learns more and becomes a better developer. By repeatedly doing this, she sees patterns that she has (or someone else has) already uncovered and solves problems more and more quickly. She seeks to master her tools. By doing this, an experienced or high-performing individual developer will move more quickly towards the goal of having a feature code-complete.

As a way to illustrate this, we can imagine the steps that a developer needs to take to get towards her goal of delivering a feature. The diagram below shows the path of an experienced developer, and how she takes small steps towards the goal more quickly than the inexperienced developer, who ends up taking a much longer path to reach the goal.

Techniques for Instilling this desire for learning in engineers can differ from person to person. Generally, creating an environment where there is time to learn is a good place to start. It can be in the form of designated times, such as Google’s 20% time, or Hackathons. It could be by creating spaces for team members to share knowledge with other members, such as guilds (a community of members with shared interests across the organization who want to share knowledge, tools and practices) or Lunch and Learn sessions. It can best be achieved by ensuring that employees have some slack in their workday to try to learn new things. For example, by not constantly having tight deadlines. Carol Dweck has some useful ideas for instilling learning in people in her book Mindset.

A high performing developer also understands the “long game”. She understands that solving the problem is a small part of what is necessary, and that the real challenge is solving it in a way that will not slow her down in the future. That is, she tries to minimise the amount of technical debt she produces.

She strives to write readable and reusable code, usually by following principles such as SOLID. She uses processes and tooling that ensure that she can release code quickly and have confidence in the quality of her code by employing practices such as Test Driven Development, Continuous Integration and Continuous Deployment.

If we observe these two developers over a longer period of time, we can see how an experienced, high-performing developer continues to take steps towards each goal, and doesn’t slow down over time, whereas the less experienced developer has to take larger and larger detours as technical debt builds up.

Level 2: Team of engineers

At this level of the hierarchy, we observe a a team of engineers (Software Engineers, DevOps and Quality Assurance Engineers).

Misaligned team of engineers:

As we observe this particular team, we notice that they are fortunate enough to have a group of individuals who are all high performing by themselves, but in this team, they all appear to be pulling in different directions. The result is that the high performing individuals produce a team which is far from high performing. Their actual path is barely in the direction of their goal at all.

This poor team suffers from a lack of alignment. The members of the team have assumptions about what their purpose is and what they should be developing, and these assumptions are not the same for everyone in the team.

Aligned team of engineers:

If the team members do work well together and have a clear understanding of the direction that they are going, then they can pull in the same direction. The team needs to communicate and collaborate to ensure they have a common understanding of each piece of work, and also about the overall objective of where they are going. As you can see, this better aligned team is moving towards their goal of completing the feature.

Techniques to achieve this alignment again differ based on the context of the team, organisation and the domain of the problem-space. Generally, the team should have some sort of identity, and long term vision which should provide high level alignment. Ideally the team members should have input into these in order to have better buy-in to their direction. For medium term alignment, most Agile software development methodologies try to achieve this by clearly articulating a goal for the team over the next period, or through their prioritised backlogs. Short term alignment is achieved by clearly communicating User Stories. The Product-Engineering level will cover this in more detail.

Aligned team of engineers who learn:

Alignment is one piece of the puzzle, but by itself is not enough to have a truly high performing team. It is possible to have a group of individuals who are well aligned and working fairly independently towards a common goal, but miss a key element of learning from each other. In the same way that a high performing individual needs to have a willingness to learn, members of a high performing team must have a willingness to learn from each other.

In order to achieve this, team members need to have psychological safety. They feel safe to take risks and be vulnerable in front of each other. As a result they learn more effectively from each other, and also have productive conflict to reach better conclusions. See Project Aristotle and The Five Dysfunctions of a Team

Techniques for building psychological safety and trust differ greatly from person to person and hence from team to team (how’s that frustration going?). To build trust, some teams do regular coffees or lunches, others go out for team activities, others play games. Meaning that without understanding the individual team and its motivations, simply trying to play some Trust Games may not be particularly effective. For psychological safety, a culture needs to be created where failure is embraced as an opportunity to learn.

This high performing team ends up in a state of symmathesy (learning together). When teams are doing this, their individuals are not just being productive (and producing individual output), they are generative. The generativity of an individual is the difference between the team’s output with that person and without that person.

If the culture of the organisation or team encourages individual productivity then some individuals may be productive at the expense of the team. In fact it is possible for productive individuals to have a net negative effect on the team. For example if the individual hoards knowledge or changes the codebase more quickly than other people can build up their understanding of it.

Generative people push for the team to grow together. They may sacrifice their individual productivity and may appear to be slow themselves, but do so in a way which significantly advances the team. A trait of high-performing teams is this generativity. See this article for more information. With this generativity, the team produces more than the sum of its individual contributors (dare I say it, synergy).

Techniques for creating symmathesy revolve around encouraging and recognising certain behaviours and discouraging others. Environments where objectives or recognition focus on “Individual Contribution” or individual productivity will generally reduce symmathesy. Instead, set objectives and recognition around the team itself, and behaviours for that team such as collaboration and helping others. Shifting the focus to peer feedback rather than manager evaluation will help. Many of the Management 3.0 techniques can help.

Level 3: Product-Engineering Team

In some organisations, the engineers are an independent team, but in others, they are a sub-team that does not work in isolation but with another sub-team which includes product representatives (Product Manager, Product Owner, UX, etc). This Product-Engineering team is a full cross-functional team. And as we notice this team, their goal is no longer about producing code to deliver features, but customer value. Where do these features come from, and how do we know if they add value or not?

Some take the view that the role of the product team (sub-team) is to define which features to build and that the role of the engineers is to deliver those features; meaning that the responsibility is solely on the product team to determine what will add value. We’ll hover at this level and look at a few different examples of this and what actually works most effectively.

Really Bad Product Teams

Really Bad Product Teams (RBPTs) assume they know what features will add the most customer value. Instead of identifying problems or opportunities, and coming up with a solution to solve that problem, they define solutions in need of a problem. They define solutions without any thought for the possibility that they may be wrong, and that their solution may not solve any customer problem. They then scope a massive set of features that cannot be broken down, and the team delivers over a long period of time, thereby taking a long time to deliver something that completely misses the mark.

Bad Product Teams

Bad Product Teams (BPTs) still largely work in solutions rather than problems, but will first prototype their solution (mock) as a way to test and refine it. But the prototype is often done without properly uncovering the problems and opportunities and as a result can only provide a minor course correction. From this point they are basically the same as RBPTs, except that their direction is slightly less far away from customer value because they have refined their solution.

Bad Product Teams Doing Agile Badly

There is a variation on the BPTs, which is teams that deliver in an incremental or Agile way. Their method is similar to BPTs, but they break up the features into small increments instead of delivering them all at once. At first glance, this Agile delivery may appear to be a significant improvement. But the problem is, these teams do the incremental part of agile, but not the iterative. They deliver small increments, without revisiting what they have delivered previously to determine if they have actually added customer value. They never inspect and adapt, so they succeed in getting to the wrong solution, but with less risk than if they didn’t use Agile at all.

Good Product Teams

Good Product Teams (GPTs) understand that they get it wrong and that the solutions that they come up with may be incorrect. They clearly define a problem that they are trying to solve, or opportunity that they are trying to meet, and then test (feedback) and refine along the way. The teams deliver incrementally and iteratively and by constantly validating and refining, manage to reach their goal of delivering customer value.

From their well defined problem, they can produce measurable outcomes, and then each time they deliver, they can test if they have moved closer to the outcome they are trying to achieve.

Great Product-Engineering Teams

Truly great, or high performing, Product Teams, are not Product Teams at all, but rather part of full cross-functional teams including engineering. They work in a similar way to GPTs, except after defining the problem, instead of the product representatives coming up with the solution themselves, they involve their whole team (engineers, etc) in coming up with the solution. This not only results in a better solution, but also means the whole team has more buy-in and will get there faster (symmathesy at play again).

To grow Great Product-Engineering teams, the initial focus of the team needs to be around clearly defining the problem, before defining a solution. The key activity here is to ensure you have an adequate Product Discovery process. Frameworks that can help with this shift the the focus of development away from long lists of features and towards learning loops that define a problem and measurable outcomes around that problem; building a solution; and then measuring to see if that outcome is achieved. For example Hypothesis Driven Development, Mobius Loop or Lean Canvas.

Level 4: Product-Engineering Department

It is clear that at this level, we are now past the the scope of an individual high performing team. It is still valuable to cover this level and beyond, because as we will soon see, a high performing Product-Engineering team can be ground to a halt if the rest of the company is not aligned.

The Product-Engineering department (which in some organisations may contain multiple different departments) contains all of the cross-functional software development teams in the company. Usually, each team has ownership of a particular product. Sometimes there are multiple teams working together in a Tribe, which has a common product. But all of these teams or tribes are contributing to a set of products which make up the product suite of the company.

Often each team is allowed to be self-organising, and will define its own direction. This freedom can be a double edged sword, and without proper oversight and alignment each product may pull in a separate direction which does not move towards the overall goal of the company. Products may compete against each other, or teams may be dependent on other teams which result in teams producing sub-optimal solutions to work around the competition or dependency. In both cases, the result is a set of product teams which are not aligned and as a result, the company’s products may not hit the overall goal of delivering value, no matter how high performing the individual teams are.

Level 5: The Entire Company

This level contains everyone in the company. We can take in each different department and observe how they move relative to one another. There are many parallels between this level and the previous ones. It doesn’t matter how high performing each department is, if the departments are not working together towards the same objective, then they will struggle to achieve the company’s goal. For example, sales may be incentivised in a way that makes them sell product features which do not yet exist and were never planned to be on the Product-Engineering team’s radar, jeopardising their objectives and delivery. HR may have a hiring and approval process which takes months, which means that other departments cannot plan and pivot quickly. Similarly for finance who may have an annual budget cycle whereas engineering may require staff changes based on quarterly planning. If there is no alignment between departments, they are unlikely to be pulling towards the company’s goal of delivering value.

Company strategy is a complex topic that is well beyond the scope of this document, but Richard Rumelt, in his book Good Strategy/Bad Strategy explains that a good strategy should contain:

1. A diagnosis: of a key challenge, which identifies which aspects of the situation are critical.

2. A guiding policy: for dealing with the challenge. An overall approach to overcoming or dealing with the obstacles identified in the diagnosis.

3. Coherent actions: that carry out the guiding policy

Once a strategy has been well defined and well communicated, the culture needs to focus on aligning the business around that strategy by focusing on the company as a whole or Business Agility. For example Domains of Business Agility.

All Levels

As a final thought, there are some simple ideas (that can often be hard to do) to apply at all levels of the organisation to help grow high performing teams:

1. A clear and well communicated company strategy that provides meaningful direction to all levels of the business

2. Communication and collaboration at every level:
   We have seen the value that can occur when people act in a generative way by contributing more than just their individual output. This requires that every level needs to work together to learn effectively from each other and come up with better solutions. Different departments, different teams and different individuals all need to work together to achieve this at a company level.

3. Transparency:
   In addition to creating trust, transparency and open communication also allow departments, teams, or individuals to know and understand the objective of others which is needed to ensure that alignment is occurring at every level.

4. Empathy:
   Each department, team and individual needs to empathise with others to properly understand what they are trying to achieve and push the company towards its goal.

Conclusion

We have seem examples of what makes high performing and not-so-high performing teams at each level, as well as some techniques for growing high performing teams at those levels. As a reader you have probably been frustrated that most of the techniques start with “it depends” and end with “change your company culture to encourage learning, collaboration, understanding problems, measuring outcomes, and alignment”. Although you have not received a step-by-step guide for growing high performing teams, you should at least have a better understanding of what a high performing team and company look like, what makes them high performing, some ideas for how to grow your team, and an understanding that the entire company has a role to play in growing (or inhibiting the growth of) high performing software teams.

High performing software engineering teams: how to grow them and how to slow them was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.