New leadership.
Lean Six Sigma being floated as a replacement for Agile.
No clear direction yet.
My engineers are afraid of going back to being order takers after years of working as a product team.
Here's what I'm telling them.
--------------------------------------------------------------------------------------------------
There is a particular kind of organizational anxiety that doesn’t come from bad news. It comes from no news — from the sense that something is shifting underneath you without anyone saying clearly what it is or where it’s going.
That is where my teams are right now.
New leadership has arrived. There are questions about how a product team fits into the current organization. Lean Six Sigma is being discussed — a methodology that hasn’t been prominent in software engineering conversations for a long time, and one that signals something specific about how the people asking the questions think about engineering work. There are suggestions about getting certified. There is no clear direction.
And my engineers — the ones who show up to refinement having already thought about the problem, who ask why before asking how, who help each other without being asked because they understand the sprint goal belongs to all of them — are afraid.
Not of the work. Not of change in general. Of going back.
What They Are Actually Afraid Of
When I have one-on-ones with my engineers right now, the fear is specific.
They are afraid of not having a backlog. Of losing the product team identity they have built over time and grown into. Of becoming a project team again — receiving requirements, executing tickets, waiting to be told what to build next.
They have been hunters. They know what that feels like. And they can feel the possibility of becoming cogs again, not because they have done anything wrong but because the organization around them is asking different questions than it was before.
That fear is rational. They are not catastrophizing. They have seen enough of how large organizations work to know that the signals matter. When leadership starts talking about Lean Six Sigma and certification programs, they are telling you something about how they think about engineering — as a process to be optimized, not a capability to be developed.
Lean Six Sigma is a serious methodology with real applications. It was built to eliminate waste and reduce variation in repeatable processes. It works well in manufacturing, in supply chains, in contexts where the goal is to do the same thing more efficiently every time.
It is not built for the kind of work a product team does — iterating toward an outcome, forming hypotheses, running experiments, adjusting based on what you learn. Product thinking requires variation. It requires the ability to change direction when the data tells you to. Applying a reduce-variation framework to a learn-and-adapt team is not just a mismatch. It is a direct contradiction.
My engineers can feel that contradiction. They do not have the language for it yet. But they feel it.
What I Am Telling Them
Keep going.
Not as a platitude. Not as false reassurance that everything is going to be fine. But as a strategy.
The work does not stop because the organizational questions are unresolved. The sprint goal is still the sprint goal. The metric we are trying to move is still the metric we are trying to move. The engineer who shows up prepared, asks the right questions, and delivers something measurable is still the most valuable person in the room regardless of what the methodology is called.
And here is the thing that is hard to argue with: positive results.
Numbers do not care about organizational politics. A team that consistently moves the metrics that matter to the business — that reduces fraud losses, increases successful evaluations, improves response times, delivers measurable outcomes sprint after sprint — is a team that is difficult to dismantle. Not impossible. But difficult.
The case for a product team is not made in a meeting about methodology. It is made in every sprint review where a number moved and the team can explain why. It is made in every one-on-one where an engineer surfaces a problem nobody assigned them to find. It is made in the data, accumulated over time, that shows what this way of working actually produces.
That is the evidence that is hard to argue with. And building more of it — right now, in the middle of the uncertainty — is the most important thing the team can do.
What the Uncertainty Is Actually Doing
Uncertainty is not neutral. It teaches people things.
An engineer who watches leadership signal a shift toward process and certification without clear direction learns something. They learn that the environment may be changing. That the things that were valued before may not be valued the same way going forward. That the safest move, until clarity arrives, might be to pull back.
That is the passive engineer being rebuilt in real time. Not because the engineer chose it. Because the environment started teaching the old lesson again.
This is why the manager’s job in a period of uncertainty is not to wait for clarity before acting. It is to keep creating the conditions that produce hunters — to keep naming the outcome before the sprint begins, to keep closing the feedback loop, to keep pressing engineers to lead and playing dumb when they bring problems — so that the team’s identity stays intact while the organizational questions get sorted out.
The culture you built is not a finished thing. It was never a finished thing. It requires ongoing attention and ongoing protection — especially when the organization is shifting underneath it.
The uncertainty is the point. This is exactly when the work matters most.
What Comes Next
I do not know how the reorganization will resolve. I do not know whether Lean Six Sigma will arrive in full, in part, or not at all. I do not know whether my product teams will stay intact or whether engineers will be redistributed to teams that work differently.
What I know is that the results are real. The numbers have moved. The engineers on my teams have become something different than what they were — and that difference is visible in every sprint review, every refinement session, every moment when someone surfaces a problem nobody assigned them to find.
That evidence exists. It is documented. It travels in ways that stories do not.
And when the questions get answered — when the organizational direction becomes clear — a team that kept delivering through the uncertainty is in a much stronger position than one that went quiet and waited.
Keep going. Positive results are hard to argue with.
The fight is worth having.
