Why risk, and not complexity, is the best lens for evaluating low-code use cases

It's common to think about low-code use cases falling along a continuum similar to this 2019 diagram from Gartner.

Thinking about use cases in this way makes intuitive sense: align the number and cost of development resources according to the amount of effort and skill required to build an application. Don't, for example, waste a highly trained (and expensive) full stack developer on a simple project that could easily be completed by a more junior or even citizen developer. And don't entrust the development of highly complex and critical applications to those who don't have the appropriate level of skill.

Duh.

Although I've seen differing opinions on what should be represented on the y-axis (some people want to replace criticality with something like business value), I do find the complexity/criticality framework helpful for describing the conditions under which a specific workflow automation project might be assigned to a citizen development squad, to professional developers, or to a fusion team, as in the diagram below:

Recently, however, I've been exploring the idea that the only REAL factor in determining the right team to develop a solution is not complexity, but rather risk.

When we say that a solution is complex, we tend to mean that it's hard to build. As low-code platforms become more robust, however, the idea of complexity starts to disappear. It starts to signal either that the proposed solution is hard to do in a particular platform (which points to platform limitations rather than to inherent project complexity), or that there is something about the complexity of a solution that introduces risk even if a novice were capable of building the solution.

As more and more low-code platforms approach the kind of feature richness of Pega Platform, I can see the notion of complexity becoming less and less important, or at least only important in so far as it is a function of risk.

Just because it's hard doesn't mean it's risky. And just because it's risky doesn't mean it's hard.

This, to me, is an important insight of the Project Management Institute, which recommends that a citizen development squad become a fusion team (what PMI calls 'assisted delivery'), or even transition full responsibility for a low-code solution entirely to IT professionals, on the basis several kinds of risk: security, operational, architectural, regulatory, reputational, or financial. In PMI's view, citizen development squads should actively collaborate with extra-departmental and/or IT resources where there is risk that can successfully be mitigated by an expert. Where there is low risk, fast track with citizen developers alone. Where high risk, give the project to IT.

The concept of risk encapsulates a lot. It includes the ideas of both business criticality and business value. The more mission critical an application is, the lower the tolerance for risk. And so even a relatively simple application may not be appropriate for citizen developers if it is customer-facing, for example, and the business cannot afford for anything to go wrong. And the higher the business value, the greater the opportunity costs if even a simple workflow isn't built in very specific ways.

This kind of thinking has significant implications for low-code platforms and the centers of excellence responsible for program governance. Instead of asking 'what features are easy enough for a citizen developer to understand?' and restricting access to more complex functionality to professional developers, centers of excellence should ask 'what kind of risk could be introduced if we gave citizen developers access to this feature?'

In large organizations especially, it can be tempting to assume that a certain feature is 'too hard' for citizen developers. In many cases, this doesn't give citizen developers enough credit: many are seasoned technologists working in a squad, and not inexperienced individual contributors fooling around with building simple apps that drive limited value. And restricting access to helpful features can significantly drive up development costs because professional developers have to be engaged, not because a task is particularly difficult, but because of a gap in functionality.

The goal of citizen development is to (a) address the developer shortage while (b) driving down cost of delivery. In this spirit, the goal of centers of excellence and enterprise low-code platform vendors alike should not be to restrict access to platform features because they are too hard, but because access would introduce sufficient risk to justify assistance from a professional developer.

If organizations are going to truly scale software delivery (building more, in less time, with fewer resources), the question that platform vendors and centers of excellence should ask themselves every day is how to give citizen development squads as much autonomy as possible up until the point where the risk associated with unsupervised feature access renders that feature imprudent.