How Retailers Can Innovate Faster - A Blueprint for Digital Transformation

Even to a casual observer, it’s clear the world’s economy is quickly changing. A company’s average tenure on the S&P 500 has gone from 60 years in the 1950’s to less than 20 years today, with the average tenure reducing at an accelerating pace. The five most valuable companies in the world are now tech companies whose goods are primarily digital rather than physical.

Today’s leading businesses have two things in common – they’re building software-based intellectual property, and they release software often. Innovators like Amazon release 50 million times a year to production, for example. Quick releases are key to innovation, as they allow for rapid iteration of new business models and new product features. When you have to build a factory, it takes many years adopt to market changes.

Retail has been especially impacted by technology, with many calling the past few years the “Retail Apocalypse.” More than 12,000 physical stores in the U.S. are expected to close in 2018 and 50% of U.S. malls are expected to close by 2023. Pockets of retail are thriving, but many retailers face extinction if they don’t change. Retail uniquely is impacted by three major forces all converging at the same time. Let’s explore each.

The first trend is that shoppers are dramatically more tech savvy than they’ve ever been and physical retailers just aren’t keeping up. How many store associates have some form of mobile device, like a smartphone or tablet? With annual retail turnover approaching 67% for part-time employees and those employees having little access to technology, it’s no surprise that 95% of shoppers just want to be left alone when they shop. It’s just easier to pull out your smartphone, scan the barcode, and find the information you’re looking for. Chances are, the hourly part time employee won’t have a clue.

The second and related trend changing retail is that shoppers are increasingly skipping retailers entirely and instead turning to digitally native brands. Most shoppers have affinity to brands far more than to the retailer. If retailers aren’t adding enough value, there’s no reason for shoppers to keep using them. Technology has allowed brands to go direct to consumer. Andy Dunn, founder of Bonobos, is credited with coining the acronym “DNVB” to describe this new breed of brands. DNVB stands for Digitally Native Vertical Brands. In his famous “The Book of DNVB” post on Medium, Andy defines a handful of key tenets of these brands:

1. Primary means of interacting, transacting, and story-telling to consumers is via the web
2. Aimed squarely at millennials and digital natives
3. The brand is vertical. Brand makes, markets, sells and fulfills on its own
4. Maniacally focused on the customer experience

Think Bonobos, Dollar Shave Club, and Warby Parker as some of the better well-known brands in this category. This new style of commerce is threatening retailers by offering value, convenience and price in a way that is hard to compete with if you think in existing business models, processes and technologies. You can see it like this: Most retailers think from product to customer. Who bought the product for the lowest price and sold the most with an efficient supply and delivery engine made the highest profits and could invest in more units. Increasing units and decreasing costs was one key to success. Unfortunately over time the customer was (almost) forgotten in this equation. Young companies today built new customer centric business models as they think from the customer (not for). With no to little boundaries and backpacks some can easily disrupt existing business models when thinking "customer first" and moving fast.

In this triangle of forces fundamentally changing retail, flexibility and speed are crucial to success. With Amazon and many of the DNVBs releasing production near constantly, monthly or even quarterly releases to production that many retailers have grown accustomed to are simply unacceptable. Innovation requires constant and rapid iteration.

Unfortunately, many traditional retailers are among the worst adopters of technology. Technology was seen as an expense that must be minimized rather than as a means to achieve competitive differentiation. Retailers routinely spend a few percent of net income on technology whereas tech companies regularly spend 20% or more. The technology money that traditional retailers do spend disproportionally goes to large enterprise vendors like SAP, IBM and Oracle for big multi-year implementations of legacy enterprise software, or the maintenance of existing enterprise software. Little of that IT spend is really in the “innovation” category.

Many of the problems plaguing retailers stems from how retailers structure their IT organizations. Companies look at IT like any function and put people who do the same job together in the same group. For example, every company has a group of accounts receivable accountants within the finance organization. Every company has a group of staff lawyers. In many cases this makes perfect sense – accounts receivable collect money and lawyers resolve legal matters. In many cases, specialization is required to perform the work. Accountants need accounting degrees. Lawyers need law degrees. In this model of work, employees are essentially machines in a factory, accepting work, performing the work, and then passing it on to the next team/machine (sorry for this analogy, every human has an individual personality, skillset, values and much more that defines them, but when it comes to organizational setups most of us are unfortunately not treated with the personal creativity we all deserve).

Unfortunately, in IT, this segmentation of work by job function is extremely detrimental to innovation. IT is unique in that to build a new feature or enhance an existing feature requires crossing multiple team boundaries. Multiple front-end teams, a service layer/API team, a back-end application development team, a database administration team, an ops team, etc are often all required to make even the simplest of changes. Teams are groups of people who have similar education and training, work together on the same tasks, sit together in the same office, celebrate each other’s birthdays, report up through a single management chain, are incentivized the same way, and have a unique culture. Teams of people within an enterprise are essentially mini tribes and they act tribal.

Other teams aren’t trusted. They’re the “other tribe.” There often aren’t personal relationships between members. There are different management chains and compensation plans. They work on different floors. When teams don’t each other, which is human nature, each team erects boundaries to protect its own interest. This takes the form of excessive paperwork, change requests, excessive documentation/run books, multiple levels of approvals, too many meetings, etc. When there’s so much friction in crossing a team boundary, and implementing even simple changes requires involving multiple teams in a coordinated fashion, it’s no surprise that it takes weeks or months to do anything. Nobody is acting maliciously – it’s just the default way that organizations structured, and it’s the default way that humans act. Everyone is acting rationally in this system, yet the consequence is release cycles that are weeks or months-long.

