Early in our careers as engineers, we’re told to invest in technical skills. We learn languages, implement patterns and frameworks, architect across the stack, and learn how to scale. Getting into the weeds of the work is what gets you credibility and clout with your teammates.

But to make more successful technical calls and advance careers, engineers actually need to develop better strategic decision-making skills — not just technical execution skills. In fact, an over-reliance on technical execution skills early in a career leads to untapped impact and stalled growth opportunities down the road. We consider this getting stuck in a downward strategy spiral, which we discuss in detail here.

Instead, the number one thing engineers can do today to become strategic leaders is to make more deliberate and effective decisions. In this post, we’ll share:

• The dreaded debate: How engineers stall growth

• How to move past this wall with the “watershed” framework

• The impact of investing in decision-making skills

The dreaded debate: How engineers stall growth

We’ve all experienced it: the loathed midnight wakeup call to deal with critical, but often unnecessary, escalations. In the moment, engineers aim for a quick fix to stop the bleeding. But in the morning, they’re eager to find more sustainable solutions with their team.

These technical discussions often start out benign. A few engineers get on a call and share their recommended solutions. One person argues their solution is ideal because it’s easy to build and doesn’t introduce more risk. Another counters that they prefer to use a new framework the engineering team has been trying to adopt for this exact use case.

Tensions mount in these moments. Conversations turn quickly from solution generation to questioning a teammate’s character and skills. The practical can become incredibly personal.

That’s because engineers are often only trained to think about the execution of technical solutions. Rather than focusing on what and why (what’s the goal, why is this important), they instead myopically focus on how (which solution is better and how can we implement it). Without clarity on what and why, people will naturally start optimizing for things in different directions. The dreaded debate has begun.

An overreliance on solutioning 

It’s natural for engineers to want to move towards solutions. Many of us are trained to identify problems and incentivized to take ownership and fix them. But when engineers are overly solutions-oriented, it’s all too easy to end up in a fiery debate instead of a meaningful discussion about a real core problem.

Often, what’s presented as the problem (such as getting paged in the middle of the night) is far from the true root of the issue. Maybe the problem is about…

• a lack of investment in quality reporting

• how hard it is to get buy-in to start new initiatives

• stalled innovation happening within the company

• existing tensions about unsustainable workloads on the engineering team

• getting paged in the middle of the night

By fast-tracking to ways to resolve the issue, we skip over the two most critical decision-making steps that will impact everything else downstream: articulating the goal and determining the criteria for how a decision should be made. As a result…

• Each person leads with their beliefs and emotions, and hasty solution-grabbing tends to amplify the voice of those who already have social capital. These situations often benefit the loudest voice in the room, or teammates with other vectors of social power: tenure, race, age, personality, stereotype biases, social relationships with decision-makers, gender, and more. 

• The debate turns personal, ineffective, and overly constrained as time gets wasted spinning in circles and debating ideal solutions that lack real-world context. Seemingly innocuous, quick decisions compound as a company grows, making it hard for future teammates and leaders to reason about why things are the way they are. Soon, people get frustrated by the lack of progress, or start doubting the skills of others on their team.

• Careers stall as the work gets unpleasant. We get bogged down working on teams that can’t effectively ship product because they’re ineffective and slow. Careers suffer and work ends up being highly stressful and unpleasant.

Lack of alignment affects all stakeholders

Ultimately, when teams overly focus on the how, it’s common that people move in different directions and nothing progresses forward. People end up exploring different options without a grounded reality on what matters most. This then leaves individuals and teams unable to effectively execute. And this lack of execution ability then makes it hard to have growing levels of impact.

Instead, develop decision-making skills by water-shedding

Water-shedding is a tool for clarifying your thinking around each step in a decision-making process. First let’s understand watersheds, which are broadly made of three sections.

The upper section is responsible for storing the bulk of the weight of the water to prevent extreme flooding.

1. The upper section is responsible for storing the bulk of the weight of the water to prevent extreme flooding.

2. The middle section is responsible for thoughtfully slowing down the flow of water and removing its pollutants to ensure the water downstream is safe.

3. The lower section provides vast opportunities for all the awesome stuff to converge — plant, animal, and human life.

Watersheds also have an immutable gravity problem — everything that happens downstream is connected to what happens upstream. We can think of decisions in the same way.

