Will Citizen Development turbo-charge your digital transformation?
I’m sure you’ve already heard this argument, that software development is now so easy that with the right tools and support you can unleash a tsunami of change delivered by non-IT employees i.e. citizen development. Having worked in low code for a while, and previously in RPA, I know that this point of view is common amongst software vendors who are always keen to show the full range of potential usage for their products. So much so that some organisations that are new to low code jump to the conclusion that citizen development is the ONLY way to proceed rather than a choice.
Being old enough to remember the process re-engineering years of corporate transformation (i.e. Lean, Six Sigma), I see quite a few parallels that make me stop and think. That said, it’s clear that the tools absolutely work. When deployed in the right way by the right people on the right problems low code makes a significant difference to business performance. But therein lie the risks:
- Right way: Many process re-engineering or Lean-Sigma programmes focused on training up employees in the hope of transforming the culture to one of continuous improvement. Often that approach failed to also address other barriers to meaningful change e.g. correctly aligned incentives, management support, enough experts to support those learning etc.
- Right people: Not every problem worth solving can be tackled by a new and/or part-time practitioner who by definition lacks the experience and skill of an expert. Aside from the obvious difference in developer productivity / speed, employee-built apps can lack the security and robustness that many business processes require;
- Right problem: Working on the front line gives employees valuable insights into where the pain points are and what’s causing them. However, just because you think a particular process needs to change doesn’t mean that it’s the right priority for the business as the bigger picture may suggest something different.
At a recent Microsoft sector community event that Kainos presented at, I was struck by the number of conversations I had with different organisations worried about the number of employee-built low code apps springing up. They didn’t doubt the benefit these apps brought to their user(s), but did worry about them being unsupported by IT and how prone to needing support they might be. Building yourself a personal app or automation to aid your productivity is one thing, but when it’s something that your team or other parties rely on it’s quite another.
So what to do? Every organization is unique in its culture and working practices so no hard and fast rules can work across the board. However, the fundamentals of introducing a new technology do still apply:
Bottom-up enablement
Understanding what a new technology can do comes before effectively identify existing problems best solved by it. Most leaders / managers struggle to keep up with tech trends so need support in this area. More significantly, they will also “ignore” problems that they believe can’t be solved to put more energy into those that can. Only by shifting their understanding of the art of the possible will you get those problems back in play.
Top-down strategy
It has to be clear to all how the new technology aligns to and enables the organisation’s strategic objectives. More likely, it will align to 1-2 particular objective(s) which will help focus its deployment from leadership into management and frontline workers.
In addition, here are some principles to consider when shaping your approach to low code adoption and the role pro-development should play versus citizen:
- Operational resilience: Will the app etc. be a useful but optional enabler to a task, or will it become core to how a team operates? In other words, what’s the business consequence of the app being unavailable or inaccurate? Even if it’s used by only a handful of people, if it’s operationally important it should probably be designed and built by a professional.
- User base: Connected to the above point of operational feedback, understanding the potential number of users would also help define how seriously an app should be approached. Every organization will define their user threshold differently based on their size, but having a rule of thumb for when a user number becomes significant enough will help.
- Scalability: Some ideas can start small within a single team with a few users, but could be directly relevant to a much wider group of users across the organization. Examples of this are organisations that have the same teams in different countries or business units, or where the underlying functionality (e.g. shared mailbox with workflow) could be used more broadly. Designing and building a solution for scalability brings in extra considerations that pro developers are better equipped to handle.
- Technical feasibility: Low code is no different to any other tool that works by configuration in so far as it can’t do everything. Some solutions will just be beyond the technical expertise it’s reasonable to expect of a citizen developer so will require at least support from a pro, and some may even need customer development.
Ultimately, low code tools like Microsoft Power Platform offer employees new and exciting ways to boost their productivity. It’s when they are being used beyond an individual’s own tasks that it’s worth checking what’s involved so the right resources can be involved to help drive success. Otherwise, we run the risk of re-creating “spreadsheet hell” with apps etc. that aren’t documented, formally supported or robust enough to be relied upon day to day.