Product Management in Platform Engineering
Treating developers as customers, some examples too. Plus, in the links and quirky quotes sections: finding Monsanto caps at the trade show at the end of history.
Suggested soundtrack: I really enjoy the London Eye show. I don’t listen to it enough.
This morning I gave my talk on platform stuff - platform engineering, building an app stack on kubernetes, etc. It was fun as always. I think there were some parts that were more shallow than usual, but I like the prattle I have going on. I want to revamp it a lot next week and give a mostly new version at cfgmgmtcamp (see below). We’ll see. Anyway: you can watch the replay here.
Product Management in Platform Engineering
As you know, dear reader, I’ve been interested in “platform engineering” and have been content-awaying at it to understand it and see what I think about it. My colleague Judy van Soldt and I wrote up what I think is one of the most important aspects: product managing your platform. It’s in The New Stack today, and here’s a excerpt from it:
If they’re not already using a platform like Cloud Foundry, most infrastructure teams we talk with are focused on building out Kubernetes as the foundation of their platform. These teams generally follow the same approach, what could be called a service delivery approach.
Service delivery-minded teams gather up the performance and capacity requirements, an idea of how many workloads will run on the clusters over the next few years, security and production needs and so on. They then build out the “kool korporate Kubernetes kloud” and are more or less done. They’ve delivered the service and now just ensure its availability.
Now the developers can come and get all the Kubernetes they want — or as much as their quota allows. This approach is more of a project mindset than a product mindset, so it gives us a good way to think about how you would product manage a platform.
The problem with this project-minded approach is that the developers need more than the blinking cursor of Kubernetes; they need ongoing help to figure out what tools they need on top of Kubernetes. And, more than likely, you won’t be able to predict ahead of time what that stack looks like for the unique needs of your organization. You’ll need to discover and evolve it, test out theories … that is, product manage it.
To do that, you should start with developers and find out what they’re doing day to day. There are two common things to start with: mapping out the path to production and improving developer onboarding.
The path to production is based on a value stream map, which charts all of the activities it takes to go from idea to designing, coding, deploying and getting to the people using the software to deliver value. Here’s a hypothetical example:
Be sure to validate this journey map with actual users! Understanding this value stream map will give the platform team an ongoing understanding of their customers, even though not every activity will be the responsibility of the platform team.
With this path mapped, you can start looking for problems to solve. Many of those problems will be eliminating waste, usually by deleting unnecessary steps, improving collaboration between different groups (often called “shifting left”) and automating processes along the path.
Another common place to start is the developer onboarding process. In one survey this year, about 50% of managers in large organizations said they weren’t satisfied with developers’ onboarding time. So, for example, you might target how long it takes a developer to start using your platform from scratch.
Another version could be to measure how long it takes a new developer to contribute meaningful code, to get through the golden path. I’d recommend just asking your developers what would be helpful by running regular surveys to find and track the elimination of developer toil.
When you start with the developers, you can better product manage what’s in the platform. This is not only picking the best fit for features, but also prioritizing how you spend your time.
If you start from the bottom, with just Kubernetes, for example, you might build out more than needed, you might miss adding in a service mesh that works well with your Java developers (or whatever type), and you certainly won’t be able to learn and adapt the tooling and internal developer portal approach you use.
Here are some examples of common problems and features platform teams tackle:
Standardizing the build pipeline and automating the generation of bills of materials for compliance and security
Automating spinning up developer environments
Establishing and improving the internal collaboration tools, like internal developer portals
Finding ways to package and configure new applications to run on the platform or to reduce the time required to modify an app to run on the platform
Modifications to the onboarding portal to add more self-service features
Additional backing services (or “middleware”) such as MySQL, RabbitMQ or Spring Cloud Services
Standard toolkits for cross-cutting concerns like security, logging, metrics and load balancing
Integrations with other enterprise systems, especially your internal systems
Multiple variants of the platform that have different service-level objectives (SLOs) and production characteristics, industry regulations and cloud sovereignty support
The last few decades delivered great advances in infrastructure; now, it’s time to build apps that make the most of those new tools. VMware Tanzu helps you build new apps, modernize existing ones, and evolve your development process around cloud native technologies, patterns, and architectures. Learn more 👉
Wastebook
“the only way I can describe the aesthetic of her account is ‘trade show at the end of history.’” Here.
“I don’t think anybody’s ever won an Oscar for a score that blatantly is bagpipes, heavy metal guitars and a woman screaming at you.” Here.
Time to make the donuts.
“‘Oooo, I’m obsessed, I’m obsessed with it,’ they say. Well, what they mean is ‘I watched it on Netflix.’” Ben Thompson on The London Ear.
After almost 30 years in enterprise software, I want my next thing to be a silverbullet that requires no culture change or thought leadership to use. Gotta go register all the variations of WestrumImmune dot whatever.
“‘Why tattoo the Ace of Diamonds?’ asks Jaki. ‘Always good to have an ace up your sleeve. And I was young and silly once. Just like you.’” -The Seven Moons of Maali Almeida by Shehan Karunatilaka
Relevant to your interests
Wearing globo-capitalist brands…ironically? - ‘Whichever way you slice it, I could easily see a “cool Dimes Square kid” rocking a tight Monsanto strapback soon after this sletter drops. Real talk, I’ve got half a mind to cop this Monsanto cap in particular, which I gotta say slaps darkly !!’ // As always, a fun-gonzo writing style is the real treat. // On the other hand, in doing some social commentary through irony, you can slip into becoming the thing you sought to shame, or at least people will think you have: ‘He knows he’s flirting with the third rail here. Wearing a hat like this will necessarily get a rise out of people in a way that isn’t exactly the same as trying to “own the libs” but does have some overlap. His basic contention, though, is that tons of people worked on Miramax movies besides Harvey Weinstein, and many of those movies were history-of-cinema-definingly great. He rejects the implication that Weinstein’s heinousness puts a permanent hex on a jawn commemorating all that work. And he rejects the idea that this cap can only be read, by default, as an endorsement (this would be true psycho s**t!!) of Weinstein.’ // Too much fashion multi-dimensional chess there.
“By 2027, 75% of enterprises will use site reliability engineering practices organization wide to optimize product design, cost and operations to meet customer expectations, up from 10% in 2022.” From “How Software Engineering Teams Should Work With Site Reliability Engineers,” Daniel Betts, George Spafford, Chris Saunderson, Hassan Ennaciri, Gartner, Jan 2023.
How many software developers are there? Evans 2022 estimate is 25.6m. SlashData Q3 2022 estimate is 33.6m.
“By 2025, 15% of enterprise applications will run in a container environment, up from 5% in 2022, hampered by application backlog, technical debt, skills availability and cultural change. Container management will reach $1.4 billion by 2025 with an estimated CAGR of 25.1%, driven by accelerating digital transformation.” From a recent “Gartner Forecast Analysis: Container Management (Software and Cloud Services), Worldwide.” // The tastiest take-away here is that only 5% of apps (OK, enterprise apps) are running in containers.
A CEO’s guide to the metaverse, McKinsey - “We estimate that the metaverse could generate $4 trillion to $5 trillion in value by 2030” // Seems crazy - perhaps there’s an expansive definition of what “metaverse” is beyond “virtual reality.”
The Cloudcast: 2023 Look Ahead to FinOps - “Matt Ray (@mattray, Senior Community Manager for OpenCost) talks about the evolution of FinOps, alignment between Eng and Finance, and FinOps best practices.”
Upcoming IRL
Speaking engagement and other places I’ll be in the wild:
Feb 6th to 8th, Configuration Management Camp in Ghent, BE - I’ll be talking about platform stuff on Feb 6th. I’ve never spoken at CfgMgmtCamp. I never felt like my type of content fit, but this year, I figured, why the fuck not? There’s an IDP talk that looks interesting too.
March 9th to 12th, SCALE 20x in Pasadena/LA - more platform talking, and hopefully some podcast recoding during DevOpsDays LA. We might even plan a Software Defined Talk meetup.
September 18th to 19th, Shift in Zadar - platform!
Logoff
This is the time of week when I have to go back and look at all those requests to give feedback on some project, or finish up some internal reporting. At first I think it’ll be, you know, not fun. My biggest joy in my professional is clicking the publish button. But, it ends up being fun. I like being in that editor/consultant mindset.
I could probably spend a lot more time in my life helping others make content, plan and strategize. I don’t know: the publish button beckons.
See y’all next time!
good stuff! thanks!