The roots (aka upper section) of any decision hold the most weight. Everything is built off of their foundation, so you need to be methodical and thoughtful at this stage. This stage includes:

• Clearly articulating the problem and goal. What pain are you trying to solve? What gain are you trying to achieve?

• Establishing guiding principles and a shared reality about what’s important

• Developing and prioritizing criteria to clarify how you’ll go about making the decision

The tributaries (aka middle section) of decision-making are about generating a wide solution set and then evaluating them against your decision criteria. This stage includes:

• Generating solutions that can realistically achieve the goal, often with varying levels of complexity

• Evaluating solutions by using the criteria you’ve establishing in the roots stage to move towards convergence

• Mitigating risks by understanding the tradeoffs of your chosen solution and making plans

The lakes (aka lower section) are where the decision is actually made, shared effectively with others and ideally documented for alignment and posterity. This stage includes:

• Making (and documenting) the decision to “show your work”

• Communicating effectively with stakeholders to make build strategic and execution alignment

• Realigning as necessary as you learn new things

How to watershed

There are five primary principles for success with this tool.

1. Know your location in the watershed

2. Articulate and build alignment around your criteria

3. Diverge before you converge

4. Communicate, communicate, communicate

5. Diagnose when things are off-track and adjust

Know where you’re at in the watershed

A meta skill in decision-making is to know where you’re at in the decision-making process. This is tough because it’s very easy to conflate problems, goals, decisions, and solutions.

Getting pinged in the middle of the night may be the presenting problem but it’s hard to get to a clear decision about what solution to pursue without first effectively framing a clear goal. Maybe the actual questions you should be asking are…

• How might we reduce the number of false positive errors being reported?

• How can we stop escalations in the middle of the night?

• What could we do to shift our investment away from this old technology?

• How can we reduce the time it takes to get buy-in on new initiatives?

Framing the goal will shape the solutions you explore, which is why it’s helpful to know where you are in the watershed process.

Crisply articulate and build alignment around your decision-making criteria

Treat decision-making like hiring. You need criteria to evaluate a candidate’s frontend, backend, leadership, collaboration, and business skills to avoid biases of just liking or disliking the person. This is the part most people skip over, and the single step that will make you a more effective and less argumentative decision-maker.

Every company has faced the consequences of making a poor technical decision. That’s why setting your criteria is so important.

While there’s no single list of criteria that apply to all decisions, common ones include:

• Time: What are the constraints for how long we can spend building? Any hard deadlines that have to be met?

• Resources: Are there money or people constraints that we need to consider?

• Stakeholder impact: How will this decision change or impact the other individuals on my team? In my role? In other departments? Customers?

• Business impact: How will this decision appeal to or prevent customers from wanting to [pay for, use, recommend] this product?

• Performance: How will this affect the speed and feature surface area of the product?

• Team development: What will we learn from making this decision?

• Maintainability: How complex is the solution? How self-evident is the logic that will be encoded?

• Observability: Does the solution lend its way to auditing, behavioral logging, and driving the insights needed to inform future product development?

• Reversibility: Can we roll back the solution if needed?

• Opportunity unlock: How will this decision help make future decisions easier?

There are many tools out there to help you develop your thinking around criteria and how they impact trade-offs, including our Trade-Offs Worksheet template. The important piece is to get explicit: Identify the criteria category that best represents your goal, note and elevate any fixed criteria (constraints), and ensure the most affected stakeholders understand and can get behind the criteria you’ll use to make the decision.

Sarah Mayberry, Director of Quality at Level and ex-Sr. QA Manager at inContact uses a simple strategy to help pull out the most essential elements on her team:

My favorite way to help engineering and product agree on the most important criteria is to use the following phrase: “If we had to deploy this at the end of the sprint, what is the list of acceptance criteria we would need to make this valuable to the customer?” I find shrinking the time frame helps both parties analyze what is essential, and different time frames (2 weeks, 4 weeks, 2 months) will expose different solutions.

Thoughtfully diverge before you converge 

In our Technical Strategy program, we cover a broad range of tools for how to expand your solution development before moving forward.

We find that thought provoking questions are often the easiest place to start to generate ideas:

• Do we have to do anything right now, or can we accept the problem as is?

• Is this a commonly encountered problem?

• Are the only solutions technical?

• Are there single leverage point solutions across the stack?

