How Improving the Developer Experience Is Key to Saving Time, Reducing Costs, and Delivering Excellence

Most businesses today are driven by technology. In the fastest-growing companies, the speed and quality of software development correlate to how quickly a business grows. If software development is a function of your business, then you already know two key facts: one, that development productivity and efficiency are paramount, and two, the software developer’s role and involvement are crucial for the growth of your business.

When organizations build on a great developer experience, it benefits the business, so much so that advancement and results are both intertwined and inseparable. Despite this, too many businesses are either lagging or struggling to realize the tangible benefits that such a positive developer experience can deliver. This results in a lack of efficiency, waste of time, sunk costs to the business, frustration, and high staff turnover. In contrast, those organizations that have overcome such challenges and have established a proven, positive developer experience have a clear advantage. This article will look at getting started with your own developer experience and will examine the top 4 factors that are key to ensuring it is effective.

Getting Started with Your Own Developer Experience 

Research shows that many tech companies limit the developer experience to the boundaries of systems and tools with an expectation that these will make a developer’s life simpler, increase their productivity, and enhance the overall experience. Despite significant investment in systems and tools, organizations rarely experience increased developer productivity. As a result, most engineering managers remain disappointed about the lack of ability to unite tools and teams and to catalyze optimum velocity. In turn, this leaves developers feeling overworked, constrained, and demotivated. 

To turn this around, and to increase the throughput of their development teams, organizations typically resort to either:

• Coaching and upskilling developers to try and increase developer velocity.
• Hiring more developers to increase overall throughput.

Sad to say, neither choice results in improved developer productivity. With the former, if the developer is limited by system or tool boundaries, then coaching and upskilling won’t fill a technical constraint. With the latter, throwing extra resources might provide a temporary workaround, but it won’t ever remove inherent limitations. In my experience, many organizations are yet to realize that the best method of increasing the productivity of developer communities is by improving the developer experience. 

Developer Productivity = Developer Skill x Developer Experience

Companies hire great developers who are skilled at their job. However, we know from experience that if we don’t offer them the best developer experience possible, then not only are we limiting their potential, but we are inadvertently constraining our own business success. 

If you are just starting to think about the developer experience and will be building from the ground up, your current perspective might look overwhelming. As such, we recommend following the Pareto Principle and looking to improve the 20% of developer experience that will contribute to 80% of your developer’s productivity.

We have identified 4 factors that are key to both an effective developer experience and to organizational success.

Top 4 Factors that are Key to an Effective Developer Experience and Pivotal to Your Organization’s Success

Regardless of where you are in the journey of improving the developer experience, here are the top 4 factors to consider:

• Removing on-call fatigue
• Documenting enough
• Paying off technical debt
• Building a team your developers want to be part of

We will look at each in turn.

Removing On-Call Fatigue

Imagine you’re a developer and you wake up to a critical production incident. You have no clue of what broke the application, your logs are incoherent, and the metrics mean nothing. Your boss is gaining altitude rapidly, voices are getting louder, and users are complaining about performance issues. There is no tracing, so you have neither clue nor hint where the performance trips, and though you want to rectify the situation and help, you’re powerless. It’s a developer’s worst nightmare, but unfortunately, it happens too often. From a developer’s perspective, this is not only frustrating, but it can also be terrifying and can lead to what’s called on-call fatigue. 

In many organizations, the pace of development means observability gets the lowest preference. The focus is to get the software into the customer’s hands as quickly as possible rather than releasing a high-quality, easily maintainable product. As a result, the team’s culture is focused on the importance of the destination—the software deliverable—rather than the journey—the impact on the team, their efficiency, and their well-being.

The good news is that savvy organizations are wising up to the fact that every incident supplies the opportunity to incrementally enhance the observability of the software. For example, setting up logs at different log levels ensures that there is a clear, traceable record at every stage. Also, setting metrics at the proper stages helps with measuring each step and can offer valuable insights into performance and related factors. Additionally, consider gathering traces from all services in your application, so that you can collect performance at different spans throughout.

It’s important to note that systems and tools on their own will not help in removing on-call fatigue. It will take both organizational commitment and time to build the right observability. However, doing so will make incident reaction and resolution far quicker, easier, and more efficient, and will go a long way towards improving the developer’s on-call experience.

Documenting Enough

