No-code Roles and Responsibilities

Great things in business are never done by one person. They’re done by a team of people.
Steve Jobs

Building software — even building software using a no-code platform — typically requires a diverse set of individuals and skills, all working together to achieve the goal. A single person could perform the smallest no-code projects but, for most applications, it requires assembling a team. Some of these team contributors may be full-time, but a lot may be part-time as people in the business function are often wearing multiple hats. So, it’s important to be clear and focused about what roles you need and what their responsibilities will be. This allows you to set clear expectations and secure any needed resources.

There is also a range of skill requirements based on varying levels of application complexity. You might be building a simple app for capturing suggestions or a mission-critical app that the business function depends on for automating its most important processes. Most likely, it will lie somewhere in between. As you look at the different types of apps, you’ll face choices for how to organize your team to support different levels of complexity.

We’ll explore both topics in this chapter. First, we’ll walk through the three primary approaches for organizing no-code teams and discuss what they look like from an organizational perspective. Next, we’ll outline the key roles that are part of these teams on a no-code development project, and we’ll explore how these “Delivery Models” and roles tie together to support effective and multidisciplinary delivery.

No-code Delivery Models

Let’s start by discussing some of the common delivery models for organizing your teams. A delivery model is simply a suggested configuration for a no-code team structure designed to support different levels of complexity and scale when building no-code applications. We will introduce three distinct delivery models in this section. Note, the process of actually picking which delivery model is right for your application should be guided by a decision framework called the “Application Matrix,” which will be outlined in the following chapter. For now, we will simply define the models.

DIY delivery

The simplest delivery model is what we’ll refer to as the “Do-It-Yourself" approach, where all the primary roles of the no-code project are contained within a team sitting inside a single business unit. This team typically has a single overall project sponsor overseeing them. This makes the business function highly autonomous and in charge of its own destiny as they do not depend on groups in IT or other organizations to form and execute a no-code project. There may be just a single no-code team. There may also be multiple teams in organizations that have a high level of no-code maturity and are building no-code apps for a large number of business units. The size of the team is less important than where the participants come from. In this model, all the roles should come from the same functional business unit that sponsors the app.


  • This is the simplest model for organization and execution, leading to efficiency and streamlined operations.

  • Team roles may be easier to resource and operationalize by the business function because of reduced dependencies.

  • Offers a clear definition of accountability and priorities within a single organization unit.

  • May be constrained by the availability of skills and people in that group.

  • Not having access to more technical development skills may lead to roadblocks.

  • It will be challenging to embed a new no-code application into a legacy ecosystem without proper technical skills.

Center of Excellence (CoE)

The next delivery model is the “Center of Excellence,” or CoE. The CoE is typically owned and led by a single overall cross-functional CoE leader. It has skilled knowledge workers whose mission is to maximize efficiency through consistent definition and adoption of best practices for no-code development across the organization. This approach typically does not get formed immediately but emerges after the organization has started building some no-code expertise from multiple projects. It then becomes attractive to standardize and centralize some no-code expertise and skills to leverage across teams. When this happens, it’s often part of an overall digital transformation initiative. As the CoE is formed, it may or may not have direct full-time staff. Sometimes, the CoE leader can have direct employees working under their supervision or they can operate in a matrix environment working with no-code creators from other business units.


  • Makes the most efficient use of scarce resources across the organization by providing team members on a centralized and shared basis.

  • Accelerates learning and adoption of best no-code practices across projects.

  • Fosters a higher degree of no-code components reuse across teams within the organization.

  • Offers higher complexity of governance because there will be a matrix of shared accountability across both the business unit and the CoE.

  • Requires additional budgeting by the organization to fund the centralized team.

Fusion team delivery

The last delivery model we’ll introduce the “fusion team.” This delivery model represents a multidisciplinary team with members coming from the business function and IT to collaborate. Typically, this model is used when you have greater technical requirements and complexity that require software developers to build some components of the no-code application. The software developers may still sit somewhere within the business function — perhaps a business function unit within the IT group — or they may be part of a centralized corporate IT function. They may also be tapped to provide expertise in specific technical areas, such as security or DevOps. Regardless of where they sit within the organization, there is shared accountability for the no-code app being built.

The fusion team model usually results in a matrix organizational model. Most of the key roles will still be driven by the business unit, but some specialized no-code roles may sit within an IT group. However, typically software developers who may be supporting the project from IT will have a dotted-line reporting relationship to the overall business unit.

Note: the concept of a fusion team is based on research11. What Are Fusion Teams, Gartner from the analyst firm Gartner. You can reference more of their research on the topic.


  • Provides access to more technical development skills required by certain projects.

  • Blends technology skills, analytical skills, and business domain expertise.

  • Offers shared accountability for the no-code solutions being built.

  • Offers higher complexity of governance because there will be a matrix of shared accountability across both the business unit and fusion team.

  • Requires additional budgeting by the organization to fund more technical talent from IT.

  • Slower and more resource dependent; requires more time to align the IT and business functions.

No-code business architect

Regardless of which delivery model is selected, there are a set of defined roles that are typically present in any no-code project. We briefly define each below, outline their major responsibilities, and discuss how they fit into one or more of the delivery models.

Role No-code stakeholder

Role No-code business architect

Role No-code creator

Role No-code CoE leader

Role Software developers/QA

Role Approvers (IT/Operations)

Final Takeaways

Building your no-code team is critical, so start by identifying the appropriate delivery model that fits the best. Next, understand the responsibilities associated with each role so that you can recruit team members best suited for carrying your project forward. While you may be able to use no-code yourself, you’re not going to realize the broader outcomes if you do it alone. Put care into your team selection so your no-code project is set up for success.

Now that we’ve discussed the various roles and delivery options, which one should you choose? Let’s look at a critical decision framework called the Application Matrix that will aid with picking the appropriate delivery model and help scale many key activities within the No-code Lifecycle.