 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Your customers have limitless demands and complaints — and you have to listen to each and every one of them. You have to sit with them while you work and explain every decision you make. And it’s all happening within the context of your company’s business strategy because you serve many stakeholders.
Does this ring true? Then you just might be a platform engineer — and a damn good one at that.
However, if you’re still at the start of your journey to embrace this platform as a product mindset, you’re not alone. Platform engineering is still a nascent discipline that looks to optimize the internal developer experience at the technological, people and process levels. A lot of organizations are just focused on the first pillar, but that misses the point.
You need to build the habit of treating your internal developer platform (IDP) like a product and your colleagues as your customers.
At FastFlowConf on September 10 in London, I hosted a panel with Syntasso’s Cat Morris, Port’s Maria Lepp, Trainline’s Karen Martin and VELUX’s Emma Dahl Jeppesen about their roles in platform advocacy — which is, at its heart, developer advocacy. Learn from them how to go from your thinnest viable platform to measurable improvements by embracing a holistic Platform as a Product mindset.
The old-school, top-down, cross-organizational platform still has its place. Certain things like zero trust security and role-based access control remain a necessity.
This attitude flips when you adopt an internal developer platform strategy.
Here you have to build something your internal developer colleagues/customers actually want to use. Set up golden paths so delightful that they need a really good reason to stray.
That requires a Platform as a Product mindset, which includes marketing and user experience design, putting time and energy into interviewing your developer colleagues, and even pair programming with them to build empathy. Learning what their greatest pains are.
“What I have seen as being quite high impact as a first use case is giving developers a self-service action to achieve an operation autonomously.”
—Maria Lepp, Port
Only then do you head back to the whiteboard and start sketching out your ideas. Look for the smallest thing you can solve for, which becomes what Team Topologies has dubbed the thinnest viable platform.
“In terms of the thinnest viable platform (TVP), it really just starts with a problem,” said Dahl Jeppesen, a platform advocate at VELUX. She gave the example of the common developer challenge of managing and writing Helm charts, “not trying to build a whole platform of capabilities from the get-go.”
As we look to improve developer experience, another early win for a platform team can be reducing devs’ context switching by just creating more pathways to find things. In the 2024 StackOverflow Developer Survey, 63% of all respondents spent more than 30 minutes a day searching for answers or solutions to problems, while 25% spent more than an hour — every day. That’s a lot of money, considering the developer’s hourly rate.
A solution to reducing this frustrating waste of time could be creating a service directory — including what exists, who owns what — or creating searchable documentation, perhaps with a simple generative AI interface.
“One thing that I see go quite wrong when people think about their minimum viable platform is to try and do a little bit of everything,” said Morris, a senior product manager at Syntasso. But a platform team, she noted, can’t build things in a vacuum: “You need to think: How do I do something end to end? What is the finished job that I can help someone get done?”
A lot of successful platform campaigns kick off with either platform engineers embedding or pair programming with app teams, or inviting app engineers to join the platform team for a time. This fosters empathy and alerts everyone quickly to what’s hampering developers’ workflow.
Then, even before you build a prototype or minimum viable product (MVP), share your prospective solutions with your developers. Get their feedback. Getting them involved early on not only means that you are tightening your feedback loops to build what they really want, but you are also building awareness and brand advocacy early.
“What I have seen as being quite high impact as a first use case is giving developers a self-service action to achieve an operation autonomously,” Lepp said.
Indeed, a platform best practice is whatever you build, make it accessible via an API so developers can build on top of it.
An MVP eventually evolves or goes away. Your thinnest platform layer needs to be built with long-term maintainability in mind. “Do it well and then you can build out from that,” Morris said.
A platform engineer’s job bears similarities to that of a product manager, according to Dahl Jeppesen. “I think a lot of the things I’m doing now I did before as a product manager,” she said, including, “discovery work, user research, applying some UX methods to this field.”
But platform advocacy is still a nascent field. She looks at her role as representing her developer within her organization, especially making sure devs have a voice to communicate with upper management.
While measuring developer experience is considered harder than measuring the results of external products, platform usage is still a solid metric. “How many people are using your platform and are they gaining value out of it?” Morris asked. “Can people hop onto my platform and solve that pain that they’re feeling?”
As previously mentioned, a platform team is beholden to many stakeholders.
“It’s very important to have an alignment across the organization of what is the desired outcome that you want to get from that minimum viable product,” said Lepp, manager of the technical customer success team at Port.
“It takes time to measure value and see ROI. But I think as long as you’re aligned and also transparent with your organization that this is a journey and we’re part of it, and you’re influencing and defining it, I think you will be able to demonstrate success.”
It’s challenging to quantify if you’re offering an IDP that increases value to your internal users. Since platform engineering is deeply sociotechnical, it calls for a blend of quantitative and qualitative metrics.
DORA metrics — deployment frequency, lead time for changes, change failure rate and failed delivery recovery time, according to from Google’s DevOps and research assessment team — is what Martin, productivity program manager at Trainline, calls “gateway metrics” for platform teams.
“It’s really important to give you those initial signals to see where you are as an organization,” she said, specifically around speed and stability.
“How many people are using your platform and are they gaining value out of it? Can people hop onto my platform and solve that pain that they’re feeling?”
— Cat Morris, Syntasso
However, loads of companies just stop there. Meanwhile, she noted, these metrics never tell you the full story.
Look at any metrics you start with as a conversation starter, Martin suggested: “I think it’s about thinking and understanding what productivity endeavors actually mean to your organization because it could be completely different depending on what industry you’re in or how your culture is.”
These initial DORA metrics are two important sides of a coin. You can’t optimize for speed at the cost of quality. And you can’t optimize for time to change, she continued, while ignoring that your engineers care most about having more dedicated focus time.
When in doubt, ask your devs. They are usually quite willing to say what they need.
“If you’ve got the time to have these conversations, get that individual feedback and then that quantitative feedback,” Martin said. “Try to find a way to aggregate that so you can sell a strong story.”
Two years ago, Morris was working at the consultancy Thoughtworks. At one organization, it took months to even get those four DORA metrics sorted.
“It was trying to align all of the teams who were all doing their own thing in their own different way. It was impossible,” she said, as they tried to collaborate over a single spreadsheet. “Whereas we were also in with the platform team doing user interviews, and they would take maybe an hour. Then sending a survey that was like: ‘How long do you think it takes you to do this?’”
In the end, it was a much easier first measure to simply ask developers how productive they perceived they were.
Kick off your internal platform strategy by asking your developers what their problems are, Martin said, early and often.
Team metrics may vary a lot, she said, but ultimately “developer joy and happiness is really what we’re trying to do, which is difficult.”
Of course, measuring developer joy is a whole other challenge. But it is proven across industries that happiness is a major productivity driver.
An added benefit of building an abstraction layer into your internal developer portal or platform is that you can create a more unified view which facilitates more unified metrics.
It can be challenging to get developers talking.
If you can’t get them complaining, Dahl Jeppesen suggested that you try spending time with them and mapping out their user journeys. This can be achieved via pair programming or getting them in a room with pizza and asking them to whiteboard out their onboarding flow or how they use their pipelines.
“They have to go through steps, what they’ve done, what they’re doing, and then have them put into words what they are feeling. What kind of pains are there?” she said. “In the end you have all this data that you can make a curve of what’s good and what’s bad.” This user journey will reveal improvements you can make.
Morris’ teams also follow this UX practice. She recommended that you always designate someone to make sure you stay focused and that all the actions are captured — just remember to regularly rotate who does this task.
Don’t just ask developers, “Tell me what’s annoying you about work today,’ Morris advised. “Then you will just get someone ranting at you for an hour aimlessly without being able to quantify.” Instead, she said, ask specific questions, like focusing on the start of the CI/CD journey.
Also, she continued, to ask them to describe their last experience using the platform. This gives you valuable open-ended data, Morris said, about what people are actually trying to do on your platform. Previous things she’s heard include:
Later, if you’ve built that bit, you can go back to them and check if that satisfied their docs or feature needs.
Another effective question to get devs talking, posed by Lepp, is: “Tell me what your software development life cycle looks like.”
“Very quickly, you’ll find out where the inefficiencies or the pains are, or which part they hate the most,” she said.
Developer surveys can also be valuable, she said, but only if you have a clear aim in mind, measuring a specific aspect of their experience. You also need commitment across your research and development organization that engineers will respond to the survey.
“Developer joy and happiness is really what we’re trying to do, which is difficult.”
—Karen Martin, Trainline
Across the hundreds of interviews this author has done with platform teams, these developer surveys are most commonly done quarterly. And, when they are done in a transparent manner — where everyone can see how each team is doing — and the results are clearly acted on by a platform engineering or productivity team, the response rate grows to around 90%. Even that becomes a useful developer metric to track.
Taking action is important to make developers feel listened to. Just be aware if folks are telling you what they think you want to hear, Lipp warned. Get people in a room with sticky notes or online with a Miro board, she recommended, answering:
You can also host your own Platform as a Product workshop to map these out visually together with your developer teams.
“We know the diversity of engineers and how they communicate,” Martin said. “Have a mix of one-on-one interviews, survey data, some of it may be anonymized, non-anonymized.” And then, she continued, “Look at the whole process and think about: Where do we think there’s blocks or waste, getting them to mark out the process where they have problems.”
Have a holistic balance, she recommended, lest you get stuck optimizing one step in the flow without considering the whole software development process. And always be careful you aren’t overburdening developers with too many questions too often, or you just contribute to survey fatigue.
The panelists also recommended micro-surveys tacked at the end of builds or included in retrospectives that just ask developers to rank, on a scale from 1 to 5, how they feel about the health of the code base. These exercises create important heat mapping throughout your platform engineering strategy.
Download The New Stack’s free ebook, “Platform Engineering: What You Need to Know Now.”
