Platform Extension Sites
Platform Engineering, Cognitive Loading & Organisational Design.
This post illustrates the potential for cognitive overloading in modern product teams that interface with internal platforms and proposes a model which leads to the best experience and outcomes for everyone involved across multiple dimensions.
Many who read this will immediately recognise, understand and appreciate the structure — even consider it obvious. But there are decision makers who don’t naturally see things this way. For those readers I hope to clarify the problem, explain the benefits of the solution and mitigate some other concerns.
Warning: oversimplification ahead. There are many different types of software and many different types of teams. But these descriptions do enough to illustrate the point I am making.
Application Teams
App teams build technical products for an organisation that are differentiated and directly solve problems for end-users / customers.
Front-end teams focus on UX, accessibility, front-end frameworks, front-end performance, security, reliability and quality, integrating with different back-ends and data sources and all of the above for different browsers and devices (mobile development).
Back-end teams focus on API / interface design, back-end languages, frameworks and patterns, back-end performance, security, reliability and quality, integrating with and often managing various databases and data systems and utilising different application packaging and hosting methods.
Full-stack involves all of the above.
Platform Teams
Platform engineering lets application teams tunnel focus on customer needs whilst enabling them to operate with high degrees of independence by making everything else easier for them.
Platforms must be simpler, higher quality and cheaper on aggregate across teams than could otherwise be achieved.
Generally a modern internal technology platform will provide products, standards, abstractions, patterns, automation, documentation, support and advice.
Consumption models include varying types and degrees of tenancy and self-service. From full multi-tenant SaaS consumption to complete self-deployment on your own compute with golden paths to everything in-between. And different parts of a platform will be different.
Platform capabilities
Only considering common technical concerns that an app team might face. Other shared tools might be considered as part of a platform such as collaboration tooling but that user base wouldn’t necessarily be exclusive to technical product teams.
Compute
Machine images, machines, container orchestration.
Networking
Public / private, north / south perimeters, east / west, firewalls, gateways, devices. VPN.
Traffic Management
DNS, CDN, WAF, Load Balancers, API Gateways, Meshes.
Security
PKI, secrets management, identity and authentication systems, scanning systems.
Monitoring systems, alerting systems.
Value stream stuff
Version control, CI / CD, GitOps, automation (testing, chaos, NFRs), more scanning systems. Change and incident tooling. Artifact storage.
Data
Data platforms, insights, analytics, object storage, databases, queues, brokers. Key values.
FinOps systems and more. Of course this is non-exhaustive. Each element has a different width, depth and complexity. There will be things I’ve forgotten or haven’t used and various custom tooling specific to the platform or IDPs which wrap it up. I am confident that this list is broadly representative.
It’s a lot.
Even in the best case with a uniformly mature platform with great abstractions, automation, documentation and support. It’s still a lot to understand to just consume correctly. Of course we won’t always have the luxury of a best case scenario. So add in unhappy paths; add in the organisation of collaboration and feature requests for platform improvement. Then add in unique infrastructure problems to solve outside of the platform. Then add in all of the application full-stack responsibilities mentioned at the beginning. The cognitive loading becomes a bit much / plain silly.
Yes, sure, some can understand it all at a high level. But we don’t work at a high level. We don’t design / build / execute at a high level.
Cross-Functional “Teams”
One of the first things that can be done to help this situation is to have dedicated people in each team to focus on the work that needs to be done to instantiate a platform so it works for the specific needs of the given application team. To advocate for platform improvements and to handle additional concerns regarding infrastructure, automation, tools and NFRs. These could be called DevOps Engineers or Field Platform Engineers or whatever you like.
Modern engineering does demand that each role utilise a broader skill set than ever before but it simply isn’t effective to try and have everyone do everything. That is perhaps as bad as traditional silo structures.
Teams need to be cross-functional so that they have the aggregate capability to control their own value stream and exercise high degrees of ownership and decision-making. Individuals need to be more open and more cross-functional but they do not need to be able to do everything.
Don’t worry. If you are an application engineer and you really enjoy working on this side of things as well that can always be enabled within a team. “All models are wrong, some are useful.”
Platform Extension Sites
Then for closely related teams / groups / units we can form another team made up of the engineers that are embedded in each. It is important that engineers remain directly embedded in the application teams to avoid silo-ing.
A few imperfect mental concepts for this model. The Death Star and an Empire Outpost. A Research Institution that sends equipment and technology to a Remote Lab to create value. McDonald’s Corporate and a McDonald’s Franchise. Remember that platform teams only deliver value when application teams instantiate the platform and make it work for their specific needs.
This helps application teams because application engineers can focus on their own unique difficult challenges where they can achieve the most impact.
This helps platform teams because they have fewer but higher quality interactions, better feedback and a reduced support burden due to skill-sets and domain knowledge and this builds consistently over time.
This helps Field Platform Engineers because they feel better supported together, can share knowledge and can identify opportunities across application teams to work more efficiently on aggregate.
This model doesn’t cost more and it doesn’t cost less. It reduces burden in some areas, allows people to focus more on where they will deliver the most value and streamlines communication pathways. It enables efficiency and higher quality outcomes which lets you move faster and improve faster at the same resource point.
Organisationally this enables career progression for those who work in this space aiding with attraction and retention. It also provides slack for technical leadership positions in these areas to effectively drive structural / systemic change where needed and generally increase quality / efficiency.
I’m confident in this being the best functional approach. I’m not sure exactly where to fit this model in terms of organisation design. In terms of skills the people fit with platforms. But it is absolutely imperative that these Platform Extension Sites embed within and primarily serve their app teams. They need to advocate for their app teams above all else. So there could be several ways to achieve this organisationally.
