Think like a Citizen, Developer!

(Views expressed are strictly my own; they do not reflect the views and opinions of current or past customers or employers.)

The Citizen Developer movement, with its new buzz word title, sounds aspirational and in many ways, it still is – but more importantly, it provides an amazing opportunity for enterprises. An opportunity we’ve not had before. The opportunity to harness ideas and improvements from those in the corporate trenches, from those most intimate with the daily problems. We can bypass the lengthy and error prone requirements processes and get to a tiny working solution faster. These solutions benefit the business and create a culture of ownership and continuous improvement. However, with and important caveat - only if done right! Here I lay out key structural components to put in place so low/no-code can benefit your organization.

According to Gartner, a Citizen Developer is “an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units. A citizen developer is a persona, not a title or targeted role. They report to a business unit or function other than IT.” [1] Essentially a lay (non-professional) developer can contribute to the improvement of your technology-based processes – who wouldn’t want that?

Personally, whenever I hear Citizen Developer, I think of the French national anthem (“Aux armes, citoyens”) and the French Revolution. I prefer to use the more pedestrian term: “business user/developer” who uses low/no-code tools to improve their, their peers, and their customer’s lives. Don’t let my peccadillo stop you from using the term, just make sure it is more than an aspirational call to arms. Let’s start with the resistance to business users/developers and to low/no-code.

The hold outs: For reasons of job security, laziness, mistrust, or an over-developed sense of doing-it-right, they do not recognize or act on the opportunity. By and large, “Citizen developer” and low/no-code are great ideas for most organizations, but you may still encounter doubters. What’s even worse, is an entrenched IT mentality that is hard to reverse once it has taken root. However, if you can leverage the insight, hard work, and good will of your employees to make their life better and make the organization work smoother, why would you not bend over backwards to support them? This is a leadership mindset change, first and foremost.

In a past job, while not part of the IT department, I championed a cost control tool built by a colleague for our customers. It was something that customers could use by themselves, and we, the support organization could use it to run the same queries and glean insights about the customer’s usage and spend. We would then pass the queries and insights to customers to see and fix the problems for themselves. This was fantastic, and we got a lot of positive feedback from customers. We solved problems and provided insights where analytics and standard reports did not yet exist. However, after a few conversations, the IT team determined it would not scale and they would rebuild the whole thing themselves. They built essentially the same tool product and delivered it a year later. It was no longer available to customers and required involvement from the support org to provision each new customer instance. We had it built, piloted with a dozen customers, but it had to be scrapped and re-built. The co-worker who had built it left, and the organization lost an expert and a champion in short order. In Jeff Bezos language, this is Day 2 thinking, and “Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.” [2].

To promote IT to be open to low/no code, I first recommend starting with inspiration. Show where business users solved company’s problems well, and where it led to unmitigated success. The famous Toyota Way, for example, included Kaizen (continuous improvement), but it was only possible if the line workers, the car manufacturer’s equivalent of the business users, are respected, listened to, and encouraged. Deryl Sturdevant, CEO of Canadian Autoparts Toyota (CAPTIN) from 2006 to 2011, makes this point and identifies delegation, empowerment of leaders, mentoring, leading with influence, and attention to the minutest of details as concepts and practices leadership needs to live by. My favorite recommendation of his, is this: “… the goal is changed and the carrot is moved. It’s a deep part of the [Toyota Way] culture to create new challenges constantly and not to rest when you meet old ones.” [3]

Projects have a finite timeline, and our culture incentivizes achieving results. These and human nature create plenty of chances for plateaus of “complacency” to form after you’ve achieved something. Growth and improvement are continuous and smooth curves, and they require deliberate and constant push forward, or Day 1 thinking. If you still have IT departments that ask for lengthy requirements documents before they will undertake incremental change, you may have a problem.

If your IT organization has an elitist view of themselves, replace them. They are hindering your growth and the agility of your business. In one job, I was part of the “R&D team” (tongue in cheek intended) – in an organization of 12 people. Yes, you heard me right, not the engineering team, not the development team, but the “R&D team;” and it was said with relish by the leaders of said “R&D team.” The team undertook lengthy redefinition of the “data model and automatic generation of objects at runtime in a multi-tenant environment based on abstract data storage.” Blah, blah, blah. The business team did not understand or have time for lengthy technobabble. They had a product to improve and grow, and here we were rethinking some pretty modest data modeling needs of the organization. The CEO, a friend of mine, finally let them go and found a team in India to rebuild everything in 3 months.

The second recommendation: Find tools with multiple modes of development. It is already a foregone conclusion that you should introduce low/no-code tools for the appropriate jobs. I am upping the ante here and saying that you should allow tools for different information processing modes. Not all low/no-code tools are good for every user or every problem. Until such a time when we have “one ring to rule them all,” our tools will take the characteristics of the people and problems where they are used. People work in different ways, and different tasks require different interfaces. You have, for example, spreadsheet type of workloads, or workflow type of workloads. Or at least that’s how businesspeople think about them at first. Accountants will think and model their problems in spreadsheets. Some will model their problem as a workflow with decision steps, transitions, and sub-flows. Artists and designers think in terms of canvases.

When my younger daughter was about ten years old, I realized that there are spreadsheet and non-spreadsheet people. I asked her to copy and paste from several lists into a spreadsheet of about 500 rows, to create one consolidated list. I even offered to pay her for the 30 minutes it should have taken her. An hour later, she came back and said: “Dad, please don’t make me use this program ever again, I hate it.” She’s the same one who painted all the doors in our house with dragons, mermaids, and mythical creatures (just before we replaced them). She is not a spreadsheet person. More of a canvas girl.

