Berlin

November 4 & 5, 2024

New York

September 4 & 5, 2024

How to drive decisions as an engineering leader

Six steps for driving important decisions forward
February 07, 2022

As engineering leaders, one of the most important parts of our jobs is driving decisions forward.

We have to be stewards of progress and clarity in our organizations. But the best path isn’t always clear cut, and getting our teams aligned with a decision can be a challenge.

Sometimes, the decision is ours to make. Other times, someone else suggests or makes the decision and we’re responsible for moving it forward and driving positive change.

Regardless, in a healthy organization, leaders should always be focused on two things: the outcomes of a decision, rather than how it should be executed; and aligning people around why a decision has been made.

This post unpacks a framework for driving important decisions, from understanding the impact of a certain direction and soliciting feedback to reducing uncertainty when a final direction is set.

1. Gather information

‘If knowledge is power, knowing what we don’t know is wisdom.’ 
Adam Grant, Think Again

At this stage, we should already be clear about what we’re solving for and why we think a certain decision should be made. We can lay out the beginnings of a plan that isn’t fully formed yet. But before we embark on moving a decision forward, we have to validate our assumptions.

The higher up we go in management, the further away we are from the metal, and our engineers have valuable perspectives that we may not see. This is why we need to solicit their feedback and adjust when we hear new information. We should do more than tell people what to do: we should seek to understand.

It can be tempting to only listen to the most senior engineers in this stage. However, less experienced or newer members of our team may note issues with the current system that the most senior folks can’t see because they’re either used to the status quo or have a curse of knowledge.

2. Talk with stakeholders

There’s a particular point in a decision lifecycle when we need to have one-on-ones with individuals who will either partner with us to make the call (other leaders) or drive the outcomes (our engineers).

These meetings are very important. They give stakeholders a safe space to explore the concept without other people around, reducing the mental energy it takes to speak the truth. The more people in the room, the more personal consequence there is in thinking through many sides of any idea at once. When done well, one-on-ones are valuable because two people can truly connect and generate ideas for outcomes.

For these talks to go well, we have to build trust. It’s vital that we all feel confident enough in our relationships to speak the truth. We should pay close attention to when folks are particularly quiet, ask questions, and give them space to talk through ideas. Reassure people that it’s okay to think through something, even if it’s not the final answer. And let them know it’s fine to address risks – in fact, that’s important.

Even if we’re not aligned at the end of the discussion, we’ll still have a better sense of the general shape of the idea and where the risks may lie.

3. Evaluate the idea

Now it’s time to assess the idea as a group. While evaluating a decision, it’s important to encourage everyone to divorce their own sense of selves from the concept. If we tie our self-worth too closely to an idea – if it’s ‘our idea’ – our self-perception is locked together with it. It makes it tough to challenge the concept. However, if it’s an idea, the end goal is divorced from ego, and the decision is made based on the best possible outcome.

While it may feel more comfortable to stick to what we know and surround ourselves with folks who support our conclusions, there is more strength in seeking out alternative perspectives. Strong leaders know that hearing other points of view is critical to a healthy organization. When people tell you there is something to reconsider, they are showing strength in the face of power to give you critical information about risks and the systems you run. My advice is to take this seriously, thank them, and consider what they’re representing.

I should caveat here that people who make personal attacks in these types of discussions and devalue others’ perspectives are not ‘embracing another point of view’. No one should have to endure disrespect in order to think things through. Whenever possible, be clear that you’re seeking alternative points of view on the idea, not on the human being.

4. Document the idea

At this point, we have data, we have our hypothesis on the correct direction to embark on, and we know why we’re doing it. We’ve heard other folks’ points of view and adjusted and incorporated that into our plan. Now it’s time to write it all down.

The purpose of documentation in this case is to capture everything we have in one place. Not only does the act of writing solidify the concept, but it allows for widespread communication and soliciting feedback more broadly.

We should also open the documents up for commenting and keep ourselves open to edits, as sharing more broadly may return some good information that may make us reconsider aspects of our course.

It can be helpful to have a decision-making model, such as RACI or DACI, which clearly captures the roles and responsibilities of the people working on the project so that everyone is clear on who is ultimately accountable.

If there’s a lot of feedback, we may want to create topical meetings with a smaller audience (think 8 not 20) to talk through some of the nuances of the decision. Anything that’s unclear to many should be captured in the doc to provide clarity in case it comes up in the future.

(For more on how to write great documents, check out my recent post.)

5. Set your final direction

It’s important to hear multiple perspectives, but it’s also important to timebox this activity so that decisions don’t drag forever. You’ve heard the engineering saying ‘it depends’, and it’s true. There will never be an approach without tradeoffs, and it’s possible to go back and forth about a decision forever.

This is the point where we make the final call. The person most responsible for the decision at the leadership level should make the decision and provide clarity for everyone who needs it: drivers, stakeholders, and anyone who may be affected. This final decision should also show up on documents, making it clear that it’s a final state and no longer in draft form.

There may be people who didn’t want to go in this direction. However, it’s crucial to explain that it’s time to move the project forward and ‘disagree and commit’. If we don’t do this, we risk creating an atmosphere where there’s a lack of clarity and accountability, which is not only insidious but ultimately very harmful.

6. Formulate your plan

From here, everyone should know the direction and it becomes easier to formulate a plan. For the plan itself, as leaders we should be more focused on how it will drive outcomes than how it should be executed.

As a manager, it’s tempting to dive in when things get complicated. We know how to write code and we have a career’s worth of background on some of the topics we manage. As much as we may want to jump in (I want to all the time), we have to trust our teams and especially the tech leads to deliver. If they are unclear on process or execution strategies, that’s when it’s appropriate to come back in and guide at the fidelity that helps them most.

But ultimately, at this stage, we should be clear as to what we’re doing and what the next steps are. Remember that in order to get here, we have to align our teams with why this direction is important and discuss together what outcome we share in this vision. The ‘why’ is the most important part.

Sarah Drasner