Leading Engineering Teams Through Strategic Uncertainty

There is a specific kind of silence that settles over an engineering team when the strategy shifts and nobody explains why. It is not the productive silence of deep work. It is the silence of people who have stopped investing emotionally in the work in front of them because they suspect it might not matter next week.

If you have led an engineering team through a product pivot, a reorg, or a sudden change in company direction, you know this silence. You also know it is more destructive than almost anything else that can happen to a team. Bad strategy gives people something to push against. Uncertainty gives them nothing to hold on to.

This post is about what to do when you are the person standing between a shifting strategy and a team that needs to keep building. Not the theory. The practice.

Bad strategy is frustrating, but it is concrete. Engineers can see the problems. They can argue about them in retros and architecture reviews. They can build workarounds. They can even find motivation in proving the strategy wrong while still shipping something useful.

Uncertainty is different. It erodes motivation in a way that bad strategy simply does not. Research in organisational psychology has consistently shown that ambiguity about the purpose of work reduces intrinsic motivation more severely than being given the wrong goal entirely.[1] The brain can work with a bad map. It struggles to work with no map at all.

The practical effect is predictable. Decision-making slows down because nobody wants to commit to a path that might get reversed. Code reviews become half-hearted because reviewers are not sure the feature will survive the next planning cycle. Engineers start asking "is this even going to ship?" in standups, and once that question enters the room, it does not leave quietly.

The most damaging part is invisible. Your best engineers, the ones with options, start quietly updating their CVs. Not because the pivot itself is a problem, but because the way it is being handled tells them something about how the organisation works. If leadership cannot communicate a clear direction during a strategy shift, what else are they getting wrong?

There is a temptation, when things are shifting, to wait until you have the full picture before communicating anything. It feels responsible. It is actually one of the worst things you can do.

Your team does not need you to have all the answers. They need you to be honest about what you know, what you do not know, and what you are doing to close the gap. Google's Project Aristotle, which studied hundreds of teams to understand what makes them effective, found that the single strongest predictor of team performance was not the quality of the strategy but whether team members felt safe enough to take risks and ask questions.[2] During a pivot, psychological safety is not a nice-to-have. It is the infrastructure that keeps the team functioning.

Your job is to create a frame that holds even when the picture inside it keeps changing. That means being explicit about three things:

What has not changed. The company mission, the team's core purpose, the technical standards you hold yourselves to. Anchoring people to what is stable reduces the feeling of freefall.

What is genuinely uncertain. Name it. "We do not know yet whether the product direction will include feature X" is infinitely better than silence, because silence gets filled with speculation, and speculation is almost always worse than reality.

What happens next. Not the six-month roadmap. The next two weeks. People can handle not knowing where the ship is going if they know what they are supposed to do today.

The way you deliver the message matters as much as the message itself. Get it wrong and you lose weeks of productivity to anxiety and resentment. Get it right and you might actually increase trust.

Tell them before the rumour mill does. The moment you know a pivot is coming, get in front of your team. You do not need to have every detail. You need to be the first source of information, not the last. Teams can forgive incomplete information. They struggle to forgive finding out from Slack gossip what their own manager knew for two weeks.

Acknowledge the cost. Engineers are not naive. They know that the feature they spent three months building might get shelved. Pretending that is fine insults their intelligence. Instead, name it directly: "I know some of the work you have done may not ship in its current form. That is genuinely frustrating, and I want you to know I see the quality of what you built." Validation is not weakness. It is the thing that makes people willing to rebuild.

Separate the decision from the execution. "The company has decided to shift focus" is a fact. "Here is how we are going to handle the transition as a team" is leadership. Do both. The first without the second creates panic. The second without the first creates confusion.

Be available, not performative. After a big direction change, do not retreat to your office and send a Slack message. Be physically or virtually present. Answer questions. If you do not know the answer, say so and commit to finding out. McKinsey's research on organisational change found that organisations where leaders were visibly present and communicative during transitions saw significantly higher adoption of new priorities and lower attrition.[3]

Theory is useful. But when you are in the middle of it, you need specific things to change in how you operate, starting now.

Shorten your planning horizons. If you normally plan in quarterly cycles, switch to two-week or four-week cycles during periods of high uncertainty. Shorter cycles reduce the cost of being wrong. They also give the team regular moments of completion, which is critical for morale when the longer-term picture is unclear. This is not about abandoning strategy. It is about matching your planning cadence to your confidence level.

