Between 2009 and 2019 I served in the Swedish Home Guard. I started as a squad leader, became a platoon commander, and later served as deputy platoon commander. Most of that time was spent alongside ordinary work and family life, which is perhaps part of what made the experience useful to me as a technology leader: it was not a separate career in leadership. It was a second place where I had to practise it.
The environments were different. The responsibilities were not. In both software development and military service, a leader is often asked to produce certainty in situations that are uncertain by nature. People want to know the plan, the answer, and who is in charge.
But leadership is not the same as control.
A plan is useful. It gives people a shared starting point and makes preparation possible. It also creates a dangerous temptation: to confuse the plan with reality.
The situation changes as soon as people begin to act. Information arrives late. Assumptions turn out to be wrong. Something takes longer than expected. A dependency is unavailable. A person who was expected to be present cannot participate. The plan remains a useful reference, but it is no longer a complete description of what is happening.
This is familiar to anyone who has worked on a software project. A roadmap is made, a backlog is ordered, and a delivery plan is communicated. Then the first contact with reality begins. Users clarify what they need. A technical constraint appears. The market changes. A production incident interrupts the plan. A team discovers that the apparently simple part of the problem is not simple at all.
The leadership failure is not that the plan was wrong. The failure is expecting the plan to remain right after the circumstances have changed.
When detailed instructions cannot cover every possible situation, people need something more durable: a clear understanding of the intended outcome and the boundaries within which they can act.
This is the difference between an instruction and intent.
An instruction says:
Go there, take this route, and do these things in this order.
Intent says:
This is what we need to achieve, this is what matters most, and these are the constraints you must respect. Decide locally how best to get there.
Intent does not mean that anything goes. It is not an invitation to improvise without responsibility. It is a way to move decisions closer to the information needed to make them well.
A person at the centre of a changing situation usually knows more about the immediate circumstances than someone further away. If every decision has to travel up the hierarchy and back down again, the organisation becomes slow precisely when it needs to respond quickly. Worse, the people closest to the situation learn that their judgement is not wanted. They wait for permission instead of solving the problem in front of them.
This is one reason I have always found agile methods attractive. At their best, they do not replace leadership with ceremonies. They create a structure in which people can understand the goal, inspect what is happening, and adapt their response.
Trust is often described as a soft or cultural concern, as if it were separate from the work. I do not think that distinction holds.
If a team does not trust its leadership, information is filtered. Bad news arrives late. People optimise for appearing successful rather than learning quickly. Decisions move upwards because no one wants to be blamed for making the wrong choice. The resulting system is slower and less resilient, regardless of how good its tools are.
Trust is therefore part of the operating environment. It affects the quality of the signals an organisation receives and the speed with which it can respond to them.
The same is true in the other direction. A leader cannot simply announce that a team is empowered and consider the work complete. Trust has to be made visible through behaviour:
The last point is particularly important. Autonomy without follow-up is abandonment. Follow-up without autonomy is control. Leadership has to hold both.
When I was a manager, I sometimes felt the pressure to demonstrate value by solving problems personally. This is an understandable trap for technically experienced leaders. If you know how to solve a problem, solving it feels efficient.
It is not always efficient for the organisation.
A manager who repeatedly steps in becomes a bottleneck. The team gets an answer, but not necessarily more capable people. Over time, the team learns to escalate rather than decide. The leader becomes indispensable in exactly the way that prevents the team from becoming stronger.
The more useful question is often not “Can I solve this?” but “What is preventing this team from solving it?”
Sometimes the answer is missing knowledge. Sometimes it is an unclear goal. Sometimes two teams have conflicting priorities. Sometimes the team lacks authority over the system it is expected to change. Sometimes the impediment is simply that nobody has created a safe space for a decision to be made.
Removing those impediments is less visible than providing the answer. It is also more scalable.
This is where the Scrum Master role, good management, and architecture have more in common than their job titles suggest. Each can be understood as the design of conditions in which other people can make better decisions.
Architecture is often presented as a technical activity: selecting technologies, defining boundaries, and documenting structures. Those things matter, but architecture also determines who is allowed to decide what.
A centralised architecture function may produce consistency, but it can also turn into a queue. Every significant decision waits for a small group of people. The queue grows, the context gets lost, and the people doing the work become disconnected from the choices shaping it.
A decentralised approach does not mean that every team designs its own universe. It means that decision rights are made explicit. Teams understand which decisions they own, which constraints are non-negotiable, and when they need to seek advice from people affected by the decision or people with relevant expertise.
This is close to the idea of an architectural advice process: the accountable person or team makes the decision, but first seeks input from those who will live with the consequences and those who have useful knowledge. Advice is not the same as approval. The distinction matters because it preserves both learning and accountability.
The goal is not to remove leadership from architecture. It is to move leadership from making every decision to designing a system in which good decisions can be made repeatedly.
The same principle becomes even more important as AI agents take on more implementation work.
An agent can follow instructions quickly. It can also act on incomplete or misleading instructions quickly. If we respond by trying to specify every possible action in advance, we will create brittle systems and enormous prompts. If we respond by removing all boundaries, we will create systems that can act without a reliable understanding of what they are allowed to do.
The alternative is to give agents a clear operating context:
This is not a reason to treat an agent as a person. It is a reason to recognise that delegation requires more than access. It requires intent, boundaries, feedback, and accountability.
The human role does not disappear when execution is automated. It moves towards setting direction, shaping constraints, interpreting signals, and deciding when the system should stop.
Military leadership is not a model for every technology organisation. The Home Guard has a formal hierarchy, a defined mission, and circumstances in which command authority is deliberately stronger than consensus. Software teams are not military units, and people should not be treated as interchangeable resources.
The analogy is useful only if it is handled carefully. I am not arguing that software leaders should command more forcefully. I am arguing almost the opposite: both environments show why a leader cannot rely on control when conditions are changing and decisions have to be made locally.
A software team needs disagreement, experimentation, and the ability to challenge its assumptions. Those qualities are not always compatible with a command structure. The transferable lesson is not the hierarchy. It is the importance of clear intent, preparation, trust, and responsibility.
The best evidence of leadership is not that every decision passes through the leader. It is that people can act responsibly when the leader is not present.
That requires more than delegation. It requires teaching people how to think about the work, making the purpose visible, creating boundaries that are clear enough to be useful, and allowing the consequences of decisions to remain connected to the people who made them.
In a sense, this is the same work at several levels:
In each case, the work is not to control every movement. It is to make good movement possible.
I still value a clear plan. I still believe that leaders sometimes need to make direct decisions. But I have become less interested in being the person with all the answers, and more interested in whether the people around me have enough clarity and confidence to find the next answer themselves.
That is command without control.
And it may be one of the most practical definitions of leadership I know.
Tags: leadership, agile, teams