Hello everyone, I'm exploring the concept of establishing a "Platform Enablement" team within our organization, aimed at complementing our core platform teams. This additional team would focus primarily on advocacy, adoption, technical documentation, and directly supporting product teams with migrations and other hands-on work. Our goal is to embrace a "platform as a product" approach. However, I have observed that not all our Platform Engineers share this customer-centric mindset to the degree we anticipate. They primarily identify as "builders". Ideally, I believe that the teams developing our products should also be the ones to engage in enablement and advocacy, fostering a strong feedback loop with our customers. Nonetheless, it sometimes feel like forcing our engineers in something they do not want to do (they are willing to do it, but not to the extend I expect). Has anyone here implemented a dedicated "Platform Enablement" team with a focus distinct from that of your core development teams? If so, how did you balance the roles between building and advocacy? I'm keen to hear about your experiences, challenges, and insights you might be willing to share. This looks similar to the AWS dev advocates and solution architects, a role I feel we are currently missing to some extend.

Hi @Grégory Vander Schueren, that’s exactly where my team was involved. I’m happy to follow up if you are interested.

i think the sell for the “builders” is that they can build better tools and solutions once they start meeting where their customers are at

Thanks @Jordan Chernev, I read both papers, these are awesome resources, and I keep referring to them. In an ideal world, I also believe that market research, evangelization, and advocacy is best if done by the same engineers building the platform tool. However, it is already hard to find people with the skillset required to be a platform engineer. It becomes even harder if you limit yourself to engineers that actually like doing that evangelization and advocacy work. I suppose this is where my initial question was going... Maybe you can a find a couple individuals that actually like doing that and have them focus on that aspect more than the others.

Gregory, it can be two different team members / archetypes doing the different aspects of these workstreams and cultural foregrounding. what i found useful is someone who is closer to the SRE archetype to be a member of a platform team as a way to help interface with product teams. also, don’t forget, evangelization is everyone’s role, including yours, the PMs, etc

OK, apologies for the book. I've sold and delivered a lot of off the shelf and bespoke platform engineering enablement engagements and the most successful teams are the ones who are: 1. Small (two pizza 😄 - several small teams with aligned goals work better than a single large team) 2. Balanced (engineers, product managers, designers or someone filling the designer persona) 3. Have an executive champion who has business acumen about the platform value proposition who is capable and committed to supporting the platform team with the exercise of political will Number 3 is the rarest and over the years that I've done this work, I've watched success follow these champions across multiple organizations. Usually they implement incentive structures in their platform, app dev, security, and other stakeholder organizations that drive success by tying individual contributor and leadership bonuses and goals to platform outcomes. You mentioned it being hard to find platform engineers, so I'm curious about whether it's hard to find them because of budget, rarity, culture, or office policies like hybrid/on-site. I can find you a handful of folks today who'd love to take on a challenge like running an enablement team, who've done it before, but who wouldn't accept if the pay was too low, the culture was poor, they were required to be in an office x times a week, or it was clear that executive leadership wasn't all-in on driving change. Because that's what it is. Change. If you've got platform engineers who don't want to engage with stakeholders, you don't really have platform engineers, yet. I have seen many crusty basement infrastructure wizard types change their mind about XP methodologies, platform-as-a-product, and user-centricity after a six week or longer intensive engagement. The challenge is then keeping it going and that's where the platform champion shines. Keeping the focus, not getting distracted, driving change.

If you've got platform engineers who don't want to engage with stakeholders, you don't really have platform engineers, yet.

i really like that

It isn't their fault, either. It's hard to get out of the "devs are a pain in the butt" mentality when every ticket they see is another developer wanting something. When you're able to engage in conversations with them as a regular part of your duties, you develop the empathy @Steve Fenton mentioned. In a balanced team, that product manager who is embedded in the platform team has a vision, starts the conversations, drives the mutual understanding of value, and helps the team realize that value and how their individual efforts can be recognized as creating it.

mentality when every ticket they see is another developer wanting something

this is a great problem to have? maybe the friction comes from the fact that automation / self-service isn't in place yet to minimize this amount of synchronous collaboration

this is a great problem to have? maybe the friction comes from the fact that automation / self-service isn't in place yet to minimize this amount of synchronous collaboration

You put your finger on it. It is definitely a good problem to have...if you're not using a ticketing system. Collaboratively developed user stories in a managed backlog, now that's a different story. 🙂 Tickets are toil. Stories are fun.

