Around the world, a tech talent shortage poses a significant challenge for business app development – more specifically, for internal products and operations apps. 

Today, over 40% of businesses report struggling with insufficient talent for app development. As the number of qualified devs fails to meet booming demand, internal transformation projects are delayed, hindered, or scrapped outright. Logically, many companies assign the bulk of their engineering resources to customer-facing apps and products.

In parallel, and partially in response to this trend, teams are onboarding no-code/low-code platforms at unprecedented levels. These changes are impacting organizational dynamics in more ways than one.

The Rise of No-Code and the Citizen Developer

‍No-code/low-code platforms relieve the internal app bottleneck by enabling non-technical people to build internal apps all by themselves. 

Using no-code tools, business teams and so-called “Citizen Developers” (non-technical, no-code solution builders) are creating and launching their own business apps, independent of engineering teams, roadmaps, and development cycles. 

Today, nearly 60% of custom apps are built by people working outside of the engineering department.  And by 2025, it’s forecasted that 70% of new apps developed by companies will use no-code or low-code tools – compared with just 25% in 2020. 

The “democratization of software” (as pundits of no-code/low-code have named it) means that business app creation is now in the hands of individuals all over the org chart – from individual contributors to the C-Suite. 

The question is, should it be?

Why Executive Citizen Developers are a Bad Idea

For some proponents of no-code/low-code, the C-Suite is a high-potential group for citizen developers to thrive. 

According to one executive quoted in Forbes, “Low-code development creates an exciting dynamic by exposing non tech professionals to IT practices to address employee pain points quickly and creatively.” The article goes on to relate an instance when the executive then “challenged a [department] team member with no developer experience” to build an internal portal for learning and development resources.

Following this line of thinking, for C-suite leaders, there are both hands-on and directive roles for citizen development, whereby executives may directly influence the choice for a no-code/low-code solution, may actively take that decision, or may even be involved in the creation of solution themselves.

Although it is valid that C-suite support for citizen development initiatives may be generally beneficial, the above argument ignores several key considerations, which – taken in total – amount to much more harm than good. Specifically, by bypassing the company’s solution development processes, by demonstrating a lack of trust in process owners, and by neglecting executive duties, C-suite leaders are setting their teams up for seriously unfavorable outcomes.

Citizen Development is not a Software Development Model 

There is incredible value in the ability to build apps without coding; however, citizen development is not itself a Software Development Lifecycle Model (SDLC). When executives push citizen development for internal apps using no-code/low-code tools, there is no inherent “exposure to IT practices” – meaning, no actual software development cycle will be pursued.   

Consider the following fictitious analogy. 

Imagine a superintendent has just shown up to work at a massive construction project site they oversee. On their way into work, they heard about a revolutionary, new bulldozer that allows drivers to operate it without any prior experience in operating heavy machinery. 

Now, you would reasonably assume that in this case, the superintendent would not simply buy the bulldozer, jump into the cockpit, and begin to bulldoze away on infrastructure all by themselves. Nor would they likely buy the bulldozer, then “challenge” a site worker to figure it out.

Because a construction site has blueprints and specifications, testing processes, environmental considerations, and other operational protocols that are managed by teams of site managers and other trained specialists. For these folks, the brand new “no-training” bulldozer may indeed be an operational asset, but not unless their processes, blueprints, and all the other specialized considerations warrant it. 

Now let’s turn back to the no-code/low-code executive. 

While executives may have the best intentions of empowering their team or investing in cutting-edge tech, they’re in the wrong position to make the decision for going no-code – never mind implementing it themselves. Generally speaking, the executive team is much too far away to understand the nuance and “on the ground” requirements of specific business processes, users, and stakeholders. 

Furthermore, because citizen development doesn’t come with an instruction manual (AKA SDLC) and the business problem at hand may not be fully understood, there’s an increased risk that the executive-driven no-code/low-code solution will not be scoped properly, and won’t deliver the desired results.

Direct Involvement: How Executives Erode Trust with their Teams

Overreach is one of the great blunders of corporate management, and when it comes to citizen development the case is no different. 

Executives sometimes demonstrate a lack of self-awareness and fail to realize how their actions communicate mistrust in their teams. They’re likely to assume that because they trust in their managers and teams, that those employees actually feel trusted, and reciprocate with their trust in management.

Even when it comes to well-intentioned actions – such as providing employees with no-code tools, or joining in sporadically on team meetings – it may still appear to team members that they’re not trusted, or worse, that their skills and opinions aren’t valued or utilized. 

“I guess the built-in contradiction is my biggest problem,” says Tal Levy, Development Lead at a mid-market Insurtech company. “If you ‘empower’ employees to solve these things, stay out of their business.“

Whether or not an executive manager brings no-code/low-code to the table, the fact remains that teams are delegated projects based on their core competencies and proximity to the problem at hand. Even single contributors (Chiefs of Staff, Special Projects Managers, etc.) are assigned projects based on their individual skill-sets, their knowledge of the business processes at hand, and their abilities to research and scope solutions. It is generally neither in the skillset, nor the interest of the executive manager to pursue this kind of “expert due diligence” when it comes to solving complex problems.

