DEVOPSdigest

Why should we focus on collaboration?

$541 billion dollars(link is external) were wasted in 2019 on useless meetings. Teams that collaborate better can drive up to 21%(link is external) profit growth. Businesses in the UK alone lose around £98.6 due to human error(link is external).The best technology in the world doesn't matter if we can't agree on how to use it.

Who owns what?

Step 1 in deciding collaboration models in a platform engineering organization is to decide who owns what. This seems obvious, but it can become murky. For example, let's imagine the platform team is responsible for creating host servers, and another application team uses those servers. The line is relatively clear — the server issue goes to the platform team and the application issue goes to the application team.

So what happens when an application consumes all of the available resources and kills the server?

Your root cause is application code, but the outcome is a broken application and broken server. Do you assign based on root cause, or on outcome?

This is not an easy question to answer, so it's worth spending some time getting alignment. The best bet is to bring people in early and work on drawing the line together, as a team. This creates skin in the game(link is external) and drives better adoption and agreement.

What platform feature do you build next?

As a platform team, your product strategy is a huge component in how you collaborate with other engineers. They're both your customers and your colleagues. There are lots of ways to prioritize a backlog, but it's important to hit some key points.

Balance Tech Debt with Features

Any good product knows how to manage between features and tech debt. Platform teams sometimes focus very hard on technical debt, because reliability is so important. It's important that, in order to have happy customers, you're delivering what they need. This is especially true in a platform team, where application teams can often be blocked, waiting for your new feature. This will occasionally mean a few messy bash scripts or hard coded values. That's life.

Measure the Business Value

It's tempting to look at the quick wins, or the interesting technology, but what matters most is how quickly your platform unlocks business value. Platform engineering is a model designed to accelerate software delivery, but you have to pick the correct software to deliver.

Some teams have had some success by scoring the business value of a feature. For example, offering the ability to manage a new type of database might unlock a new product venture that needs its unique capabilities, but it's a lot of work. Some values that represent these two opposing forces will help you to cut through the noise.

The Golden Path

When you've decided which features to build, you need to define how to encourage your users to adopt them. Platform engineering at scale cannot be entirely driven by conversation, this type of engineering will become a major constraint on delivery as the platform grows. Instead, engineers opt for the golden path. The way to do this is to implement self service tools that deliver these for the user.

How does this impact collaboration?

Platform engineering requires deep, meaningful conversations with your customers. If you're constantly fielding questions about compliance, it's going to eat into your time. 35% of respondents(link is external) cited a lack of time as a barrier to effective communication between and within their teams. 

Self-service tools are more than just a scaling strategy, they're an optimization that unlocks the space for meaningful collaboration.

Encourage Contributions

Jealously guarding the source code of your platform is a surefire way to drive two negative outcomes. Firstly, your team will feel the full pressure of every application team's priorities. Secondly, your users will feel more disconnected from the product itself, and will begin treating you as if you belong to a separate organization.

Skin in the Game

It's tempting to make an argument about productivity, but the bigger challenge in platform engineering is adoption. Adoption can be driven through a number of methods, but the most organic is to allow your customers to be a part of the solution. Creating a route by which your engineering community can contribute features, even documentation changes, lets them see a little part of themselves in the platform. Nothing drives adoption better than that.

How should you ensure consistency?

When you open the doors to external contributions, you need to ensure consistency of implementation. You do this using the same models and methods that are well understood in open source software. Your core contributors are your approvers, who have also built a series of automation tools to check that the contributor has added tests, updated documentation, followed naming conventions and linting rules and more.

Don't neglect the human connections

Platform engineering, taken to its extremes, puts a wall of self-service software between engineers and consumers. A focus on collaboration early will help to keep that connection alive, and ensure that users and engineers are sharing constant feedback, building trust and, ultimately, creating the human platform that will keep feature delivery running smoothly.