[codethatwerks]

It depends a lot on company culture but ideally talk to a decent sample size of the employees across teams and find their perceived pain points. Then measure things: time to build locally, time for CI, time for tests to run, release frequency. Gather the combined data from measuring objective things and developers subjective experience and work it out from there.

If your role crosses over with SRE and platform then you need to get the data for these things to.

Make sure you understand why X is like it is for all X that you want to change. Know the history and the battles won and lost that got it like that.

Move slow and fix things!

Of course if the culture is all “quarterly goals, show progress etc.” then you may need to adapt for that too. Maybe get some quick win projects out that are no brainer things. Parallelize tests or project master branches etc.

By the way your list of changes might be perfect or awful. It is like a diet plan… it depends on the person and the reason for it.