“As an executive you can give access to [no-code/low-code] tools, you can encourage their use – you can even require it if you want,” says Levy. “But getting directly involved in solution development without knowing the real pain points would make for useless solutions.”

Citizen Development is not a Good Use of Executives’ Time

Let’s not forget that a well-functioning C-Suite should be too occupied with executive responsibilities to be building or driving no-code/low-code initiatives themselves. 

Let’s use the COO for example. 

The broad outline of a tech COO’s responsibilities might look something like this: 

• Overseeing operations, managing resources, and forecasting operational capacity
• Developing and implementing operational policies and procedures
• Maintaining and improving operational efficiency
• Hiring and managing cross-functional teams and operational departments
• Identifying operational bottlenecks and addressing them proactively 
• Building the company operational strategy and implementing it
• Acting as the bridge between the executive team and the rest of the organization
  

Indeed, many of the focus points presented here could be aligned with citizen development activities. After all, the COO is responsible for all things operations. They’re the de facto “process hackers” of the C-Suite. Why wouldn’t they just drive it forward themselves?

The answer is simple: they have better things to do. 

In order for a no-code / low-code platform to be a viable solution to a business problem, the problem must first be identified and understood at a high-level. This works well coming from the COO. For the COO, their head stays above the weeds of day-to-day operations so they can spot operational patterns, shortcomings, and opportunities. 

But that’s not easy work. It requires skillful reporting and management, a firm grasp on the company’s resources, a pulse on current workload capacity across the organization, and most importantly, a sense of how operational problems impact other teams within the organization, customers, suppliers, and partners.

Put differently, the COO needs to own and understand problems – not solutions. That’s where the teams and team leads come in. As the “problem owner”, the COO remains in the best position to determine what’s working and what’s not. 

There are nuances with every role in the C-Suite, and company size matters. The degree of “hands-on” in the executive team varies massively from a 20-person startup to a 2000-person corporate. Either way, executive management is highly complex work, and the responsibilities of forecasting, budget ownership, strategy, hiring, team management, reporting to the board, and all that other stuff amounts to a very full plate. Citizen development really shouldn’t have any place on it.

What Can Executives Do to Support Citizen Development?

No-code/low-code tools can still be massively beneficial for organizations looking to operate more efficiently and build solutions faster. The C-Suite can play a number of important roles in that pursuit, without hand-holding or overly-directive involvement. 

Enable team leads (with limited strings attached)

Mutual trust building starts on day one. Executives should hire team leads who reflect back the values, competencies, and experiences they wish to see. Of course, there’s always a degree of calculated risk when it comes to hiring and task delegation, but if executives aren’t comfortable with that, then they may want to consider another profession.

Enablement of team leads is really about providing leads with trust, accountability, budget, and – most importantly – a clear understanding of the goal or problem needing to be solved. From there, it’s the responsibility of team leads and their teams to worry about the “how”. So long as the problem is solved – and executives do need to own that – the onus of citizen development should be on the teams, provided that is the decided course of action.

Support a No-Code Culture

No-code tools can solve simple problems and automate a lot of everyday grunt work. Executives can help build a no-code culture by supporting automation initiatives through budget and additional training opportunities. Executives can also spotlight examples and give kudos to team members and teams that have used no-code tools to automate processes and improve results. 

Supporting a no-code culture also means knowing when to say “go for it”, and knowing when to use caution, and refer to specialized teams and in-house engineering for guidance.

Celebrate Successes / Be Transparent About Failures

If a no-code solution is part of a broader initiative to transform a complex business process, and that transformation is a success, be sure to celebrate it. Operational teams don’t often get the credit of commercial teams when it comes to delivering big projects or bringing in results. Be sure to give that credit where it’s due, and make teams feel collective ownership for no-code/low-code successes.

Likewise, executives need to remember that failure in business is equally important. If a no-code/low-code solution doesn’t succeed in solving a problem, doesn’t live up to the initial hype, or isn’t chosen in the first place, be transparent about it. It’s critical for teams to be on the same page and have the full context, especially when it comes to understanding why something didn’t work. It’s also essential to building and maintaining trust. 

Conclusion

Citizen development can dramatically improve operational efficiency and effectiveness. But when it comes to executives taking the role of solution developer themselves, the risk does not warrant the reward. 

Executives are not situated in the right operational proximity to drive solutions themselves, nor do they have a full grasp of the solution development process or the bandwidth to properly follow it. By overreaching into hands-on development mode, they risk burning trust with their team leads and teams, and – furthermore – they shirk their core management responsibilities which are so essential for their teams to succeed in the first place.

Executives can, however, be evangelists and sponsors of citizen development, and there are many opportunities for them to drive the organization forward using no-code/low-code tools. Their hands, however, should stay off the steering wheel.