https://platformengineering.org logo
Join the conversationJoin Slack
Channels
aws
azure
back-end
building-our-platform-engineering-team
chaos
documentation
envoys
envoyz
events
general
gitops
idp-architectural-design
idp-resources
intros
israel
it-meetups-organizers
jobs
kubernetes
loc-angola
loc-atlanta
loc-bangalore
loc-brazil
loc-canada
loc-dallas
loc-dcmetro
loc-france
loc-germany
loc-india
loc-irvine
loc-japan
loc-korea
loc-norway
loc-poland
loc-russia
loc-singapore
loc-vietnam
metrics
mychannel-
observability
outages
platform-coffee
platform-culture
platform-design
platform-engineering-in-edge-computing
platform-engineering-milan
platform-leadership
platform-stories
platform-tech
platformcon-news
platformk8sathome
platformscript
product_management
product-management
qualityassurance
security
serverless
support
team
terraform
test2
uk
verisure-commonservice-datastax
verisure-commonservice-datastax
Powered by Linen
platform-culture
  • n

    Nigel Kersten

    06/10/2022, 9:11 AM
    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
  • n

    Nigel Kersten

    06/10/2022, 9:13 AM
    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/
    👀 1
    👍 2
  • n

    Nigel Kersten

    06/10/2022, 9:13 AM
    (not without doing the rest of the stuff Amazon have done to make that model work)
  • s

    Steve Spear

    06/10/2022, 10:33 AM
    @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
    👀 1
  • g

    Galo Navarro

    06/10/2022, 10:41 AM
    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!)

    https://www.youtube.com/watch?v=ApEOiNC4GrA▾

    👏 1
    j
    a
    l
    • 4
    • 6
  • n

    Nigel Kersten

    06/10/2022, 10:45 AM
    hey everyone - happy to chat about any thoughts folks have about my talk ! https://platformcon.com/talk/a-prescription-for-platform-engineering
  • n

    Naya Kumar

    06/10/2022, 10:48 AM
    @George Hantzaras, great definition of platform engineering! Any other proposals? 😅
    😂 2
    g
    • 2
    • 2
  • l

    Linda Shay

    06/10/2022, 11:01 AM
    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? 🙂
    g
    j
    • 3
    • 4
  • s

    Simon Haslam

    06/10/2022, 11:51 AM
    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)?
  • g

    Galo Navarro

    06/10/2022, 11:54 AM
    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.
    👍 3
  • a

    Alison Rosewarne

    06/10/2022, 12:00 PM
    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.
    👍 1
  • s

    Simon Haslam

    06/10/2022, 12:02 PM
    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.
  • s

    Simon Haslam

    06/10/2022, 12:07 PM
    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.
    👍 1
  • s

    Simon Haslam

    06/10/2022, 12:11 PM
    @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)
  • g

    Galo Navarro

    06/10/2022, 12:12 PM
    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.
    💯 6
  • g

    Galo Navarro

    06/10/2022, 12:13 PM
    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)
  • a

    Alison Rosewarne

    06/10/2022, 12:16 PM
    "Selling" aligned autonomy is considerably easier when people have lived with trying to be productive in the aftermath of unconstrained autonomy 🙂
  • g

    Galo Navarro

    06/10/2022, 12:17 PM
    well
  • g

    Galo Navarro

    06/10/2022, 12:17 PM
    this is a speech I gave once
  • a

    Alison Rosewarne

    06/10/2022, 12:17 PM
    Explaining commercial realities and keeping a customer focus is also very important.
    👍 1
  • g

    Galo Navarro

    06/10/2022, 12:19 PM
    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."
    👍 2
  • g

    Galo Navarro

    06/10/2022, 12:19 PM
    Sometimes, it went well. Other times, not.
  • s

    Simon Haslam

    06/10/2022, 12:20 PM
    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.
  • s

    Simon Haslam

    06/10/2022, 12:22 PM
    oh, for this record, this is not how I would like it of course 😁. It will get better over time I think.
  • a

    Alison Rosewarne

    06/10/2022, 12:23 PM
    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.
    👍 1
  • g

    Galo Navarro

    06/10/2022, 12:25 PM
    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.
  • s

    Simon Haslam

    06/10/2022, 12:29 PM
    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 🍱
    🙌 1
  • o

    Ohad Shushan

    06/10/2022, 12:32 PM
    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

    https://youtu.be/Hl2nCOfnsT8▾

    T
  • j

    jpeach

    06/10/2022, 10:44 PM
    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?
    ✅ 1
    t
    a
    +5
    • 8
    • 13
  • j

    jpeach

    06/13/2022, 5:22 AM
    @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?
    👀 2
    g
    a
    +2
    • 5
    • 23
Powered by Linen
Title
j

jpeach

06/13/2022, 5:22 AM
@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?
👀 2
g

Galo Navarro

