I've been thinking about trust and trusting working relationships a lot recently. People trusting me to do things and me trusting others to do things. I've been thinking about it as it is something I am not very good at and something I am actively trying to improve.
I am in a very lucky position in my role at ONS. My boss is Laura, one of the smartest people working in civic tech and a very very good line manager. Her creating a trusting environment for me to work in has been vital. I simply would not have been able to do my role without it. I have been lucky enough to have had this in a few places, but in 18 years in the industry, maybe only twice before. James was the first person to really talk to me about this and more recently Tony built a whole team based on it.
The catalyst for this post though is having spent time in a recent end of phase retro with one of the teams I work with. It was the end of a Beta, so looking back over a 9 month run of work and so had plenty of ground to cover. Alongside some very useful reflections (why was our full test suite not in the CI environment earlier? Aren't spikes great? Our User Researcher is a absolute hero) I started to think about how the project was set up. not in terms of its scope, or the structure of the Agile processes , but in the permissions I could offer the team.
In my role as a Service Owner this is something I have spent many an sleepless early morning considering. I am responsible for digital projects and my urge is to get involved in them. Sometimes because I feel I can add value (I've done this stuff for twenty years, I must have learnt something… right?) and at times because people ask for my input and others because things are happening in different ways to which I would do them. It was this last point that nagged at me. It was clearly a sign of poor management from me, yet I kept fiddling with things. So, I tried something different.
Being a leader means trusting other people to do the things you care about most.
I stepped back. Not (I hope) in a reckless way. I tried to divert my attention fully to creating the space for people to work. Consuming myself with the contractual, project governance, budgets, Sign offs, noise and faff of a business, hiding it away in my inbox. This may seem like dumbing down a project, but I hope it was about removing barriers. Taking the noise out of the system was an attempt to make sure the team could focus on those that mattered. Our users and each other.
Maybe it was obvious to everyone else, but building a team that undertakes user research every two weeks, one that genuinely has permission to self organise, one that can set its own direction and make the right technical choices does not happen by chance. You need to spend time and effort building the space for that to work. Also, and this is the bit that I am trying to improve, you need to wholly and unequivocally trust the teams you create.
My role as a manager [1] is to bring the very very best people into a room and then fight for them every day. Trusting that this will translate to delivery is scary, but in a sense, everything. Sure, I bring my whole self to work every day and try to help in any way I can, but when they need me, not I need them.
Has this worked? It is hard to tell. Maybe? Is as far as I have gotten so far. It is the kind of thing that matters though and something I want to talk about more.
[1] Janet talking about super heroes here made me wince. I think I might have secretly self identified as a super hero until fairly recently. I am so so sorry.