Non-Cloud Native Companies: How the Developer Experience Can Make Digital Transformation Easier

There is a large and growing number of software developers in the world. Despite what we hear in the media, not all are in Silicon Valley, or working at startups, or even at major tech companies. In fact, many – perhaps most – work at companies in “traditional” industries – regional banks, retail chains, health insurance companies, etc. Spurred by the need to interact with end customers through an excellent software experience, these companies are changing how they think about software. They want to place it at the core of their business, compete for customers based on its efficacy, and not fall behind their peers.

The focus of the conversation is often the cloud, figuring out how to “get there”, which cloud to choose, and how to handle security. Non-cloud native companies report challenges extracting value from their cloud investments. They cite the pervasive skills gap as a barrier to success: according to a recent McKinsey survey, 95% of respondents say a lack of cloud talent and capabilities holds them back in their transformations.

To succeed at digital transformation, organizations must go beyond the “get to cloud” mentality because simply moving apps to the cloud only confounds the problems they already have. Instead, there must be a more intentional strategy. Going “all-in” on the cloud means you’ll also have to adopt new ways of teams working together and break down the silos of the past. Solving for the developer experience is a powerful and convenient way to break through the old thinking that separates infrastructure and DevOps teams from the lines of business.

Minimize developer toil

One survey found that developers spend only 32% of their workday coding. When developers can’t work on developing software, it costs the business money. “Toil,” the term commonly used to describe the grunge-work developers must deal with, diminishes productivity. Eliminate toil, and you increase productivity.

This calls for the teams building the platform and pipelines to see the developer as their customer in a way that goes beyond the corporate-speak of the past. They must be motivated to question assumptions of what can and cannot be automated, and be judged based on metrics such as the time taken from a developer being “ready” to when the modification is in production, or the time it takes a developer to be onboarded to the platform. The culture needs to constantly ask “why is this thing hard for the developer.”

Invest in automation

When your team automates its processes, your software supply chain becomes streamlined. Your developers can then put the software in a continuous delivery production loop — a virtual conveyor belt that governs the process. In effect, your code enters a production-like environment without developers having to perform the productivity-killing inventory configuration tasks. This goes beyond technology improvements alone: they must include stakeholders from legal teams, for example, who might by default stand firm on the requirement that certain checks are manual. While there may be laws that force manual sign-off, in my experience if a team really thinks hard, not only is much more automation possible but in fact it is a better solution for the business stakeholder than the previous manual-only process.

Only invent what differentiates you

Platform Developers at non-cloud native companies have grown used to doing everything for themselves. Their bootstrap mentality is admirable, but building a tool that’s already available elsewhere is a terrible idea. Don’t build a platform for Kubernetes, for example. They already exist. Only build those things that differentiate your company. For the rest, save time and resources and look into existing solutions. The Silicon Valley giants have to build new infrastructure because they have unparalleled scale; if you don’t – and you probably don’t – then make use of their inventions rather than creating your own.

Cross-pollinate your teams

To force the cultural change, Infrastructure and DevOps teams might be trying their best to serve the developer, but walking a mile in someone else’s shoes isn’t easy even with the best of intent. Consider cross-pollinating the teams, rotating a few individuals every so often, as the permanent state. That way, those creating the developer experience will have to experience it themselves, which tends to blow up any feeling of pride in one’s creation. In the opposite direction, the application developer gets to explain the problems inside the DevOps team in a much more effective way than in a series of meetings. Above all, the tactic helps the overall culture of collaboration in a more effective way than I’ve seen result from any insistence by management that “we’re one team”.

Developers love it

Furthermore, application developers crave understanding what they are trying to accomplish and problem solving in light of it. A happy developer is one who works directly with business people who define the goals, use creativity to solve them, and experience the results. An unhappy developer is one who builds something dictated without understanding why, and never finds out if it worked. This is one of the secrets of retention, and indeed attracting developers, which is usually overlooked.

Lose the perfectionism and connect with the end-user

Non-cloud native companies are trying to connect to the end user. Our past mentality is not to release an application until it’s perfect. However, development is continuous at cloud-native companies: they start with a minimal viable product and perfect it as they go along. While this process sounds reckless, it allows the development team to see what features users like and don’t like. Then, they can go even further and connect with the end-user through surveys and research. End the hesitation and perfectionism. I have never worked with a team that in retrospect wished it had released later when things were more ready.

Getting the payoff for the business

Assuming this is in motion, there is still more cultural change to drive. The point of an excellent and always-improving developer experience is for developers – really product teams – to be able to continually produce and modify software in support of the business. We need to bring business stakeholders into the ongoing process of software development, which means defining customer success criteria for each major step forward in the software, creating hypotheses for how to make it happen, working continuously with developers on requirement definitions that fit those criteria, measuring them against customer feedback, and closing the circle with refined and new hypotheses.

These are some of the ingredients that I’ve seen are the most important to help organizations progress along their digital transformations, but often overlooked because they call for behavior change and bold thinking. Developer experience must be a priority, which takes new ways of thinking and interacting between developers and infrastructure teams. Once it’s improving, the developer must be connected to the business teams to reap the benefits. Add these to the technology improvements of the cloud age and non-cloud native companies really can make the leap.

To learn more, visit us here.