Pace layers, Platforms and software development
I have been spending time reading and thinking about Pace Layers which came to my attention by way of the Not Boring newsletter, which always lives up to its monicker. For those who really want to learn more on this, I’d recommend the book by Stewart Brand, The Clock of the Long Now.
The idea of Pace Layers is this: A healthy civilization consists of layers. Some of these move slow, others move fast (and others in between). All these paces are essential.
Fashion moves at a rapid pace, and gets thrown away on a whim and reinvented in days or weeks. At the other of the spectrum is nature, which moves very slowly — measured in hundreds of thousands or millions of years. Stewart Brand writes that
In a durable society, each level is allowed to operate at its own pace, safely sustained by the slower levels below and kept invigorated by the livelier levels above.
Each layer must respect the pace of other layers. Governance moving slowly enables the system to be thoughtful of changes to society as a whole. It would serve us poorly for the most part if the government moved at the same pace as fashion. When governance moves quickly, we get the Russian & French revolutions.
The following characteristics hold true for pace layers
Fast Learns, slow remembers
Fast proposes, slow disposes
Fast is discontinuous, slow is continuous.
Fast and small instructs slow and big by accrued innovation and by occasional revolution.
Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power.
All durable dynamic systems have this sort of structure, making them adaptable and robust
This led me to thinking about software development, agility and pace layers. I see the following analogy: Fast layers on the top, slower layers at the bottom. All of them serve a vital purpose. Slow layers — platform, business models — wield power. Fast layers — experimentation, releases — allow quick tests and addressing immediate customer needs. Each layer informs the others, and the fast layers must follow the dictums of the powerful slow layers. All of them are essential.
A knee jerk reaction to this picture would be that ‘the fast layers are agile, the slow layers hold us back’. This is really a poor understanding of the importance of the slow layers. Ignore platform principles, and you have an (e.g.) insecure release. Ignore the business model, and your CEO will be breathing down your neck, justifiably, for missing out on revenue goals. Ignore target states and your CTO or Chief Architect will demand an explanation.
The Experimentation layer
Most Software companies have an experimentation layer, enabling rapid testing with customers. Some of these experiments pay off and many are dead ends. This is a the fast layer: Releases and tests in agile companies happen on a daily/weekly basis. Rapid feedback from customers results in an impact on the roadmap & feature releases. For a particularly interesting experiment, the result may influence quarterly plans or even annual plans. The key metrics are number of experiments launched and the percentage of successful experiments.
Feature Release layer
This is the layer associated with ‘sprints’ in agile development. A backlog is developed and worked on, resulting in a release. The typical sprint is two weeks long. Discoveries during & after the sprint informs the quarterly plans, and often the annual plan.
Planning cycles
Most organizations have some strategic outcomes , annualized or sometimes over multiple years. They are then broken down into quarterly chunks that enables tracking towards the goals. I am a fan of ‘working backwards’ — set your goals and then backtrack into your investments and quarterly goals. Arguably, this should be a layer below the platform layer since platforms also have planning cycles. I chose to keep this here because platform planning cycles often are multi year and this is more focused on product planning cycles which are shorter.
Platform Layer
The platform tier consists of company assets that are foundational. Just like plumbing and foundations in a house, this layer is slow to change: As an example, a platform may have a particular cloud provider as a choice. Typically, moving to a different cloud provider is a difficult choice. Some companies may choose to be cloud agnostic — then they are even slower as they deal with varying security models, services, retraining of employees, greater cost. Even simpler example — for example, an auth provider — requires significant work for an platform to change. Yet conforming to the platform layer is an absolute must in tech companies. Where technology teams get into trouble is not adhering to the platform principles and building up significant hard to remove debt.
The Business model Layer
Finally, business models are hard to change. As is often discussed in The Innovator’s Dilemma, a different business model offered by competition is very difficult to adapt to for most companies. The competition often starts out as an ankle biter, easy to ignore — until it is too late. Kodak is often thought of as being unable to adapt to technological change — digital media- however I think of it as being unable/unwilling to change its business model when confronted with the threat.
Platform and Business layers can help create moats. iOS and android are platform plays, and it is extremely difficult to compete against moats. I highly recommend Bill Gurley’s writeup on Android as an example of a moat and the difficulties it creates for competition.
Lock in via the slow layers
The downside of the slow layers are — well, they are slow. A competitor, for example, who creates a new business layer will create a problem for incumbents . Slow layers have all the power — but are resistant to change and requires a massive organizational effort for a transformation to happen.
The downside of the slow layers are — well, they are slow. A competitor, for example, who creates a new business layer will create a problem for incumbents . Slow layers have all the power — but are resistant to change and requires a massive organizational effort for a transformation to happen.
Platforms are key to successful companies. Platforms also evolve slowly. And that is a good thing at peacetime (focus on incremental changes & discipline), and a bad thing at wartime (urgent changes needed). At my current workplace, I choose to hitch my wagon to public cloud as the ‘platform’ and focus on building services natively on top of it — a thinner layer than is expected in most tech companies. This allows us to move at the native speed of cloud, with the attendant downside of ‘lock in’ which is a tradeoff I would make in most cases.
