Managing Platform Teams: How to Structure and Run a Great Platform Team – Interview with Karen Cohen From Wix.com
Even today, in 2019, there aren’t many companies around with their own platform teams. Usually only the big companies have them. There is little know-how going around in the industry, so putting one together and making it work well is quite the task.
Wix.com is one such company in need of a platform team, to serve the needs of over 150 million users, more than 20 products, and the many hundreds of developers working on them.
We did an interview with Karen Cohen, Wix.com’s engineering manager in the platform team. She has loads of experience, and it’s not just as good as gold; it’s a lot better.
She also held a platform product manager position, so she knows the daily workings of a great platform team inside and out.
And she’s sharing some of it too, so let’s grab onto the invaluable lessons bestowed upon us. We'll be touching on:
- Background and job at Wix.com
- Biggest challenges
- Difference between platform teams and product teams
- How does the platform team fit in?
- Relationship and communication between platform and product teams?
- Platform engineering team structure
- When do you need a platform team?
- Best practices for managing platform teams
I am an engineering manager and product architect at Wix.com, where I design and build infrastructure and platform products. I enjoy the challenge of reconciling developer experience and operations, as well as the end user’s goal and experience.
For over 13 years, I have worked on a variety of multidisciplinary projects as a developer, product architect, manager and mentor. I believe in and practice leadership without authority, and I help people understand both the business context and the underlying architectural landscape.
In my spare time, I regularly organize and speak at tech conferences, write a blog, and take an active part in Wix’s R&D events and branding efforts. You can follow me on Twitter as well.
In the past two years, I faced two big challenges. The first was setting an architectural roadmap to slowly fix some of our core legacy systems. I got to talk about how we approached that problem at DevOpsDays Amsterdam 2018.
The second challenge we’ve been dealing with is increasing the bus factor within our team. It takes a lot of trust to make any cultural change, and I’ve been fortunate to have my team collaborate with me on it. I gave a talk about our process at DevOpsDays Riga 2018.
"The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus." It happens where a team member might create critical components by crafting code that performs well, but which also is unavailable to other team members, like undocumented, never shared, or otherwise incomprehensible work to others. Thus a key component would be effectively lost with the absence of that team member." [Wikipedia]
The main difference is between breadth and depth. When a product team makes a decision, it usually impacts that product, but when a platform team makes a decision, it impacts several other teams and products. To perceive the impact of a change, team members must have an understanding not only of their own architecture and flow but also of a wide range of product flows and architectures.
Our team is part of the core server architecture at Wix. We hold information about what defines a website (URLs, apps, rendering and metadata). Our servers are part of every website creation and of rendering flow at Wix.com.
It’s complicated. Platform teams have to walk a fine line between being enablers and protectors. On the one hand, they have to open up as many capabilities as possible, and on the other, they must bind clients from doing harm to themselves or to others.
To the product team, this type of behavior may paint the platform team as inflexible (putting platform before product requirements) and may lead to frustration. Therefore, it’s extremely important to communicate both the need behind the feature and the obstacles facing the platform in order to arrive at a solution together.
There are many ways to structure a platform engineering team. The most basic focus areas are the following: operations (alerting, monitoring, etc.), product (what the user experiences and how it’s impacted by the platform), architecture (how the platform fits in with the general product flow, servers, infrastructure, etc.) and code quality (a must for any team).
Ideally, these would be on the mind of every engineer on the team, but people are naturally drawn to different areas, so make sure you have at least one person leading each of those.
When you need a platform. :-)
When a company gets to a certain size, you start seeing teams implement similar features (e.g., 3 teams building a Google calendar integration, 4 teams building a coupons solution, etc.). Depending on the company’s direction, it may make sense to invest in a team who would own all these features as infrastructure.
Make communication a priority. I find that assigning a point person on your team for each client works wonders. These point people are similar to account managers; they are your clients’ communication line and will be the voice of the clients to you and to the team.
By doing this, you establish other official communication lines (in addition to yourself), test for managerial abilities, and enable your team members to take initiative. Because those point people get unfiltered context directly from the client, it’s easier for them to take initiative and to solve problems on their own.
Of course, all this goes hand-in-hand with maintaining the team aligned with one another and with the greater company goals.
Take time getting to know the background of any problem. Then, work on phrasing the need behind the problem, be it technical or otherwise. When we do this, it helps us reach a wider variety of solutions and to uncover biases in the initial thought process.
This habit keeps all parties learning and growing together, all while instilling humility.
The most important clue that you need a platform development team is when you have different product teams working to implement the same features.
When you have a platform team, they need to work on communication with other departments twice as hard as any other team. Their decisions on the platform affect the product developers, and indirectly the clients as well, so their calls need to be spot on.
This is why their internal workings are also superbly important. Any issue that may come up has a bigger impact to the company in a platform team than it would in a product team, so managers really have to be on top of everything.