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 \u2013 perhaps most \u2013 work at companies in \u201ctraditional\u201d industries \u2013 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.\n\nThe focus of the conversation is often the cloud, figuring out how to \u201cget there\u201d, 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.\n\nTo succeed at digital transformation, organizations must go beyond the \u201cget to cloud\u201d mentality because simply moving apps to the cloud only confounds the problems they already have. Instead, there must be a more intentional strategy. Going \u201call-in\u201d on the cloud means you\u2019ll 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.\n\nMinimize developer toil\n\nOne survey found that developers spend only 32% of their workday coding. When developers can\u2019t work on developing software, it costs the business money. \u201cToil,\u201d the term commonly used to describe the grunge-work developers must deal with, diminishes productivity. Eliminate toil, and you increase productivity.\n\nThis 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 \u201cready\u201d 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 \u201cwhy is this thing hard for the developer.\u201d\n\nInvest in automation\n\nWhen your team automates its processes, your software supply chain becomes streamlined. Your developers can then put the software in a continuous delivery production loop \u2014 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.\n\nOnly invent what differentiates you\n\nPlatform Developers at non-cloud native companies have grown used to doing everything for themselves. Their bootstrap mentality is admirable, but building a tool that\u2019s already available elsewhere is a terrible idea. Don\u2019t 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\u2019t - and you probably don\u2019t - then make use of their inventions rather than creating your own.\n\nCross-pollinate your teams\n\nTo force the cultural change, Infrastructure and DevOps teams might be trying their best to serve the developer, but walking a mile in someone else\u2019s shoes isn\u2019t 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\u2019s 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\u2019ve seen result from any insistence by management that \u201cwe\u2019re one team\u201d.\n\nDevelopers love it\n\nFurthermore, 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.\n\nLose the perfectionism and connect with the end-user\n\nNon-cloud native companies are trying to connect to the end user. Our past mentality is not to release an application until it\u2019s 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\u2019t 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.\n\nGetting the payoff for the business\n\nAssuming 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.\n\nThese are some of the ingredients that I\u2019ve 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\u2019s 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.\n\nTo learn more, visit us here.