Software runs the world. From small start-ups to big tech, software businesses are ubiquitous and affect almost everyone daily. Moreover, traditional companies that once thrived without much technology now find themselves embracing software as a core business requirement. Where there is software, there is software development. Where there is software development, there are often hidden costs, bottlenecks and waste - and humans who burn out from frustrating processes and high-stakes pressure.
There is one discipline in the software development world that addresses these problems and it is called Developer Experience - or DevEx for short. In recent months, I’ve often found myself explaining what DevEx is to people outside of the tech industry. That turned out to be really helpful for me, even though it wasn’t easy to describe the impact of DevEx without using technical concepts like CI/CD, platform, IDE, IaC, etc. This led me down a few rabbit holes, but eventually I gained a new perspective that I’d like to share.
DevEx in a Nutshell
If you run a business, then you care about the bottom line. To have any bottom line worth thinking about, you need a product or service that provides value for a large enough number of customers. Then you need to make them aware and want to buy whatever it is that you are selling. In short you need at least a viable market, product-market fit and the right marketing strategy.
If the business has software development at its core then this bottom line is also directly linked to the software engineering work that goes into it: How fast are features shipped? How quickly can the course be corrected when market conditions change or new information arises? How much time does maintenance take away from moving forward? Is decision making supported by high quality feedback loops? Are customers complaining about reliability? And so forth.
Multiple disciplines have emerged over the years that take on these challenges: The DevOps movement revolutionized how we think about building, delivering and shipping software. Platform engineering aims to solve common scaling problems. Part of this ecosystem is the field of DevEx that this article is about.
So what is DevEx then?
From my own experience, reading articles, blogs, job descriptions and social media posts over the years I found there is a broad spectrum of how people think of DevEx. On one side of this spectrum is the view that DevEx is in charge of building tools that help developers more easily and faster test and release their software. More specifically, that often translates to the team that owns the software delivery pipeline (i.e. the processes and tools that get the software from the development to the user). I think of this as Functional DevEx.
On the other side of the spectrum DevEx looks at the whole developer journey (i.e. from hire to leave) as if it were a critical system. That makes all frictions and blockers that affect the impact that the developer can have (on the outcome) a concern. This implies a potential agenda everywhere that can affect the developers doing their work: processes, culture, and of course also the tools that influence day-to-day tasks. I call this Comprehensive DevEx.
I am a big proponent of the latter, holistic approach. This is what I will be referring to when writing about DevEx in this article. I believe this is the only sensible approach that leads to significant positive impact for the business that applies it. What this impact is and how DevEx manifests it is what I want to convey here. In my previously mentioned discussions outside of the field I noted that doing so is not easy, because it often requires deep knowledge about software development work. There is a knowledge gap that hinders discussion. I want to bridge that gap with a thought-model that explains the impact of DevEx from first-principles.
Unpack Impact
The impact that DevEx has on said bottom line is indirect: It acts upon the factors that lead to the outcome.
So what are these factors then?
Established DevEx frameworks, like SPACE, focus on measuring both human performance aspects (satisfaction, well-being, cognitive load, etc) and system performance aspects (error rate, throughput, stability, activities, etc). I won’t dive into any of that in this article nor will I expect that you, the reader, has any familiarity with the topic. Instead I will introduce four new factors. They are not intended to be used as directly-measurable metrics for day-to-day DevEx work. Their value is in providing an intuitively understandable framework that facilitates the discussion that I want to make happen - within and outside of engineering war rooms. I strongly believe that this will open up significant opportunities and alleviate real pain. Both on the engineering side and for the business.
Consider the following:
- Education, encompassing all learning and knowledge gained that is relevant for impact.
- Competence, measuring how well education can be leveraged for impact.
- Motivation, describing the willingness to be impactful towards business goals.
- Environment, evaluating the structure and frictions of the system within which work is being done.
The first three of these factors are traits of the engineers, the last is a trait of the organization.
To establish that these factors are sensible I will share a short thought experiment for all of them. In each I will provide a scenario where two potential hires only differ in one of the factors. If this difference is reasonably sufficient to predict the impact that the hires will have on the business outcome, then it is reasonable to assume that they are indeed good factors.
Education
Education - as a container word for any learning or knowledge gain, whether formal, informal or otherwise - should be almost intuitively clear. An example in the world of software engineering is easy to construct:
Say you run a business that provides a service or product through a custom iPhone App for your customers. Now you need to hire a developer to add more features to this App. You have two candidates: Alice, who has an impressive computer science degree and literally wrote the book on iPhone App development practices. Then there is Bob, who you know just started out looking into coding in his free time. You would expect Alice to be able to be productive and ship features that translate to increased adoption and revenue much quicker than Bob, because she has the knowledge to do so and Bob hasn’t. You would expect Bob to take a long while to catch up to where Alice is already. You would very likely be right. Knowing only this difference, you can make a good prediction.
Competence
Competence - as all the experience and developed understanding to apply your education for effect - is equally intuitively obvious. Considering again that hiring scenario, this time Alice and Bob both have a comparable computer science degree, but Alice has already worked for ten years in the field at various well-reputed companies. Her resume and self-presentation in the interview show that she has seen a lot of interesting tech problems in her career - and that she was able to solve them creatively and learn from them. The specifics of her past work align well with what she is expected to do in this new role. Bob however is fresh from the university. He has great aspirations and a puppy-eyed enthusiasm. He has not yet any idea of what kind of challenges await in field-work, but he feels his university degree prepares him for every eventuality. Knowing this it is reasonable to predict that Alice is much more likely to be impactful than Bob - just on the basis of their perceived work competence.
Motivation
Motivation - as the internal drive, interest and willingness to exert effort towards a goal - clearly predicts outcome too. This time Alice and Bob have comparable education and work experience. The difference this time is their drive. Assuming you can look in their head and see that Alice is genuinely interested in the work and really wants to help reduce the pain that your product is mitigating for your customers. On the other hand Bob is bored, burned out and considers this opportunity just as another gig to make some easy cash. Based solely on this, you can correctly predict that Alice is much more likely to deliver a higher impact towards your goals than Bob is.
Environment
Environment - as the sum of all the tools, organizational structures and processes that are part of the value generation and affect the developer - is certainly factoring into the outcome. It is not under the control of the candidates, but it is the context in which they are being hired into. To see the effect Alice and Bob are moved after the hiring stage. Both have equal education, competence and are highly motivated. Alice works in an organization where she can focus on developing the App. She gets effortless highly accurate feedback from the users and can roll out changes within minutes. Bob’s workplace requires him to spend a lot of time in coordination meetings, he rarely has an hour of uninterrupted time to work on the App. New releases require a lot of approvals from different departments and many highly stressful, manual steps. They are done only monthly, bundled together with many other developers changes. Given this, it should be obvious that Alice is much better positioned and therefore much more likely to contribute a lot more outcome.
Hiring Problem?
While the environment is not in the control of the candidates, the other factors are independently good predictors for the outcome of their potential work impact. Surely, a good hiring pipeline can account for them? Well, no. Or rather: only somewhat, and it depends on the nature of the business that is hiring.
Ramp-Up Costs
Say your business is a restaurant and you have poached a known top chef from a competing eatery. It would be reasonable to expect that your new hire is able to serve their signature dish equally well in your place as they did at their previous employment. Assuming access to all the right equipment, ingredients, etc, of course.
However, if your business is in tech and you hire a senior engineer then things look quite different. Unless that is your first hire in a new venture, there is likely already a large code base, or many, and often a rather complex technical infrastructure that goes along with that. To understand the current state the engineer often needs to understand the history that led to it as well. More so, previous design intentions and choices often still make up a good part of the active code, even if they are superseded by novel approaches. It will take time for this new engineer to be able to safely roll out changes. It will take even longer until that engineer is anywhere near their peak performance. In large infrastructures a year and more are perfectly expected ramp-up times. This ramp-up time is longer for higher level engineers, which usually goes along with more experience. The reason is of course that higher levels come with greater responsibilities and therefore larger scopes of complexity that must be integrated.
Domain Costs
During this ramp-up time the new engineer will improve their Education by integrating the domain knowledge: Understanding of the code base, infrastructure, organization, culture, and so forth. They add to their Competence by applying their knowledge and navigating the domain (the workplace). Their Motivation is also affected by the experience of the engineer while going through this process and being confronted with the Environment. Negative experiences (like frustration, confusion, anger) usually drain motivation quickly, whereas positive experiences (like success, feeling supported, aha-moments, leveling, etc) build it up.
In other words, in addition to the education, competence and motivation that the engineer comes with there is:
- Domain Education, that can only be acquired after joining the company and learning about the local setup, code, structures, etc.
- Domain Competence, that can be only gained when already working within the structure of the company.
- Domain Motivation, that is shaped by the experience of the individual engineer in the Environment.
I am going to call this the **Domain Cost. **The price that has to be paid to approach peak or even high performance.
Somewhat a Hiring Problem
Back to the question whether this is a hiring problem: If there is a very low domain cost, then sure. If there is high domain cost, then only insofar that hiring can filter for potential peak performance and potential timeframe to get there. With tech companies, unless they just start out, there is almost always a high domain cost, because it simply reflects the size and complexity of the structures that make it up and that individual contributors must deal with.
To be clear, my use of peak performance may imply that this is only about getting the last few percentage points of performance: It is not. This is about even low to moderate performance. The best software engineer in the world won’t be able to be productive if they don’t know how to ship code, have no clue where to make changes, or are unable to get the right approvals if that is needed.
Process, not Destination
Complexity usually tends to breed more complexity. Your tech business is not static. The code-base is not static: it may be refactored and restructured massively and many times over its lifetime. The infrastructure is not static: it may evolve through designs, or arising opportunities, it will shrink, grow and generally scale many, many times. Processes resulting from organizational structures are not static, because organizations tend to re-organize themselves periodically, they move through expansions and contraction, they are influenced by many changing factors like changes in leadership or market conditions.
That means: the domain specific knowledge continuously evolves, corrects itself, extends, deprecates and so forth. This is why I chose Domain Costs over Ramp-Up Costs. The expenditure is continuous. It starts with a steeper curve (i.e. onboarding and ramp-up). It still will have many small and large curves ahead.
Do not fall into the trap of looking at this only as a “cost of doing business”, because this would leave a large opportunity on the table: leveraging this understanding well to vastly increase the outcome. This brings me to the topic of this post:
DevEx for Impact
A general recipe for DevEx work is hard to come by, although I will try to provide commonly applicable examples shortly. In real life the work is highly situational. DevEx is fundamentally interested in every step of the developer journey: starting with hiring, on-boarding, ramp-up, day-to-day and ending in off-boarding. Every aspect of the systems and organization that affect developer work along this journey is a concern of DevEx. While DevEx will not “run” all these places, it will certainly have an agenda for them if they cause friction or provide opportunities. The specific measures then depend on the situation of the organization: where is the largest friction to be removed? Where are the easiest gains to get?
Having this said, let’s have a look at concrete actions that DevEx can undertake to improve the four factors. I will need to use some software development jargon to illuminate their effects, but I will try to limit that as much as possible.
Mind that what I propose are large scale initiatives, which bundle many individually useful efforts that could be undertaken separately, or at least iteratively. I aim for the bigger picture. Furthermore, none of these efforts need to be done by DevEx, although DevEx will be interested in ensuring that they come to be and is well positioned to initiate and drive them at the start.
Pave the Delivery Pathway: CI/CD
Create standardized, automated pipelines that reliably build, test and deploy software changes with minimal or no manual intervention. Yes, this is “classic CI/CD”. The goal is to increase the efficiency of the software assembly line.
What does this impact?
- Environment: Drastically remove friction in code delivery by categorically removing many manual error scenarios and eliminating manual efforts.
- Competence: Provide fast feedback loops for developers enabling rapid iteration and fast validation.
- Motivation: Eliminate frustration and anxiety that come with manual, high-risk software releases. Increase job satisfaction by allowing engineers to focus on development work.
Unlock Engineering Know-How: Knowledge Management
Create a centralized knowledge hub (sure, a wiki) that enables knowledge ownership and provides quality feedback pipelines to these owners. Enable domain actors to contribute with ease. Advocate organizational buy-in to prioritize and remunerate knowledge management work of engineers. Based on this, create and maintain a streamlined learning pathway for onboarding.
What does this impact?
- Education: Flatten learning curves, especially during initial onboarding. Reduce distribution and access costs for crucial knowledge, lowering learning barriers.
- Competence: Reduce cognitive load of “hunting for information”. Increase confidence to act through reliable, authoritative information.
- Motivation: Signal interest in long-term growth of individual engineers, improving trust and goodwill.
- Environment: Reduce friction of navigating within systems. Disperse tribal knowledge boundaries.
I think a note on using AI (or specifically LLMs) is needed here: I consider this an implementation detail, as it is “only” an interface for the information. A powerful one, but it builds on reliable and recent domain-specific information as any other interface would. The above proposed measures for knowledge ownership and ease of contribution are unchanged by that and I maintain that guided learning pathways are also not obsoleted, but amended by this technology.
Fast-Track Talent: Systematic Leveling
Establish a buddy system for onboarding and a career-long mentor system that incentivizes participation and is supported by best-practice knowledge and complemented by self-guided learning paths.
What does this impact?
- Education: Extremely short feedback loops enable quick learning. Largest possible bandwidth for tacit knowledge and culture transfer. Enables continuous learning.
- Competence: Quickly overcome beginner problems in onboarding and ramp-up. Early exposure to production work, with safe-guards, builds confidence fast, reducing ramp-up strongly. Enables continuous skill development.
- Motivation: Strongly reduce anxiety and confusion during onboarding and ramp-up. Demonstrates deep investment in person, building loyalty and engagement.
- Environment: Supports collaborative and knowledge-sharing culture. Builds fast support pathways and deep connections that reduce communication friction.
Empower Builders: Developer Platform
Create a unifying platform where developers can make use of standardized templates, tools and services (like requesting test environments, managing monitoring, accessing application logs, configuring scaling for applications, etc) that are entirely self-service and reduce the amount of complexity developers have to deal with.
What does this impact?
- Environment: Increased consistency and reduced complexity free up mental resources. Reduce cognitive load reserved for secondary activities that are not development.
- Competence: Empowers engineers to manage their applications with low effort, giving them control and enabling them to focus on their core competencies.
- Motivation: Less frustration when engaging with infrastructure, through hardened and performance-optimized workflows.
- (Education): Persist organizational knowledge in code, countering knowledge degradation and enabling knowledge validation.
Bridge Team Silos: Cross-Team Exposure
Create structures to give individual engineers the chance to rotate temporarily in other teams (especially adjacent ones) to transfer both explicit and tacit knowledge peer-to-peer.
What does this impact?
- Education: Creates a channel for tacit knowledge transfer. Breaks down knowledge silos. Enables T-shaped knowledge building (deep learning in specialization, broad understanding of context).
- Competence: Improved decision making abilities through better understanding of related systems and organizations.
- Motivation: Forms bonds, contributes to motivating we-feeling.
- Environment: Establishes shorter communication pathways. Improves collaboration.
How Much Impact?
You may have noticed a lack of any hard numbers that predict the business outcome in the previous examples. That could not be helped. DevEx is similar to adjacent disciplines like security or reliability. They all affect the very “fabric” and shape of the systems that they are part of, which makes predictions rather difficult. It is very challenging to quantify the damage to customer-trust - and the bottom line in the years to come - that was prevented by thorough security measures. It is almost impossible to count the outages that did not happen due to top-notch reliability efforts. Similarly, it is futile to attempt to measure the impact of inventions that were made because of continuous learning structures that have been put in place. Or the time saved by automating annoying processes that then freed engineering resources to improve documentation, which then prevented countless person-years of information hunting, and so forth.
The field of medicine provides an excellent comparison. A medical doctor knows what “healthy” looks like, generally speaking. Similarly DevEx practitioners know what a “healthy” system looks like and what a “healthy” developer journey entails: smooth workflows, fast feedback, uninterrupted information flow, stable and efficient operations, etc. Medicine uses “pain” as an indicator for health problems. So does DevEx, although it calls this “friction”, which manifests as developer frustration, slow processes, unreliable tooling, or production incidents. Both medicine and DevEx can formulate treatments to improve the state towards “healthier” (see the previous examples). Both think of their domain (the human body and respective tech organization) as complex systems where changing one part influences many others.
Now, a medical doctor can still confidently say that healing a broken leg will enable a patient to walk and run substantially faster. However, they would not be able to predict how many seconds faster the healed patient would run in a 100 meter sprint. The notion itself is ridiculous. In that same sense can DevEx identify significant friction (i.e. the “broken leg”) and confidently state that addressing that will improve the outcomes: faster delivery, higher quality, more innovation, etc. So while the precise impact of individual measures may be forever elusive, there is no question whether “curing” unhealthy components is tremendously beneficial to the whole.
Having this said: DevEx, reliability, security and medicine have plenty of hard numbers to go on. They are all strongly leaning on empirical evidence. However, these are proxy metrics. Like DORA’s metrics, which are well established by now, they can be used to measure the health and identify friction, but they won’t give you a good prediction for the bottom line of the next quarter.
Conclusion
I hope this article illustrates how a comprehensive DevEx can impact the bottom line by improving the factors that lead to it. Needless to say, I have only I provided a snapshot of what is possible
I am deeply curious how others look at DevEx and see the opportunities it offers. Write to me, if you have opinions!
