⬅️ Buf.build Your REST 🧭 Map of the Platformatique ➡️
IDP Wasn't Built in a Day
Music: Morcheeba - Rome Wasn’t Built in a Day (2000)
This week we look at similarities in platform engineering, data operations (DataOps), and revenue operations (RevOps) teams.
Getting Informed
As mentioned previously in Fudge Sunday, an Internal Developer Platform (IDP) can be thought of a uniquely custom stack or toolchain. The group of engineers that support that stack or toolchain are the platform team.
https://fudge.org/archive/happy-when-it-toolchains/?utm\_source=jaycuthrell&utm\_medium=email
From my perspective, if you compare the goals and stacks of a platform team to the goals and stacks of a go-to-market (GTM) data operations (DataOps) or revenue operations (RevOps) team, the argument can be made that there are a particular set of learnings to be had from interlock. I also believe there are similarities in the advantages to managed alternatives to replace more manually intensive design choices.
In this day and age, it’s so easy to stress 🎶
Last week, Evan Dunn at Syncari asked me a simple question (paraphrased). Evan’s question led to an elongated issue of the newsletter.
_Hi Jay. What are your observations on GTM data quality impact for revenue teams – especially with unicorns?_ – Evan
You could say this question really plucked a string or struck a chord (nerve?) — and so I had to respond — and I did so _within seconds_.
_Evan – oh wow! This might be getting on a bit of a soapbox. The fragility of data stream is what I’ve noticed. For want of a nail… For example, it’s not uncommon for a unicorn to experience turnover in the key team members that created heroic pipelines when a systematic pipeline would be documented sufficiently enough to be survivable._
_Jobs are so plentiful that you can’t fault the individual contributor for grabbing at the next brass ring. However, you can fault GTM leadership for not insisting on pipelines that are precariously held together by sheer manual efforts by their under-appreciated RevOps team members._
_Result: You chase waterfalls in revenue, mirages of margin, and get distacted… squandering time through losses from opportunity cost that compounds when you are literally sticking a wet finger in the air to gauge GTM signal._
Also, I’ve been reading the newsletter of another Customer Data Automation Community team member, Greg Meyer. You should subscribe right now if my reply struck a chord with you too.
Naturally, I believe my opinionated reply was much faster because I have been reading Greg’s newsletter.
When I read Greg’s newsletter, I cannot help but see patterns in DataOps and RevOps that are closely aligned to the same goals in platform engineering pursuits. Indeed, there are _pipelines_ that a DataOps and RevOps team must maintain for the GTM team just as their are CI/CD _pipelines_ that a platform engineering team must maintain and streamline for maximum software engineering team development comfort and increasing productivity.
Raising a data pipeline or an IDP might require a village. But, does it have to be that way every time or all the time?
I’m having a daydream we are getting somewhere 🎶
Of course, adopting a _managed to-be_ toolchain that replaces the _manual as-is_ toolchain will have implications on the team composition and requires a focus on ruthless removal of annoyances associated with undifferentiated engineering[1]. Then again, the adoption of a toolchain might start with one or more parts of a complex and precarious _single-point-of-vacation-failure-engineer_ time intensive pipeline.
Speaking of _pipelines_ that are survivable designs, I do believe that my attempt at a Wardley map last week points to a future where Cloud Service Providers (CSP) will have opinionated stacks that can replace portions of the custom layers within toolchains and, perhaps, those toolchains within an IDP.[2]
https://www.infoq.com/news/2023/02/aws-deployment-pipelines/
So, what will be the next big thing in platform engineering, data operations, and revenue operations?
Until then… Place your bets!
Disclosure
I am linking to my disclosure.
Shout out to Paul Swail ↩︎
Shout out to Renato Losio
🤓 ↩︎
