Product Owner Tom Goldring explains how we turn client needs into a living requirements document that our teams can use to guide software development.
Over the years, I’ve worked in a lot of different roles in different types of teams. But there are two periods of my life that I think contributed most to my understanding of what makes teams work effectively together – and what doesn’t. First as a soldier, and later in life as a volunteer lifeboat crew member with the RNLI, both roles where trust in your team is paramount, and careful leadership is needed to get the best out of your people.
Respect isn’t automatic – but it’s vital
When I was 16, I joined the army as a Junior Leader, colloquially known back then as a “boy soldier”, doing my basic training with the Junior Leaders Regiment Royal Artillery, on completion I joined my regiment, 7th Parachute Regiment Royal Horse Artillery. I served with this regiment for a decade, at home and abroad.
In the Army, some things are like the books and the movies, and some definitely aren’t.
There’s a phrase you’ve probably heard a lot: “I’ll follow them anywhere”. That’s real – and that’s born out of reliability, responsibility, and trust. You’re potentially putting your life in the hands of the people around you, so the close team mindset is crucial. But, unlike the media, it’s not all getting yelled at by your superiors; that’s not how respect is earned, and it’s useless for building camaraderie in a squad.
Often, young soldiers are promoted quickly and given enormous responsibility in the Army, both for their squad and the equipment they use and maintain. Leaders need to empower their squad, giving them the agency to complete their tasks without micromanaging them. Respect goes both ways; trusting your team shows respect, and they will respect you in turn.
As a team member, you take responsibility for learning your role and getting it done reliably. That, and being someone who can take (and give) banter, is all you really need to start building that connection with your squad.
A lot of the connection also comes from proximity, spending day and night with the same people for weeks, months, or even years on end. Once you have that rhythm of everyone getting on with their own jobs effectively, the longer you work with that group, the easier teamwork becomes.
You need to trust the team around you
There’s a 25-member volunteer crew at Fowey Lifeboat Station, where I served on the crew for 10 years. On a shout, seven crew members operate the large all-weather lifeboat, while three run the smaller inshore lifeboat.
It’s daunting to join a crew, especially when everyone already knows each other well – you’ve got to prove yourself quickly. Fortunately, it’s not that different to the Army: do your tasks properly and quickly, learn the quirks of working on the lifeboat, and be a friendly face at the pub, and people will start to trust you.
The last thing you need when you’re on a shout in a Force 10 storm is a crewmate you can’t trust. You’re all working together to bring people home safely – those you’re rescuing and the crew – and that requires a lot of moving parts to slot together seamlessly. But there’s no one barking orders on the deck of a lifeboat; everyone knows what they need to do, and they get on with it, helping each other out as they work.
I remember coming alongside a powerless yacht in lumpy seas and getting ready to transfer to the casualty vessel so I could get them ready to attach the tow from the lifeboat. You’ve got to pick the right moment to step across safely; judge it wrong, and it’s very easy to injure yourself or fall in. One of my crewmates, Jan Philp (AKA ‘Little Jan’ – because his dad is ‘Big Jan’) came up behind me and grabbed a handful of my jacket to steady me. He said: “tell me when you’re ready to go”, and when I was, he gave me a shove to help me across the gap. That small interaction tells you everything you need to know about the trust on that crew – they have your back when you need support and give you a nudge when you need it.
Coding teams need trust and respect too
The Army and the lifeboat are unique situations, but the thing they both teach about leadership is that trust and respect go both ways – up the chain of command and down, and both have to be earnt. The Army and lifeboat have a hierarchy – which to an extent has to be there, whereas in contrast Headforwards minimises hierarchy as much as possible. This lack of hierarchy – if anything, creates a greater need for trust amongst teams, in that to get the best out of the team and each other, you can’t resort to just ‘telling them what to do’.
In any environment, the first, most practical concern, should be “can you do the job?” After that, it’s all about trust, respect, and connection with your team, whether they’re fellow soldiers, crew members, or developers. And being proactive, personable, and reliably good at your job is the basis for all of that.
We’re all intelligent people, capable of making decisions and owning them. That means I don’t need to micromanage when I’m in a leadership position; my job is to guide, not to mandate. But, like making the leap to a stranded boat, sometimes people benefit from an extra nudge in the right direction.
Perhaps unlike my other roles, in development I encourage people to disagree and discuss. My experience doesn’t necessarily mean I know more than my teammates; it just means that I know different things. Taking the time to understand each other’s perspectives and skillsets ultimately makes for better code and a closer connection with the people you work with (and healthy debate is a luxury you can afford when you’re not pitching and rolling at sea).
Respect and trust are the two words I keep coming back to. In any role, they’re the two most important values a team needs to share to work together effectively towards the best outcome.