Hi folks, I'd like to learn from you all on how you approach support. For scoping, let’s talk about supporting engineering orgs of 1000 or so, with a platform org of 75 or so. Like most platform orgs, the focus is on enabling engineering by reducing cognitive load and manual toil. What has worked for you? What has failed? Stories welcome!

It will all stem from the culture you set. How do you outline the mission and values of your organization

Also size of organization changes this pretty significantly.

Thanks @Andrew Fong and @Andy Fleener, I 100% agree with you. I am not looking to lift-and-shift from anyone here directly, I'm just looking to hear how you all are addressing this need today. I'm curious about what factors you consider, and how you've organized yourselves to solve this problem. It sounds like you both have been managing this. Can you share more about what you all do?

Yeah I mean it depends but in general trying to build a community via “internal open source” model is a high level strategy I’ve been trying to use.

Interesting! So in that model you’re actively encouraging co-development of the platform then?

correct. You can’t build an effective platform without direct honest feedback on the value of what you’re building.

Agreed. To address the feedback bit, I’ve done detailed customer interviews / jobs-to-be done analysis. I’ve never tried an inner source model though. About how large of an engineering org are you supporting?

50ish

Thank you @Andy Fleener! Fascinating.

If interesting to you Michael, I also wrote about how we scaled our platform team using inner source (supporting a ~500 eng org, with ~30 PE engineers). There are some other small bits in there that might answer other curiosity questions… always happy to chat.

Awesome! Thanks for sharing @Lou Bichard. I'd love to learn more about this strategy and the philosophy behind it.

I’d strongly suggest to join the community at: https://innersourcecommons.org This is very useful (IMO) too: https://patterns.innersourcecommons.org

Wow, thanks! I'll check these out!

I've found the innersource approach to be quite powerful and continue to go back to it. Even in 2000-5000 engineering orgs it really made a big different in collaboration. I see it as related to having a product focus in platform engineering, but using innersource approaches really involves the engineers on the ground on a day-to-day basis to collaborative solve developer problems and get that product feedback and drive adoption.

Hey @Andy Fleener 👋 How does this `"platform-adoption" channel` work ? • Platform PMs post new feature and users are commenting with their feedback? • How do users find time/motivation to answer? Who are the ones giving valuable feedback? Individual Contributors? Staffs (transversal roles)? Managers? Thank you 🙏

It’s sort of a combination of a place to post new features and a support channel for helping people use the platform. Most of the help comes from the platform team but not all of it.

Nice ! Thank you !

The goal of our support was to get the engineering community to support each other with some basic triage items like, why did my container die, the deployment is stuck, how to do x.. There is a general "collaboration" channel, but then other channels for specific questions around authentication for example. When my team needs to investigate, they liked using HALP which converts slack conversations into trackable tickets. HALP also allows for a rotation and for people to get pinged so they are trolling slack channels or responding to direct or here requests. https://www.atlassian.com/software/halp For feedback in the platform, we do have advocates in various groups that collect information, but that also can be from power users. We have various engineering guilds here and they help out with interviewing people in the guilds (python guild for example) with what works / doesn't work in the system.

This is great, thank you for sharing!

In my case, I lead a Frontline team of Platform Engineers covering support for: • Compute Platforms mostly EKS based • CI/CD tooling • Backstage These three streams were separated two years ago, and there was a lot of friction for our ~5000 developers that didn’t know where to raise tickets and got frequently bounced across intakes. Currently we have a single intake form, we receive 1000 tickets per month and my team can handle 80% of that. The left ones - usually the trickiest ones - will be escalated to the Backline teams depending on the type of issue. We got to this 80% gradually by having: • runbook identification through data gathering • backline teams joining our standup calls • backline teams providing specific Knowledge Transfer and documentation Now we’re pushing towards automation and process strengthening so that we can broaden our support scope, thus removing even more friction from the developer journey.

Thank you @Giorgio Delle Grottaglie, in my own experience, it seems that when you get to near the 5000 dev level, you start needing more systemic ways of managing the requests like you've described. Have you defined any SLA/SLOs, or otherwise set expectations in terms of time to triage, time to respond, etc.?

yes @Michael Galloway we had historical data to help us up with initial SL*O*s for time to resolution first. Then we added time to respond and time to assign as well as being more granular on request types to that the SLOs could be better tailored. We never talked about SL*As but* SL*Os* to emphasize that we commit for the best but we’re not breaking any contract

Thanks for the context @Giorgio Delle Grottaglie!

No problem at all @Michael Galloway! Happy to chat further

I didn't come here to product plug, and I'm really just here to learn, but when you talk about reducing toil and cognitive load for your engineers, that's a pretty major part of what the company I'm with, DX does. The main way we accomplish that is an automated 5 minute survey for each engineer that takes place once per quarter which gets a consistent >90% response rate across our customer base. The survey was designed by these researchers: (Nicole Forsgren, Margarete Anne-Storey, Liz Pavese, Gergely Orosz, Pat Kua). We use this data to measure 25 pillars of developer experience(also identified by our researchers), to uncover roadblocks in the development process, and to identify areas to prioritize. This gives you a pretty great way to support your engineers, as they can point directly to the issues they're having for you to address, and you can prioritize the issues based on the qualitative data. Then when you couple it with the actual quantitative data(PR times, etc.) it becomes a pretty powerful way to address things. Here's a direct link to our survey guide in case you were thinking about running your own surveys: https://uploads-ssl.webflow.com/6227cfc17392f4e422607276/64b9b5b8d7f75e65ff8a6a04_SurveysGuide.pdf Also here's a link to the 25 pillars of DevEx we measure: https://dx25.getdx.com/ If you have questions, feel free to dm me too.