CTO Fraction

Menu

The 8 Essential Roles of a Software Delivery Team

Successful product and engineering teams share a common ingredient: well-defined roles owned and exercised by designated team members.

Can you imagine a custom home builder on whose team no one owns the role of an electrician, plumber, roofer, framer, or…? What would happen if no one owns one of those critical roles during a home construction project?

Building software is similar. However, sometimes certain roles are assumed when in reality no one owns them. This oversight can lead to inefficiencies and long-term consequences. I believe that 8 essential roles need ownership on a delivery team for successful software delivery.

The Definition of a “Delivery Team”

For this article, a “delivery team” is defined as an autonomous unit capable of taking a product concept from ideation to launch, whether it’s a minimal viable product (MVP), a feature enhancement, or a defect fix.

The size of the work is irrelevant in this case. What matters is that a delivery team is a self-sustained team that possesses the requisite skills to navigate the full software development life cycle (SDLC).

Why Roles Are Important

For a Software Development Life Cycle (SDLC) to be successful, certain functions have to be executed as part of the process. Those functions are completed by the people on the team.

When any of those functions are skipped the result is less than ideal, and in some cases could have long-term negative consequences.

Therefore, every delivery team must first have the capabilities necessary to fill the essential roles. Second, the team has to have an established structure, which ensures that each role is being owned by someone on the team.

It’s worth noting that a single person can fill more than one role. This is typical on smaller teams and/or in startup environments. On the other hand, in larger organizations it is common to have every person fill just a single role on the team. More on this in the last section “Team Composition”.

The 8 Essential Roles

With some small variations, I believe these are the essential roles necessary on a delivery team.

Manager/Team Lead
Without the Manager/Team Lead it is harder for a team to operate well as a unit. Yes, some frameworks support the idea of “self-organizing” teams, where the manager’s role is simply focused on their individual needs, such as career growth and HR-related responsibilities. While I believe that such teams can be successful, in my experience the maturity level of the entire team, and each individual, has to be very high for the team to be successful.

Also, in my observation, it is healthier to have a designated person who, if not all the time, periodically rises above the weeds and observes how the team is operating as a unit and as a whole. The manager/team lead is necessary to oversee the effort of the entire group and ensure that nothing falls through the cracks. This person ensures that the team communicates well, has good processes, has clear goals, and ultimately delivers what they committed to.

Product Owner
Without the Product Owner, the engineering team has no clear direction as to WHAT needs to be built and WHY. The Product Owner prioritizes the work for the engineers. This person ensures that what is being worked on is the most important thing to be worked on. The Product Owner also provides all the requirements for what needs to be built. He/she is the first-level customer of the engineers.

UI/UX Designer
UI/UX Designers focus on creating intuitive and aesthetically pleasing user interfaces and experiences. Their role is crucial for ensuring that digital products are user-friendly, engaging, and aligned with the needs and preferences of the target audience.

Architect
Architects design the overall structure and framework of a software system. Their role is essential for ensuring that the system is scalable, maintainable, and meets the functional and non-functional requirements of the project. Architects are especially important on large-scale projects and/or when blending legacy and new systems.

Technical Lead
Technical Leads are experienced developers who provide technical guidance, mentorship, and leadership to a development team. Their role is vital for moving the technical direction of the project, resolving technical challenges, and ensuring the delivery of high-quality software.

Tester
Testers are responsible for evaluating the quality and functionality of software products to identify defects and ensure that they meet the specified requirements and standards. Their role is essential for detecting and fixing bugs early in the development process, thereby enhancing the reliability and performance of the software.

Software Developer
Software Developers are responsible for writing, testing, and maintaining code to develop software applications or systems. Their role is fundamental for translating requirements into functional software solutions and continuously improving and enhancing the product.

Release Manager
Release Managers oversee the planning, coordination, and execution of software releases to ensure the timely and successful delivery of new features and updates to end-users. Their role is critical for managing release schedules, minimizing risks, and maintaining the stability and integrity of the production environment.

NOTE: Some deployment pipelines are more complex than others. Also, in rare cases (where release flags are used), it is possible that production deployments are completely automatic and the role of the Release Manager is fully automated.

The Pitfall of Skipping Roles

The natural inclination is to look at the list of these 8 roles and automatically assume we need at least 8 people on a team. This faulty assumption happens when we mix the notion of a “role” or “responsibility”, with “title” or “person”. However, one to one ratio is rarely necessary.

The danger comes from the tendency to skip roles, especially on smaller teams. What happens is, the team does not define and designate each role to a person. The result is – that certain roles are not assigned and ultimately no one is responsible for them.

When that happens various problems start to accumulate over time, because an important function of the team is unaccounted for. While the consequences are less noticeable initially, they multiply as time progresses and the team grows.

Here is an example:
A small team is working hard on delivering feature after feature. No one owns the role of being the Architect on the team. Before a new feature begins, no one pauses to design how this new feature will fit with the rest of the system. No one evaluates if some of the functionality is already written in another part of the product and can be reused for this new feature. The engineers who own the new feature design it in a vacuum without any regard for the larger picture. In the process, they end up creating some duplicate functionality code. The feature is released successfully and everyone is happy. No one notices the extra code and extra complexity, because the customers are happy and they love the new functionality. However, this process repeats over time, and before long we have a complex and difficult to change system. Now it takes twice as long to build new features or make enhancements, and every time changes are deployed to production new defects are introduced at a rate faster than before.

Is the complexity of scaling your software company daunting?

You’re not alone. Many tech startups and small businesses face similar challenges, often lacking the dedicated roles necessary for seamless software delivery. This is where I can step in as your Fractional CTO. With extensive experience in guiding companies through the intricacies of product launch and organizational scaling, my services are designed to fill the gaps in your team, ensuring your projects cross the finish line successfully.

Need guidance? Discover the advantages of incorporating a Fractional CTO into your strategy.

Let's Chat

Team Composition

The goal of this section is not to propose the ideal team composition structures. This is a topic for another article.

The idea here is to demonstrate how different compositions can account for each of the roles described above. It is to demonstrate that these roles can be assigned in a very flexible way that fits your particular team model.

The examples below are just some options and not an exhaustive list.

2 Person Team

  • Product Team Member – Product Owner,
  • UI/UX Designer, Manager/Team Lead
  • Engineering Team Member – Architect,
  • Tech Lead, Tester, Software Developer, Release Manager

3 Person Team

  • Product Team Member – Product Owner,
  • UI/UX Designer, Tester
  • Engineering Team Member 1 – Architect,
  • Tech Lead, Manager/Team Lead,
  • Software Developer, Release Manager
  • Engineering Team Member 2 – Software Developer

6 Person Team

  • Product Team Member – Product Owner,
  • UI/UX Designer
  • Engineering Team Member 1 – Manager/Team Lead
  • Engineering Team Member 2 – Architect, Tech Lead, Software Developer
  • Engineering Team Member 3 – Software Developer, Release Manager
  • Engineering Team Member 4 – Software Developer
  • QA Team Member – Tester


The image below shows a sample 6-person team scenario. The main point is not who owns what role (this can vary from team to team), but that every role is owned someone qualified.

Click image to see larger version.

Conclusion

Creating good software is a multifaceted process. It requires various skills and efforts throughout the effort. Therefore, certain roles and responsibilities are necessary for any size team. Sometimes the team is small and one person may be responsible for several roles. Other times the team is very large and those responsibilities are spread out among the team members.

The important part is to not neglect any of them to ensure a better delivery and overall result.