• Are there additional product and business needs that necessitate a more ambitious or complex solution?

When it comes time to evaluate:

• Question your riskiest hypotheses

• Use the criteria you developed to evaluate solutions

• Identify the big risks and how you’ll mitigate them

• Know when it’s time to decide

Remember, the goal here is to separate problem articulation (roots), solution exploration (tributaries), and decision convergence (lakes).

Communicate, communicate, communicate

A decision is only as good as its ability to be adopted and executed effectively. To get there, you’ll need to align folks around how you came up with the decision and how you’ll execute against it.

For example, during Marjori Pomarole’s time on WhatsApp and Facebook’s security team, she was responsible for leading a big migration off of vanilla PHP to the new language Hack, a typesafe dialect of PHP that would ease security holes. 

The migration would impact hundreds of engineers, so Marjori’s team was deliberate about frequently aligning teams and gathering feedback.

Overcommunication saves time and saves pain. In one case, a 30-minute meeting ended saving us months of work by doing a quick gut check on some unnecessary endpoints. We tried to communicate as much as possible, but we incurred 5 or 6 side events that were big. Some teams were unresponsive or slow to respond when we told them an upstream or related endpoint to change. But we should have given more time for teams to reply back on those endpoints that were critical.

– Marjori Pomarole, co-founder of Maystra

Like with solution development, there are many different tools you can use to bring other folks along and ensure that you’re aligned. Our Stakeholder Influence Map is a good place to start to identify who needs to be involved and how they may be impacted by your decision-making. 

Diagnose when you’re off track and readjust To become adept at decision-making, notice when you’re entering debate territory, diagnose what’s happening in real-time, and learn to remediate with a different path.

Let’s look at a few common signals that you might be off track.

Roots

Word Salad

If you can’t identify the real goal in one sentence, try again. Then re-evaluate if your well-defined goal is actually real, urgent, and important.

Clashing Songbooks

Does one person want to go to France, but the other wants to go to Japan? Notice when people debate at the level of solutions, not criteria, and bring them back to the real roots goal.

Locking Horns

If you can’t agree upon the most important criteria, lean on the decider to help clarify them. If there’s no clear decider, establish one. Ask for feedback on the decision-making criteria rather than on your favorite solution

Ludmila Pontremolez, an ex-Technical Lead at Square, is now CTO and co-founder of Zippi, which offers financial solutions to help informal workers in Brazil manage their expenses and avoid accumulating debt. In the early days of building, she describes how engineers were really excited about ensuring their architecture could scale effectively.

When the microservices hype started, the engineering team was super pumped about splitting our monolith into microservices. Medium is filled with articles focusing on the beauty of having a microservice architecture, and how it solves all your problems. It was early days at Zippi, and with a small engineering team, I couldn’t justify refactoring our system with artificial – and relatively arbitrary – boundaries to solve problems we didn’t have, while increasing the baseline complexity of our system.

– Ludmila Pontremolez, CTO and Co-founder of Zippi, Ex-Technical Lead at Square

Tributaries

Making Haste

No decision is perfect, and each solution has risks — but rushing to pick a solution without ensuring it passes muster won’t do you any favors. Do a quick pre-mortem: What does your decision imply? What may fail? What risks need acknowledgment?

Binary Traps

Explore at least 3 viable options so you don’t get stuck arguing about only two options.

Chasing Rainbows

Careful of getting overly excited about a solution before tying it back to the goal. Let patience and intellectual honesty guide you. 

Lakes

Lost Plots

People lost sign of the goal, let alone why one solution was picked over others. Document it. Future you will thank the past you.

Too Many Decision-Makers

If you’ve called a large “decision” meeting with tons of people who have very little context on the thinking, pause right there. Focus on who needs to be involved and who doesn’t, and only call the meeting when you’ve got a recommended strategy (or when you’re checking for alignment at the roots or tributaries level).

Stalling for Time

If you won’t make a decision out of fear of picking the wrong option, know that all decisions have flaws. You can plan for those, but don’t fear choosing a well-thought-through option when you have enough information.

The impact of investing in decision-making skills

The foundational elements of decision-making are similar for all engineering roles, from junior IC to seasoned VP. Ultimately, water-shedding is a tool that will compound in benefits as you develop it across your career. As your scope of ownership increases, so too will the lens of possible criteria you may need to consider.

