My Expectations of Leaders

Last week I ran an induction/introduction session for my new senior leadership team where I set out my expectations from them as leaders. I made some notes on the train up to the meeting, partly as a rehearsal and partly to ensure I didn’t forget anything. Here are the notes, NB I might have phrased some of this differently when I said it, and I haven’t polished these notes, but one of my team said they were worth sharing and she was saving them for sharing with others she might work with in future. So I’m saving them here so that I can find them again, and perhaps polish and refine them when I need to repeat my expectations to new people I work with. I also hope to hold myself to these expectations.

My Expectations of Leaders

You’re all here because I chose you. I chose you because I believe in you. I want you to do the same for the people in your teams.

This is a pivotal time for our team. 2017 was about working out why we are here, what we’re for. 2018 is about translating that thought into action and showing the organisation that we add value.

Each of us in the room has a key role to play. We each have our piece of the jigsaw to shape and polish. Today I want us to make sure that we all know the big picture, and we understand which bits of it we own. From there we can go and make it real.

Role of the Leader

Our role as leaders is to clear obstacles out of the way, set an overall direction and then stand back and watch the team deliver. The Sandhurst motto is “Serve to Lead”. It’s an apt description of leadership. My expectation is that we serve the team, sometimes as an example, sometimes as a facilitator, other times as an advocate. We aren’t really part of the team, but we need to be its champion.

Letting go is hard. Especially when the people do things in a way that you wouldn’t have done. Worry less about the methods and more about what is going on. Are they learning? Are they growing as a team? Are they delivering outcomes and engaging people? So long as the answer to any of these questions is “Yes”, then let it happen. Defend them from above. Encourage and support. Meet their expectations of you.

Decision Making

Decisions should be made by the most junior person that is comfortable with making it. When you get something referred to you to make a decision then you need to explain your rationale and the factors that you took into account to the person that referred it to you. This helps to build decision making capability and also ensures that if a similar case recurs that it will be treated consistently.

One of the most powerful things that you can ask someone is what they would do, and why. You’ll get a different perspective, and also perhaps a better solution. The thing about leadership is that often you know less of the detail that your subordinates, so they will often have a better view of a specific problem than we do. We will have a wider view, and sometimes that changes the required approach. We need to share that information with the team. Let them make the right decisions. Wrong decisions come from a combination of insufficient information and a different interpretation of the objective. If the team shares its objective and has relevant information the decisions should be sound.

Managing People

  • People are not interchangeable resources, every one is unique and needs to feel that we are treating them specially
  • People who deliver projects are employed to think about what they are doing. Thinking about what they do is the key difference between PD Professionals and the more junior people we ask to follow the script
  • People will only think about what they are doing if they are engaged in the work, so we need to engage people as individuals
  • We need to treat everyone as an adult
    • No micromanaging
      • Agree deadlines/timings – be realistic about them
      • Set out the whole task and how it fits the bigger picture
      • Recognise your instinct to control, and let it go
      • People need to choose how they will do things
      • Involve people in planning work
    • Listen to people and find out what motivates them, they’re all different
    • Give people flexibility to work where/when it suits them
    • Allow your team to succeed, people need to know they’re winning
      • Set them short term milestones you know they can accomplish well, then build the challenge when they’ve got used to success
      • Allow them to work as a team to achieve outcomes – don’t tell them how, let them figure it out for themselves
      • Be supportive and coach when needed
    • Accept failure gracefully
      • We learn by doing, not every attempt succeeds
      • Failure is a learning rich environment
      • Mistakes mean people have been doing things, doing things is good
      • Iterate on experience to improve

Being Agile

If you aren’t quite sure how to make this work, you could do worse than trying agile methods.

  • Work out who your users are and what they need.
    • Break this into a series of bite sized outputs, something a single person could do in a day or so.
    • Prioritise these from soonest needed to later.
  • Get the team in a room and focus on the top dozen or so.
    • Get the team to decide how long they think each of the things will take.
    • Sort out any dependencies and either add them to the work list, or work around them
    • Set success criteria for how you know the work is done well enough.
    • Allocate the work to people (get them to volunteer for what they think they will be best at).
  • Do the work, and check in daily at a ten minute (or less) stand-up how they’re getting on.
  • At the end of the sprint period check back on estimates versus actual effort. This will help improve planning for the next and future sprints
  • Repeat until you run out of work, time or money.

Sprint lengths vary, but most teams go for one or two weeks. Some run longer. They key to this method is that there are tangible results that helps the team feel that they are achieving results. There’s also an opportunity to revisit things in response to changes in the operating environment. If you need to replan, or plans are negated by events mid-sprint more than once then the chances are that your sprint is too long. The converse is also true, sprints that are too short lead to slightly more time spent planning than doing. The focus is to get most of your effort on doing relevant things. Most teams I’ve worked with have settled on two weeks as an acceptable compromise.

Also, when you are doing new things you should bear in mind the Government Service Design Principles.

  1. Start with user needs
  2. Do less
  3. Design with data
  4. Do the hard work to make it simple
  5. Iterate. Then iterate again
  6. This is for everyone
  7. Understand context
  8. Build digital services, not websites
  9. Be consistent, not uniform
  10. Make things open: it makes things better

Leave a Reply