Most engineering teams maintain runbooks. These helpful documents lay out the steps to execute manual maintenance tasks on the systems a team operates, helping to reduce mistakes and increase consistency. Runbooks are often most valuable in high-stress, emergency situations, giving engineers a path to follow in stabilizing the system, instead of improvising troubleshooting steps that might make the problem worse.

Many engineering teams also maintain a set of values to guide them in their work and their collaboration. These values are often established at the company level, but they can be created by departments or individual teams as well. But how often do you actually use those values in your day-to-day work? How frequently do others on your team use them?

If your team is like most, the answer is probably “not very often”. We often create sets of values because we feel we’re supposed to, but unless we understand the job they are meant to do, we won’t actually use them. People who join your team might see your values at onboarding, only to never think about them again. Even worse, you might not think about them either.

As Peter Drucker says, “Effective leadership…is not based on being clever; it is based primarily on being consistent.” A well-crafted set of values serves as a runbook for leadership consistency. Just as a runbook makes sure we’re consistent in responding to certain kinds of problems in our systems, strong values help us do the same when confronting difficult interpersonal situations.

Let’s look at a couple of scenarios we’ve all likely faced as leaders and think through how strong values could help guide us through them.

“I accidentally dropped the `users` table in our production database!”

If you’re making up your response to this situation on the fly, it’s really easy to blame the individual engineer who did it. You might be tempted to say something like: 

“Why did you not triple-check your `drop table` command before you ran it? You know we’re fighting hard to renew our biggest customer, and now we have hours of downtime to explain to them! Why weren’t you more careful?”

But let’s say one of your team values includes having a “growth mindset”. If you let your values guide you like a runbook in this situation, you’d likely take a deep breath and say something like:

“I know you didn’t mean to drop that table. It’s OK, we’ll get through it. But I would like you to jot down what happened while it’s still fresh in your mind so we can learn from it and keep someone else from running into the same thing.”

If you’re serious about having a growth mindset, it’s really all you can say, and everyone on the team benefits from your response. Your consistency shows them that “growth mindset” actually means something in your organization. Additionally, having this engineer’s back when you’re managing the situation up to your leadership, shifting the onus from the individual to the system, shows everyone on the team that you’ll have their back too when they make a mistake. If you do this consistently, the so-often aspirational value of a growth mindset becomes real, creating a sense of safety and trust that actually accelerates your team’s growth.

“No real software engineer would write it this way.”

In this situation, this is not the first time you’ve seen your lead engineer write something like this in a code review, and you’ve talked to them about it twice before. What do you do? It’s tempting to keep giving warnings and chances to this person because the thought of losing a key member’s contributions is scary. 

But let’s say that “safety” is one of your team’s core values. This engineer is clearly making the working environment less safe for others by responding to perceived code issues with direct personal attacks. There are a couple of things you need to do if you’re using the value of “safety” as your runbook in this situation.

First, you need to make sure you’ve provided for the lead engineer’s safety by giving them clear and direct feedback. If you’ve only hinted at the problem, there’s a chance they haven’t fully understood. The ideal outcome here is restoration, with them repairing their relationships with the team and building back trust; they can only do that if you’ve been honest with them. The Center for Creative Leadership’s “Situation, Behavior, Impact” framework can be very helpful here.

Second, if you’re sure you’ve gotten the message across and the problem persists, then your “safety” runbook requires that you shift your focus to the safety of the rest of the team. This could mean putting the lead engineer on a performance improvement plan with termination as a direct consequence. As an alternative, if you’ve already established the severity of the situation and the circumstances have not changed, it could mean terminating their employment immediately. 

The important thing to remember is that you must listen to your “safety” runbook when it tells you that there’s no possible contribution one individual could make that justifies their making the rest of the team feel unsafe. Decisions like this are never easy, but your values can hold you accountable to do the right thing.

Establishing your values as a leader

If you’re going to use values as a runbook to help you be more consistent as a leader, you first need a set of solid values to work from that you really believe in. These may not be the same as your company’s values, and that’s OK as long as they’re not in conflict. You can easily create a set of “team principles” that work in tandem with your company’s values with a more direct impact on how you and your team operate.

Creating a set of values is a big topic that I can’t do justice to here, but as Patrick Lencioni wrote in Harvard Business Review, you have to make your values mean something. It’s wise to involve your whole team in this process. After all, one of the goals of consistently modeling your values is encouraging your team to lean into them as well, and it’s much easier to do this if you have their buy-in from the start.

You also shouldn’t feel like the values you establish need to be permanent. Teams, like systems, change over time, and values sometimes need updating just like system runbooks. A value of “speed” that makes sense as you’re trying to get an early product out the door might need to change over time to “stability” as customers start to depend on your product. A value like “growth mindset” or “safety” might be more durable. Ultimately, your values will likely be a mix of both.

Consistency is key

The value of a runbook lies not in its creation, but in its use. The same is true of values. If you build a habit of reaching for your values in difficult situations, you’ll increase the consistency of your leadership and you’ll teach your team to do the same. The trust built by your consistency will go a very long way in helping everyone achieve their best work. 

It’s challenging to build and follow a meaningful set of values, but using them like a runbook to guide your actions as a leader can help, and the results are absolutely worth it.