As an individual contributor, you may face decisions about which technology to use, how to scope or sequence a feature for development, or how to ensure x-platform functionality.

As an engineering manager or lead, you may face decisions about whether to fund a project, how to make your team more efficient, whether to extend an offer to a candidate for hire, or how your team’s work impacts another team’s ability to execute against their goals.

As a director or VP, you may face decisions around whether to do a major product overhaul, whether or not to build or buy a new operational skill, or whether a complex redesign ought to include a rewrite of an old framework that’s becoming brittle.

Example: Building something from scratch

Let’s see it all come together with a real example. 

Zippi’s investments in the early days were big foundational bets to find market fit. One of the biggest decisions Ludmila had to drive was how to architect the core credit card operation to enable flexibility around billing cycles.

In advance of exploring any solutions, she and her team agreed on the most important criteria for how to build the architecture of the product.

• Business impact: The credit card operation was the core value prop. Any solution needed to establish a unique value asset that was difficult for others to replicate.

• Opportunity unlocking: Any solution must make it easier to build customizable features on top of. Architecture overly reliant on third parties would be disqualified if it limited execution against the immediate future vision.

• Time to develop: The Zippi team didn’t want to drag the project over a long period or force quick, inefficient timelines.. They determined the solution needed to happen in six months with four engineers.

• Reversibility: Any investment in architecture needed to be de-risked enough to understand how to reverse the decision.

They then explored several solutions that would fit the bill, such as:

1. Build everything from scratch: connect directly with the network and build all the transaction authorization and billing capabilities

2. Connect with a processor that already does authorization and billing, and have them create a weekly billing cycle

3. Connect with the processor, have them send the authorizations real-time to us, and build the billing in-house to enable any degree of customization

We found a processor that was willing to do #3, but the idea of having a system that authorizes real-time was scary to me at that stage. So far in my career, I had never dealt with systems that need to be up 24/7 answering requests in less than 200 ms. I thought about what it meant in terms of needing robust monitoring systems, and on-call engineers reachable at any time of day and day of year.

However scary, option #3 would allow us to build an unique engineering asset, and a strategic moat around our product, so we went ahead. 12 months in the operation, and the system is super stable and hardly gives us any head-aches.

– Ludmila Pontremolez

By generating multiple solutions and recognizing the risks and tradeoffs with each, her team was able to thoughtfully plan in advance of the decision rather than deal with big fires only as they showed up.

This flexibility in the billing cycles, and the ability to customize beyond the initial weekly concept, turned to be a key asset in our company: in a world with more independent workers, more people are living outside of the monthly salary paradigm, so having the freedom to customize billing cycles to match individuals income cadences made our offer even more powerful than initially envisioned. If we had chosen to have a third-party build the weekly system for us, it’s unlikely that they would have been able to quickly accommodate any further iterations.

– Ludmila Pontremolez

What you get with better decision-making

Thoughtful and thorough decision-making saves you time down the road by investing a little extra time up front. More importantly, your impact as an engineer will be a direct reflection of the quality and scope of your decisions.

[Create] a culture where senior people understand the weight of their words and avoid being prescriptive. Instead, help your teammates develop frameworks from decision-making at every opportunity. This may sound silly, but assertive decision-making is a muscle that needs to be stimulated at every opportunity from day 1 in anyone’s career. “What other options have you considered? What risks do you see associated with each of them?”

– Ludmila Pontremolez

Ultimately, water-shedding helps you develop this muscle by encouraging:

• Rigorous, defensible thinking. Often, slowing down to speed up is the most effective way to think through problems.

• Clarity and confidence. This process is for you — not your boss, teammate, or anyone else. It develops your own sense of confidence in your thinking.

• Empathy for others. Knowing who is impacted by your decisions will lead to fewer enemies and more allies. Moving from vigorous debate to meaningful discussion makes technical conversations feel less personal and more collaborative.

• Fewer blow ups and surprises. No decision is without its flaws, but thinking through real implications from a systems-level reduces the chances of late-stage blowups, false tradeoffs, and surprised coworkers whose workflows could be broken by your decision-making.

Curious about more? Our Technical Strategy and Scaling Product Delivery programs provide frameworks and templates to help solve some of the key challenges that engineers face in growing organizations. Apply now to become a Reforge member for our Spring 2022 cohorts.