Increase communication frequency. This sounds obvious but most leaders do the opposite during uncertainty. They go quiet because they do not have anything definitive to share. That quiet is corrosive. Even if the update is "nothing has changed since last week," say that. A brief weekly standup or async update that covers what you know, what is still open, and what the team should focus on this week takes ten minutes and prevents hours of unproductive speculation.

Protect the team from noise. During a pivot, everyone in the organisation has opinions about what should happen next. Sales wants one thing. Product wants another. The CEO had a great idea on a plane. Your job is to act as a filter. Not every signal from the organisation deserves your team's attention. Be deliberate about what you pass through and what you absorb so the team can focus on the work that is clearly in scope right now.

Create explicit "safe to build" zones. Even in the most uncertain environments, some work is clearly valuable regardless of which direction the strategy takes. Infrastructure improvements, test coverage, developer experience, documentation. Identify this work and frame it as the team's anchor. It keeps delivery moving and gives engineers something concrete to commit to when the doubt starts settling in.

Hold one-to-ones more frequently, not less. During uncertainty, your one-to-ones become your most important leadership tool. This is where you hear the real concerns, not the polished ones from the team standup. Ask specifically: "What is worrying you about the direction right now?" and "What would help you feel more confident about the work you are doing this week?" These questions surface problems early, before they become resignations.[4]

This is the hardest part. When the goalposts are moving, every engineer's instinct is to slow down and wait for clarity. That instinct is rational. Your job is to give them a reason to keep moving anyway.

Redefine "done" for the current context. If the six-month outcome is unclear, define "done" as the smallest useful increment. What is the thing we can build this sprint that would be valuable regardless of which direction we go? That question almost always has an answer, and the answer is almost always more useful than waiting.

Celebrate learning, not just shipping. During uncertainty, some of the most valuable work a team does is not building product. It is running experiments, testing assumptions, and generating the information that will eventually make the strategy clearer. Make that work visible. Call it out in team meetings. Treat a well-designed experiment that confirms the right direction as a win, even if no code shipped.

Keep technical standards high. There is a real temptation during pivots to cut corners on code quality, testing, and architecture because "we might throw this away anyway." Resist it. Sloppy code during uncertainty creates technical debt that compounds regardless of which direction you go. And asking your team to write throwaway code tells them, implicitly, that the work they are doing does not matter. It is the fastest way to accelerate the disengagement you are trying to prevent.

Make progress visible. When the strategic picture is murky, concrete visible progress becomes the team's anchor. Use demos, internal showcases, or a simple weekly "here is what we shipped" post. The point is not to prove productivity to management. It is to show the team, and yourself, that forward motion is happening even when everything else feels uncertain.

If you are reading this because your team is in the middle of a strategy shift right now, here is what to do this week.

First, have an honest conversation with your team. Tell them what you know, what you do not know, and what you are doing to get clarity. Do not wait until you have the full picture. Waiting is the problem.

Second, identify the work that is clearly valuable regardless of direction. Put it at the top of the sprint. Give the team something they can commit to without reservation.

Third, shorten your planning horizon. If you are planning in quarters, plan in weeks until the uncertainty resolves. Review and adjust at the end of each cycle. This is not a sign of disorganisation. It is leadership that matches reality.

The companies that come out of strategic uncertainty stronger are not the ones that had the best strategy. They are the ones whose leaders kept the team connected, productive, and trusting through the transition. That is not about having answers. It is about earning the right to say "I do not have all the answers, but I will not leave you guessing."

A note from fusecup

At fusecup, we work with engineering leaders who are building through change, not waiting for it to pass. If your team is navigating a pivot, a reorg, or a shift in direction and you want someone to think it through with, we are always happy to have a conversation. No agenda, no pitch. Just honest thinking about what might work for your specific situation.

1. Locke, E. A. & Latham, G. P. (2002). Building a Practically Useful Theory of Goal Setting and Task Motivation. American Psychologist. Research consistently shows that clear goals, even imperfect ones, produce higher motivation and performance than ambiguous or absent goals.
2. Google re:Work. Guide: Understand team effectiveness (Project Aristotle). rework.withgoogle.com
3. McKinsey & Company. How to beat the transformation odds (2015). Research on organisational change management showing that visible, communicative leadership during transitions correlates with higher adoption rates and lower attrition. mckinsey.com
4. Pluralsight / Baylor University. Effective 1:1 Meetings with Your Engineering Team. Research shows employees with regular one-to-ones are nearly three times as likely to be engaged. pluralsight.com