As a society, we have some crazy expectations from the applications we use. Secure, bug-free, and user-friendly. Application development must keep pace with the rapidly changing business environment, increasing client expectations have driven development and iteration times from months to hours. The challenge with such rapid development is the gap between development and the end user. That gap represents a translation challenge of mapping user needs to working software. Agile and DevOps principles have the user highly involved early and throughout the development process. This constant interaction is effective, but expensive in both time and resources. What if we could remove the gap entirely and have the user develop their own applications? Low and no-code platforms are enabling Power Users to build applications that were recently only possible through professional developers. This new development pipeline has much to offer, but how should it be managed?
A Power User is an individual whose skills and expertise are more advanced than most other users. Every office has a spreadsheet wizard who solves problems for their colleagues. Today we have more tools than spreadsheets. Low code automation, application development, and business intelligence platforms are revolutionizing the way business users perform their workflows. Empowered users can skip the resource intense development processes and focus on building what they need. No more artifacts, boards, SCRUM meetings, quality assurance, user acceptance testing, or environments to manage. The entire development team has collapsed to one; therefore, hopefully no more communication gaps when the user is also the developer. With significantly less overhead, rapid prototyping can be done in days. Low code applications built by Power Users are supported by the foundation enabled by the platform they are using, saving months to years worth of development when compared to from scratch development.
Rapid development of applications through a low code interface does have its drawbacks. Reducing the development team to one introduces a single individual dependency risk. What happens when your office’s Power User gets mauled by a cat and is no longer available? When developing for one, the likelihood that the application has any documentation is very low. How well are the office spreadsheets documented? Probably not that well. Despite the rapid development potential of low code systems, much of the velocity is captured through templated features. When Power Users are solving novel problems, the development time can be significant for a single individual. Here are some questions to ask. How is development planned? How are issues tracked? What is being done to prevent building a black box (hello Excel marcos)? What will be done if the application becomes wildly successful and has been adopted widely through the organization? Managing these questions will require some structure.
There are no hard and fast rules for managing application development through Power Users as every environment is different. Let’s define some dimensions to help map your organization’s environment to a potential governance process. The core strength of Power Users is the removal of the development team and the administration layer that such a system requires to coordinate efforts effectively. The greater degree that the project is pathfinding, the less mission critical, fewer total users, and fewer types of users, the greater benefit a Power User can provide. At the end of the day, the exercise falls into risk management; a prudent manager would never allow a critical application touching numerous internal and external stakeholders be dependent on a single individual, no matter how powerful their wizardry skills are.
A Power User can be anyone in the office, and there are some simple structures to build robustness into Power User driven application development. The first is paired development, a common practice in software development, and a simple solution to mitigate the single dependency risk with the additional benefit two minds bring to a problem. The second is the implementation of a continuing education program within your organization to train staff in the use of these platforms. Low-code platforms are more akin to word processing and spreadsheet applications; a few training days a year can do wonders in the organizations working knowledge. Lastly, define the boundaries to which a low code application will require involvement with your organization’s IT staff. Some questions to explore. When the application is client facing? When the application is used by more than one department? When an application has been actively used for over a year? When the application as an expected operating impact over a determined value? Power Users can unleash innovation in organizations. Boxing in Power Users can stifle creativity, yet unbounded development may lead to fragmentation and creeping system risks. Proper governance of Power Users is a key element to staying technology relevant.