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.

Considerations

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.

Considerations

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.

Considerations

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

The no-code stakeholder is a business function role — often a senior functional leader — who acts as an executive sponsor on behalf of the business unit. Typically, they are chartered with articulating the no-code app business vision and requirements and working with the no-code project team to review and approve business use cases, prototypes, MVPs, changes, etc.

The no-code stakeholder typically will have a good understanding of the business process and have sufficient authority to make decisions related to functionality. Finally, while the stakeholder does not need to be deeply technical, they should understand the technology and its ability to impact the business.

Responsible for:

Working with the no-code stakeholder on defining requirements and design and ensuring alignment of the options and business needs.
Providing subject matter and process domain expertise that shapes design activities.
Participating directly within the no-code development team in the app building process; may take on more challenging components.
Coordinating with IT and Operations to plan, schedule, and conduct Governance reviews.
Coordinating with Operations once the app is approved and ready to deploy to production.
In fusion team delivery scenarios, coordinating with IT software developers to build out custom software components of the no-code application.
In fusion team delivery scenarios, coordinating with IT to build or validate integrations to other systems and APIs.

Delivery models:

Applies to all delivery models.
In the CoE or fusion team scenarios, the multidisciplinary teams should still have a dotted-line reporting to the no-code stakeholder who is ultimately responsible for the project direction and success.

Role No-code business architect

The no-code business architect is a business role often filled by a more senior expert. The architect is responsible for setting the most suitable design approach. The architect decides on the right option to deliver the project and the combination of reusable components that will be needed. They also make sure the solution aligns with the business value. They are usually directly involved in the no-code project and own more challenging design or development tasks.

Responsible for:

Working with the no-code stakeholder on defining requirements and design and ensuring alignment of the options and business needs.
Providing subject matter and process domain expertise that shapes design activities.
Participating directly within the no-code development team in the app building process; may take on more challenging components.
Coordinating with IT and Operations to plan, schedule, and conduct Governance reviews.
Coordinating with Operations once the app is approved and ready to deploy to production.
In fusion team delivery scenarios, coordinating with IT software developers to build out custom software components of the no-code application.
In fusion team delivery scenarios, coordinating with IT to build or validate integrations to other systems and APIs.

Delivery models:

Applies for the CoE and fusion team models. Might be engaged in the DIY model.
The no-code business architect typically sits within the business function itself. However, the CoE may also have a number of architects who can provide subject matter expertise in more specialized areas. They may also help the CoE drive overall standards and best practices, such as fostering, harvesting, sharing, and reusing of components across teams.

Role No-code creator

The no-code creator sits within the business unit and has a strong understanding of the business domain. Importantly, they also possess strong user empathy. They sit within the no-code project team and have been trained in using the no-code tools. They are responsible for the system configuration and quality activities using no-code capabilities.

Responsible for:

Working with the no-code business architect and no-code stakeholder to contribute to requirements and designs activities.
Participating directly within the no-code development team to build the app; responsible for owning specific work items (micro use cases) in the backlog and implementing the use of the no-code tools.
Defining and executing quality assurance (QA) activities to validate end-to-end user scenarios.
Producing user documentation, training, or enablement related to the no-code application.
Working with the no-code business architect to develop feedback mechanisms and collect user and system feedback.

Delivery models:

Applies to all delivery models.
There will be one or more no-code creators on the team based on the size and scope of the no-code application. For larger applications, there may even be multiple teams of no-code creators who are working on the application in parallel.

Role No-code CoE leader

The CoE leader is a cross-functional leadership role that helps drive efficient prioritization and management of capacity and people resources leveraged within a shared CoE.

Responsible for:

Driving the adoption, sharing, and reuse of best practices for no-code across the organization.
Driving the adoption, sharing, and reuse of components — often from some type of shared internal repository or marketplace — across project teams.
Supporting the no-code stakeholder in procuring and assigning resources to the no-code project team (especially around specialized skill sets).
Responsible for recruiting, training, certifying, and enabling no-code creators.
Responsible for managing the process, applying correct governance policies, and promoting the no-code culture and strategy.
Helping to manage coordination and conflict resolution across teams.
Can help coordinate the planning and scheduling of governance reviews.

Delivery models:

Applies to all delivery models.

Role Software developers/QA

Software developers and QA resources participate (if needed) as part of fusion teams to help build and test more complex technical components (e.g., new architecture services and custom integrations). They have been trained in custom software development tools, skills, and methodologies.

Responsible for:

Directly supporting the no-code development team to build the app; works with the no-code business architect to own more technically complex components of the overall solution.
Defining and executing quality assurance activities on their components.

Delivery models:

Applies to no-code fusion teams.
These are typically IT roles, either sitting in corporate IT or perhaps business unit IT. They are typically not directly part of the no-code project team, but they should still have a dotted-line reporting to the no-code stakeholder who is ultimately responsible for the project direction and success.

Role Approvers (IT/Operations)

Approvers participate as needed at certain stages of the lifecycle and they are responsible for advising on team compliance, governance, and security criteria. They also provide final governance checks and approval for Go-Live. They have been trained in governance and provide subject matter expertise to support the no-code project team.

Responsible for:

Directly supporting the no-code development team in planning and executing governance reviews (typically in coordination with the business architect).
Directly supporting the no-code app release deployment with the final release activities and post-release monitoring or support.

Delivery models:

Applies to the CoE and fusion team models.
These are typically IT or Operations roles, usually sitting in a shared corporate capacity — often representing Legal, Compliance, IT, Security, human resources (HR), and other administrative functions. They tend not to be directly part of the no-code project team, but approvers should still have a dotted-line reporting to the no-code stakeholder who is ultimately responsible for the project direction and success.

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.

03. Principles of No-code Development

05. Application Matrix