Many organisations are embarking on internal developer platform initiatives to manage some of the complexities around continuous delivery in distributed architectures. The scope of these platforms can vary, but they usually involve a mixture of shared infrastructure, managed templates, common tooling, and guidance around best practice.

A key feature of these platforms is the notion that they are often optional. They are part of an ecosystem where a preferred stack is supported centrally, but teams are free to choose their own tools. This pattern is seen in Netflix-style "paved roads" that encourage a culture of freedom and responsibility while reconciling it with organisational goals of velocity and reliability.

Product thinking is often applied to these platforms so that engineering teams are treated as customers whose needs will shape the platform. Incentives are preferred over mandates and participation is secured by engagement as opposed to controlling governance.

This is tied up with notions of servant leadership and inverted leadership pyramids, i.e. the engineer is king and managers should be there to serve the team. It is a natural extension of the agile focus on building projects around motivated individuals. You give engineers the environments they need and trust them to get the job done.

It is also a direct rebuke to top-down technology decision making. This is fair enough. Having served under the yoke of overbearing enterprise architecture teams I know how demotivating it can be to have constraints imposed by distant teams of elders.

However, there may be more top-down decision making involved in these platforms than their advocates care to admit.

Exercising soft power

This talk of choice and engagement may sound empowering for engineering teams, but the reality is that these platforms constrain a team's freedom to choose their own tools. A shared platform creates its own gravity that can be difficult to resist.

Platform adoption is encouraged through the exercise of soft power. Diplomacy and influence can be used to encourage adoption, but the very existence of a shared platform creates pressure to use it. The rhetoric may be about encouraging "wise" and "responsible" decisions, but the understanding is that team will have to support any divergent technology stacks. You've got to be brave to go your own way when there's so much investment being put into a mandated solution.

Product-driven thinking does have its limits. This isn't a free market and there are no competitors. Teams are unlikely to start their own, rival platform. Your shared platform is a monopoly provider, and the choice is to conform or bear the enormous overheads associated with opting for an alternative.

Constraints can be a good thing?

Shared platforms tend to be very opinionated and assert a series of choices around tooling and patterns. This may be inevitable in modern distributed architectures, as simply deploying a container to Kubernetes involves navigating a complex ecosystem of overlapping tools for configuration, security, observability, and such like. A platform normally asserts these choices onto any solution that uses it.

Like it or not, shared platforms are often used as a control mechanism, with templates, shared libraries, and preferred patterns forcing engineers down a constrained path. Platforms inevitably pursue an agenda to standardise solution design across teams to foster greater certainty and reliability.

The quid pro quo here is that engineers will lose the freedom of design in return to free access to managed environments. It becomes easier to deploy, test, and monitor assets in production, it's just that these assets become more homogenous.

This is not necessarily a bad thing. Constraining the decision space for teams allows them to focus on more relevant concerns around business requirements. It stops them spending time on generic concerns around configuration and deployment.

An organisation also needs to achieve some economies of scale. The long-term maintenance burden associated with heterogeneous application stacks can be ruinous. A more standardised approach makes it easier for an organisation to adapt to change and control costs.

Platform compliance is often dictated by financial concerns. It is incredibly hard to achieve widespread platform adoption when engineering teams are split between different cost centres and budgets. If you can afford to go your own way, it's enormously tempting to do so rather than play "good citizen" and adopt the platform approach.

Responsible actors

Like it or not, there is a governance issue here. Allowing teams to build their own infrastructure can be a sign of weak leadership. Engineers aren't above weaponising rhetoric around team choice to justify some strange choices. I have been treated as an ivory tower architect for daring to suggest that a small engineering team might struggle to spin up and manage their own Kubernetes cluster.

There is an assumption is that teams have the skills and experience that they make responsible choices. Some teams will want to do something different because they can. This can be a dangerous argument that justifies all sorts of bureaucratic nonsense, but you cannot assume that teams will always be responsible actors. Let's face it, it's often more fun to go your own way than use the boring platform. It might look better on the CV too.

The idea of an optional, product-driven platform originally gained traction in large tech companies that routinely attract high-powered engineers for six-figured salaries. These organisations can afford to foster autonomous engineering cultures that are underpinned by a high level of technical expertise. The rest of us need to be a little more explicit about ensuring participation in shared platform provision - or at least more deliberate when exercising soft power.

Filed under Agile, Development process and Strategy.