If you are pitching up for developer experience team in an established organisation, how would you justify the investment? Has anyone gone through or have examples I could look at please ?

Time & money, if we improve the delivery speed by X, reduce defects by Y bc of Z, have 3-5 well known launched projects that you can use as a litmus test to validate your reasoning and 1-2 pilots lined up for the piece you want to fix to justify

I find that efficiency arguments tend to get mired in value conversations, and are hard to actually prove after the fact

Easiest way into the hearts of people that hold budgets is a tangible analysis. Developer experience is a very lofty term and can mean a lot of things - the better you can prove that you’re actually generating value, the more easy it gets. I would try with a simple value stream analysis that identifies the tasks in your SDLC as well as possible and separates the work time from the wait time. If you reduce the wait time, you reduce the overall cost of the process. Multiply with iterations through that process - simply get the number of commits or executed test runs per month from the corresponding tooling. This is no in-depth analysis or accurate ROI projection, but will get you tangible enough numbers that should get you budget to do a real analysis. If that yields potential, you’ve got your founding mandate. Fun fact - reducing SDLC wait times is NOT always converging with DX work, but if you create initiatives that generate value, you earn the credibility to execute on less tangible initiatives which might just be more aligned with DX.

It’s really hard. I’d agree it’s easy to get trapped in analysis paralysis and sometimes it needs some faith from leadership to get buy-in. Looking at waste in your organisation and analyse the drag/cost on the business is a good start. (rather than something theoretical around productivity). 1. How fragmented are squads? How much time is spent maintaining snowflakes all over the place? 2. What about incidents? Is there too many? Are there learnings? Could tooling reduce the waste in analysing, improving etc,. 3. Costs? Is the business literally wasting money in poorly understood poorly right-sized systems. 4. Build / Deployment times. How long are engineers waiting around/context switching and what opportunities are there? 5. DR. How prepared is your org for disaster, how risk-averse is the business? Are there other business requirements that are poorly managed by teams directly where a platform team could take some ownership. These are just examples but assembling some pragmatic hypothesis and provide metrics where possible. You can always use surveys to tell a story, or small scale analysis and extrapolate out. It’s really easy to get into analysis paralysis so just try get something compelling sounding other there and iterate based on feedback rather than try answer every question.

The strategies above are excellent, this is an older article, but covers a lot of what you're looking for: https://getdx.com/blog/devex-executive-buy-in/ Another interesting case that's come up recently in advocation for the work of DevEx teams is tying the work of the DevEx team into the executives' AI related initiatives, like measuring adoption of GenAI type tools, whether they're internal or external too. At the end of the day, Execs have things they care about, and don't care about. Finding what they care about, and relating your DevEx team's work to that is a going to be the key.

Linking developer experience to productivity and as a result to the customer satisfaction combined with providing clear measurements to have some drivers for management could help to get buy-in.

Hey Kaz, is the DevEx team focused on internal development? Or is it about polishing external surfaces? I think your approach depends on that.

Showed that table of services we have and approaches to docs can be handled with Backstage, and moreover it has a lot of plugins. Also, I worked several weekends for speeding up process.

@Nolan Sullivan its internal development. We are part of the platform engineering organisation

Finding the biggest pain point in the current state of your organization and platform is a great place to start. A lot of engineers get excited about building out tools that they later realized no one uses or try to solve for problems that don't have a large or holistic impact. That won't win you more chances on new ideas down the road. Another interesting question to ask is, when teams hit a wall or challenges that do impact their productivity - who has the time to fix or improve that thing? Product teams should not be spending their time dealing with pipeline issues or figuring out how to quickly spin up a new environment or service, they want to build features! When I pitched the a DevEx team (now platform engineering) that was one main selling point. It also helped we were growing and building new microservices which always add more complexity. Let's try to abstract things like infra away from these product engineers!