What are you optimising for?
Recently, one of the teams I am lucky to work with showed me a tool they had built to help plan and manage Cloud adoption. It captured system data, project data, dependencies between applications and platform capabilities, and the roadmap for launch and enablement of those capabilities. Such a tool is helpful for any Cloud adoption programme, but what really stuck with me was the goal that the team had set for themselves.
The team wanted to answer two questions. First, what were they optimising for? And, second, what would they do differently depending on the answer to the first question? If they were optimising for cost, then one set of dependencies mattered more than another set. If they were optimising for agility, then they would give one set of tasks more priority than another set. If they were optimising for risk, then they would build their plan this way rather than that way.
I think that answering these questions - not just for strategic Cloud adoption, but for any complex endeavour - is vital, for three reasons.
First, I think it is helpful to express our goals in terms of optimisation. It is normal to express and elaborate the goals of any task that we are undertaking, whether we define a mission statement, a set of requirements, a backlog of user stories, or set KPIs or OKRs. But it is also normal that we cannot achieve all of our goals in all dimensions at the same time: most complex endeavours are optimisation problems, where we need to figure out which goals we will give priority to, and for which goals we will accept compromise. This might seem obvious, but it is often hard to accept that we cannot have everything at once: personally, I have learnt the classic tension between time, quality and cost many times (often the hard way), but that doesn’t stop me wanting to optimise for all three simultaneously.
Second, even more importantly, I think that humans have a hard time keeping track of what they are optimising for. This is particularly apparent on large, complicated programmes of interconnected activity. We set out with what we think are a clear set of goals, but soon become deeply invested in the way we organise, manage and report the programme: inevitably, we sometimes find ourselves optimising for the smooth running of the programme, rather than the outcomes we want to achieve. If you think that you are immune to this, ask yourself this question: have you always been prepared to stand in the way of finalised and agreed deadlines for the sake of a better outcome that may take a bit more time? If not, then you may have optimised for the short term (smooth completion of the programme) over the goals the programme was intended to achieve: I know that I have done this, and it is very difficult (and usually unpopular) to resist.
Third, while we may wish to optimise consistently for a set of outcomes over time, achieving those outcomes may require us to optimise differently along the way. The right priority at the start of a transformation may not be the right priority at the end. For example, if you are running a strategic Cloud adoption initiative, you may optimise for short-term velocity and learning at the beginning (get something live and acquire experience in operations) and optimise for your long-term goals of cost, risk and agility as your maturity grows.
Tools such as the one I saw help us answer the question of what we are optimising for, and what it means to optimise for that outcome. But, in any complex endeavour, we will continue to need clarity and courage as well as data to achieve those outcomes.
