Ro Data Team’s “Project Ownership” Approach

Empowering Individual Contributors through Ownership of Team Quarterly Goals

Here on Ro’s data team we’ve implemented what we call the “Project Ownership” model. Each of our quarterly OKRs and projects is assigned an owner from the team who, along with their manager(s), bears ultimate responsibility for the success of said goal/project.

These individual contributors (“ICs”) are owners of the project regardless of how many other individuals — from the data team or otherwise — need to contribute work and thought towards it. Project ownership can touch communications, technical design, usability design, process development, dependency management, and user training, in addition to more “standard” role-defined responsibilities such as data analytics, data engineering, data science, etc.

The goal of this paradigm is to (a) empower team members by tying their work to company success as directly as possible and (b) achieve the best possible results for the company by giving each project as much structured thought and attention as it could possibly have and (c) give IC’s the chance to develop skills that are very important to have in a lot of data-oriented roles.

Is it worth stating that a project owner is never simply handed a project or goal to be accomplished alone. Communication, structured thought partnership, and project management partnership between the responsible project owner and other stakeholders is a constant. Additionally, there are a growing number of resources at a project owner’s disposal every day.

It is also worth stating that we are highly conscious that this model is not a one size fits all approach. Not all ICs, for example, will want to engage in communications, and their resources of time and effort may be best allocated executing on a core competency. In our case, the Project Ownership model grew organically before we formalized it. All members on the team opted in, with a track record of successful project ownership before doing so. We are still considering how important the “potential for Project Ownership” criteria should be when evaluating future data team candidates.

Setting Project Owners Up for Success

Twice Weekly Ownership Check-ins

Communication between project owners and managers/stakeholders is constant, but requiring structured check-ins is key no matter how much communication is already taking place. Each project owner on the data team is part of a twice-weekly check-in group which also includes managers and program managers. This meeting is more in-depth than a traditional engineering “stand-up”. Depending on the project, questions for project owners during this check-in might include:

  • Which OKRs + projects are you the owner of?
  • What progress have you made since the last check-in?
  • What are you going to work on next?
  • How are you prioritizing your different projects against each other for the next 2–3 weeks?
  • What meetings are you having, and what meetings do you think you need to be scheduling?
  • What communications are you running?
  • Where do you need help or resources?
  • What design decisions are being made as part of your projects? How are these decisions being made?
  • What questions have come up that you are having trouble answering? Let’s schedule time with the right people to figure this out.
  • What external dependencies (i.e. deliverables from other teams) do you have in progress? What external dependencies do you need to be anticipating? How is the progress of your external dependencies?
  • What process problems have you found? What are the most important process additions/adjustments that have to be made? What do we need to add to the our “Data Team Project Ownership Resources” (this is explained in later sections)?
  • Have you logged all work and summarized important communications in the appropriate place in Jira?

Project Owner Resources

A data team project owner has the following resources as a first line of general enquiry:

  • Their manager and peers
  • The team’s ever-evolving “Project Ownership Handbook”

A project owner can get process and design assistance, among other things, from:

  • A technical program manager
  • A product manager

Most Importantly: Always Be Communicating, Getting Buy-in, and Confirming

A project owner should always be:

  • Logging progress and important communications in our Jira system
  • Keeping everyone aware of key project developments
  • Consulting relevant parties/stakeholders when planning
  • Always, always, always confirming plans of actions with others (peers, managers, stakeholders)
  • Following approval requirements

The Data Team’s “Project Ownership Handbook”

The data team’s project ownership handbook is less of a fully-baked guide and more of what intellectuals might call a “living document”. It is essentially a series of organized guidelines that includes actual examples of these guidelines being implemented and how the guidelines came to be.

We host our handbook in Notion (a product similar to Jira Confluence), where anyone can access it and offer feedback

Every individual on the team is encouraged to contribute to the handbook, though it is important to note that most often a guideline does not come to be a guideline without at least two people puzzling out a best solution for the motivating question. It is also important to know that guidelines are expected to evolve and split over time and with discussion, meaning that a reader of a guideline should not take the guideline as a hard rule without evaluating the viability of this guideline for their current use case.

Quotable quotes from “Pirates of the Caribbean”

A simple example of a guideline might be “When helping design a new production data model, make sure that there is allotment on the development schedule for data team design QA and not just for functional QA.” A more involved example stems from a recent series of bumps in getting manual data inputs on a repeating basis from other departments in the company and establishing ownership of input/output accuracy. A number of individuals, including the technical program manager and individuals from the departments in question, are working together on setting up process and ownership protocols for these data inputs. The more generalizable lesson for the handbook here is “What to Do When Your Project Requires Periodic Inputs from Other Departments”. Doubtless, the guidelines on the topic will continue to evolve.

Constant Feedback Cycles

To maximize the speed of personal growth we are implementing quarterly feedback cycles which incorporate feedback from teammates and relevant individuals in other departments. The mechanics of designing these feedback rounds and implementing them is for another article.