Sustaining Citizen Development beyond the Hype

Citizen Development in Real Life

Sharjeel (07:05):

Now, that's pretty comprehensive Matt. I guess that's both ends of the education process. Not only do you improve the process but you approach it wisely, and that's great.

So, the term Citizen Development might be new to many folks, Matt. So, what is it and how to do it, and how did you get involved with it. 

Matt (07:33):

That's a good question. Yeah, the term Citizen Developer or Citizen Development, I've actually had some people tell me that it sounds like a weird nefarious plan for the government to control their citizens. That's not the case, of course, but I get it. 

It is kind of a weird term. So, let me do my best at trying to describe what it is. I'll kind of describe it real high level, but then I think the best way for me to illustrate it is to tell you about my Citizen Development journey and how I got involved in it.

So at a high level, Citizen Development is about safely empowering people who are not formally trained coders to build their own software applications through the drag and drop capabilities of a low code no code platform. The best way I can describe is as follows.

Matt (08:27):

Low Code No code is like a box of Legos. So, instead of having to build something from scratch with all the raw materials, you just grab an existing Lego block and you start piecing it together with other blocks of different sizes and different purposes to create something quite magnificent.

A child can create a house, a car they can create the likenesses of people and characters all with the same box of Legos. And, so that's what a low code no code platform is like for software development. 

You as a non-coder do not have to build the app from scratch by coding. You can grab existing widgets and start piecing them together into applications such as workflow approvals, tracking, reporting, all of these different types of applications. But like I said earlier, I think the best way for me to illustrate Citizen Development is to just tell you about my Citizen Development journey.

Matt (09:32):

Why and how did I become a Citizen Developer? I'll tell you this story in three parts because they all build on each other. 

First, I'll tell you about my problem solving nature, and then I'll tell you about a failed software project that I was responsible for, and it ended up being the catalyst for me to look into Citizen Development. 

And then the last thing I'll tell you about is actually my first experience with low code no code and becoming a Citizen Developer. 

Let’s start with my problem solving nature. I want to start there because that's who Citizen Developers are, they are problem solvers. If you are one who is okay with the way things are today, you like coming in, doing your job, check the box and go home, then I would probably say Citizen Development is not for you.

Matt (10:25):

Citizen Developers are inquisitive. They want to look at something that exists and make it better, and they want do so with technology. So, that's kind of who I am by training and at heart. I'm a problem solver. My education is in engineering, and my first job was as a quality engineer. 

As a quality engineer, I solved problems reactively and proactively. And, reactive meant fixing the quality issue after it already occurred. While proactive meant preventing the quality issue from occurring in the first place, I much preferred working on proactive prevention and would do so by controlling the processes that would ultimately produce the result. 

Now, my favorite tool for controlling the result was something called Poka-yoke; it's a Japanese term that means mistake proofing. For example, you put a physical attribute in an assembly fixture, and it makes it impossible to install a right side part where a left side part belongs.

Matt (11:39):

And, it was satisfying because it was consistent and reliable, and I could count on it to produce the same result every time. 

Now, what does that have to do with Citizen Development? I think I'm illustrating this because this level of control that I came to appreciate in manufacturing became the baseline for what I would expect later from my software projects. 

And so that brings me to the second part of my Citizen Development journey. And that's my first software project, which frankly was a failed software project. This was the catalyst that pushed me towards Citizen Development. 

So, after a few years of being a quality engineer, I was asked to lead a large back office project that would require standardization of 10 business processes and the development of software to control them. And as I said, this was my first software project, and frankly, it didn't go well at all.

Matt (12:42):

The team and we succeeded in improving and standardizing the 10 processes on paper. 

But personally, I failed at getting the software developed. I was thorough in documenting the system requirements as I leveraged the same error proofing and process control mentality that I learned as a quality engineer. 

But, I was astonished when I got the quote back for what it would take to build this software that I spec’d through my requirements. 

The cost was in the millions of dollars. The timeline for developing it was on the order of several years. And then the flexibility was virtually non-existent. 

Basically, I had one shot to get it right because the project team and the coders, they will have moved on. They have other projects to focus on, and frankly, this lack of flexibility is just not realistic. How could we possibly get something of this magnitude right the first time?

Matt (13:45):

What about continuous improvement? What about changes to the business? 

We will have to continuously update this. So, I need flexibility. So the bottom line on this software project is that I could not justify the software without slashing the requirements to the point that we might as well stick with what we had, which was an old green screen system, spreadsheets, email, and shared drives, which I'm sure many here can relate to. 