One added knock-on effect of focusing on rapid product delivery is that documentation often takes lower priority. One of our developers commented in a recent meeting that of all the organizations they have worked at, not one has figured out a great way of creating, managing, and organizing documentation. Typically, there is either too little or too much documentation. The former usually means a lack of both context and detail, and the latter means it’s either difficult to find the information you need, or, if you are one of those fortunate enough to locate it, you discover it’s out of date (usually due to a lack of authoring resources or their priority).

The best practice to rectify this is to start by figuring out the documentation that your dev-team needs. Where possible, involve the developers who built the service and therefore have a solid understanding of the entire system. Naturally, each team will have different levels and expectations for what they need, and it is likely that you will need to share basic guidelines for your dev-teams on what is required in terms of standards, expectations, etc. Beyond that, empowering the respective teams to decide their own scope will help with business-goal alignment, buy-in, and commitment.

As part of this scope, you will need to decide on how to store and share your documentation. Our own experience has shown that Confluence is an excellent tool for both internal and external engineering collaboration purposes. For technical documents, our developers prefer having the document closer to the code base, so we store the technical documents in the code repository. 

Developer productivity is often measured by how quickly they can release a feature. Sadly, the rapidity of release and the demands of the next project means there is rarely time to create accurate documentation. This not only adds to the pressure on the dev team but also impairs the long-term maintainability and sustainability of the product. In contrast, empowering your developers to create the documentation in parallel with the services they build ensures that you are building software that is maintainable from the outset. Good documentation provides clarity, offers a better overall onboarding experience, and avoids that much-dreaded downtime.

It is important that the time to create or update documentation is incorporated into your project phases and that a product is not ready for release until all components—documentation included—are complete. A feature is not stamped “Done” until it has both the required metrics and observability and is accompanied by the necessary documentation and tools for easier incident management.

Paying Off Technical Debt

Management of technical debt is an age-old topic of debate in the software development community. Sadly, the community still hasn’t figured out a consistent solution to address it: Executives want the engineers to expedite business growth; product managers want to get new features into the customers’ hands ahead of timeline and budget; customer-facing teams want to adhere to SLAs and  OLAs and keep customers smiling by fixing bugs on time and as promised. All the while, developers are trying to keep everything moving, often being pulled pillar-to-post, and are continually juggling competing priorities that affect agreed delivery timelines. Unfairly, it is they who get the blame for lack of predictability and not meeting delivery deadlines.

When aging software is on its last legs and is relegated to crawling where it used to run, it is important to note that frustrated developers can only do so much. The lack of attention and prioritization is frustrating, and organizations that eventually find themselves in this situation also discover that they have a higher-than-normal turnover of staff. Imagine running a car daily for 5+ years and never getting it serviced or maintained. It’s going to deteriorate, right to the point where it stops working and you’re faced with a choice: a massive bill to restore it to its former glory, or a one-way ticket to the junkyard. It’s the same with technical debt. However, when a software developer in a fast-growing business raises awareness about an ailing platform that is impacting the health and stability of the application, this is rarely welcomed. Though “Don’t shoot the messenger” springs to mind, from an organizational perspective, it is important to do more.

The best developer experience is delivered by encouraging your developers to pay back tech debts as part of their day-to-day function. By acknowledging and addressing such debts, you are not only investing in overall improvements but also helping the company move faster while supporting you in delivering a much better customer experience.

Building a Team Your Developers Want to Be Part Of

The saying is that employees don’t leave companies; they leave managers. Research shows that this is true in 57% of cases. In my opinion, developers place greater emphasis on the collective team rather than the individual manager. By building teams that your employees are proud to be part of, you are improving morale, establishing a more fruitful environment, and promoting better work (and work ethic) from all involved. This will increase productivity and results.

Indeed, when you are among people you trust and respect, creativity has no bounds. The best software is not produced by a 10x developer, but by a team that the 10x developer builds. Teamwork is key and the stronger the team, the better for everyone. Close-knit teams have already acknowledged and accommodated each other’s strengths and weaknesses, are used to working together and have already established the platform and framework that allows them to address and solve any problem. Two heads are better than one, right? An additional and significant benefit is that such collectives are usually focused on achieving business, rather than individualistic, outcomes. 

Conclusion

The developer experience is about building an environment that helps your developers achieve and operate at peak productivity. Arriving at that level of productivity is unlikely to come only through tooling. Rather, it will come through creating and providing an experience conducive to the developer’s environment. 

Where software and tool limitations arise, throwing more resources at the problem is doomed to fail. To succeed, you need to improve the overall developer experience: build on what you have, ensure it is up to date, accurate, and easy to follow (for existing team members and for new hires), and make it a priority of all future deliverables and releases.