papajuans weblog

Writings and notes

Platforms in Retrospect

Posted on • 1367 words • 7 minute read
Last updated on

Here’s a collection of thoughts that I put together after running a platform group at my old company for 6 years. I led a group of about 50 people across 8 teams that was responsible for all content systems - from authorship all the way to end-user delivery.

Note that when I write “platform” I’m referring to teams responsible for shared component/service that other teams use to deliver features to end-users. I am distinctly not referring to infrastructure platforms aka “internal developer platforms”.

Avoid ownership purgatory

If you read Alex Ewerlof’s Archetypes of Ownership (and also Bryan Cantrill’s name change suggestions), you’ll come away with a nice framework for understanding the elements of proper “ownership”. For teams that sit behind-the-scenes of end-user facing groups, there’s a very real possibility of falling into one of these six archetypes - largely because you’re often delivering stuff to enable another thing. When the final value created requires work from another team, there’s a dependency that creates weird ownership lines between the stuff end-users see and the thing(s) that drive it.

I think for platform teams the broken archetype I found most prevalent was “foot soldier” - missing the “mandate” pillar. Because of the dependencies on other teams to realize value, there’s a difference between the mandates of platform and delivery groups. This gap is what creates weird ownership boundaries - platform groups deliver a seemingly more utilitarian component to be leveraged by other teams, but when few features or groups are using that component the separation of mandates feels needlessly forced and possibly a useless abstraction.

You can avoid this awkwardness by having the right collaboration model and associated activities. Joint projects where there’s shared ownership in the initial phases have been, in my experience, the most effective and efficient way to both prove value and find the appropriate system boundaries.

This sort of fragmented value chain is common and sometimes cannot be avoided. Note that this isn’t necessarily bad. In fact, one could argue that service-oriented architectures prefer this sort of fine-grained setup to enable autonomy across large engineering teams. However, these on-paper benefits of SOA really occur at engineering teams at a large scale and moreover, are often evaluated in retrospect after the product and engineering teams have sniffed out the appropriate boundaries and value.

Which ties into my next point…

Avoid premature abstractions (sometimes)

I think for a lot of engineering leaders (myself included) there’s an inherent ickiness when you see duplication in code or components. Which makes sense - as software engineers we’re trained to abstract things out in order to remove duplication (DRY, etc). And for good reason - abstracting things out can solve larger classes of cases than the one originally presented.

This holds even more weight for platform groups - ideally we want to solve entire classes of problems and enable multiple clients all at once.

However, there are 2 penalties when you strictly and blindly apply DRY principles at the coarser levels of your system - ownership purgatory as outlined above but also speed of delivery. Going through the software/product process that takes an initial idea and abstracts it out in order to account for future use-cases takes time and inhibits creating momentum.

This is often the case when a new idea is presented - take for example a new feature UserLikes, where a user can “like” a thing. This might naturally need a UserLikes API; but someone smart sees UserLikes model is actually a special case of a more generic UserVoting API, so instead we should really make a UserVoting API that can do both the original thing and more! Of course, to do the original UserLikes thing, we need to special case some client-side code from the UserVoting API, but that’s “just an implementation detail”!

Note that there’s honestly no right or wrong answer to this contrived example - it’s all dependent on the organization and potentially what exists (maybe UserVoting already exists). And if you’re in tune with some of the random debates on DRY itself - this probably sounds familiar.

The point here is that rushing to more abstract solutions (eg building UserVoting instead of UserLikes directly) for unproven and unknown features takes time that can drag down your overall delivery cadence. And if you plot the time/value being generated from premature abstraction, it’s most likely a sub-linear - which isn’t ideal.

Experienced leaders and staff (either with key institutional knowledge or just plain good judgement) often minimize the wrong abstraction naturally by both knowing where boundaries should be but also making well-calculated bets on how much to abstract in the first place. I don’t think there’s any set formula on this but if you’re unsure, skewing conservatively towards always delivering immdiate value is at least a linear progression - which can help build much needed moementum.

And as with everything engineering, there are of course exceptions. Big capital investments in large technical projects easily break this rule - but note that there’s typically broader organizational alignment for activities like this in the first place.

This idea I think is similar to martinfowler’s website around that shares a similar sentiment - HarvestedPlatform. The gist of it is that you don’t begin with the idea of a shared component but instead you make it and refine/evolve it to potentially become into a shared component. This idea fits nicely with both gaining momentum and also avoiding ambiguous ownership.

Seek alignment at every turn

Platform teams naturally have more bureaucracy to navigate to find alignment. This can easily be overwhelmingly exhausting - platform groups often have their own vision/idea while their feature teams can have a differing set of priorities. But prioritizing alignment is the most critical step for platform engineering leadership in avoiding the pitfalls above.

What does alignment look like? Tangibly, it means being able to explain very clearly and concisely between the work being done and the end goals of the organization. When you’re able to express to your team(s), your peers, and your management about why and how this work will effect change in the right direction, you’ve (hopefully) created a train of thought that easily links the “why” with the “how”. If you have trouble explaining this concisely - it’s a smell; either the project scope/definition needs refinement or the manner in which you’re communicating isn’t effective.

There’s no perfect process for creating alignment; it’s a soft-skill that requires a lot of exercise and also highly dependent on organizational circumstances. In my experience, this is often started in “official” planning ceremonies (OKRs, quarterly planning, etc), but often transitions (and typicaly more productive) through to side conversations. And this is where strong peer relationships are most valuable - either in evangelizing your own ideas or collaborating with others to find out how you can fit in.

If you’re in a mananger-of-managers position, this is most certainly not an exercise in screaming “be aligned!” to your direct staff. Your job is to create the circumstances of alignment by both ensuring that the right people are conversing (internal and external to your group) and also that they’re aligned with your own objectives. And similar to yourself, you’ll know you’re headed in the right direction when your staff can paint a relatively clear picture between their projects and the overall goals of your group and the broader organization.

I’ve made all of the above mistakes in my tenure and I hope these bits are helpful if you find yourself in the unique position of running platform groups. If you have questions or comments, drop me a note at ryan@heythatsmypizza.com.

More Readings

See Also