Shifting left, shifting right
Are we on the cusp of a new era of empowered non-engineers?
Shifting left to developers. One of the biggest technology themes of the past several years has been the “shift left” of several key areas of responsibility to developers from other functional areas. The term comes from the idea that the typical technology value chain diagram starts on the left side with developers who write code which is then pushed towards production and actual business utility which is typically depicted on the right side of the diagram. Development (dev) is on the left, infrastructure (ops) is in the middle, and business is on the right. We’ve seen this trend with security (Snyk), testing (Testim, which was just acquired by Tricentis, among others), and observability (Datadog and many others). Software continues to inexorably “eat the world” and, along with it, the organizations that run the world. As the center of business gravity shifts towards developers, as software becomes increasingly complex, and as the pace of continuous deployment cycles increases, it’s only logical to expect developers to shoulder more of the burden for an increasing set of functions.
Enter no-code. Lately, however, I’ve been increasingly wondering about the possibility of “shift right” — a complementary but opposite idea. The idea behind “shift right” is that the no-code design paradigm may allow developers to extend “engineering-like” capabilities into other parts of the organization. No-code (and low-code) have already started to revolutionize how some software applications are being built and adopted by customers. We have been investing on this theme for some time, and my partner David has written about this very thoughtfully based on his extensive experience at Airtable — perhaps one of the best examples of this approach. Airtable, Miro, Wix, Notion, and many others are great examples of SaaS tools that are pursuing this “customer-built growth” (CBG) model. Our portfolio has a number of examples: Datos for customer-built remote patient care pathways, Levity for customer-built ML-based workflows, LoudNClear for customer-built marketing automations, and Forwrd.ai for customer-built predictive analytics.
Shifting right to internal customers. But what happens when the customers are internal? What functions are internal engineering teams serving that could — more efficiently and more agilely — be performed by other non-engineering teams within the organization? Can tools be built to enable that sort of intra-company democratization? What would such tools look like and how would they be packaged up, productized, sold, and deployed?
Webflow is a great example of this idea. The company’s positioning and brilliant advertising emphasized how Webflow’s front-end builder enables business teams to modify and deploy critical customer-facing front-ends without hitting obstacles caused by the need to work closely with engineering (or design) teams. Uniform is doing something similar with the DXP (digital experience platform). Statsig appears to be attempting the same for A/B testing. Our portfolio company, Candu, is enabling customer success teams to build pages directly into SaaS applications to drive faster adoption, better engagement, and happier customers — and all without any engineering involvement. Each of these is an example of “shift right.”
We are — we think — still in the early innings of figuring out how the shift-right trend will play out and how far it will go. I suspect there may be more areas where shift-right tools can help a business run far more smoothly, freeing up developers for more critical tasks. We also struggle with the complexity of these sales cycles: in most cases, both the engineering team and the business team must be engaged and supportive for the solution to succeed.
A call to action. If you are working on a company that is pushing a shift-right strategy — please let us know. I’m eager to hear about new opportunities for this approach — and to learn about the sales and adoption challenges you may be facing and how you are solving them. The shift-right world — if it comes about — should be a dynamic and efficient one — and we will continue to look for companies that are cracking the code on how to design and scale business in that domain.
