Does your team experience the leadership you think you give? Lessons from the British Army
You check in because you want to help. Your team experiences another interruption. You offer a quick suggestion, but someone hears a decision they are expected to follow. Your intention and their experience can both be real.
Leadership feedback helps you examine that gap. It asks how your behaviour affects the people working with you, rather than relying only on your intention.
The British Army’s Coaching Handbook describes a 180 Leadership Tool that supports self-awareness and development through feedback on leadership behaviour. I will borrow that principle for a small, practical exercise in a tech team.
The Army connection
The handbook links feedback with identifying development needs and making a development plan. For a tech lead, the useful question is what you will change after hearing how others experience your leadership.
Start with one behaviour you can influence. A broad request to “rate my leadership” is harder to answer and easier to turn into a popularity score. Specific questions give people something observable to discuss.
A tech team example
For example, a delivery lead sends several direct messages each day asking whether work is on track. They intend to remove blockers before those blockers grow. Developers often stop what they are doing to assemble an update, even when nothing has changed.
The lead asks for feedback on how the team discusses progress. The aim is to understand whether the current approach helps the team get support, and what it costs in interruptions. You do not need to collect a rating for every part of leadership.
| Step | What the team can see |
|---|---|
| Ask | A specific question about progress updates. |
| Understand | A summary of the effects and competing needs. |
| Change | One agreed adjustment to routine and urgent updates. |
| Review | A date to check interruptions and access to help. |
How to put it into practice
Choose the behaviour and explain the purpose.
Purpose: Make the request specific and safe to understand.
The lead explains: “I want to review how I ask for progress updates. I need enough information to help with blockers, and I want to understand whether my messages interrupt work unnecessarily.”
Explain who will see responses, how they will be used and what you can change. Do not promise anonymity if the collection method or team size makes people identifiable. In a small team, distinctive examples can reveal who contributed even when names are removed.
Offer more than one route to respond. A conversation may suit one person; a written response or a trusted facilitator may suit another. Make participation voluntary and avoid asking people to disclose personal circumstances to explain a preference.
Ask about events, effects and alternatives.
Purpose: Gather usable observations rather than a verdict on your personality.
Ask when an update request helped and when it interrupted useful work. What happened next? Was the team unsure which messages needed an immediate reply? Was there a place to raise a blocker without waiting to be asked?
Invite positive feedback too. You need to know what to preserve, not just what to change. Someone might value the lead’s fast response when a dependency is stuck, while wanting routine questions moved to a shared channel.
Listen without correcting each answer as it arrives. Clarify what happened, then reflect your understanding. Explaining that you meant well does not tell you whether the process worked. Avoid collecting customer details or private information that is unnecessary for the review.
Look for a change you can test
Purpose: Turn the feedback into a visible decision.
In this example, imagine the responses suggest that routine requests feel urgent because they arrive as direct messages. The lead could propose one shared update point, with a separate, clearly explained route for work that is genuinely blocked.
Check the proposal with the team rather than declaring the problem solved. A single morning update will not help if a critical dependency changes that afternoon. Agree which changes need a fresh update and who needs to see them.
Feedback is evidence to consider, not an automatic vote. If there are conflicting needs, explain the trade-off and choose a small adjustment to review. Do not dismiss an isolated concern just because it is less common; it may still need attention.
Report back and review the effect.
Purpose: Show that contributing feedback led somewhere.
Publish a short response: what you heard, what will change, what will stay and why, and when you will review it. Keep quotations or identifiable examples out unless the contributor has agreed to their use.
After two weeks, ask whether routine interruptions have decreased and whether blockers still reach the right person promptly. These are review questions, not claimed results. If the new approach hides problems, adjust it.
The lead must also follow the agreement. A shared update channel loses its value if people still request the same information privately throughout the day. People will judge the change by what happens after the feedback exercise.
A practical starting point
What to try next
Choose one behaviour you can change this month, explain the request, listen to the responses, and set a review date before collecting more feedback.
You do not need to agree with every interpretation. Show people you heard their experience and explain your response clearly.
Source: British Army Coaching Handbook, section on the 180 Leadership Tool and continuous feedback, printed page 18. The worked example, questions and tech-team tools are original Coded Female adaptations.
You May Also Like
The Importance of Mental Health Care for Work-Life Balance
How to write a tech CV that shows your impact, even without metrics
