Grow our support capacity

[choldgraf]

Context

Over the last few weeks we have had several conversations around the limited bandwidth that we have for direct user support on our hubs. Currently, we follow a rotating support steward approach, but we are fundamentally limited by a few things:

• We have limited bandwidth and more operations / development issues than we can tackle already
• Our team has expertise in infrastructure but less experience in dedicated user support

This means that we are both extending an over-extended team into doing user support, and also that we have a mismatch in our team skillsets to the work that is being done. We want our engineering team to focus their time on engineering tasks, so that they are empowered to do the work that matches their skills and interests.

Proposal

We need to grow our support capacity somehow, this is an issue to discuss and track efforts to do so.

Some options we discussed

Here are a few ways that we could grow our support. They aren't necessarily exclusionary, but some take more time and investment than others.

1. Improve our support processes - By improving our support processes, we can boost our efficiency and thus our capacity.
   • Pros: Could be done relatively quickly without major changes to team composition
   • Cons: Will have limited effectiveness in the long-run because it does not fundamentally change the number of hours in the day we have available.
   • Issue tracking this: Define some first-line and second-line support processes infrastructure#1068
2. Divert more non-engineering time to support. Right now our support steward team consists of the engineering team + myself. However, @colliand and myself could spend more time on the support side to free up engineering more for operational tasks and fixes.
   • Pros: This would create a better match between support actions and people that are focusing their efforts on being community-facing.
   • Cons: @colliand and myself are already over-subscribed as well, so this doesn't solve the fundamental capacity crunch.
3. Contract out support work to another person / organization. We could investigate whether individuals provide support as a service in a relatively hands-on way. This wouldn't be like an "outsource to a call center" situation, but perhaps we can find contractors that specialize in supporting teams.
   • Pros: Could be a way to boost our support capacity relatively quickly if we found the right person.
   • Cons: Is not a long-term investment in our team's support capacity and practices, and may create imbalances in team collaboration.
4. Ask for support help as in-kind donation from our partners. Some of our partner organizations have their own support staff (e.g. Berkeley and Toronto). We could consider asking them to join 2i2c's broader support team more generally.
   • Pros: Could be a way to boost our support capacity relatively quickly if we found the right person.
   • Cons: Similar to contracting, is not a long-term investment in our team's support capacity and practices, and may create imbalances in team collaboration. May also create tension for the support person given that they'd have two organizations guiding their time.
5. Define a role that is partially dedicated to support and hire somebody in it. We could define a role within 2i2c that has support work as a core part of their job, and hire somebody.
   • Pros: Is a long-term solution to this problem, and would let us dedicate time and expertise to support.
   • Cons: Would be expensive and time-consuming to create this role and hire somebody.

Suggested next step

I suggest we make some short-term progress here by making a quick push on #1:

• Define some first-line and second-line support processes infrastructure#1068

But that we focus our efforts on #5 as a next step via a new issue, unless we believe that we are really pressured on support capacity, in which case we should look into #3 or #4 as temporary fixes.

Thoughts on hiring a support role

Here are some thoughts on hiring somebody that can do support. We can paste these into a new issue if we create one to track that work.

I believe that a natural place for dedicated support people to live would be within the "product and community" area of 2i2c (for which we are currently hiring a lead). This seems like a natural place for somebody who would be hired with a "community-facing" role in mind. The skills needed to do good technical support are likely similar to the skills needed to run workshops, community listening sessions, etc.

In addition, there are a few things we should consider in deciding when is the right time to push on this:

1. Financial capacity. Would this be a financially sound decision? It would shorten our runway, but if we can make a case that this would improve our relationship with other communities then this might still be worth it. It may also inform conversations like @rabernat's suggestion to rethink the community representative role.
2. Hiring capacity. In addition to financial resources, designing a new role and hiring for it also takes significant time from many people (just see how many hours we've put into the product and community lead!).
3. Waiting for the Product and Community Lead? Finally, this person would likely work closely with the product and community lead - maybe we should hold off on a role design / hiring process until they are more closely onboarded so they can help us design this role.

This is also related to:

• Define separate support and operations teams infrastructure#1155

thanks to @damianavila for having a few conversations with me about this!

Updates and actions

No response

[yuvipanda]

Waiting for the Product and Community Lead? Finally, this person would likely work closely with the product and community lead - maybe we should hold off on a role design / hiring process until they are more closely onboarded so they can help us design this role.

This seems quite important, as most of our support is not directly from users but from community representatives. I'd suggest waiting.