Unleashing the Creativity of Engineers: Improving the Developer Experience

Over the last few years, we have heard popular quotes about “software eating the world” and “every company is a software company”, and the implications are clear—every company has to support its business with good software. But has every company made all the changes required to their operating models, company culture, and way of working? I think there is quite a bit more that needs to get done, in particular as it relates to improving the developer experience.

The Rise of the Developer Experience

Recently, Developer Experience (aka DevEx or DevX) has become a trend that addresses some of the challenges that companies face with the rise in the importance of software delivery. Three aspects are especially worth exploring:

1. Software developers are now crucial employees: While in the past, software engineers might have worked more in the background to support back-of-house systems, they are now vital employees shaping the differentiation of company products and customer interactions.
2. Software delivery has become more complex: With the IT landscape broken down into smaller pieces (down to microservices and serverless functions) and the tooling landscape increasing in numbers while delivery is accelerating, it is clear that the complexity of governing and controlling this ever-increasing flow is challenging existing ways of working. A more systematic answer is required that is not just an incremental uplift from previous approaches.
3. The modern workforce is more fluid: Working with a changing set of contractors and SI partners and with people choosing to change jobs and employers more frequently, consistency in a company cannot rely on informal knowledge sharing. Besides uplifting the knowledge management strategy, having processes and systems created that make the right way to do things also the easiest way to do something goes a long way to supporting knowledge management.

So, with this in mind, how can improving the Developer Experience and Platform Engineering help? Before we get into this, let me give you my definition of differentiating Developer Experience and Platform Engineering. 

What is Developer Experience

Developer Experience focuses on the developer and covers everything that shapes the experience of developers. Suppose you put yourself in the shoes of the developer. In that case, you see that the organizational structure the developer sits in and the ones he interacts with play a significant role, and so do all the processes the developer needs to follow. Two other essential dimensions are providing meaningful career models and an engineering culture that makes it easy to learn and grow. One more example is a developer’s first experience with your organization—the onboarding process. How quickly and with how little pain can a developer start their job, write code, and deploy into an environment for the first time?

What is Platform Engineering

Platform engineering focuses on the systems the developer engages with. Think about all the tools a developer could need to do their job. This sprawling landscape of tools is fantastic to explore but can be painful to control for an organization. Getting the balance right and combining the tools seamlessly and efficiently is core to having a good developer platform. Unfortunately, it’s not as easy as just putting the tools together; adoption is a crucial problem. It can only be successful when you consider your platform a product and your developers and other stakeholders as customers.

Sources of Developer Motivation

We have the recipe for successful technology organizations if we add Agile methods and DevOps culture and practices into this mix. Technology organizations rely on motivated employees doing the right things.

If you’re familiar with Dan Pink’s work on motivation (see his famous book Drive), you know that knowledge workers (and developers are precisely that) get motivated by purpose, autonomy, and mastery. So what we do in organizations should support these sources of motivation—and they do. 

Let’s look into this further to explain how our mix of approaches provides a very promising environment to allow each developer to give their best and make the organization successful.

The Developer’s Purpose

Knowing which organizational problem our team is meant to solve is empowering for individuals. They have a reason to get up in the morning beyond doing their duty. It also provides them with the context to make better decisions and directs their creative energy in a way that aligns with the organizational goals. We can support the understanding of the developer’s purpose through practices like Agile methods that focus on product management and engaging directly with customers and stakeholders, vertical integrated teams aligned with products and services that the company provides, BizDevOps practices that allow developers to see the impact they are making.

The Developer’s Autonomy

Few things drain motivation more than just feeling like a cog in the machine. Having to deal with many dependencies or ask frequently for approvals restricts autonomy. One good way to measure autonomy is the number of tickets a team needs to raise or the number of dependencies with other parts of the organization that a team needs to manage. The more autonomous a team and its developers feel, the more they feel they are in control of their own destiny, which supports motivation. One of the “silent secrets” of achieving autonomy is that the application architecture significantly influences the level of autonomy you can achieve. Complex, entangled, or monolithic systems create very restrictive dependencies and are challenging to de-couple.

The Developer’s Mastery

Self-improvement is a crucial driver for many human activities. Think of all the hobby chefs, DIY gurus, and after-work musicians. At work, this usually comes in two dimensions: 

• Technical mastery, which means we are getting better in our craft, our role, or our technical area. 
• Business mastery, which means we are getting better at solving the problems for our organizations. 

Fast and frequent feedback can best support achieving mastery or progressing toward it. All the work going into creating rapid testing cycles, deployment times, and cycle times support this. In addition, it is essential to define measures that developers can use to see whether they improve technical and business mastery. These measures are not to compete against others but rather are most effective in allowing people to measure their progress. The popularity of certification pathways is an excellent example of supporting technical mastery in a chosen area.

Five Dimensions of the Developer Experience

Bringing all this together, we have five key dimensions that help define the Developer Experience, can improve autonomy, mastery, and purpose, and, hence, improve motivation in developers, which in turn helps organizations achieve business success:

1. Organizational Structure and Ways of Working: How do organizations organize themselves? How does that shape interactions and experiences? What methodologies and practices do they use?
2. Culture: What behaviors are encouraged and discouraged? How are people incentivized? How do we deal with challenging situations?
3. Developer Career Model: What does a career look like? And, how many different possible pathways exist for people to find the most appropriate?
4. Developer Journeys: These are the processes and system touchpoints a developer follows to achieve an outcome (e.g., deploying a new API, setting up a test environment, running a simulation, etc.).
5. Developer Platform (a.k.a. systems and tools): All the capabilities are supported by tools and these need to be orchestrated. Additionally, you want to be able to pull data and analytics out of the tools for insights and decision-making. All this requires architecture and integrations to make work.

There are several things to consider in each dimension and different approaches organizations can take. I will be exploring this in further blog posts. Stay tuned and sign up for the IT Revolution newsletter to be notified of new posts.

- About The Authors

Mirco Hering

For over ten years Mirco Hering has worked on accelerating software delivery through innovative approaches (what is now called DevOps) and six years ago started experimenting with Agile methods. He supports major public and private sector companies in Australia and overseas in their search for efficient IT delivery. Mirco also blogs about IT delivery at notafactoryanymore.com and speaks globally at conferences about Agile, DevOps and organizational psychology.

Follow Mirco on Social Media

• 
•