I recently worked with a team that had spent nearly two years building an application.
They were not lazy. They had been working hard, solving technical problems, and responding to requests from the company’s managing director. But every time new information arrived, the scope changed. A feature was added. A requirement was revised. Something the team thought was finished had to be reconsidered.
The changes appeared reasonable. After all, should the team ignore useful information simply because development had already started?
But there was a deeper problem. After almost two years, nobody outside the development team had tested even a basic version of the application. There was no beta release. No real user had struggled with it, benefited from it, or shown the team what mattered most.
The team kept changing the product, but it was not learning from the market.
That distinction matters because constant change can look like agility. The plan keeps moving. The team keeps adjusting. Leaders can point to every revision and say, “We are responding to new information.”
But changing the plan is not the same as becoming more agile.
Agile leaders do not change direction every time something changes. They protect the win, adjust the play, and learn from evidence.
Change Is Not Always Learning
Suppose you are driving to Baguio and learn that traffic has stopped along your planned route. An agile response is to find another road while keeping the destination clear.
A reactive response is different. You turn left, then right, then left again whenever someone sends a new traffic update. Eventually, you are moving constantly but no longer know whether you are getting closer to Baguio.
That is what happens in many organizations.
A customer makes a suggestion, so the team adds a feature. A senior executive attends a conference, returns with a new idea, and asks everyone to adopt it. A competitor launches something new, so priorities shift. A technology provider demonstrates an impressive tool, and a new project enters the plan.
Each response may make sense by itself. Together, the changes can create confusion, delay, and unfinished work.
The organization becomes highly responsive but poorly directed.
Agility requires movement, but not all movement is progress. Agile leaders must know which new information deserves action, which information should be watched, and which information is simply noise.
They also need something stable enough to organise their choices. Without a clear win, flexibility becomes drift.
Protect the Win, Not the Original Plan
Many leaders think agility means being willing to abandon the plan. That is only half the idea.
Rigid leaders protect the plan even when the evidence changes. Reactive leaders abandon the plan whenever a new concern appears. Agile leaders protect the objective while changing the way they pursue it.
The team building the application did not need to treat every original specification as sacred. But it also did not need to redesign the whole product whenever someone introduced another possibility.
It needed to clarify the win.
Who was the first user? What problem should the application solve for that person? What could the user do after trying it that was difficult before? What was the smallest version that could create that result?
Those questions would not have eliminated uncertainty. They would have given the uncertainty a centre.
Once the win was clear, the team could evaluate each proposed change. Would this change help the first users accomplish the result? Must it be included before testing, or could the team learn without it? What would happen if it were added later?
The conversation would move from “Is this a good idea?” to “Does this idea help us prove the next thing we need to know?”
Many ideas are good. Agile leaders are not paid to collect all of them. They are paid to decide which ones deserve attention now.
Make the Decision Smaller
One reason leaders delay is that they make the next decision too large.
“Should we launch the application?” feels dangerous when the product is unfinished. Leaders imagine customers seeing its weaknesses, employees becoming frustrated, or the company damaging its reputation. Because the decision feels large and permanent, they keep preparing.
A smaller decision creates a different conversation.
What if the team allowed five selected users to try one function? What if the test lasted only two weeks? What if the goal was not to prove the application was ready, but to discover where users became confused?
Now the company is not betting the entire product. It is buying information.
Jeff Bezos popularized a useful distinction between one-way-door and two-way-door decisions. A one-way-door decision is difficult to reverse and therefore deserves more careful analysis. A two-way-door decision can be reversed with limited consequences, so it can often be made through a lighter and faster process. In his 2016 letter to Amazon shareholders, Bezos warned against using one heavy decision process for both kinds of choices.
A limited beta test is usually a two-way door. The team can choose the users, control the scope, collect feedback, and stop the test when necessary. Yet organizations often treat it as though they were launching permanently to the whole market.
When leaders treat every decision as irreversible, the safest move always appears to be more preparation. Unfortunately, more preparation without contact with reality can produce a more expensive mistake.
Agile Leaders Learn Through Contact
The application team had plenty of information. What it lacked was contact.
Meetings produced opinions. Reviews produced revisions. New requests produced more work. But no actual user had been given the chance to say, “I cannot find the button,” “I do not understand this step,” or “This one feature saves me thirty minutes.”
Evidence like that changes the quality of the decision.
A leader may believe ten features are essential. Real users may reveal that two create most of the value. A team may worry that an unfinished design will discourage people. A small test may show that users care more about speed than visual polish.
Agility is not the ability to predict every change. It is the ability to create useful contact with reality early enough to adjust.
This is why prototypes, pilots, simulations, and minimum workable versions matter. They turn assumptions into something the organization can examine. They do not remove the need for judgement, but they give judgement better material.
The question is no longer, “What do we think might happen?”
It becomes, “What happened when someone tried it?”
What CEOs Must Make Clear
CEOs often ask teams to become faster and more agile. But speed will remain a slogan if people do not know which decisions they are allowed to make.
When every change requires approval from the top, teams learn to wait. When leaders punish unsuccessful experiments, managers learn to hide uncertainty and recommend only safe ideas. When priorities keep changing without anything being stopped, employees learn that finishing is less important than responding to the latest request.
Agility is not created by asking people to move faster inside the same system. CEOs must decide where teams need freedom, which boundaries must remain firm, and what kind of failure is acceptable in a controlled test.
They must also distinguish direction from method. The company may remain committed to improving the customer experience while changing the technology, process, or sequence used to achieve it. A clear direction gives people the confidence to experiment without making the organization feel unstable.
When the destination remains unclear, every experiment looks like another distraction. When the destination is clear, a small test becomes a disciplined way to move towards it.
What HR Must Develop
HR teams often describe agility as a competency. The framework may include adaptability, openness to change, resilience, collaboration, and learning orientation.
Those qualities are useful, but a competency description does not yet develop an agile leader.
Leaders become agile by making decisions under uncertainty. They need to practise separating assumptions from evidence, identifying reversible decisions, designing small tests, and deciding what new information should change.
Instead of beginning with a broad agility workshop, HR can begin with one project that has become stuck. Bring the leaders responsible for it into the room. Ask them to clarify the result they are trying to create, identify the assumptions keeping the project large, and design one test that can produce useful evidence within seven days.
The project becomes the learning laboratory.
This does not mean every leadership program must solve a live operational problem during the session. It means the learning must stay close enough to real work that participants can see how the ideas change a decision.
The goal is not for managers to say, “I understand agile leadership.”
The goal is for them to make a smaller, wiser move while the whole answer remains uncertain.
What Trainers Must Change
Trainers can easily turn agility into another content-heavy topic.
We explain volatile environments, introduce agile mindsets, teach popular frameworks, and encourage participants to embrace change. The presentation may be engaging, but the room can remain safely theoretical.
A stronger session places participants inside a decision.
Give them a project with incomplete information, competing requests, limited resources, and a deadline. Let them decide what must remain stable, what can change, and what they can test before making a larger commitment.
Do not rescue them too early with the model. Let them experience the cost of treating every decision as equally dangerous. Let them see how a large problem becomes more manageable when the next move becomes smaller.
Then connect the lesson to their work. Which project has remained in preparation for too long? What decision is everyone treating as irreversible? What could be tested without betting the whole project?
The trainer’s value is not in explaining agility better than everyone else. It is in designing the moment when leaders discover that they can move without pretending to know everything.
Three Questions That Create Movement
When a project keeps changing but never seems to advance, leaders can return to three questions.
First, what must remain true? This identifies the win, the customer need, or the non-negotiable condition that gives the project direction.
Second, what is the smallest useful test we can run? This reduces the size of the decision and creates contact with reality.
Third, what evidence would change our next move? This prevents the experiment from becoming another activity. The team knows what it is trying to learn and how that learning will affect the next decision.
These questions are simple, but they change the conversation. They move people away from defending a complete plan and towards building a useful path of evidence.
Develop Leaders Who Can Learn While Moving
The team working on the application did not need another reminder that change was happening. It experienced change every week.
What it needed was a way to stop confusing revision with progress.
The next breakthrough was not to produce another improved plan. It was to place a smaller version of the work in front of real users, study what happened, and allow the evidence to guide the next move.
That is the kind of practice we need when developing leaders through practical leadership training. Agile leaders are not developed by telling them to welcome change. They are developed by helping them make better choices when information is incomplete, risks are real, and waiting also carries a cost.
An agile leader does not need to know everything before moving. But the leader must know what the team is trying to win, what can be tested safely, and what evidence deserves to change the plan.
That is agility: not changing constantly, but learning quickly without losing direction.
About Jef Menguin
Jef Menguin is a leadership development consultant and motivational speaker. He created The Leader’s Game and Supervisor Factor, practical leadership-development systems that help organizations turn priorities into everyday leadership behavior.
Explore his work in leadership training, discover his motivational speaking programs, or connect with him on LinkedIn.