Lessons in teamwork from the Army and RNLI
Developer Mark Strudwick shares what he’s learned about teamwork from previous lives as a soldier and lifeboat crew member – and how it applies to coding teams.
This HeadTalk is designed to provide you with a set of basic tools to help you feel more confident in engaging in the process of strategy. My hypothesis is that great strategy and highly effective software development share much in common. Do we have skills and superpowers that should make us brilliant at this? If we have, how can we start to translate them?
Here’s a diagram I will refer to throughout – on the left we have the software development team that’s just formed, and on the right, the product owner and a circle that represents a view of where they want to be in six months.
Misconceptions
There are a number of common misconceptions about strategy:
- It’s only for people with lots of experience/the board.
A strategy is for everyone. If a strategy is believed by a company just to be for the board, it won’t work at all, because the delivery of strategy has got to be done by everybody.
- Strategy is a plan.
I hope that in Headforwards we better understand that a plan never survives first contact with reality. Some think of a strategy as a document that tells you a plan – then they put it on a shelf and don’t touch it, so whilst it might have a plan within it providing a starting point, it’s not a plan.
- Strategy has to be blue sky and aspirational.
A company needs to have blue sky thinking and inspire and create aspiration to achieve things, but that is where vision and purpose sit. Strategy is actually about much more focused goals or objectives which you then have to work
Defining strategy
Let’s start by looking at a few definitions of strategy:
- It’s a plan of action to achieve an overall aim.
This is a good succinct summary but in my opinion, a bit too simple.
- It’s a plan of actions to create value.
What I’ll call ‘top end’ value is where what your strategy aims to do is offer more value than your competitors to the marketplace. It could be you can do things more cheaply – that’s adding value to the customer, or you add innovation or a new process or service which enables them to do things quicker or better than their competitors. Really importantly though, there’s another end of the value chain which is about the inputs: a strategy can also focus on how to increase value through its people – that can be as crude as just making the company outwardly more attractive.
- In business, strategy is usually concerned with markets, and it addresses the question ‘how do we win in the market?’
This is a simple view but it’s not the only view – you might not agree with it. A strategy that focuses on value might not always be about winning, so I’ve included this on purpose to get you thinking.
Richard Rumelt
I can’t talk about strategy without mentioning Richard Rumelt and his book Good Strategy Bad Strategy.
Rumelt’s definition of strategy is ‘designing a way to deal with a challenge.’ To that I add, or achieve a goal. Challenge on its own has negative connotations.
Rumelt breaks strategy down into three key features to help us identify whether something is a strategy in the first place, and if it is, whether it’s a good strategy or a bad strategy.
- There’s a diagnosis.
If an individual can’t answer the question ‘why’, they haven’t done any diagnosis and the strategy is likely to be misplaced.
- Guiding policy.
A statement, usually a goal that actually changes the approach from being linear A to B, to something more sporadic (as my diagram illustrates).
It’s an overarching guide that says regardless of where you’re going to end up, you need some kind of guardrails (my word) so that you can’t just go anywhere. There has to be some focus – so it’s about constraining certain actions without defining what should be done.
- Coherent actions.
We know you can’t deliver a strategy unless you do things, so that’s where the ‘actions’ part comes in, but coherence is such a critical part of a real strategy: if a strategy looks like a set of bullet points that don’t interrelate to each other, it’s unlikely to stand the test of time.
Good strategy vs bad strategy
A good strategy should be simple and obvious. That doesn’t mean it will look simple and the strategy be immediately obvious. It means that if I spend half an hour explaining my strategy to you, by the time I’m finished, you should get where I’m going with it.
It should identify the goal or challenge to overcome, and identify the actions. What are we trying to do differently? What is the goal? What are the actions that are going to get us there? We also need to think about how each element of the actions is going to support other elements so there is coherence.
It should be focused and allow us to say no; a bad strategy tends to try and please everybody, whereas a good strategy will always involve difficult choices. It’s a guide to what you should stop doing as much as it is a guide to what you should do. Strategy always involves change, and change always involves choices. If everyone smiles and says “yes, there’s something for me in that”, it’s probably not going to be a good strategy.
A bad strategy has lots of fluff – hot air, and is often focused on the aspiration rather than how we’re going to do it. You can’t just have a goal – you must have the actions that tell you how to achieve it. Sometimes objectives don’t appear bad, but they might not be deliverable – if you don’t have the resource or the capability, then it’s a bad objective.
Superpowers
Great strategy tends to find superpowers – things that propel change in a way that’s almost unbelievably successful. Here are a few:
- Proximate.
Research shows that if you set a strategy that’s more proximate, it’s more likely to be successful. Proximate goals are goals that aren’t necessarily unstretched, but that are achievable and believable.
Eg. When the US decided to come up with the simple goal of getting a person on the moon, it was a proximate goal. It sounded audacious but they already knew they could do it – they just had to focus their strategy and their resources.
Proximate is a very good superpower: if you all understand and feel like something can be done (even if it is a stretch), it’s much more likely to get done.
- Chain link is about analysis and understanding. If you can analyse a strategy properly, identify the linkages between things – actions and interfaces, and order them well, then you will have a superpower.
Eg. To really succeed at what it does, company X has to improve its sales, improve the quality of what it does, and increase its capability to deliver it. If the company starts by trying to focus on sales, it might end up in a position where it is going to deliver to new clients in poor quality and doesn’t have the capacity to do it. That’s going to kill it quicker than anything reputationally.
The Chain Link idea says all those steps are important (improve sales, quality increase capability), but you’ve got to do them in a certain order – if you don’t do them in that order, you’re in trouble. If you get them right, then you’ve got a superpower.
- Leverage.
In software and tech, leverage is often about finding an imbalance or a weakness in the existing model and exploiting it. Technology breakthrough can often be a big lever – a new novel piece of technology which other people don’t have, which addresses a weakness in the current product or service. If you find that and exert leverage on that, you’ve got a superpower.
Design
I get the sense that most software engineers like the idea of crafting great software and there’s a heavy design element in that. Everyone will have a different view about design, but these are a few of my ideas to reinforce the point I’m making that design is so important in strategy:
- Multiple solutions, multiple perspectives.
Do you have tools or sessions where you look at different solutions? Do you look at those solutions from multiple perspectives? Do you use those sessions to refine and look at how the design can better fit together?
- Trade offs.
Are there trade-offs between different approaches? If you’ve got six points, do these things diverge or is there a way that you can evaluate them to superpower them up so that they do join up or nearly do?
- Identifying and solving problems/the tools of UX.
How you put that user mindset on and the processes you go through when testing are very applicable to designing a strategy.
- Test, hypothesize, refine, iterate, listen for signals.
A lot of people believe that strategy is fixed – I don’t believe you can deliver strategy that’s just in a straight line – you need to test, hypothesize, refine, iterate, listen for signals. If anyone ever tells you that strategy is 100% correct because they’ve done the analysis, they are wrong – no one is ever correct in strategy. But if you apply the processes that you apply in software, you will hopefully guide yourself to the mark.
Summary
Like design, strategy is an iterative process – there is no way that the strategy you come up with at the beginning will be the same as that deployed at the end. Embracing that and being at peace with the fact you still have a target but will be iterating your processes, means you’re much more likely to succeed.
When divergence occurs, your default is probably to think that your original idea is better than the divergence, and that’s exactly the conversation I’m trying to start through this HeadTalk. Do you have tools to help you analyse whether divergence is positive or negative? If after analysis we establish that the divergence is good, great, but if it starts to take us over those all-important guardrails, cut it.
I believe you can spot good strategy by its coherence and beauty, and I believe we have the tools and capability to design a great strategy – let’s do it together!
Related posts
Requirements gathering: How we prepare – and use – a requirements document
Product Owner Tom Goldring explains how we turn client needs into a living requirements document that our teams can use to guide software development.
Why data quality is so important – and how you can improve yours
Data Solutions Designer Kanaga Selvi Nachiyar explains how we measure data quality and help organisations improve their data practices.