One manager, years ago, had me create umpteen diagrams for a content management system we were operating. Data flows, system component diagrams, deployment diagrams, swim-lane diagrams, etc. She thought in diagrams and flow charts, in PowerPoint and Visio. Yet another manager asked me to change a procedure I had written, from a bulleted list to a matrix that “flows from left to right.” Matrix, being a euphemism for a spreadsheet. I realized that there are four (or possibly more) kinds of people in the world: Word people, Excel people, PowerPoint people, and Visio people (more on this in another article). There is no right or wrong way to take in data (information processing mode) but imagine a world where we did not have Word, PowerPoint, and Visio, and all had to use spreadsheets. It’s not just about the right tool for the right job, but the right tool for the right person. Information is tool agnostic, but as humans we are wired for different ways (modes) of ingesting, processing, and presenting it.

You should consider multiple low/no-code tools, in the short term, to give tools to those who think differently. The difference between someone choosing to improve a process with low/no-code or continuing to send files via email is how natural and ergonomic it is for someone to pick up the new tool. The friction the tool provides, including going against the grain of the user, can render it irrelevant, and cause the user to revert to the old ways. The promise of low/no-code is that everyone can make music without having to be Yo-Yo Ma (famous cellist). Today that is an overstatement, the low/no-code tools are barely out of the cradle. There may be a future where we do have a tool that morphs and adapts to the user’s information processing mode, but that day is not here today. Even Microsoft Office and Google Docs have not merged these information processing modes into one tool, instead they offer specific tools for each type of usage or user.

Today you have Alexa, Siri, and Google Assistant trying to make text, or spoken-word, work as a productivity tool. You have tools from Decisions, Pega, and even Monday providing a workflow interface for productivity. Smartsheets is committed to spreadsheets, and AirTable starts you off with a spreadsheet experience. Amazon Honeycode is attempting a canvas-based development paradigm. There are over a hundred low/no code platforms out there, but currently there is no tool to smoothly handle all these information processing modes. Furthermore, for the sake of simplicity most low/no code companies tend to excel at one or two modes, but all four is not practical in one tool today. Give some consideration to the types of people a specific tool will appeal to.

The final recommendation has to do with support. You will need to create centers of excellence (COE) to help with the adoption and successful use of low/no-code platforms, or you will have spent a pile of money for no noticeable long-term results; and possibly introduce security holes or data leaks. With low/no code you are asking non-programmer business users to think in terms of: code, deployment, source/version control, integrations, security, backup and recovery, and user experience. That range of skill is seldom available in one highly skilled developer let alone a business user trying to put on a developer hat. Most of these disciplines are needed to create a robust process for your organization. SaaS (Software as a Service) providers will try to remove some of the complexity by doing it themselves behind the scenes. In the end, when you scale past the tiniest of apps, with two or three users, you inevitably will have to address these concerns. And that’s where the COE can provide some guardrails and support.

Take for example versioning or source control. You’d think that everyone working from the same worksheet/application means that you just need one, i.e. the latest version, and you simply take snapshots for backup. But how do you improve your application and how do you transition your users, data, and sharing/security settings to the improved application? How do you make changes while the application is in use? Your business users/developer will not think about those nuances, nor should they have to. Until low/no-code matures, however, these questions will remain with us. Unsolved they will limit the usefulness, reach, and efficiency of your low/no-code efforts.

Those who are serious about unleashing the latent capability and creativity in their business user population will need to provide support. A multi-disciplinary team of experts can provide training, select the right low/no-code platforms, provide guardrails and support integrations with existing systems, and monitor usage and security. A minimalist team should include several developers as well as security and user experience experts. Do not forget about user experience – there is no point making an application nobody can use. (I’ve seen PhD’s create amazing products with terrible user interfaces.) Later you can add business analysts, project managers, analytics and data science experts, as well as architects and strategists.

Start small, don’t over think it! But provide the variety and support for your business users/developers to be successful with low/no-code. If you need more convincing low/no-code is here to stay you’ve read the wrong article, but if you see the potential, I hope you have gleaned a few nuggets. First off, low/no-code is a cultural shift as much as it is a technological shift. Second, you must allow some experimentation and the best set of tools will surface within your organization. Finally, you need to provide support for this initiative otherwise it will die the slow death of a thousand cuts.

?

P.S. If you’ve read this far you deserve an explanation for the headline picture for this article. What do Canadians and Olympic athletes have to do with how we think about citizen developers? Simple: We tend to think of citizen developers as nice polite and well behaved Canadians who (love you Canada but you have this good reputation). We also tend to think of citizen developers as highly skilled Olympians who will champion our products and the low-code way of life. In fact, Citizen developers are people like you and me. We yell at our spreadsheet when we’ve accidentally deleted a column, or we cannot use the pivot table function. We can barely use spreadsheets, and balk at IF() or TRIM() functions’ complex syntax. And most of all we are not going to champion your product unless we can win some gold medals after we are trained on it… I know, it’s a bit of a stretch but that’s how my mind works, this is the best metaphor I could find, and Canadians won’t?mind if I pick on them (in a loving?way) :p

?

[1] Gartner definition of Citizen Developer: https://www.gartner.com/en/information-technology/glossary/citizen-developer ?

[2] Day 2 is death, from Jeff Bezos letter to shareholders 2016. As archived at SEC:?https://www.sec.gov/Archives/edgar/data/1018724/000119312517120198/d373368dex991.htm

[3] Learning from the Toyota way: https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/still-learning-from-toyota

[4] Thank you to The Globe and Mail for letting me steal this picture of the Canadian team at the 2020 Tokyo Olympic Games?https://www.theglobeandmail.com/sports/olympics/gallery-photos-of-tokyo-olympics-opening-ceremony/