I failed to deliver on this project. I'm happy that a vision was trapped in my head for a better way to develop software. I thought there had to be something less expensive, faster, and more flexible, but still robust. 

And I'll give you a little bit of an analogy here. This is how I thought about it. I thought about it in an analogous way to how Atari brought the home console in cartridges to the video game industry.

Matt (14:52):

So, before Atari did that if you wanted to play a video game, you had to go to a bowling alley and play this one standup machine like Centipede or some of those other ones like Asteroids or Space Invaders. 

It played one game. It costs several thousand dollars, and it was not accessible to the masses. And then Atari came out with this home console unit that I think costs like $99. And, then they just had cartridges for each video game, right? 

So you could buy a different video game, plug it in and play, and it only costs like, I don't know, I can't remember the prices, let's call it $30 for each cartridge. 

And so I thought, why can't we do that with business applications? Why can't we have a platform that already exists, like the home console for Atari?

Matt (15:45):

And then all you're doing is plugging and playing your processes and adding on top of that platform. So, I shared that vision with some of my colleagues. And, actually several years after my failed project, one of my colleagues called me to say that they saw a demo of an app building platform that looked like the vision I described. 

And, I checked it out and confirmed that indeed it's what I was looking for. But the irony here is I was leaving for another company in a week after, after I checked it out and figured that would be the last that I'd see of that app development platform. 

So, I was extremely disappointed. And this brings me to the, the final, in third phase of my story, my Citizen Development journey story. This is where I switched companies. And when I got there, it turns out that seeing that app development platform was not a disappointment because this new company that I worked at it had similar process and system problems as my prior employer.

Matt (16:52):

So, it turns out that these process problems and system problems are kind of ubiquitous. They kind of exist at every company. And, this app building platform, which would later be categorized as low code, no code was back in play. And to make a long story short, I started learning the platform and building my own apps. I'm not a coder; I'm a process person. 

Through low code, no code, I could build some very effective apps and control my processes, like I had envisioned before. And, so a few examples, the very first app I made was just an app to chase down status updates. It took me, let's see, it took me about eight hours to build, but it saved me 200 hours of chasing down status updates a year. So that was a 25 x savings.

Matt (17:46):

The second app I build was for price change approvals. If you wanted to change the price of a part you had to go get approvals, up to 15 approvals depending on the price change percentage. And through this app, we were able to get the number of approvals down to five. And we never lost a piece of paper because it was electronic, where before it was paper-based, people would get to approval number 14 and then lose the paper and have to start all over.

And, the reality is they just they didn't follow the process consistently. This app forced it to be followed the same way every single time. And then the third app that I'll mention real quick is one for procurement requests where buyers would request their purchasing assistance to do some kind of work.

Matt (18:37):

They would do it through email, and everything got lost in email. Not everything, but many things. And so there was chaos. I made an app to control those requests in one place. And we basically created order out of chaos. And so I would describe low code, no code as my superpower. 

I enjoyed solving problems with it so much so that others took notice, and they asked me to teach them to build apps on this low code, no code platform to solve their business problems. 

And we formed a team of five different people leading and building apps for their area of business. And I was pretty proud of it. But the thing that I'd say I wasn't proud of is that we couldn't scale beyond our immediate circle of influence.

Matt (19:30):

So it was just the people around me who knew me that were willing to take the chance and learn low code, no code, but we, outside of that circle of influence, we did not expand. 

I felt like the true value of low code, no code and Citizen Development was not being realized by keeping it to this pocket of five people. Later I started a consulting business. I started a consulting business where I was helping other companies solve their problems through low code, no code and process improvement. 

And I tried to teach Citizen Development at scale, but I didn't move beyond these individual projects. I didn't get any sustainable Citizen Development culture to happen. Let me, let me just stop there. Those are my three phases of my Citizen Development journey.

Sharjeel (20:29):

That's awesome. It reminds me, like the particular examples that you have shared, like status update app or price change, approvals, procurement requests, these are all things that IT won't entertain in a typical organization. And the resource would be frustrated that they're not listening, listening to him or her. And I guess the, the route that you took, that's the future, of making your own professional life easier through apps.

Matt Hubbard (21:06):

Yeah, sure Sharjeel, I would agree that it was effective and it is the future. But, I think one of the reasons why it didn't scale for me is because I didn't approach this in partnership with IT and executive leaders. I just kind of did it off in a corner. And so I think that kind of gets to this conundrum of how do we make it scale?