Andy Roberts

Head of Commercial and Accounts

Andy is Headforwards Head of Commercial and Accounts. He has worked in many different environments from the military through to a number of challenging corporate roles including CIO and Change Director. Having worked in many industries such as engineering, finance, communications, utilities and insurance, in roles as both customer and supplier he has a greater understanding of how people, teams and organisations operate helping his ability to continuously improve his approach.

On paper, being an empowering leader is quite straightforward – you trust your team, have confidence in their abilities, share responsibility and provide opportunities for them to take ownership of their work. 

In reality, it’s more navigating a path between being careful not to lean too far one way and lose control, or too far the other and hold too much.  

Empowering leaders don’t necessarily know the specifics of the industry in which they work – not everyone in a leadership role at Headforwards knows how to code for example. The skill is the leadership, and this is applicable across many different agile industries, not just software development.  

Letting go  

If you’re going to be a successful empowering leader, you must trust people from the off; the only way you find out whether you can trust someone, is if you trust them. 

The need to demand and control is human nature – everyone wants what they want, however much they might try to pretend they don’t. An empowering leader lets go, gives team members the power to make decisions, and doesn’t interfere when they consider that decision to be wrong. 

This is surprisingly difficult to achieve, and I’ve seen many an ‘empowering’ leader asking the team what they think, before steering the conversation full circle back to their way of thinking.  

This is a big problem; it’s usually painfully obvious what’s happening, and the team knows its contributions are falling on deaf ears.  

A leader pretending to be open to ideas, or responding with, “that’s not right” when asking “what do you think”, deflates a team. The team members have been hired for the job because of their knowledge and expertise, which is now being totally disregarded. 

It can be challenging as a leader when you don’t agree with a consensus. It can be helpful to think carefully about why you feel a certain way and why everyone else might feel differently. Often it is worth letting the team go with their consensus.  

There will be times when you’re right – of course, but you’ve got to be strong enough to let the team go and learn from the experience.  

Getting something wrong is a huge learning curve, and teams who make mistakes, improve. If a team is being told what to do all the time, it’s going to frustrate them, remove their enthusiasm, and critically, restrict their learning because they’re not thinking for themselves.

The flip side – empowering too much 

A good agile leader trusts their team and gives them the autonomy to manage themselves and their projects, but this can backfire quite easily. 

There is such a thing as too much freedom. Here are some examples: 

  • Empowerment needs to be structured cleverly, thought through, and explained very well to the team. If it’s too broad, it can take the drive out of people (“I haven’t done it yet”, “well I trust you, so it’s fine”). Not everyone responds well to being trusted implicitly and it can lead to a lack of productivity.   
  • If a leader continually says, “it’s up to you / you decide / I trust you / you don’t have to do it if you don’t want to”, the power can often shift too heavily towards the team members and it’s very difficult to get back. If the team has ultimate control over what they do and are used to managing things on their own terms, it can cause problems when they have to do something they don’t want to do – like a mundane project.   
  • Not every team will be able to cope with every decision. For example, if a leader isn’t an expert in coding, they shouldn’t try and get involved with decisions based on coding. However, when it comes to talking to a client, finding out what they want, deciding how to do it and how it should be delivered, there probably needs to be some leadership other than the Development team. The team might empower their Scrum Master or Delivery Lead to do it, because they are the experts in that field.  
  • People must be helped on their journey to being empowered. Giving too much freedom can be overwhelming for an individual. For example, if a person running the team is in charge of a budget, and as a leader you say, “you’re in control, it’s your budget, go off, do whatever you want to do”, it’s too broad. The team member might be reluctant to ask for help for fear of looking weak. There needs to be detail in there – “You’re the expert, you go and do what you need to do, but if you’re not sure, come talk to me.” As a leader, it’s your job to teach the skill of being in charge but also being able to ask for help.  
  • In any team, there’ll almost always be a person who doesn’t want to be empowered – they just want to be told what to do, and another who wants to be empowered but doesn’t have the maturity to cope with it (“I spent double the budget, but we really needed everything”). As a leader, you can’t blanket empower your team, you must respond to the maturity and willingness of the individual team members.   

There will be times when you’re right, but there will also be a lot of times when you’re wrong. Let people make mistakes, even if you’re crying inside.   

It’s more difficult to rein things in once you’ve given the team too much power, so be careful about how you empower. Make sure you continue to lead; you can still support whilst you empower.  

Finally, don’t build a hierarchy that compromises getting to the right person to get the right answer. Make sure your team understands that they should ask the person who has the right knowledge, regardless of any hierarchy.  

Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770