25 years ago a young and naive me went to university to study Marine Navigation, My hope was that I could use the skills I learnt to travel the world and get paid whilst doing it. To my horrow I learnt fairly quickly that the reality is that most ships are in port for less than 24 hours and most time is spent at sea.
After university I found myself in the crazy world of IT and since digital delivery and product management. Nevertheless I learn’t a number of things that have served me well in my career in the subsequent years. Here’s what they were:
Know your destination
Before coming up with a plan, a ships captain will be given a charter, this will specify whats expected of the journey. Depending on the type of charter this can include
- The destination
- The cargo
- An expected arrival date and any time based penalties
Often product teams can be spun up without having a clear set of objectives or outcomes, this should be the first step as product owner to define the objectives for the team, specifying:
- Expected outcomes
- Any constraints
A team that knows what is expected of them, has more chance of being successful. If there is uncertainty, you can still use this rule, to define a small discovery to explore the problem space and potential solutions. Time-boxing is a useful constraint that prevents the team getting trapped in ‘analysis-paralysis’. The expected outcomes of a discovery would be a clear set of findings with next steps defined and agreed.
The hardest parts are the beginning and the end
Leaving and arriving at port are the times when there is the biggest risk of an accident, space becomes limited, traffic increases and there’s a lot more land! These are the parts of the plan that need the most focus. The same is true in project delivery. If a team hasn’t got a clear understanding of what they are working towards, haven’t agreed ways of working or identified who they need to collaborate with they’ll run aground very quickly. Similarly as the delivery crunch gets nearer, there’s less time to respond to change, there’s a risk of corner cutting, burnout and mistakes being made.
As a deliver manager, having a good focus at the two ends of delivery pays dividends in ensuring a smooth passage, getting a team aligned and agreed on ways of working is an investment worth making, similarly as a project comes towards a big release, or closure this will take much more effort and focus than the middle bits, knowing this is the case and managing your time and energy accordingly is vital to avoid burnout.
Know your constraints
It’s easy in agile teams to assume that everything is unknown, and we’re exploring completely new landscapes, this is rarely true. Reality is there will be as many ‘known-known’ as ‘unknown-unknowns’ understanding these is crucial to void you wasting time trying to solve things that can’t be changed.
This is true in passage planning too there are a number of knowable variables:
- Tide times and heights
- Bridge heights
- Traffic zones such as the Dover straits
- Landfall and depths
- Fuel consumption
Knowing what your constraints are ensures you map the most appropriate route within these contexts. A smaller vessel may not be constrained to the same depth channels as a larger one for example. It’s pointless trying to make that not the case, it just is.
Digital folks like to push the boundaries and rightly so, but its useful to identify early the constraints you cannot change in order to put your energy into the things you can, this may include:
- Prices people are willing to pay for your product
- Budget
- Time
- Technical landscape
We may not like all of these but we should establish which constraints we definitely can’t change early on. Constraint breeds creativity, better solutions emerge when fully considered for their context.
Know your instruments
A modern ship has a number of instruments to aid navigation:
Radar and AIS (Automatic Identification System) for identifying other vessels
GPS (Global Positioning System) for position
and
ECDIS (Electronic Chart Display Information System) for overlaying this information onto the passage plan to allow you to change the plan based on realtime information.
Instrumentation helps greatly, with decision making, but there are limits:
Whilst GPS has made positional accuracy easier, there are still factors which mean the position is not a certainty:
- The number of satellites available to fix the position of GPS affects the accuracy. GPS (Navstar) accuracy is also worse in polar regions due to the nature of geostationary orbits.
- Whilst GPS is accurate to within a few metres, the position of the receiver on a vessel hundreds of metres long is important. The GPS location fix can be hundreds of metres from the point of biggest danger (the bow). Knowing and understanding the limitations of your measures and instruments is important to avoid making the wrong decisions
AIS isn’t on all vessels, and radar can’t always pick up small craft.
Understanding these limitations is key to making effective decisions, if you use tools that aid making product decisions, such as analytics, make sure you take the time to understand their limitations. Use a variety of methods, and don’t become dependent on just one tool before you make a decision.
Show your dangers
A passage plan will make known dangers very visible, areas of danger are overlaid onto the route to ensure they are extremely visible, marking things like shallow water, rocks or bridges. Often plans will hatch out large amounts of space around them to provide time and space to manoeuvre if the vessel ends up in the ‘danger zone.’
Delivery teams are usually pretty good at identify potential dangers but then squirrel them away in a risk spreadsheet somewhere that no one looks at. Try and find ways to make risks visible so you don’t lose sight of them, risk radar’s on a board somewhere can help, or a risk ticket type on your backlog just keeps them visible, and if they’re visible they are more likely to be managed!
Constantly adjust
A 1 degree error in direction on an ocean scale passage plan can result in making landfall hundreds of miles from where you expected, other factors such as wind, tide and other shipping movements can make you go off course, its necessary to constantly check your current position and adjust your course to where you want to end up. An important part of a passage plan is to continuously update it as you learn more about your position and conditions at the time.
Product plans are no different, they should adapt to the events that happen on the journey of delivery, there’s nothing more disheartening (and ineffective) than to blindly follow a plan that was agreed weeks or months ago and not adjusting it to the reality emerging from the process of doing, yet so many roadmaps stick with fixed goals that don’t need to. Often this is due to stakeholders liking false certainty. Find narratives that highlight real world examples where this is a bad idea that they can relate to, use a shipping analogy if it helps!
Dial down the noise
In areas of high traffic, the number of vessels can impede good decision making, the ‘noise’ becomes too much to identify what to do next. For example in Hong Kong the harbour authorities would dial down the radar feed they were receiving so that they could only pick up large high risk vessels restricted by their draft or their ability to manoeuvre. This allowed the port authorities to focus on those vessels that presented the highest danger of collision. Smaller vessels were obliged to get out of the way of these larger vessels under maritime law and had the manoeuvrability to do so, they were also intrinsically motivated, nobody wants a ship of several hundred thousand tons that takes miles to come to a stop bearing down on them.
Product teams can be quickly overwhelmed with requests and ideas, a good product manager needs to find a way to reduce the noise and keep focus on the primary goals the team needs to succeed. Getting that balance right can be tricky, expectation management with stakeholders, providing enough information without the team feeling unclear or disempowered is a challenging set of skills to master.
It’s easier to change course than speed.
One of our lecturers told us that if you scaled down a supertanker to the size of a yacht, the engine would be equivalent to an electric drill, and the rudder would be the size of a postage stamp. Large vessels take a long time to accelerate and decelerate, there are no brakes on a boat and it came take miles to come to a complete stop. We were always taught, “its easier to change course than speed.”
This is true with team as well. Teams take time to bond and work out how best to work together, once they get their momentum they can really start having an impact. If your teams are being constantly chopped and changed or disbanded and re-formed for different projects they will take time to become effective. It’s far more effective to develop product teams or standing teams and bring the work to them, rather than forming a team from new every-time. Change their course not speed.
All professions have their own languages.
Joining a new profession can be a bewildering experience, learning the language and dialect can take time and it’s easy to feel stupid when faced with it at first. Most modern practices fall back on acronyms but the marine industry has its own language going back 1000’s of years. Whilst English is the international language of the sea, the variance of dialect and understanding of intent can vary from culture to culture. So much so that the maritime industry has developed its own dialect ‘SeaSpeak’ to facilitate communication between ships whose captains’ native tongues differ. I often think similar constructs would be useful in other industries.
IT has a similar challenge of impenetrable language, compounded further by the fact that most IT systems are built to solve business problems. Finding ways to communicate effectively between these two groups is an under-rated art and over time I have learnt that this is a key part of my role as team leader. I’ve learnt to develop the confidence to put my hand up and say “I don’t understand that” nine times out of ten I’m not the only person, but its never a comfortable experience to admit uncertainty.
Just because you have ‘broadcasted’ doesn’t mean others have ‘received’
Most communication at sea happens over VHF Radio. This is an open broadcast system, everyone here’s your transmission which makes directing your message accurately important. Being specific about who you are attempting to communicate with and why is fundamental, as is building in a high level of redundancy to your message. Repeating the core part of the message is standard practice to ensure that the receiving party gets it. I’ve found the same is true with most communication, don’t assume just because you’ve sent that email/text/IM that the other party has received and understood it. Asking for acknowledgement is one way to confirm your message has got through, another is to ensure that it’s ok to say, “can you repeat” allowing people to ask again if its not clear to them or they don’t understand is key.