I totally agree - people importing these “movements” into their organisations without taking into the context of their business and people does more harm than good

I wrote a piece on this sort of thing for banks

The “two pizza team” ideology coined by Jeff Bezos simply doesn’t translate to a 200-year old, 10,000-employee bank that must abide by strict regulatory requirements and meet compliance and security standards.

https://www.globalbankingandfinance.com/why-big-techs-approach-doesnt-apply-to-global-finance/

(not without doing the rest of the stuff Amazon have done to make that model work)

@Nigel Kersten @Maciej Raszplewicz On the topic of two pizza team I thought this note re partitioning work to allow better engagement of distributed intelligence would be relevant https://conta.cc/3GfjYAK

Good afternoon! I am around for Q&A about my talk "Salesman tricks for the Platform Engineer", let me know if you have any questions or feedback (DM or here are both fine!)

hey everyone - happy to chat about any thoughts folks have about my talk ! https://platformcon.com/talk/a-prescription-for-platform-engineering

@George Hantzaras, great definition of platform engineering! Any other proposals? 😅

Really enjoyed your talk @Galo Navarro, great job explaining all the tricks! I was wondering, what happens with new hires? Do you still have to sell them on the platform or is it now an established part of the culture? 🙂

I've been watching lots of useful sessions, thanks to all the speakers. One question, which I think I was reminded of during Nicki's session yesterday, is if we split the org into Product Dev/Run and Plat Eng, how do we help Product devs be happy with what they're doing and not wanting to dive into infra/plumbing? Devs often want to do a lot of what is in Plat Eng scope, for various motives: new tech, fancy tooling, more cloud experience (and, let's face it, sometimes it's just to get these things on their resume/CV). You can move them to Plat Eng, but if their thing is to do app/feature dev for external customers that doesn't work long term. So somehow we need to help product Devs need to get the skills/experiences they want, and ideally act as ambassadors for Plat Eng rather than competitors (re-inventing what is effectively platform code in the product)?

I think the split is just in terms of scope. You split product vs. platform because there are different scopes. Same as you may split teams focusing on "the messaging feature" and "the image manipulation feature". That is just scope of work. However, IMO, regardless of that scope, every engineering team should take a product-oriented mentality. They are producing something that someone else will use. And they need to understand needs, requirements, manage users, etc. Of course who the customer is will vary many aspects, but the core of the matter is the same: every engineering team needs to do adult product management.

Secondments can be a good way to give engineers a taste of another team / challenge, learn a few new skills, develop empathy but not realign their career away from their core passion.

Yes, I think that's good in theory, but I feel we battle a bit with the DevOps principle of autonomy & being allowed to pick what they want as long as it meets the requirements. I'm pretty sure 99% of people here are behind the cognitive load vs team size thinking (à la Accelerate, Team Topologies, etc) but getting buy in for golden paths seems to be quite a challenge with very dev smart teams.

Secondments are something we tried (actually what triggered this question 😉). We will be trying more of the TT ideas of embedding Plat Eng devs in to "main product" team dev sprints, which I'm hoping might work better. BTW @Galo Navarro yes, I am coming to terms with platform as a product, just still tend to think of the "main applications" as our key products.

@Alison Rosewarne actually I do like the idea of secondments into platform eng (I have only experienced a small sample size & other factors will have been at play too)

I think the autonomy point is one of the most misunderstood by engineering teams. Autonomy means not "do whatever you please". And it is what leads many infra teams to disaster: they do their own pet projects (that sometimes turn into cathedrals), and then get surprised that people don't adopt them,. etc. This might have worked in the 90s when "the systems folks" were a monopoly. It is not true when you have commercial companies working in that scope because they will obliterate that kind of team. Platform teams are literally building products that compete with commercial ones. They need to function accordingly.

I think there is almost equal complexity in selling a platform externally to engineers, as it is in helping engineers adopt that kind of mentality. Also, hiring ordinary product engineers helps a lot (they bring the mentality out of the box)

"Selling" aligned autonomy is considerably easier when people have lived with trying to be productive in the aftermath of unconstrained autonomy 🙂

well

this is a speech I gave once

Explaining commercial realities and keeping a customer focus is also very important.

Someone was telling me that startups are nimble and very autonomous and we should work in that way. My reply was: "look, startups get autonomy, they can chose what they do etc. But, they also have a runway. And the runway does not last. Fine, if you want to do things your way go ahead. But, I want to see outcomes, I want to see metrics of success I can agree with, and I want to see them moving in the right direction."

Sometimes, it went well. Other times, not.

FWIW, from our perspective, security is the #1 reason we have to reign in full autonomy - we have to have protected/scanned pipelines to production since it's hard for anyone to keep this stuff secure at the best of times 😁. I would love to get to a point where "main product" devs say "the platform is so amazing we want to use it and couldn't think of anything better" but for now we just have to lay that down as law.

oh, for this record, this is not how I would like it of course 😁. It will get better over time I think.

It's can help to regularly remind and educate of some of this platform value that gets forgotten over time. If teams are going to carve their own path that is fine - they are still beholden to the regulatory and other compliance environment. The list is usually long and involves talking to a lot of interesting stakeholders.

The only thing where the analogy with the marketplace (platform competes in the marketplace) doesn't work so well is in natural selection. In the market, natural selection operates ruthlessly. In companies it's easy that weak products last longer, because there can be less accountability. Showing accountability is important, people need to feel natural selection at work.

Thanks for your input @Alison Rosewarne & @Galo Navarro - I saw both of your sessions this morning and made plenty of notes! Time for me to grab some lunch 🍱

Solving the ‘Speed Paradox’ with Backstage and Cloudify: a Full-blown PaaS The Rise of the Internal Developer Platform (IDP) One potential solution to the speed paradox is the Internal Developer Platform (IDP). As its name suggests, an IDP provides a single place where developers can find all the resources needed to run their development environment. An IDP allows developers to speed up their development processes by offering improvements in: • Efficiency - simplifying the way developers get access to their development and testing infrastructure through a self-service experience; • Consistency - providing a consistent way in which developers consume infrastructure resources across teams • Visibility - providing a single place where developers can see all the development pipelines, workflows, and states that are associated with their specific environments. Watch Nati Shalom, our CTO, session at PlatfromCon T

So given the discussion above, I'm really interested in people’s experiences in bringing platform thinking into organizations with high autonomy, low hierarchy and weak coordination functions. Assuming you built some starting point, how did you go about leveraging that to begin to align teams?

@Alison Rosewarne You mentioned that one of the PMs in your org was measuring an “hours saved” metric for your OKRs … can you give any detail about how you approached measuring this?