Death Of The "Spotify Model" • Gijs Meijer & Marcin Pakulnicki • GOTO 2022
ฝัง
- เผยแพร่เมื่อ 15 มิ.ย. 2024
- This presentation was recorded at GOTO Amsterdam 2022. #GOTOcon #GOTOams
gotoams.nl
Gijs Meijer - IT lead of retail banking products at ING Bank Netherlands
Marcin Pakulnicki - Head of IT at Daily Banking Tribe at ING Bank Netherlands
ORIGINAL TALK TITLE
Death of The Spotify Model: On Radical Productivity Improvements at Enterprise Scale
ABSTRACT
Many ‘productivity’ talks are filled with abstractions on how to create ‘high performing teams’. Many of them use ‘Agile’ concepts which sound nice for the internet and often work for a particular use case, but how do you actually scale improvements across a large IT enterprise? All this while maintaining engineering happiness, and delivering on your projects?
In 2015, the busdevops way of working aka ‘The Spotify Model’ helped ING Bank to a next level of Agile way of work. It brought us many nice things, but we identified some issues along the way and we will cover them in the presentation. After 5 years, it was time to take the next steps.
This talk describes the good, the bad and the ugly when you want to establish a (large scale) top engineering culture and highly performant IT departments where technology is a first-class citizen. [...]
TIMECODES
00:00 Intro
02:37 Setting the scene
03:44 What books inspired us
05:54 Way of working at ING over time
06:59 The "Spotify Model"
12:07 Improving the journey
16:15 Death of the IT manager
18:14 MicroTeams
25:32 Product thinking
28:30 What happened to OPS?
31:07 From Linux specialist to cloud engineer
36:29 Is it all awesome?
40:05 Rolling out at scale
45:24 Conclusions
46:35 Outro
Read the full abstract here:
gotoams.nl/2022/sessions/2018...
RECOMMENDED BOOKS
Gene Kim, Jez Humble, Nicole Forsgren, Patrick Debois & John Willis • The DevOps Handbook • amzn.to/3C0Rj0C
Matthew Skelton & Manuel Pais • Team Topologies • amzn.to/3sVLyLQ
Jennifer Petoff, Niall Murphy, Betsy Beyer & Chris Jones • Site Reliability Engineering • amzn.to/3xYac2Q
Marty Cagan • Inspired • amzn.to/3dPz7iq
Reed Hastings & Erin Meyer • No Rules Rules • amzn.to/3Cjottx
Forsgren, Humble & Kim • Accelerate: The Science of Lean Software and DevOps • amzn.to/3tCz1xO
Fred Brooks Jr. • The Mythical Man-Month • amzn.to/31NJc5C
/ gotocon
/ goto-
/ gotoconferences
#Change #BlastRadius #SpotifyModel #ProductivityImprovements #Productivity #EnterpriseScale #DevOps #ING #Simplicity #MicroTeams #Flow #Feedback #Culture #ProductThinking #CloudNative #Containers #k8s #SRE #TalentDensity
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
th-cam.com/users/GotoConf... - วิทยาศาสตร์และเทคโนโลยี
„From 7 to 4 engineers without hardly any velocity loss“. „The mythical man month is true“. I’m sorry but I’ve heard and seen these things and they ended up in understaffed cognitive overload multi tasking overtime burnout teams. Or, things that were done like documentation, tools, automation, reducing technical debt,… all gets cut off by „no feature, no priority“. For a while, that might seem productive to do features as crazy as possible without having people that identify themselves with the product, but it will most likely have mid or long term effects. Even if the infrastructure engineers can build upon are that great as promoted.
Questions can come in ⬆️....
Hmm so we go from having separate ops, to dev ops, to a platform team doing ops. Full circle?
Questions can come in ⬆️....
Making the wall of confusion great again ☺️
Separating the devs from the consequences of their work (good or bad) has been proven to not be a good idea. Handoffs to other teams (which is what is happening here) is definitely going back to the older ways. He describes tight coupling between the platform teams and the development teams
Why would you have a dev feature team develop a feature and then turn to an (likely understaffed and overworked) Platform team for building the monitoring and support? This is not SRE, it is old school dev handoff to ops thinking.
Also, I wonder how their technical debt situation will look in a few years…
Is he saying that you dismantle the team - even if the product is still in production? This means the poor platform team is now getting all the app ops work? That is not platform work… it is application operations work… Do they have enough resources to be successful? Sounds like a return to the old days more than anything.
I don’t know if they really read the same Team Topologies book I read…
The point of this all seems to be to optimize for Human Resources / full dev utilization at all times.
Sounds like a real blast to work there. Noting innovation here, really. It’s a mix of new teams being mapped over old IT processes and a staffing strategy to keep everyone “fully utilized” and “productive”.
1. How did you measure the impact of team forming and dissolving phases?
2. With teams changing shape, how do you handle constant forming phase in terms of differing experiences and egos associated with it?
3. Why smaller teams resulted in no impact in performance? As in: what is the fundamental component?
3b. Who decided; and based upon which criterion who to eject from the team?
3c. What was the churn rate of ejected developer s?
4. With at most 4 People per team, how do you handle shift-left competencies?
5. How so you shape small teams in terms of experience?
6. How do you handle domain context when you constantly shift people around?
---
I'm quite skeptical about the conclusions. It seems that they have optimized for a local maximum.
I would be interested in learning a developer's point of view. The concept of this transformation sounds concerning in many points.
Questions can come in ⬆️....
"Remove the purpose from the team" is what killed it for me.. Wonder what the engagement levels and staff turnover are at this org
But how do you actually measure velocity in software teams?
Separating the devs from the consequences of their work (good or bad) has been proven to not be a good idea. Handoffs to other teams (which is what is happening here) is definitely going back to the older ways. He describes tight coupling between the platform teams and the development teams
Why would you have a dev feature team develop a feature and then turn to an (likely understaffed and overworked) Platform team for building the monitoring and support? If the devs release the code and need tweak the monitoring for some reason, what do they do? Open a ticket for the Platform team to do this for them, I assume? This is not SRE, it is old school dev handoff to ops thinking.
Also, I wonder how their technical debt situation will look in a few years…
Is he saying that you dismantle the team - even if the product is still in production? This means the poor platform team is now getting all the app ops work? That is not platform work… it is application operations work… Do they have enough resources to be successful? Sounds like a return to the old days more than anything.
I don’t know if they really read the same Team Topologies book I read…
The point of this all seems to be to optimize for Human Resources / full dev utilization at all times.
Sounds like a real blast to work there. Noting innovation here, really. It’s a mix of new teams being mapped over old IT processes and a staffing strategy to keep everyone “fully utilized” and “productive”.
I just finished watching the video and this was abhorrent. This is what happens when tech orgs get too big and have long time employees. Beware.
Lol you had product teams exploring and prioritizing all the work until years in the future, and when that gave you estimates you didn't like, you just destroyed the teams.
I see two insecure men boasting about their new job for 45 minutes, nothing else. You started the devops "journey" in 2012 and you didn't figure out how to quickly deploy java applications until 2019? 25 different ways to release code? What? How? What kind of madhouse were you running? Teams of 12 people? Why?
Banks = COBOL !