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.
„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.
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”.
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?
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.
„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 ⬆️....
"Remove the purpose from the team" is what killed it for me.. Wonder what the engagement levels and staff turnover are at this org
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 ⬆️....
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”.
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?
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.
Banks = COBOL !