https://platformengineering.org logo
Join Slack
Powered by
Hi <@U02MTEBU53M>, I love the idea of the Platform...
# platform-blueprints
p
Hi @Manuel Pais (co-author Team Topologies), I love the idea of the Platform as a Product and I'm trying to adopt this into my company. The interesting part of your talk was connected that Platform should be some kind of a bridge to new technologies and innovators that keep eye on the new ideas and pass them to the stream-aligned Teams. Are you familiar with cases of treating Platform as a sometimes interrupter and not helper in introducing stuff? That Teams are okay with what they do (even if it's not effective) and there is some kind of pushback of changing the things that are working as always. Do you have any histories/examples how to break this wall? We are trying to find metrics, evangelize why something is important but it's quite difficult. Another questions: did you meet a Platform for Frontend? I mean we have a monolith architecture in our frontend approach to our pages and frontend developers spread around the Teams. According to Conway law, the monolith frontend that was designed to be shared across different teams, turns into monolith that everyone builds their own things into it and there is no sharing components between Teams. I'm thinking that Platform for Frontend would be a good option, any similar experiences?
πŸ™Œ 1
m
Hi Piotr!
So the shift you need in the platform is to focus on user adoption, engagement, and satisfaction.
This sounds a bit like a startup, right? Well, that's exactly the point. Find out what differentiates the internal platform, how you can really help the teams reduce cognitive load and accelerate.
Not all teams will "get it" at first, or care about it. And that's ok.
Consider the adoption lifecycle for your platform services/features.
Some teams will be early adopters of what you offer, others will wait and see, and some might be quite reluctant in fact.
It's a bit of a "trap" we have bought into thinking we're done when we make a feature available to our internal teams.
That's just the start of that feature's lifecycle actually.
You should have already early adopters for that new feature (because you collaborated with the teams that requested it, right?)
Next up is to focus on early majority, start "marketing" the feature/service and identify any major roadblocks/friction for more teams to adopt it.
You might find out the feature is not adequate for many teams, then you have to go back to the drawing board.
Or, like you said, teams are too busy to "change", then it's on you to lower the cost of adoption.
We go into a lot more depth on all these aspects in our Platform as a Product online training btw: https://bit.ly/3MS88Pt
(use conference code platformcon-15off for 15% discount)
As for the Frontend questions, what I've seen sometimes are "design platforms" or "design systems" but those have more of a UX/UI focus. Here's an example from NAV, a gov org in Norway: https://teamtopologies.com/industry-examples/how-the-internal-technology-platform-creates-value-at-nav
They say: "The design system is a library of design components, guidelines and good practices. The main user groups are designers and front end developers."
The difficult thing (one of) about platforms if evolving the boundaries of what's in and out. I would expect that for frontend as well.
p
perfect with the frontend, this is exactly the idea of building Design System team, thanks for the article
πŸ‘ 1
but regarding being a frontrunner in new technology ideas - should we sometimes "create" a need for using some tooling/change the current approach? But that moves us into salesman territory and selling vacuum cleaners that maybe no one wants / is reluctant to use and selling creates a major frustrations. Do you think there is a place for such kind of projects on Platform roadmap?
j
in my opinion, if you treat your platform as a product, then you follow the playbook for product management. The one definition of product management that I like is that PMs empower product teams to solve hard problems – customer problems and business problems – in ways that customers love, yet work for the business. In your example, I don't think you should ever create an artificial need for a new tool. You should be driven by what problems to solve, and the tools are a way to achieve it
πŸ‘ 1
m
What Jessica said πŸ™‚ Also the drive for better tooling should be mostly internal to the platform, not "pushing" new things on the consumers.
If a new tool or piece of tech makes things simpler for the platform teams, then go ahead. Now depending on the kind of abstractions the platform provides, this might have varying impact on platform users so you'll need to consider that, collaborate with them to figure out a reasonable plan forward that doesn't suddenly increase teams cognitive load because "oh my god we have to use this totally different tool now to do the same thing we did for the past 6 months" πŸ™‚
But we're talking about evolving the tech in existing platform services, not on artificially creating the need for new tooling on the platform users.
Finally, if your goal is to help teams improve their workflows and/or ways of working by having them use a different tool, then talk about it with them, empathize with how difficult/time consuming that might seem for them, discuss the value/cost ratio with them, and how you can help simplify that.
p
Thank you @Manuel Pais (co-author Team Topologies) and @Jessica Ulyate, much appreciate your feedback
πŸ‘ 2
m
thank you for this thread, it comes at the right moment for me πŸ™‚
πŸ‘ 1
27 Views
Open in Slack
PreviousNext
Powered by