Every company uses technology, but does that make every company digital?
Not quite. Companies of every size and industry are on their journey to being digital to meet customer needs for seamless experiences, as well as increase internal efficiencies.
Often, that means building tech into operations, whether it’s developing an app to file claims, a chat bot to manage service outages, a patient portal to host telehealth appointments, or a simple e-commerce capability.
This is not just the mandate of the present, it’s the future—and traditional sectors increasingly look like tech companies as they build solutions to capture market opportunity and fend off competition.
But just because traditional companies are looking more like tech companies doesn’t mean they’re acting like them too. If every company is soon to be a software company, how should that change their mindset and key processes?
While traditional industry organizations aren’t set up the same as the “disruptors,” they still face the same pressures: speed, security and quality. Now, traditional companies should borrow the same best practices of mature software technology companies to maximize their success and accelerate their digital transformation.
Top Industries Employing Tech Workers (3.98 million IT jobs in the U.S.):
- Professional Services
- Finance and Insurance
Much like shepherding a drug for FDA approval or preparing for an acquisition, software development has its own lifecycle (SDLC) which is unique to each company but ideally aligned around common best practices.
In DevOps, the concept of shift left has been around for decades to describe the practice of moving software testing for quality and performance earlier (left) in the process. Microsoft famously popularized the mantra “test early, test often.”
The goal is to increase speed to market and avoid having to manage costly bugs or other issues before they are released or near-released into market.
To stay competitive, traditional companies need to adopt the tried-and-true methods that many tech companies have honed over the past two decades, starting with the concept of "shift left" in software development and scaling key processes across the organization.
The process also helps ensure more predictability and higher quality to help companies meet their brand promise and customer demands.
Agile software companies have already been working in this model, as customers and business leaders alike have come to expect near constant updates and product releases:
Netflix deploys code thousands of times per day
Amazon is known for releasing at least a deployment per second, and
Airbnb deploys 125,000 times per year
For years, software companies have been placing an emphasis on security in code, apps, and infrastructure earlier than ever. It’s a trend we’ve recognized from the 300-plus software diligences we conduct each year through our M&A transaction advisory services. Partly because it’s proven to reduce the impact of cyber incidents: A 2019 report by the Ponemon Institute found that the average cost of a data breach for companies that did not have a Shift Left approach was $4.59 million, while companies that did have a Shift Left approach experienced an average cost of $3.34 million, or 27% lower.
For companies in other sectors, adapting to the shift left model may begin by joining up security and product teams in the design phase, building connections between risk and R&D teams, and ensuring stronger customer feedback loops.
The bottom line: It’s unfortunately not as simple as flipping a switch. While testing earlier is now a commonly accepted process in software companies, security priorities have created new sources of tension and process changes that companies starting on this journey should seek to circumvent.
In theory, engineers and security professionals have similar goals: put out software that is high quality and minimizes risk to the business. In practice, there is often an adversarial relationship.
The challenge comes down to competing mandates and incentives. Many engineers are reviewed based on how much and how fast they ship, with pressures coming from business leaders to fulfill their requests and updates immediately.
On the other hand, security and compliance professionals are under pressure to reduce risk and ensure quality – and their jobs could be on the line if they miss a critical vulnerability. It comes to a head in the software development process.
In one organization, to build bonds and common understanding between risk and other departments, they gathered all the stakeholders together for a conversation on risk tolerance.
For each software priority, each stakeholder could voice their concerns, which put risk and opportunity on a sliding scale.
In the end, the CEO could make a clear call on risks they were willing to take in the name of speed and service, and where there were bright lines.
Everyone was heard and then with direction from the CEO, they were aligned and empowered around a clear mission to move forward without fear of punishment if something failed.
In one company example, there was an inherent distrust between the developers and security team. It was by design – the security team literally had to poke holes in the work product of the developer. They have to assume a mistake was made or a weakness was missed to do their jobs effectively. Similarly, compliance teams have a reputation for slowing a process down or in some cases, stopping it all together in the name of protecting the company from risk.
The net is that relationships between the engineers who develop software and the risk professionals who test it has been more along the lines of “frenemies,” and not as healthy as it should be.
There is a way to shift from frenemy to productive, positive collaborators. When companies form multidisciplinary teams – with representation from software developers, customer service professionals, and security and compliance professionals – they can foster a more collaborative process that achieves everyone’s goals.
It can sound counterintuitive, but developing software that builds in security and compliance features from the ground up and moving testing earlier in the process does not actually slow down the SDLC when done right.
Companies need to look at the software development process holistically, not just up until launch. In fact, while shifting left may make the time to launch a little bit slower, it’s still a faster SDLC overall because it drastically reduces the time and stress post-launch and needs to fix bugs or weaknesses.
A recent study makes clear how shifting left can scale:
Companies with a DevOps approach deliver software 200x more frequently than others, according to DevOps Research and Assessment (DORA) and Google Cloud.
While speed to market will always be important, for some Fortune 1000 companies, there’s a line between being fast and being first. In highly regulated industries like financial services and healthcare, many companies may prefer to be early vs. first because they lack the size, resources or reputation to handle the scrutiny and risk that comes with introducing a truly brand new offering or capability.
For example, while telehealth is an increasingly mature offering, it’s also complex. In the beginning, healthcare organizations needed to consider secure platforms, state and local regulations, privacy, access, quality of care and more. The risks of failure were not just reputational and financial – it could be life and death. For small and midsize healthcare organizations, the right strategy was to wait until some bigger players went first, learn from feedback and adopt what worked for their organization, then make their move.
That’s a sound strategy for many, and the shift left principles can help companies move quickly once the market opportunity and roadmap to success are more established.
Competing effectively with software companies will also require looking at related processes and workflows. In some cases, this may mean a mindset shift to be more data-driven and algorithmic and have a vision that drives and simplifies prioritization.
For example, tech companies with an agile model set a product roadmap that is informed by the business strategy and factor in engineering resources pragmatically – with focus on bandwidth and what the team can realistically achieve.
On the flip side, too many traditional companies are underinvested in engineers and end up with an understaffed department that spends more time responding to the most urgent tickets and not making enough progress on strategic initiatives.
They jump from putting out one fire to the next and are measured by projects completed vs. products enhanced. It’s not possible to deliver your best work in this environment, and so companies without a disciplined process end up with fewer releases and product updates, and more problem-rich code.
The costs of bad code are significant:
According to the Consortium for Information and Software Quality, faulty software cost U.S. businesses $2T in 2020.
But companies can’t evolve to a more mature model without commitment from every part of the organization. It requires clear vision, multidisciplinary teams, and incentives that connect to desired outcomes.
While technology is the obvious foundation for any software development process, the reality is that while some projects fail due to technical issues, more often than not it’s people that make or break an initiative or launch.
The same is true when you apply this methodology to any goal. In fact, “shifting left is a process and culture shift, and change management is essential to see it through to success,” said Rick Sabatino, a director in organizational change management at West Monroe.
While the journey will look different for every company, it can follow this roadmap:
In addition to CEOs, many organizations now have a Chief Product Officer, Chief Technology Officer, Chief Information Security Officer and Chief Operations Officer.
Which executives should lead the path to a more agile model? All of them. Tone and direction at the top is essential to getting buy in across the organization and holding teams accountable.
Executives with different mandates need to come together first to align on what’s most important – the customer – and then cascade that across the organization.
To effectively collaborate across the organization, data also has to travel across the organization. That means ensuring teams have access to the right data, that it’s accurate, and that they are empowered to act on it.
A good first step is to make sure you have the right infrastructure in the cloud to support data access and collaboration, then empowering teams to use it.
As companies establish more frequent deployments, there should be an increase in learnings and customer information as well. It’s critical to ensure teams are reviewing feedback and insights regularly to incorporate into strategy, new updates and new products.
For example, apps often have high rates of abandonment after download. If teams are reviewing use drop off data regularly, they can problem solve and make updates that increase value.
Interpersonal tension and mistrust are at best a distraction and at worst debilitating to an organization.
In too many organizations, anyone who’s not in the risk department views risk as an adversary. But it’s hard to battle anyone if they are on the same team.
If there’s current distrust between engineering and security or risk and operations, it’s critical to orient them around the same goal and develop empathy for each side’s roles in achieving it.
Consider the move to a digital front door in healthcare. Scheduling an appointment through a patient portal sounds simple, but it requires IT to build a patient-friendly portal that has HIPAA compliant security protocols to protect data, then connects with the operations and administrative teams to sync calendars, the finance department to invoice and pay securely and the providers to ensure communications capabilities are aligned with needs. If a technology solution serves or enables key departments across an organization, they should all have a say in its development.
Whether you’re a large global company or a start-up in growth mode, your resources are finite. Developing a more digital process also means working within your reality, and when it comes to the software or product development process, that means prioritization.
The right priorities will be different for every organization, but the deciding factor should be what is most important and urgent for the customer. In some cases that may be a new feature or update, in others it’s patching a new security weakness. Clarifying the priorities in a year, quarter, month and even week leaves less room for overworked teams and underserved customers.
Any time organizations are plotting change or launching a new initiative fatigue is a factor.
Teams can grow tired of learning and trying new things and feel stalled if the project is taking a long time.
However, organizations can maintain momentum and urgency by breaking up processes into smaller, shorter-term steps. Set product or software feature milestones in two-week bursts so that teams can celebrate more wins and feel incremental progress each week.
Even as the markets and business climate changes, it’s still a constant that what gets measured gets done.
The shift left model and move to build more agility to processes fails without accountability. Companies should create a common set of goals and milestones that multidisciplinary teams work to achieve. For example, risk professionals can have a dotted line accountability to product teams and vice versa.
If product teams are measured holistically against not just how much they are shipping but how secure their solutions are, they will be more inclined to seek help from their colleagues and build in controls from day one.
Tech companies have a common model for promoting product value to customers: feature, advantage, benefit. The same frame works for companies considering a shift left model for product and software development.
Shifting processes left (feature) helps ensure fewer bugs and security weaknesses in software, while also increasing speed to MVP (advantages). The result? More satisfied and loyal customers (benefit).
But don’t overlook the related benefits across the business. Teams produce better work in a less contentious environment. Happier engineers and security professionals will stay with a company longer, building institutional knowledge and saving turnover costs.
In addition, for companies that might be looking for PE investment or considering a strategic sale, IT and security due diligence will be a much smoother process as investors are increasingly considering the security risk of an organization in their deal thesis.
If these carrots aren’t incentive enough, the regulators will follow with the stick. Including risk and security protections is likely to not be just a business imperative but a regulatory requirement soon, as regulators take a more aggressive posture to protect consumer interests, particularly in risky sectors like financial services and healthcare.
Traditional companies have a limited runway to adapt their internal processes in order to act and compete more like a tech company. Shifting product and software development processes and adopting a more agile approach will be essential to that evolution.
Our teams are entrenched across traditional and tech sectors and are uniquely positioned to help companies turn shift left and DevOps concepts into reality because our processes reflect these same principles. We bring together a multidisciplinary team of product development, IT, security, and people and organization experts and agile processes to help companies do the same inside their business.
To learn more, contact us.