Since the beginning of computing, this segregation by job function was necessary because of the specialization that was required. Configuring a network router was a very complicated task, akin to fixing a truck engine or performing a surgery. Extensive domain expertise, was required, including certifications. Database administrators, network administrators, storage administrators, etc each had their own “black magic” that nobody else could replicate. With true cloud emerging in the past decade and advancing so much, you just don’t need specialized teams of people doing work anymore. Anyone can create a network using the command “$ docker network create frontend-network.” Storage is just there and available to use, with the cloud vendors handling the complexity of redundancy, hardware drivers, capacity planning, etc. A competent developer can now set up an entire vertical stack of hardware and software in a matter of minutes. With the recent advent of Function-as-a-Service offerings like AWS Lambda, developers don’t have to care about anything. They just write their code and push it to their vendor. The vendor manages the entire underlying stack.

Stepping back even farther, well-intentioned managers feel the need to institute rules. When someone screws up, a rule is implemented to prevent that mistake from happening again. Let’s say a developer accidentally truncates a table in pre-production by executing a mis-typed script. Rather than simply restoring the table and letting the embarrassment of the mistake deter it from happening again, managers institute policies requiring sign-off of every script executed against a database. Maybe the manager takes it a step further and requires another team to execute every script, no matter how simple. After all, who wants mistakes? The issue is that these rules accumulate over time to the point where projects slow to a crawl and developers become little cogs in a big, slow machine. Other forms of this “over-management” phenomenon include requiring sign-off from a centralized architecture board for every decision, multiple unnecessary code reviews, management approval of designs, excessive documentation requirements, management approval for any piece of software, etc. “I don’t trust you” is what employees hear. Nobody wants to be a cog in a machine. Top employees leave because they don’t want to be constrained - they want to innovate. With a heavy management overhead, they can’t perform at their top performance anymore. To counteract the problem of delays, managers (often well-intentioned) add more people to teams. “If 10 people aren’t getting the job done, let’s double the team size to 20 and we’ll double the throughput” is the thinking in the executive suite. What managers don’t realize is that members of a team working on the same area must each communicate with each other.

Every new member of the team must communicate with every other member of the team. Fred Brooks succinctly summarized the problem in his famous Mythical Man Month book (1975) as:

“..the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.”

Again, this further serves to slow down projects. Johannes Mainusch documented this phenomenon nicely in the following chart:

Adding more people to existing teams doesn’t work. What does work?

Fortunately there are some well-established approaches to speeding up development that have long been how Silicon Valley-based tech companies have operated. First and foremost, it’s crucial to re-orient your team’s goals around a single metric: how long it takes to release a new feature to production. Efficiency, standardization, adherence to process, focus on cost, etc are all important, but speed should be the orienting factor. Innovation fundamentally requires rapid iteration.

Avoid structuring your organization in terms of technology layers. Rather than have a horizontal database administration team, for example, have a small cross-functional team of 5-10 people who look after the search domain, from the UI down to the infrastructure. That team should have people of different disciplines, from design down to ops, who are capable of making changes to the “product” they own. That team should see themselves as the owners of a product, rather than as individuals working on a database, for example. Members of the team should sit together in the same office, report to the same person (either solid or dotted line), and be incentivized to deliver new functionality for their product, which in this example is search. Functionality and data should be exposed through APIs, and the only means of consuming a team’s functionality or data should be through clear, well-defined APIs with SLAs attached to them. While the different teams should all have a shared vision and strategy, the day-to-day meetings that fill up calendars will largely disappear because each small team has what it needs within the team to release on its own. Rather than have to file a ticket with design to get a new front-end widget designed, the designer on the team can just do it. It’s all so much easier when work is done in small, trusting groups. Crossing teams boundaries is extremely time-consuming.

Related to a more product-focused orientation is the need for managers to let go and allow their people to innovate. In many professions, the best worker is only marginally better than the average. A good truck driver may be 10% better than a peer. A good welder may be 2x better. But there are a handful of creative professions, including IT, where someone who’s “good” is easily many times better than their peers, and the best can be 25x or even more. Software development is inherently creative. Unfortunately, process can build up to the point where the average IT worker’s productivity is a small fraction of what it should be. Rather than trying to control every minute detail, managers should communicate vision and strategy but give creative professionals the freedom they need to innovate. In 2018, does it really matter what database a particular team decides to use? No. Does it matter whether a team uses GitHub or Bitbucket? No. Is the $10/month that Bitbucket charges going to bust anyone’s budget? No. So why even bother managing those small details. Instead, give teams the vision and strategy, allowing them to figure out their own implementation details. Focus on the “why” not the “how.” If individual team members can’t handle the freedom, have them switch to maintaining legacy applications or something with a more rigid structure.

These are really the two major changes you have to make. The rest will flow naturally from there. There will be challenges along the way given how large these changes are. Maybe people don’t see the need to make the changes because they’re missing context. Maybe they have a good position on a team they like. Maybe they really like the coffee machine on the floor where they work. Maybe they’re just stuck in an old mindset and want to be told what to do. There are a myriad of reasons that people will resist this or any other change. To bring people along, make sure you have full organizational buy-in from the board on down. Without that buy-in, others will undermine the initiative, as organizations naturally don’t change much. Make sure to give employees the full context. The retail apocalypse is real and large swaths of retailers are facing extinction if they don’t adapt. Offer case studies where this has worked before and if possible bring in external speakers whose organizations have gone through this change.

These changes are absolutely required to succeed in today’s modern retail climate. With Amazon, DNVBs and others fundamentally changing retail significant meaningful change is an absolute must or extinction is nearly assured. Remember that this is 90% human-related, 10% technology-related. Incrementally change the organization structure, allow teams more freedom to innovate, and the transformation will largely happen on its own. ?