Key Takeaways

• Navarro argues that an effective platform team needs to find the balance between setting organizational standards and permitting product team autonomy.
• Standards should focus on “effectively encode and disseminate existing organizational knowledge”.
• Providing the product team with a clear mandate and goals helps them “introduce tools that generate small impacts to a wide surface”.
• Setting a North Star for the platform team as a measurable metric helps ensure that the output of the platform team is meeting the needs of downstream teams.

In his recent article Galo Navarro, discussed his learnings as Principal Software Engineer at Adevinta in building a platform and supporting team to support over 1500 developers. He indicates that companies that reach a certain size tend to create one or more teams to care for their technical infrastructure.

He calls out that the key struggle within these teams is to find the correct balance between setting standards but allowing for individual team autonomy.

Navarro states that “opinionated Platform teams risk coming across as patronizing, ivory-tower-dwelling jerks that impose capricious choices on other engineering teams.”

InfoQ recently sat down with Navarro to discuss approaches to structuring a platform team to enable them to best support the organization.

RELATED SPONSORED CONTENT

From Docker to Kubernetes: Container Networking 101 (By O’Reilly)

Database Requirements for Microservices

Radically Collaborative Patterns for Software Makers

Free Product Owner Learning Path

The 2020 Apache Pulsar User Survey Report

RELATED SPONSOR

**NGINX Plus is the complete application delivery platform for the modern web. **Start your 30 day free trial.

InfoQ: You indicate that for a platform team to be able to make a meaningful impact the organization must have standards. Could elaborate on what you mean by that and what sort of standards you feel need to be present?

Galo Navarro: Sure. The point of creating a platform team is to leverage economies of scale. Organizations create that type of team because they expect to amortize the costs of building tools and infrastructure over the population of engineers that will use them.

Imagine a Platform team that is asked to provide an RPC solution for service-to-service communication, but some of their product teams want to use JSON, others Thift, others Protobuf, others their own custom serialization format. The Platform team is in a tough spot. If they support every choice they multiply cost (dev and maintenance), this is what I mean by spreading too thin. If instead they support only one or two, they reduce their surface of impact. Either way, this team will have a lower ROI for the company. On the contrary, if the organization is able to settle on one standard, the Platform team is able to focus on building one solution that immediately spreads to every engineering team, and can then move on to solving other problems. The team has a higher ROI, and more chances of success.

Standards are inseparable from economies of scale. There is no Internet without a standard networking protocol. No global logistics without a standard shipping container. An organization that creates a Platform team is looking for economies of scale, and must be ready to define and evolve standards if they want to set this team for success.

For your second question, the type of standards that make more sense to me are those that a) address roadblocks / friction points that slow down product teams, and that b) are specific to the organization. Standards that:

• Effectively encode and disseminate existing organizational knowledge. I stress “existing” because I think you don’t want to introduce innovations through standards, but rather consolidate choices that have been tested and hardened by experience, and are trusted to be applied across the organization. These are best practises, successful patterns, scar tissue, etc. Good examples here can be build systems, runtimes, etc.
• Function-like APIs that both decouple and articulate organizational units, allowing teams to make productive assumptions about each other, while remaining independent. An example could be everything around service-to-service communication (e.g. JSON over HTTP, gRPC, Thrift), tailored to org-specific needs (e.g. authentication/authorisation, security standards, instrumentation, quality assurance…)

#platforms #paas #infrastructure #programming #cloud computing #devops #development #article