if you find yourself in a social dynamic like this one, maybe those groups aren't the right set of pioneers / early adopters you need

Most of the customers I've supported or sold to have some flavor of waterfail going on, to include all the usual PMP type activities, or worse, co-opted Agile naming conventions, but not implemented practices. SAFe is a good example of an organization like this, where they're trying to buy a bucket of agility. Anyhow, sometimes you meet folks where they are and try to help them learn the value of agile practices, and sometimes you tell them you're sorry, you can't help them until they help themselves. Change is hard and the frozen middle needs champions to lead them out of the cold.

Give the platform team slack in the system to do consultancy. Meaning directly pairing up with customer squads to understand and unblock them while they deliver always with an eye on generalized solutions to the problems faced.

Hey @Grégory Vander Schueren! I wouldn’t worry too much. It’s actually a problem that starts to surface with scale. The more people your platform use, the further your platform team grows - it’s infeasible to think that this growing team will behave differently from any other team because they have a different job title. There will always be individuals who are more suited to specific tasks, and not letting them pursue this is just making them less happy. There are two questions remaining in my mental image of this: 1. how will you make sure that the people who have more outside contact are able to actually inform the people who have less outside contact? Well this is establishing a good product management practice and comms inside the team. Please note that “less outside contact” never equates to “no outside contact” - platform engineers still need to identify themselves as servant to the platform users. People who can’t do that are possibly even happier in a different team and function. 2. should you actively use that mechanism? I’ve been part of some bigger platforming initiatives and when you hit a certain scaling point, it makes sense to do so. Before you reach that point, looking for people who fill specialized roles is not feasible because it makes team management more complicated when you need to find stand-ins and the like. …and of course, the generic caveat that how you drive your platforming initiative must be aligned to how your org operates, so the success you can generate by such a pattern is largely determined by your own organization structure, processes, and platform maturity. E.g., having a team that “goes out” is much more beneficial while you’re in innovation and growth mode - they can onboard new users and train existing users on new features - tasks where a different skillset might benefit you quite a bit - and bring home the vital feedback in a structured way that guides the builders.

Hi Gregory I remember in our org when we switched from a clunky deployment process to new. Teams were quick to adopt to this change because of the reduced deployment time and better integration experience. I could be bias 🙂 In my experience, teams will use platform offerings that are secure, easy to use, and help them go fast. That's certainly the approach we have taken to run our internal developer platform. We do have a two-person developer enablement team to assist teams with anything software development. However the focus of the enablement team is less about the internal developer platform, and more about how teams could build and solve problems using the platform. If anything, the developer enablement team is also a consumer of the internal developer platform, and the first to provide feedback.

“Our goal is to embrace a “platform as a product” approach. However, I have observed that not all our Platform Engineers share this customer-centric mindset to the degree we anticipate. They primarily identify as “builders”.” We face a similar challenge that teams are building features then asking internal customers what they think, rather than asking the customers what they need and building that. It’s changing now as we have a Product Owner in place and a completely neutral UX designer interviewing developers to find out what they need. These requirements will be fed to the PO so that features can be prioritised - then the building phase can begin. It slows us down a little for now but I believe it’s the correct approach for long term success.

@Grégory Vander Schueren thanks for sharing your thoughts on this. I'm in a somewhat same place as you. Started our Platform Engineering team last year with the focus of shifting technology to Kubernetes but then also changing the platform from a technology we use to being a product. Last part takes a lot of work, since it is both the inside the team and outside in the organisation, I need to work on a change. 😉 I have a good team of platform engineers - where we talk about platform as a product, but it is a new thought, and I need to break it down in "tasks" - i.e. so what should we do differently now - when it is SO much easier to just talk tech. with the developers. My focus has been on behavioural design, looking into how to change the mindset - both with the platform team and the developers, since it is on both "sides" of the interaction that we need to change. It is a new way of interacting when the platform engineers used to sit in the teams and support them. I'm not aiming at big changes just little by little we change the way we talk and it'll hopefully impact the way we walk.

what i've found helpful in those transitions is framing the discussion that it's about the same work, it's just through a different lens. treating your partners as customers and asking your team to think of themselves as a company within the company providing a product for others to use (dare i say, a startup) is a helpful change leadership and change management mechanic. i also leverage this team topologies infographic to bring the message home. https://1048636645-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa[…]ng?alt=media&token=1e642c2e-1418-4772-958e-1604b62c3868 (note, if you click on the link, it will download the file directly. i don't have a good way of linking to it inside a browser address)