Beyond what you've masterfully described, the other main obstacles we encounter on our journey are: overriding existing architect and cloud engineer roles that have already made decisions and are absolutely entrenched with strong resistance to change often perceiving any proposed change as a direct attack on their decision-making authority; a perceived lack of need for scaling within overstaffed teams that have become accustomed to low quality and speed standards.
Well, our context is tricky: we don't have a CTO, and teams are led by a Service Line Manager who is only responsible for their own product line. This means there's literally no single stakeholder for global engineering optimization, making the platform team's mission an uphill battle.
We strongly believe that without top-management sponsorship, any large-scale, top-down initiative is bound to fail. So, we've adopted a more grassroots approach.
- Planting seeds: we focus on the teams most open to innovation, helping them adopt our shared toolchain and processes.
- Showcasing value: we run periodic showcases to communicate the concrete wins and the value generated by using the new toolchain, *hoping* other teams get inspired and follow suit.
A key lever: we offer a "fast-lane support" model. Teams that adopt our shared solutions get dedicated support from us as a center of competence for cloud, pipelines, and tools. For those who don't, support is best-effort.
It's a slow burn, but it's the most pragmatic way we've found to drive change from the bottom up.
This is a great post Mirek, we often face the same situation as a platform team.
I feel your pain! (literally now I lead platform teams)
Beyond what you've masterfully described, the other main obstacles we encounter on our journey are: overriding existing architect and cloud engineer roles that have already made decisions and are absolutely entrenched with strong resistance to change often perceiving any proposed change as a direct attack on their decision-making authority; a perceived lack of need for scaling within overstaffed teams that have become accustomed to low quality and speed standards.
I know what you are talking about 👀
How do you deal with that? Trying to live with it, or do you have any pro tips to share?
Well, our context is tricky: we don't have a CTO, and teams are led by a Service Line Manager who is only responsible for their own product line. This means there's literally no single stakeholder for global engineering optimization, making the platform team's mission an uphill battle.
We strongly believe that without top-management sponsorship, any large-scale, top-down initiative is bound to fail. So, we've adopted a more grassroots approach.
- Planting seeds: we focus on the teams most open to innovation, helping them adopt our shared toolchain and processes.
- Showcasing value: we run periodic showcases to communicate the concrete wins and the value generated by using the new toolchain, *hoping* other teams get inspired and follow suit.
A key lever: we offer a "fast-lane support" model. Teams that adopt our shared solutions get dedicated support from us as a center of competence for cloud, pipelines, and tools. For those who don't, support is best-effort.
It's a slow burn, but it's the most pragmatic way we've found to drive change from the bottom up.
A very motivating text!
Additional what-if question:
What if you had to advise a team that had exactly the same restrictions as your team?
Would you agree that nothing can change under these circumstances and that the team is best off continuing as it always has?
Excellent questions! Thanks :)