When I describe the roles on a delivery team, I am describing responsibilities, not necessarily people. A role is a bundle of activities and accountabilities that has to be owned by someone. On a small team one person might wear two or three of these hats; on a larger one a single role might be shared across several people. And the roles are not permanent labels. Someone who is tech lead on one engagement might be a regular engineer on the next. With that framing, here is what each role owns.

Product owner#

The product owner is accountable for the product vision, strategy, and the business result. They keep the team focused on real user needs and the outcomes that matter, and they provide the guidance on scope, priority, and quality that everyone else steers by. Practically, that means working with delivery to set roadmap priorities, defining acceptance criteria with the team, reviewing and signing off on completed work, and often running the sprint demo. They are also the product's champion outside the team, synchronizing with stakeholders and continually characterizing how the work is moving company objectives. On a consulting engagement this role is sometimes staffed by the client and sometimes by the delivery side.

Delivery lead#

The delivery lead keeps the team on track and owns the cadence of the work. They run the recurring ceremonies, including standups, planning, retrospectives, and demos, and they own the team's velocity, publishing it and adjusting to keep delivery on track. They translate ideas into actionable user stories with clear acceptance criteria, manage the inevitable changes in requirements and assumptions, and surface risks, scope changes, and timeline concerns early through honest communication. They are the escalation path when something needs to go up to stakeholders. The delivery lead also frequently picks up adjacent work the team needs, such as acting as a manual tester or coordinating like a project manager, to keep the engineering team unblocked.

Tech lead#

The tech lead owns the technical direction and the bar for craft. They define the target architecture, guide the engineers' day-to-day technical work, and make sure the team takes collective ownership of solution quality. A big part of the job is communication: facilitating between the engineers and the business, design, and other stakeholders, and helping the product owner relate technical work back to business value so it can be prioritized sensibly. They identify and unblock technical risks, mentor the engineers, and communicate the technical vision upward. Two responsibilities are easy to forget and worth naming explicitly: making sure the team can keep operating when the tech lead is unavailable, and actively growing the next tech lead. A lead who is a single point of failure has not finished the job.

Software engineer#

The engineers hold the standard of craft through the life of the project and own the quality of the solution and the code. Beyond completing development tasks for their stories, that means building real understanding of the business challenge from both a value and a technology standpoint, keeping test coverage high, engaging genuinely in code review, and committing within the team's agreed coding standards. The role is not "take a ticket, close a ticket." It is shared ownership of whether the thing being built is good.

Experience lead and experience designer#

Most teams need design coverage split across two altitudes. The experience lead owns the overall experience for the product, providing high-level direction for a user-centric design, making sure that experience aligns with the organization's strategic goals, and mentoring other designers. They communicate the experience strategy to the rest of the team, the product owner, and stakeholders, and collaborate on product vision and scope.

The experience designer works closer to the artifacts. They represent the end user inside the team, run user research and usability testing, develop personas, and produce the wireframes, clickable prototypes, interface designs, and design elements the engineers build from. They also establish style guides and pattern libraries where none exist yet.

An account-facing layer#

On client engagements there is usually an account-facing responsibility too, sometimes folded into a delivery or account lead. It owns the overall client relationship, ensures the client stays delighted and heard, acts as the senior point of contact, and handles the budget, scope, and timeline conversations at the level above day-to-day delivery. It partners closely with the delivery lead so that the relationship and the work stay in sync.

Why frame it as responsibilities#

The practical payoff of treating these as responsibilities rather than fixed seats is that you can check a team for gaps. Walk the list and ask, for each, "who owns this here?" If a role has no clear owner, you have found a risk before it bites you, whether that is no one owning experience design or no one growing the next tech lead. The roles flex with the engagement; the accountabilities should never quietly go missing.