06/13/2022, 7:49 AM
We didn't use it as OKR but did track an approximate metric for this in some tools. One example: we built some automation to auto-merge PRs when approved, send reminders to reviewers, or send PRs with dependency updates (this was some time before GH implemented many of these). We just took conservative estimates of how much each of those actions took on average (e.g. "sending a PR with a lib update takes 10 min") and multiply by executions of the tool. 10 mins may look small, but if you're automating this across the org the numbers add up to quite a lot already. And, being conservative gives you the luxury of not having to defend the number (in fact, you can easily argue that it actually saves a lot more than 10 mins). We didn't use this so much for OKRs, but it did appear in a few presentations to execs in this form: "Look, it took N engineer-days to build this tool, and now it's saving 10*N engineer-days per month." It helps a lot to justify getting headcount.
a

Alison Rosewarne

06/13/2022, 9:38 AM
It's an evolving practice but involved: 1. Comparison of before platform and after platform efforts for the work no longer required, e.g. if you use our web micro frontend approach you save 90 days up front and then ongoing maintenance costs. 2. Multiplying effort to build components as savings everytime you use them. e.g. a button in our design system took so many hours to build so everytime you use a button you've saved those hours. 3. Reduction of toil time savings - some automation saves ongoing manual effort (especially per AWS account which really adds up).
Like any metric it will ultimately be gamified but while it is driving the right behaviours (platform adoption and platform development for maximum impact) we'll stick with it.
j

jpeach

06/13/2022, 9:46 AM
To what extent did you find yourself using potential time saving to prioritize vs estimated savings to demonstrate benefit after the fact?
I do like the idea of specifically finding an activity that can be measured (like CI). It's a good approach to focus the team and also to show the benefits. Nice and concrete, and serves double duty!
g

Galo Navarro

06/13/2022, 9:57 AM
This type of very objective metric was quite useful for us to focus the team and related to the autonomy topic we discussed a few days ago. A typical problem we has was "engineer has an idea about $tool, wants time to build it, will get annoyed if we say no". This type of conversation can lead to engineers feeling frustrated because we impose features etc. So we tried to say "ok, bring us the data: show how much time your tool is expected to save per execution, how is it going to get adopted, etc.". If you bring a business case and it works out, let's do it.
It's useful not only for prioritisation, but also gets engineers into the product mindset.
j

jpeach

06/13/2022, 10:11 AM
Yeh that makes sense. Used carefully it sounds like a useful practice - thanks for the info!
a

Andrew Fong

06/13/2022, 1:41 PM
Orgs also need to decide how they want to balance throughput vs latency. There’s a lot of tools that reduce engineers cycle time locally but have no actual impact on the throughput of the organization. Using time saved metrics works well at macro blocks but breaks down at the micro bc that time isn’t recapitalized into something else.
a

Alison Rosewarne

06/14/2022, 10:08 AM
To what extent did you find yourself using potential time saving to prioritize vs estimated savings to demonstrate benefit after the fact?
Historically I'd say we were definitely focused on the latter - demonstrating benefit after the fact. Moving forward we want to do both (prioritise according to hours saved as well as report actuals).
There’s a lot of tools that reduce engineers cycle time locally but have no actual impact on the throughput of the organization.
Could you expand on this a little more? If this point is about system inefficiencies entirely related to tech and tools, yes this is a problem to measure, identify, and often solve with something other than more tech and more tools 🙂
r

Rohan Kapoor

06/21/2022, 4:03 PM
In our team called Ethos at Adobe, we measure zero to hello world and zero to production readiness (cycle time) as key metrics which we report on a quarterly basis. We have a semi-automated way of capturing these for now so we ask developers who go through the onboarding documentation to track these times in a spreadsheet (not perfect) which we use as a baseline and calculate the mean time over the year to see performance.
We also quantified these times in terms of $ value by multiplying it by average developer salary and potential hour savings (10-20%) to come up with reasonable monetary savings value in addition to the time taken
g

Galo Navarro

06/22/2022, 7:23 AM
We did this too ^ I'd note something I mentioned in my talk though: I found it dangerous to frame the platform's benefits as cost reduction. So when we used that type of metric we gave it a spin and presented those numbers from a different angle. We did not save 10% engineer hours. We added 10% engineering capacity.
r

Rohan Kapoor

06/22/2022, 3:59 PM
@Galo Navarro Very interesting. Were you able to quantify it in $ amount? Wondering what adds the most impact for leadership
g

Galo Navarro

06/22/2022, 4:03 PM
You can do hours saved * avg salary
But we did not use that argument much, it is dangerous because you create the expectation that you will generate those savings consistently, which ls hard and will backfire
With leadership the general argument was “teams following our recommended practises and using our tooling perform better than those who don't”
Better being quantified with metrics backed by industry research like those in Accelerate
Which tend to correlate with the subjective perception people make about teams (e,g teams that seem reliable and effective happen to fare well in those metrics)
r

Rohan Kapoor

06/22/2022, 4:19 PM
Got it, you mentioned you did a talk. Did you share some of these best practices there? Would love to watch it!
g

Galo Navarro

06/22/2022, 4:20 PM
Here is the link

https://www.youtube.com/watch?v=ApEOiNC4GrA▾

👀 1
r

Rohan Kapoor

06/22/2022, 4:21 PM
Thank you!
🙌 1
View count: 34