How to Build and Run High-Octane Platform Teams — In Conversation With Karen Cohen
By — Mohit Agrawal (Director of Engineering, Urban Company)
Introduction
We recently interviewed Karen Cohen around top challenges in building and running a high-octane platform team. Karen works at Wix as Director of Product Management. She leads privacy products as well as the product for enterprise and strategic partnerships. She is an experienced developer, architect, manager, mentor, and product manager. She has led platform teams at Wix, and has been working closely with different product teams.
Let’s hear what she has to say about Platform Building.
What are the top challenges you have faced while building a high impact platform team?
The top challenge was communication. Bringing in product and business context to the Platform Team’s daily decision making, and vice versa as well as communicating outwards our platforms’ abilities (APIs, architecture) and constraints has been challenging. The bus factor plays an important role in it. For example: if a person holds all the cards (information, ability to solve problems) they are also the only person who can make decisions and communicate outwards. I have a whole talk about that. Reducing the bus factor in our team was a big deal. The talk is called My Tiny Phoenix Project.
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 is also known as the bread truck scenario, lottery factor, truck factor, bus/truck number, or lorry factor. 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, such as work that was undocumented, never shared, encrypted, obfuscated, unpublished, or otherwise incomprehensible to others. Thus a key component would be effectively lost as a direct consequence of the absence of that team member, making the member key. If this component was key to the project’s advancement, the project would stall. [Wikipedia]
What’s the difference between a platform and a product team? How does the communication between the product and the platform team happen at Wix?
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, platform engineers must have an understanding not only of their architecture and flow but also of a wide range of product flows and architectures.
As for communication between platform and product- it’s complicated. Platform engineers have to walk a fine line between being enablers and protectors. On the one hand, they have to open up as many capabilities by implementing the right platform services as possible, and on the other, they must bind clients from harming themselves or to others. To the product team, this type of behaviour 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 to arrive at a solution together and create a unified platform strategy.
What are the best tools or ways to get continuous feedback around platform products?
Talk to your customers. Once a quarter/six-months send each of your platform developers to develop a feature, for a week, with the product group. Before bringing in a platform developer, have them do on-boarding in a product group for 2–3 months. Whenever there’s a break you can take (for example before transitioning a developer to be a team lead for a platform team) have them take a hiatus for a month at a product group.
Have each of your developers be a POC for a certain product, be the champion of that product, and know their product flows by heart. Mind the product. A platform is a tool, not a solution.
How should platform adoption be driven across the entire engineering team?
It’s like any other product. If it’s not useful to your customers they won’t use it, they’ll find workarounds and hack their way through the problem. You need to show them there is real change happening in a direction that serves them, otherwise, they won’t even try.
Showing them change is a cultural thing. In some places, it simply means bringing in new blood, a person who’s approachable and personable and who’s got that mission statement written on their forehead. The culture is different for every organisation, city, age group, etc. When approaching this problem be as cynical as possible and keep asking, “As a client, what’s in it for me (WIIFM)?”.
How important it is to solve for the legacy which has recently started causing issues?
It’s important only if it serves a purpose. Legacy code is not a problem if it provides value and doesn’t keep you from moving forward with your business objectives.
If you can recognise a piece of the puzzle, will be a problem in X amount of time, plan for that ahead of time, put in some effort to take care of the issue.
How should product teams handle the engineering OKR’s along with business and product requirements?
I assume that by Engineering OKR’s you mean items like uptime, time to resolve an issue, response time, etc. These metrics are always tied to the business/user expectation. If a service is down but no one is using it, do you care? You don’t. This is where a holistic view of the system is necessary. Let’s say we want to improve response time. It’s not enough to say “We need everyone to work on their response times”. We need to understand where the bottlenecks are in the system and focus on them. We also need to have metrics to be able to understand whether or not we managed to improve at all. So, the question keeps going back to - what are you trying to achieve (this is a business question) and what is holding you back (this is the engineering question).
If there is a part of your system that is hard to make changes on — but no one ever needs it to change — find a way to reduce maintenance costs for it and move on. If there is a part of your system that is hard to make changes on and you find that it is continuously a bottleneck, understand how it is a bottleneck, take measurements, make a plan, measure yourself as you go.
[Follow-up] But it’s really hard for a business to understand the futuristic leverage of re-design, refactors, or optimisation for that matter, as business teams have delivery targets which are hard to push back?
That’s a time trade-off. Similar to depositing money in the bank. You can have your money now and buy that piece of candy, or you can put it in the bank and buy two pieces of candy later.
It’s up to you to reflect that. For example, you should ask how many more deals will we see of this type? Meaning is this a one-off or is this something we see repeating itself. You can always start with a hack in your code and when the third or fourth case comes along you make a better solution.
What should be the size — the platform team vs the product team?
In my humble opinion, staffing should be done once there’s a roadmap. There were times when the team was one person, there were times when it was 8 people. I’m a big believer in the agile allocation of resources. However, that may not work for many companies, it relies heavily on a certain culture that not many companies aim for.
[Follow-up] Yeah true, and I think product teams have more leverage there due to business-driven push, so a product team’s resource allocation is more agile than that of a platform team?
That’s exactly what we should change when thinking of platform products. Once you familiarise yourself with the different product strategies (of the products you’re serving) you should then create your strategic roadmap. Think about the changes to the platform which will allow you to provide better service to the different stakeholders. Understand what may hold them back in the near quarters vs future years. What are the biggest problems your clients will be facing and how do you fit into the solution.
Once you have a plan you become proactive. You may start spotting product solutions that you can help with or even initiate new ones.
Conclusion
Based on the conversation, we can say that the platform team needs to make sure that they work in great synergy with the product teams, and add value to them. Each platform engineer should recognise product team’s pain points. They should work closely with the product team and help them out by building platforms which provide ease of development and save time.
Most of the times, glitches in platform products have larger impact than glitches in product flows as platform issues impact all overlying product flows, so platform engineers must be on top of everything.
About the author –
Mohit handles core platform at Urban Company. He likes to build standardised and opinionated solutions which solve for data analytics, developer experience and productivity, application security, and infrastructure reliability. In his free time, Mohit loves to travel.
Sounds like fun?
If you enjoyed this blog post, please clap 👏(as many times as you like) and follow us (@UC Blogger) . Help us build a community by sharing on your favourite social networks (Twitter, LinkedIn, Facebook, etc).
You can read up more about us on our publications —
https://medium.com/uc-design
https://medium.com/uc-engineering
https://medium.com/uc-culture
https://www.urbancompany.com/blog/humans-of-urban-company/
If you are interested in finding out about opportunities, visit us at http://careers.urbancompany.com
