Building a platform team at a fast-moving startup

What is a platform team?

Although most organizations tend to describe a platform team slightly differently, on a fundamental level, a platform team is the team that has centralized expertise and ownership. At the same time, it should allow a healthy amount of control and customization by product teams. The platform team is also broadly responsible for improving the organization's flexibility and developer productivity.

How to build a platform team

Identify roles & responsibilities

Answering some questions like what are the team's roles (which pieces of the software puzzle will they build/own/maintain) and responsibilities (what they're accountable for, what they can do to build a working relationship with other teams, how often they communicate with other stakeholders, etc.)

Write a mission and/or vision statement

The team's mission statement should help align the team on its core goals and build a sense of camaraderie and shared ethos.

Poach & grow talent internally

Often at an organization's growth phase, there are pockets of tribal knowledge and SMEs that are invaluable in understanding a system. They are the flesh-and-blood documentation of a system, and can be much more quicker at adding value to a platform team than a new hire.

Build trust

Many engineers are often resistant to change and care deeply about things they've built. Often times the platform team can come in and re-architecture or change things, leading to some friction. The platform team needs to build trust first before they can get buy-in from the development team; after all, they're the platform team's customers.

Lay down best practices

Unlike development teams, one of the stated goals of a platform team is very good documentation and detailed guides. This helps immensely in —

1. Boosting developer productivity.
2. Clearly communicating the team's vision.
3. A solid framework to iterate upon.

Documentation is the lifeblood of the team and it cannot be seen as a separate task in a sprint; it has to be given equal importance as (sometimes even greater than) code.

Take ownership and build accountability

As the platform team starts to take shape, taking voluntary ownership of either legacy systems or new systems that they've built is important. This frees up developers to focus on external customers' deliverables. Becoming accountable shows that the team is growing and maturing, and that they're a key part of the chain of trust.

Establish a communication API

Crisp & inclusive communication of what the team is working on, what it plans to achieve, the risks it perceives and helpful tips to developers (even as JIT) at a predictable cadence is very important to build more trust and effectively participate in larger efforts inside the organization. This can also double as free PR for the team!

Create a feedback loop

Every member of the team can appreciate —

1. An external frame of reference.
2. Validation for their ideas.
3. Gratitude from seeing their work positively impact a developer or a product.
4. Inputs that drive them to build cooler stuff.

A feedback loop manages to keep the platform team engaged with their customers (developers and product teams). It offers valuable insight into their core demographic, and helps not silo them away from the rest of the organization.

Publish data, metrics and internal SLAs

The team should regularly publish data on —

1. Development progress.
2. Technical backlog.
3. Issues fixed.
4. Performance improvements made.
5. Security threats mitigated.

A dashboard or a status page can help communicate the team's effectiveness to everyone at the organization. Additionally, at a certain level of maturity and stakeholder confidence, it is worthwhile setting up an internal SLA that holds the team to a higher standard.

Enable a self-serve platform

As the tools and the platform itself matures, they should evolve in the direction of automation. This becomes a force-multiplier for the team itself, making room for even faster iterations, bigger goals and a more stress-free environment for the platform engineer.

Challenges & possible solutions

While there's a lot of compelling arguments for building a platform team, there are also a few challenges that they can face.

Disillusionment & disenfranchisement

More times than often, the platform team is a disruptor. It has the wisdom of hindsight and knowledge of past mistakes to learn from, and it aims to fix a lot of things. This can often understandably lead to a sense of disillusionment (and perhaps a sense of betrayal) in some engineers that wrote legacy code.

This can be handled by bringing on those same engineers to the platform team either full-time or as loans, giving them an opportunity to fix their old mistakes (because a good engineer will always do that happily).

Fragmentation and more silos

A classic growing pain in any startup is fragmentation of expertise, and ever-so-slightly increasing over-specialisation. As more teams are formed with a more specific focus, knowledge tends to become hidden in pockets more and more.

To be honest, I personally don't have a good solution for this problem. Perhaps it is wiser to accept this as a part of growth and evolution. What can perhaps make it easier to gain wider acceptance is clearly set expectations upfront. Cross-functional knowledge sharing can be built with more documentation (perhaps tailored to team-specific personas) more forced collaboration (internal hackathons, regular presentations, etc.).

Loss in development velocity

High development velocity is highly favoured in the world of agile startups. Developers tend to view any additional process as bureaucracy and view them as a waste of time. The platform team has its own deadlines, but also has to efficiently manage the time that the development teams' output spends in its quality gates (compliance and regulatory requirements, specific Dev(Sec)Ops tool checks, etc.).

Striking a good balance between keeping the development teams moving forward but also making sure all best practices checks have passed is a skill that only be developed on-premises, and it is very finely tuned to the organization's culture and it's people.

Growing technical debt

Technical debt is the bane of developers' existence, and we all wish there was a magic wand we can wave to pay it all off. However, in the real world, the onus of clearing it often falls on the platform team. This can be a double-edged sword, as it can often be the draw for some engineers, but can be a deterrent for others.

This can be solved via regular internal hackathons based on debt. Perhaps additional incentives (not necessarily in monetary form) can be given to independent contributors and teams that clear their backlog. This can also be gamified — for example, a team can gift anybody X "brownie points" for clearing off some debt item; "brownie points" is a placeholder for an incentive of some kind.

Impedance mismatches in prioritization

Following best practices will not always be the top priority for a lot of development teams, while it is the other way around for a platform team. There will almost always be some impedance mismatch between the two teams because of this and every member has to be sensitive to this.

Project managers can help strike a balance here. The platform team can also groom champions or ambassadors that can rally around the team around compliance with the best practices checklist.

Trust-building

Building trust is of prime importance, doubly so for a new team. Also compounding this issue is that the security team has a tangentially different focus than the other teams, requiring way more effort in building trust and gaining equal footing at the organization.

This will probably be a slow process (especially if there are new hires on the team), but can be achieved with heavy focus on transparency, relying on data as truth, seeking buy-in from other teams and involving them in platform decisions and finally some good old dogged persistence.