I recently put together some notes on my experience running several different platform teams over the years at HubSpot. They were well-received on the wiki there so I thought I’d update and repost them for external consumption. The experiences come in the context of ten years of work at a rapidly scaling company, so your mileage may vary.
TL;DR I tend to prefer velocity over predictability for at least some of the team’s capacity
First a quick definition to get out of the way – what is a platform team? I think of a platform team as a team managing backend APIs and systems that build upon base infrastructure (databases etc) to provide the core of a product. Many teams rely on that core system to allow them to build out additional facets of the product experience.
Goals
I try to have my teams operate as a leverage-seeking missile – do the next best item based on value per unit time and up to date knowledge about what all our client teams need. I’ll happily upend the best laid plans given a rich opportunity to make an immediate impact somewhere.
Deliver value early and often
I think of value over time in an area under the curve fashion – i.e. the sooner we can get work shipped to our internal customers and then through them to our external customers the more time that work has to garner that value. Delivering “1” value today and “1” next week is better than nothing now and “2” next week.
I like to have our team outputs ready just in time for client team to use; if our outputs are sitting on a shelf somewhere awaiting adoption that’s a missed opportunity to have done something else that would be accruing value.
Never leave a client team blocked
I like to aim for low latency for small requests. If a team discovers they need something they didn’t anticipate and it’s top of mind for them, I don’t mind shifting gears to have our team solve that today. They’re likely to be ready to use the change quickly and we can get swift feedback.
Doing this does require enough slack in the schedule so that we’re not jeopardizing any major deliveries – slack is a valuable asset all teams should get more of. We all encounter the unexpected and teams project managed to the minute are more likely to let those issues fester.
I believe responsiveness is particularly important for a platform team; teams that get a reputation for saying “later” become obstacles and will find their client teams independently implementing features in their own code bases that should be shared in the platform.
Process
An important factor is deeply understanding incoming requests. Don’t just be a request taker. Instead, work with the other team to understand the why and what behind the request and the order in which they plan to roll out functionality. Then we look for the following:
- What do they really need? Looking through their requirements with closer knowledge of what your platform can do may be an opportunity to present alternative approaches using existing functionality or more incremental improvements.
- Do they need everything right away? What’s the smallest unit of work we can deliver now to get them moving on development work, perhaps even delivery of some features?
- When will they need the balance of the work?
Running through this process usually allows us to determine the true underlying need and design a series of changes we’ll make to satisfy those requirements. We can get these documented as issues and get to work!
CTA for teams requesting features: Please spend more time documenting the project requirements and the gap between what the platform provides and less on designing your preferred solution from the platform. We’ll work together on that to incrementally deliver something great.