Just because I’ve seen this transition happen so often, I thought I’d jot down for you what it normally looks like. If you’re working in a large enterprise, this is a pattern that can cost you lots of energy at best and your job at worst.
Let’s imagine a scenario: You are on prem with OpenShift now. Operations are heavily centralized against a dedicated team. You’re moving to the cloud. New AWS account. Everybody gets access to everything. Freedom is the new structure, you think it’s a great idea to weaken operations and move this “closer to the teams”. The teams start off by building great stuff. You proclaim happiness. Senior devs are ecstatically happy. CTO approved.
Here is what your next 48 months will look like:
First 6 months
- Individual teams will go crazy and spend time building fancy, unique stuff that makes sense for them individually.
- As much as 20% of their time is now spent bashing through cool new stuff such as Terraform or ArgoCD. You hear sentences like “this is such a good investment into my future, is it not?”.
Months 6-12
- First members of your operations teams are showing up at internal AWS adoption meetings warning that this is getting a lot to handle and that requests from individual teams pile up.
- Individual teams realize that it’s a lot to deal with Crossplane while making sure frontend test-coverage remains high. Senior backend engineers feel the responsibility to take infra and operations tasks on their shoulders. I call this “shadow operations”. Great stuff, you now have many operation teams with none of the scale effects.
After 12 months
- In the yearly review EMs realize that general deployment frequency has decreased by 20% with a strong downward trend.
- Infra VPs start to warn that things will get out of hand.
- Security teams are flagging that it’s hard to control what happens where and in what standard.
12-24 months
- On avg engineers leave orgs every 1.5 years. Which statistically means the majority of teams now have new hires who have to deal with all of the self-scripted mess the team in t=0 created.
- Maintenance overhead increases dramatically.
- Deployment frequency is further reduced.
- At the check-in meetings teams now reference platform models more often. Words like “Team Topologies”, “Golden Paths”, “Paved Roads” and “Internal Developer Platforms” occur more frequently.
24 months
- During the yearly review the management now decides to adopt a platform model.
- A platform team is initiated, a VP platform position is created.
24-36 months
- The HR team tries to understand what a platform team is and whom to hire.
- Some internal positions are shifted towards this team.
- Some functions are hired.
- Thoughtworks is hired too but cannot start in the next 12 months because they are out of capacity.
36 months
- Deployment frequency is at an all time low.
- Change failure rate continues to increase.
- EMs are doubling down.
36-48 months:
- Platform V1 is built and rolled out to the first teams.
- The management doesn’t really firmly enforce the use.
- The platform is built to be too restrictive and developers rebel.
48 months:
- Developers start to leave in whole teams.
- Deployment frequency is in the basement.
- The platform team is frustrated.
Sounds grim, right? It doesn’t have to be. Join my webinar on the 1st of June where I’ll present a step by step guide to platforming your delivery setup which will help you to prevent falling into the trapps I just brought up.
