Product Teams Group and Structure

Starting April 4th, 2022 our Product and Engineering organizations will be oriented around Groups.

What does a “Group” look like at Clipboard Health?

A Group is a cross-functional unit led by a Group Product Manager alongside one or more Engineering Managers.

Groups consist of:

  • Multiple product and engineering pods
    • each “pod” is a PM and a group of developers
      • Each PM reports directly to the Group PM in charge of their group
  • Strategy & Operations Team representatives
  • Product Operations Team representatives

Groups are oriented around a set of customer problems (“missions”). Those missions are not fixed or even exclusive; there might be times when multiple Groups are attacking the same problem. That’s both acceptable and (on the margin) expected.

What problem are we addressing with this change?

As the team has grown, it has become increasingly difficult to communicate and collaborate, both within the Product team and across teams.

Previous versions of our Product organization could rely on organic communications and interactions to disseminate knowledge within the Product team, but we’re starting to see evidence that this kind of ad-hoc communication is becoming more difficult.

While I believe that what we’ve been doing is still working at the moment, I don’t see that being the case a few months from now. The kind of communication that got us here won’t get us to where we want to go.

A variation of this communication problem is that it has become harder to collaborate across teams. As we’ve grown, It has been “easier” to stay siloed within our respective functional units. This is often a second-order effect of a “The [X] team doesn’t listen” sentiment spreading.

This reorganization addresses that sub-issue. Since folks across teams will work and mix within individual Groups, we will preemptively prevent the spread of the harmful sentiment above in addition to getting more people involved in problem-solving to inform better resource allocation.

The end state we’re striving for is “highly aligned, loosely coupled”.

How does this address the “across teams” problem alluded to above?

When it comes to how we work with Engineering, we’re going to further integrate engineering managers into Group rituals, with the intent of bringing them closer to the customer and reducing the time to resolution for any issues related to PM <> Engineering interactions.

There are no immediate implications related to working with teams outside of EPD, but we’ll look toward further cross-functional integration over time. Our current-best idea is to work with leaders of other teams to define time-bound tours of duty for select members of their team to help set a specific project up for success. This would be some non-negligible amount of their capacity as defined in collaboration with the leader). These team members would indirectly report to the Group PM for the duration of the tour.

What Groups are we starting with?

We will start with four Groups pursuing the following missions:

  • Workplace Customer Problems
    • As an HCF, I want the quality of my part-time/agency HCPs to be at least as good as my full-time HCPs
    • As an HCF, I want shift management to be frictionless
    • As a new HCF, I need staff in the building today
    • As an HCF, I want to be able to solve my problems without Support involvement
    • As an HCF, I can’t get all the HCPs I need through CBH because I ran out of credit
      • As CBH, we might lose a lot of money due to bad debt
  • Worker Customer Problems
    • Quickly acquire and activate high-quality HCPs
    • Make the booking experience fast and easy
    • Make payments fast, reliable, and seamless
      • As CBH, we might lose a lot of money due to fraud
  • Marketplace Problems
    • As an HCF, I think CBH/staffing is unreliable
    • As an HCP, there are shifts I would have worked if the pay was higher
      • As an HCF, I am having a bad experience filling shifts
    • As an HCP, I don’t have enough good shifts
  • Platform Engineering Group
    • The mission of the Platform Engineering Group at Clipboard Health is to ensure that our engineering system (services, infrastructure, applications) can meet the demands of scale as our business grows. Platform teams make investments to complement and accelerate the work of our more purely product-focused teams.
    • Note the Platform teams will also help reduce the risk of collision since we’re not dedicating product real estate to particular teams.

These missions are not a collectively exhaustive list of what could be worked on, but simply what we’ve deemed to be the most important missions at this moment in time.

Will Group missions evolve over time?

Yes, absolutely. Quarterly planning will be a forcing function to re-evaluate what missions we staff, but Groups are encouraged to shuffle as needed to respond to new inputs arriving throughout the quarter.

Is Group staffing set in stone?

No. We’ll consider Group staffing to be “elastic” and the staffing may shift from quarter to quarter. What matters most is maintaining confidence that we are solving the most important problems for our customers. In other words, the bounds of the org structure should be viewed as guidance and not as rigid determinations of “ownership”.

