Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword
Platform Engineering

Tame the Tiger: A Lighthearted Guide to Platform Teams

A few lessons learned — often from mistakes — about scaling an organization and navigating the complexities of platform team development.
Dec 8th, 2023 10:30am by
Featued image for: Tame the Tiger: A Lighthearted Guide to Platform Teams
Image by Brigitte Werner from Pixabay.

In the grand scheme of successful products and burgeoning teams, there’s a lurking entity that rarely gets the recognition it deserves — the elusive platform team.

Having steered the ship of two platform organizations in my career, I’m mildly vexed by the scant attention our community bestows upon the delicate art of chartering platform teams.

These teams, by their very nature, become the Achilles’ heel of both the product and the teams they serve.

Can you honestly say you haven’t encountered an internal team that cheerfully asked you to wait until the next fiscal quarter to address a bug you diligently reported?

In this article, I’ll share insights from my time at Google, Firebase and Zynga, particularly from building platform teams. I’ll focus on lessons learned — often from mistakes — about scaling an organization and navigating the complexities of platform team development.

What Are Platform Teams and Why Have They Proliferated?

As organizations evolve, leaders cast their net wide in pursuit of efficiency amidst a growing workforce. Platform teams have emerged as the golden ticket, promising an array of efficiency gains:

  • A reduction in duplication across product teams (think core services like observability, DB and storage, DevOps and engineering productivity tools);
  • The facilitation of hiring specialists for those nitty-gritty skill sets (Ops, mobile development, frontend, data science, metrics and more);
  • The strategic standardization of services, rendering you impervious to fretting about these details as you scale and rearrange your teams.

Indeed, the concept of platform teams is well-established, replete with standard organizational shapes we’ve grown accustomed to.

However, the very efficiencies we cherish often double as the culprits behind inefficiencies. We’ve learned to grin and bear it since the overall balance remains positive.

But, as it turns out, we could do way better.

The Side Effects of Outsourcing Costs

If there’s one gem of wisdom to pocket from this article, it’s this: minimizing externalized costs is the crux of platform org design.

What are these externalized costs, you ask?

Picture this: you’ve set sail with a release engineering (releng) team at the helm, responsible for your organization’s grand releases.

The catch? There’s a slew of unavoidable manual steps and legal tango dances involved. Crafting a self-serve release model suddenly feels like unraveling the Gordian knot.

The releng team opts for an easier route — the release train. Product teams hop on the release train, waiting for their ticket to be punched.

Product teams must now pin their hopes on the release train’s reliability, meticulously scheduling their grand unveilings and messaging campaigns.

But here’s the kicker — hotfixes and emergency releases are the curveballs that’ll leave you swinging. The release team, in all its wisdom, has to ponder, “What qualifies as ‘worthy’ of a Friday night hotfix?”

Since the costs of releasing are external to the product team, guess who’s playing the villain? Yup, the release team, slowing down the release pipeline and setting the bar for hotfixes impossibly high.

Flip the coin, and you’ve got the costs of leaving a prod bug unattended until the next scheduled release, all neatly externalized to the release team’s detriment.

The solution? Maintain the release trains but whip up a self-serve, well-documented hotfix process. Let each team determine their weekend-worthy bug fixes, and suddenly, the costs of releasing become as internal as that hidden stash of office snacks.

Chargebacks: Because “Who’s Paying for This?” Is Not a Joke

As your organization scales, teams groove to their own cadence. Syncing up becomes essential, even if it feels like a corporate hoedown. When choosing between competing team priorities starts to feel like a reality show elimination round, you know it’s time to up your game.

Chartering a platform team should come with a promise of everlasting sponsorship. Leaders must continue backing their requests beyond the chartering ceremony. Abandonment is not an option!

What’s the secret sauce to making clear decisions, you ask? Chargebacks! These are your golden tickets for costs that stubbornly reside outside the product team’s purview. We’re not just talking about the usual suspects — compute, storage and metrics teams offering up their own versions of IOUs.

Think outside the box:

Remember our releng example? Measure the time taken for releases in SWE hours (a quirky but effective metric). Product teams chase cost efficiency, and the release team aims to be the life of the party, constantly slashing the ticket price for teams on the release train.

Deprecations, anyone? Teams planning to bid farewell to legacy versions can slap on a fee for continued support on those obsolete platforms. Suddenly, it’s a bidding war!

Supporting the Talented Side of Platform Teams

As previously mentioned, one of the prime reasons for setting up a platform team is to become a magnet for niche expertise. (Ops, mobile development, frontend, data science, metrics — you name it.)

But tread carefully, for you’re about to dive into the realm of performance calibration.

It’s time to tweak your performance guidelines. The usual accolades for expertise in critical areas? Not anymore. If you’re the “security guru,” it doesn’t automatically grant you a high-performance rating. Remember, impact metrics like qps aren’t calibrated against the product teams’ scorecards.

If you’re centralizing specialized talent, go all in. Don’t scatter (say) your mobile devs among product teams while maintaining a central mobile team.

You’ll end up with a game of musical chairs having to plan opportunities equitably and calibrate the impact of individuals with unrelated job responsibilities.

Centralization isn’t a one-size-fits-all deal. Choose which functions to centralize wisely, based on your products’ needs. For instance, centralizing UI designers might seem like a smart move, but if your product thrives on brand identity, treating them as a shared resource might just stir up a design showdown.

To PM or Not to PM: That Is the Question

The age-old debate: should platform teams bring on a PM? I stand firmly on the side of treating your offerings like a gourmet dish and your consumers like discerning foodies — this demands product management.

A platform PM’s role might sport a different hat from the norm, but team chemistry and crystal-clear expectations are non-negotiable. PMing here isn’t about grand creative endeavors; it’s a symphony of organizational wrangling, systematic communications and operational finesse. Not every PM is cut out for this particular dance.

While the temptation to swap a PM for a TPM (total product maintenance) might linger, nurturing your platform service like a prized orchid will yield better fruit for all.

Remember our organizational wrangling? If PMs in product teams dance to the tune of top and bottom-line metrics, having a platform PM speaking the same language at prioritization sessions is a game-changer.

And that, my fellow readers, brings us to the grand finale! Best of luck with your platform teams — may your charges be fair and your releases as smooth as butter!

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Flip.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.