Not every engineering organization has the luxury of a dedicated developer enablement or platform engineering team. Here’s how to drive better outcomes without one.
Even for organizations with a dedicated developer experience (DX) function, expecting them to magically solve every issue isn’t realistic – or fair.
How do you foster a culture of continuous improvement without a specialized team? At Multiverse, we’ve begun experimenting with a lean-inspired approach, putting engineering managers at the helm. Here’s how it’s been going.
A DX wake-up call
It all started when we introduced a tool to gauge developer experience. We had just recently formed a platform engineering and developer enablement team. To see how it was going, we surveyed engineers across several dimensions, such as test efficiency, managing technical debt, and production debugging. The initial results were eye-opening: a lot of the areas in which our teams were finding difficulty were not surprising – documentation, managing technical debt – but we weren’t aware that our incident response process was such a source of stress.
Up to that point, our development enablement team had been focusing on big initiatives to improve developer experience, such as re-architecting chunks of our monolith to make it more maintainable. Instead, we decided to pinpoint problem areas using the data we had collected, defining them as the gap between our current state and the ideal situation. Then, we brainstormed hypotheses about the root causes and tested them with small experiments.
This approach, inspired by the lean manufacturing A3 method, led to a flurry of mini-experiments. We revamped the incident management process, restructured the alerting system, and streamlined build scripts, among other things using the following process:
Problem definition
We pinpoint a specific issue. Let’s say our DX survey highlighted “Codebase Experience” as a major pain point. We define the problem as the gap between our ideal codebase (easy to read, navigate, and modify) and the current reality.
Metrics for success
We identify clear metrics to track progress. For codebase experience, this might include time to onboard new engineers, frequency of encountering confusing code, or time spent refactoring.
Hypothesis generation
We brainstorm potential root causes. Maybe it’s inconsistent coding styles, lack of documentation, or too many “quick and dirty” fixes accumulating over time.
Experimentation
We design and run short experiments to test our hypotheses. This could involve implementing a new code linter, setting up documentation workshops, or dedicating time for focused refactoring.
Standardization (if successful)
If an experiment proves effective, we make it the new standard. This might mean updating our coding guidelines, incorporating the new tool into our workflow, or establishing a regular refactoring cadence.
Empowering engineering managers
A lot of the issues we were identifying could not be solved only by the developer enablement team. Being more culture and process related, the team started to feel that their impact would be limited if they proceeded as the only source of technical changes. What we needed was something more sustainable, and driven by the product teams themselves.
We proposed to involve engineering managers more deliberately in continuous improvement (“kaisen”) practices. This was imperative, as quite a few of the DX metrics were proving difficult to shift. Having engineering managers participating on the triaging of the results of the developer experience survey, and then leading their teams through a process of continuous improvement, allows us to scale.
The continuous cycle
Granted, none of this is ground breaking. The challenge is in the continuous and consistent application of the process of problem solving, using each issue as an opportunity to train the engineers themselves to identify problems, and run through the process. Every problem identified and mitigated improves the team directly via a reduction of friction or improvement in speed, but more importantly it also accelerates the team by offering an opportunity for them to train their problem solving skills.
This process doesn’t stop with one problem. It’s a continuous cycle of identifying, prioritizing, and tackling issues. Over time, this lean approach empowers teams to take ownership of their developer experience, fostering a culture of improvement and innovation.
This approach requires buy-in from engineering and product leadership. It also means managers have to dedicate a good chunk of their time to kaizen activities, and engineers are given enough slack to be able to work on improvements. Married to other modern techniques, such as strong observability and usage of service level objectives and error budgets, we hope to be able to continuously evolve our engineering team towards a generative culture.
The takeaway
Continuous improvement isn’t a quick fix, it’s a long-term investment. By empowering EMs and instilling a kaizen mindset in every engineer, we’re building a healthier, more productive engineering culture.
At Multiverse, we’ve helped over 1,000 companies close critical data, AI, and tech skill gaps in their workforce. Whether your goal is to upskill and reskill your employees, or recruit high-potential talent, our approach can help you build the right capabilities to unlock transformation. Learn more about Multiverse Apprenticeships.
Promoted Partner Content