What are the central tenets guiding this transition?

  1. Speed of execution is most important: We won’t succumb to BigCo slowness
  2. Maintaining an ethos of extreme ownership
    1. Extending on this, we will allow no organization around product real estate or “swimlanes”

We’re prioritizing speed and will seek to avoid roadmap coupling (e.g., “Pod A is not able to solve their problem because they’re waiting on Pod B to build something lower on their priority list”).

We’ll propagate the use of a set of rituals and artifacts that teams will leverage to mitigate the collision risk that this structure creates. On the Engineering side, we’ll assign specific "owners" for maintenance areas as we're doing now as well as use an internal open-source model where anyone can make a PR against any area under the assumption that the owner/maintainer is the subject matter expert and has to review/approve the change.

I’m not a PM or Engineer, what does this mean for me?

As mentioned, to start we’ll have Strategy & Operations and Product Operations team members embedded within these Groups. We’ll then work with cross-functional leaders to craft tours for members of their respective teams to work within a Group for a time-bound period when it’s deemed necessary.

“Embedding” means being:

  1. Formally included within the Group
  2. A part of goal-setting and quarterly planning for the Group
  3. Staffed to projects at the discretion of the Group PM on a case-by-case basis

The Group PM is the “portfolio manager” for the Group – they’ll be directing traffic, coordinating planning processes, and determining where the Group generally, spends their time.

The reason we caveat #3 with “case-by-case” is that the extent to which #3 is true depends on the ask and the opportunity cost. The leaders of the S&O and Product Ops units will have their own portfolio management authority and will have to work with the GPM to negotiate investments as needed.

If/when a member of a cross-functional team performs a tour within a Group, the Group PM would not have staffing discretion outside of the scope of the project that the tour is oriented around. But this cross-functional team member would be embedded for all intents and purposes – they’d attend weekly Group rituals and would indirectly report to the Group PM.

To set these embeddings up for success, there will be a “dotted line reporting” relationship between those embedded and the Group PM. Dotted line reporting simply means that the Group PM may write a quarterly review for the cross-functional team member. Management authority continues to reside with the functional leader. Note that Engineering Managers will also “dotted line report” to the GPM.

Why pursue this dotted line structure? Don’t we already collaborate?

We already collaborate, but it’s becoming more difficult as we grow. With the goal being “highly aligned, loosely coupled”, this structure should enable greater alignment on where we’re investing, as well as provide more leverage to the Group PM (without incurring coordination costs). We’ll revisit if this slows us down and is counterproductive to our original goals.

Does my presence in a Group mean that I will receive a quarterly review from the GPM?

The Group PM will have the option to write a quarterly review for those that are embedded within a Group. Of course, those embedded will be encouraged to write feedback in the other direction, as well.

How will Groups affect my day-to-day?

Each Group will create its own public Slack channel where teams can work in the open, problem-solve, raise clues, and ensure that we’re working on the most important problems.

There will be a Weekly Group Meeting with:

  • The GPM
  • The Eng Manager(s)
  • The PMs
  • S&O members within the Group
  • Product Ops members within the Group
  • Members from other functions that are on an active “tour”

That meeting will consist of everyone bringing a weekly write-up to the table and a long table read. To start, these meetings will be on the order of 6 or so people. Write-ups will be shared publicly post-meeting with individuals outside of the meeting, who will be encouraged to asynchronously read and comment. These meetings will be derivative of the existing Weekly Product meetings.

At the pod level, pods will continue to operate as they do today.

For quarterly planning, you’re expected to engage in our brainstorming and prioritization exercises.

How does this change affect this upcoming quarter’s (Q2 ‘22) planning?

The changes affect planning across two dimensions:

  • The problems each Group is working on
    • Do you think that a Group should prioritize an unlisted customer problem ahead of one that is listed?
      • Please challenge the list and advocate for altering the list! You can work with the GPM to hash this out, but please share your documented thoughts in a public forum (e.g., product team channel) to facilitate ambient awareness.
  • Planning logistics
    • Minimal change: The only change is that the GPM and EM(s) will have investment planning meetings with pods (instead of that being myself and Mike).

What does the Group structure mean for new products?

New products (e.g., BillTerms) will be isolated from the Groups. The Groups encapsulate the “staffing marketplace” product suite and we want to insulate our new upstarts from the necessary processes that Groups will maintain.