Thread by @swardley

X : When you talk about MttR are you talking about Mean time to Repair?
Me : Yes and no. I prefer to think of this as Mean time to Recover either from a failure or some other impact such as a change in the market, another players actions. To understand this ...

... look at the strategy cycle - created from Sun Tzu's factors and John Boyd ...

... now, one of the key aspects of this is how quickly you move around the loop ...

... this means you need to observe the change, orientate around it (i.e. communicate to the right source), decide what you're going to do and act ...

... each of those has a "Mean time to" ...

... hence when a change occurs (such as a failure) then your Mtt (mean time to) Respond depends upon your Mtt to observe the failure, orientate (communicate it to the right place), decide what to do and act upon it ... i.e. MttR is a combination of all these.

Throughout history (as far as I can see), every industrialisation of an act which has caused a major change in MttR has led to a co-evolution of practice ...

e.g. the shift of compute from product to utility, increased the speed we could provision servers (i.e. we could act), hence reduced the mean time to act and hence MttR ... this lead us to shift from ...

... practices such as N+1, scale up (capacity planning), change control, disaster recovery to design for failure, chaos engines, distributed systems (scale-out) to CI / CD. The change in MttR created DevOps ...

... in the Serverless world, the change impacts two parts ... mean time to "act" because of provision of the environment but more important mean time to "observe" because of billing per function. Our ability to respond increases.

... it's this which is leading to a co-evolved practice that combines finance and development. Ignore billing per function at your peril - it changes refactoring, business models, monitoring (through capital flow) etc ...

... if you think that containers because of portability (this has limited impact on MttR bar specialised cases) or because of some slight performance / cost improvement is going to change the world, you're going to be very disappointed. You are missing the bigger picture.

I do mean MttR as in Mean time to Recover. I noticed I used Respond in the above description - you have to respond but the key is to recover from the change which might take several loops. They are very similar except in some cases your first response is the wrong action ...

... so first you need to observe the change (or failure) such as "using respond not recover", orientate around it, then decide what to do "e.g. recreate the whole thread or correct it" and act. Your MttR is made up of all these parts.

Accelerating your MttR is how you loop faster whether it's correcting an error that has appeared or reacting to a market failure or change - whatever it takes to restore the equilibrium or stabilise to a new equilibrium.

X : But that's not how [XYZ] uses the term.
Me : I really don't care. Understanding the importance of a change to MttR was how in 2008 I directed Canonical to focus on new practices before the term DevOps was on the scene. We were all over that space as it emerged. No accident.

... if you want to argue about what MttR means, that's your business. From my business, I am only concerned that as activities industrialise then changes to the speed at which we loop causes a co-evolution of practice. That's all I care about and that's enough to capture markets.

If you still have doubts about how important this change was for me, in 2008 not only did I encourage Ubuntu to get close with every tool related to the new practice, I made my only one hire. Someone I thought had the right background to exploit the change - @botchagalupe

X : If you were MSFT, who would you hire today?
Me : Gosh, that's a loaded question. I'm not in the game today and so I won't answer but there is one person that I could build an empire around. I'm afraid you'll need to work out who she is for yourself. That's enough clues.