Recommended resources
The freely available resources this lesson will direct you to.
Hello again. In the previous lesson, we treated onboarding as an end-to-end operating system rather than a list of engineering tasks. One part of that system was accountable ownership. This lesson makes that idea more precise: when a deployment depends on sales, product, engineering, security, customer success, and the customer, what should each party actually do?
For the role you are preparing for, this distinction matters as much as technical skill. You may lead the customer relationship during onboarding and build the integration. Neither responsibility gives you authority to approve the customer’s data policy, change the product roadmap, or redefine what was sold. By the end of this lesson, you should have a practical way to identify who performs work, who makes a decision, and where your job is to coordinate rather than decide.
Separate delivery ownership from decision authority
Consider a sensitive data field in a customer’s operational records. You can investigate where it comes from and implement an agreed transformation. The customer’s data owner must confirm what the field means. Security and privacy owners may need to approve how it is handled. If the transformation requires a new platform capability, product and software engineering have decisions and work of their own. You can own the path to a resolution without owning every judgment along it.
A compact vocabulary for these distinctions is RACI: Responsible, Accountable, Consulted, and Informed. Watch the two indicated portions of Adriana Girdler’s video before applying the terms to onboarding.
RACI explained its simple yet powerful - The most watched RACI matrix video on YouTube
Watch “RACI explained its simple yet powerful” from the RACI channel for a short distinction between doing work and owning its decision, followed by a check for gaps and overlaps.
Watch the role definitions, focusing on the difference between the person doing a task and the person with final authority for it. Then watch the matrix checks for why an unassigned or multiply assigned decision can stall work. We will use RACI as a way to reason about boundaries here, not build a full project matrix yet.
In this lesson, Responsible means doing the work; Accountable means owning the result or decision for a specific item; Consulted means providing input before it is settled; and Informed means receiving an appropriate update. The important phrase is specific item. “Own onboarding” is too broad to tell you who may authorize data release or prioritize a software fix. “Approve the customer’s source-field definition” is narrow enough to name a decision-maker.
A useful default is one clear accountable owner per decision or deliverable. That does not mean every task has only one contributor. Nor should you pretend that a vendor and a customer share one pool of authority. If the customer must authorize access to its records, distinguish the customer’s approval of access from your coordination of the access dependency. You can be accountable for making the request visible, timely, and escalated; only the customer can grant it.
The internal roles: different kinds of ownership
Job titles vary across companies. A small team may combine functions that a larger team separates. Read these role descriptions as a starting model, not as a claim about your future employer’s exact organization.
SaaS Roles Definitions | Winning by Design Blog
Read Winning by Design’s “SaaS Roles Definitions” to see how initial deployment differs from longer-term customer success, and why a technically skilled, customer-facing role may cross conventional job-title boundaries.
In “Group 3. Customer Success Roles,” read the role descriptions beginning in “ONB – Onboarding Managers” and ending with “TAM – Technical Account Managers.” Pay particular attention to the contrast between an initial go-live focus and the CSM’s ongoing adoption focus. The account-manager description between them provides context for who may retain commercial ownership after a sale.
The distinctions become more useful when stated as contribution, authority, and boundary:
| Function | Main contribution during onboarding | Boundary to keep visible |
|---|---|---|
| Onboarding engineering | Leads the deployment journey; investigates requirements; implements and validates customer-specific configuration, integrations, migration, mapping, and access setup; coordinates blockers and launch readiness. | End-to-end delivery ownership does not confer commercial, product, security, or customer-policy authority. |
| Sales / commercial owner | Transfers what was sold, relevant expectations, stakeholders, and unresolved promises; helps resolve commercial ambiguity or a proposed change in scope. | Does not silently become the technical delivery lead after handoff. |
| Customer success | Maintains attention on desired outcomes, stakeholder engagement, user readiness, and the transition to an ongoing relationship. | Does not own a migration merely because its success affects adoption. |
| Product | Determines supported behavior, product direction, and priority among product changes or defects. | Does not automatically commit to building a feature because one onboarding needs it. |
| Software engineering | Investigates and changes shared product code or infrastructure; assesses feasibility and technical consequences of product fixes. | Is not the default owner of customer-specific project coordination. |
| Security / privacy | Establishes and reviews controls for access and sensitive-data handling; identifies required evidence and authorized approvals. | Does not replace customer-side approval of the customer’s own data use or policies. |
| Customer team | Supplies systems, data, domain meaning, identity configuration, approvals, participants, and acceptance decisions within its authority. | Cannot be treated as a single contact who can decide everything. |
This is a functional map. For example, a solution architect or sales engineer might have shaped the integration before contract signature. You will need their design context, but the person who proposed an approach is not necessarily the person who implements it. Likewise, if there is no dedicated customer success manager on a deployment, the adoption and handoff questions do not disappear; someone still needs an explicit assignment.
The description of your prospective role makes one adaptation especially important. In some organizations, customer success owns the onboarding plan while implementation owns technical readiness. Here, the onboarding engineer is expected to lead the onboarding project and customer relationship during that phase, as well as perform technical work. Customer success may still contribute to outcome alignment and receive the account for ongoing work. Copying another company’s ownership chart without this adjustment would create two apparent project leads—or none.
For a second view of these boundaries, read the following Grasp guide. Its sample split between implementation and customer success is useful precisely because you can compare it with the more consolidated role described above.
RACI Matrix for Cross-Functional Responsibilities | Grasp
Read Grasp’s “RACI Matrix for Cross-Functional Responsibilities” for a default cross-functional model. Use it to identify the kind of decision each role can own, rather than copying its example assignments unchanged.
Near the beginning, after the pointer to a Gainsight role overview, read the function table, from its introductory sentence through the Product row. In the following discussion of Solutions versus Implementation, notice the distinction between agreeing a viable design and delivering it; then read the role distinction through the example of separate customer-success, implementation, and product decisions. Finally, under “Read a RACI matrix horizontally and vertically,” read the concrete-work guidance. Focus on why “manage onboarding” is a poor substitute for naming an actual deliverable or decision.
Two boundaries deserve particular care. Product and software engineering collaborate, but their responsibilities are not interchangeable. Engineering can establish why shared code behaves as it does, estimate a fix, and implement and test one. Product weighs whether and when a change belongs in the product, alongside customer and platform priorities. You should describe the onboarding impact to both, not promise the customer a fix date that neither has confirmed.
Security and delivery also collaborate without merging authority. You might implement a redaction rule or configure restricted access. The relevant security and privacy authorities determine whether the proposed treatment meets applicable requirements; customer authorities determine what they permit for their data. In a sensitive-data deployment, “the engineer configured it” is not equivalent to “the right parties approved it.”
The customer team is part of the delivery system
Calling someone “the customer” can conceal several different owners. An executive sponsor may resolve priorities and remove organizational obstacles. A data owner or operational subject-matter expert can confirm what a source field means. An identity administrator can configure the customer side of single sign-on. Security and privacy representatives review the use and transfer of sensitive records. Intended users can show whether the resulting workflow is usable. One person may wear several of these hats, but you should not assume they have authority in all of them.
RACI Matrix for Cross-Functional Responsibilities | Grasp
Return to Grasp’s “RACI Matrix for Cross-Functional Responsibilities” for its treatment of customer-owned dependencies. This is the corrective to an internal-only ownership map.
In “Customer responsibilities belong in the operating model too,” read the customer-side guidance, from the list of possible customer responsibilities through the governance principle about customer-only actions and decisions. Focus on the difference between managing visibility of a dependency and performing the customer's action.
This gives you a practical rule for an unfamiliar customer organization: name the required decision before guessing who can make it. “We need a contact for data” is vague. “Who can confirm that this code has the same meaning in both source systems?” identifies domain authority. “Who can authorize transfer of historical records for the agreed purpose?” identifies a different authority. You may need both answers before treating the data work as ready.
Customer success has a related boundary. It can help identify stakeholders, prepare adoption, and maintain continuity beyond launch. It cannot accept a data interpretation on behalf of the customer’s domain owner, or grant access on behalf of the customer’s identity team. Clear customer-side ownership protects the customer as well as the schedule.
Route a cross-functional problem without absorbing it
Suppose a migration sample loads, but a field used to categorize operational reports appears to mix two meanings. The customer expected the output to be usable at launch and asks whether you can “just transform it.”
The phrase sounds like an engineering request, yet it contains several different questions:
- What does the source data mean? The customer data owner or domain expert must establish the intended interpretation and provide representative evidence. You can investigate the records and make the ambiguity visible.
- Can the agreed implementation handle it? You can assess whether a documented mapping or configuration within the onboarding work is sufficient, then implement and validate that approach if authorized.
- Would this require new product behavior? If so, product owns the product-priority decision, informed by software engineering’s feasibility assessment and your account of the delivery impact.
- Does the change affect sensitive-data handling? The appropriate customer and internal security or privacy owners must review the relevant implications; you should not treat an unapproved treatment as a shortcut.
- Was the work commercially included? Sales or the designated commercial owner helps establish what was committed and resolve ambiguity. A recollection of a sales conversation should be investigated, neither dismissed nor automatically converted into new scope.
- How does this affect the customer’s intended use? You coordinate the explanation, revised options, and decision path during onboarding, with customer success involved where adoption or the ongoing relationship is affected.
There is no need to convene every role for every field. The point is to split an apparently single problem into its actual work, decision, and approval boundaries. Doing so prevents a familiar failure mode: the onboarding engineer works hard, produces a technically plausible answer, and discovers late that the person entitled to judge it never agreed.
A short set of questions can guide this routing whenever a request lands with you:
- Is it execution within an agreed approach? If so, it may be yours to do.
- Does it establish business meaning, policy, scope, or product behavior? Identify the authorized decision-maker before implementing the answer.
- Does someone else control a prerequisite? Name their action and maintain visibility of its effect on delivery.
- Who needs to know the outcome? Keep the customer and internal owners aligned without making every participant a decision-maker.
You remain responsible for following the question through. “That belongs to another team” is not a complete response when you are leading onboarding. A better boundary is: “That team owns the decision; I will bring them the context, track when we need an answer, and reflect the result in the deployment plan.”
Key takeaways
Onboarding engineering owns the coherence of delivery, not every underlying decision. Sales owns commercial truth; customer success contributes adoption and continuity; product decides product direction; software engineering diagnoses and changes shared software; security and privacy owners govern controls and approvals within their authority; and customer-side owners supply and authorize what only the customer can. Actual titles may differ, so identify the function and decision right rather than relying on an organization chart.
When ownership feels ambiguous, make the item smaller: name the work to perform, the decision to make, the prerequisite to supply, or the approval to grant. Then assign each to someone with the ability and authority to act. In the next lesson, we will put these owners into the typical journey from signed contract through discovery, implementation, validation, go-live, and handoff.