Mission

Offload Product Engineers when there are too many paper-cut problems to solve, so they can focus their time back on deep problems.

Paper-cut is great as it helps to stay grounded in reality as well as understand deeply how people use the product, but it can’t be where all the time is spent. In this context, “paper-cut” includes support questions.

Why does this role exist

Responsibilities

• Resolve users’ issues. You will solve these issues at two levels.
  • on the surface. It's achieved by answering them on GitHub, email, Slack, Twitter, Zendesk, Discord, etc.
  • at the root. It's achieved by creating or updating documentation and by fixing bugs in collaboration with the relevant developer, and building missing features.
• Build product knowledge. Continually research and learn the current and future best practices of using MUI.
• Provide feedback. Work alongside product managers to define and shape the product goals, roadmap, priorities, and strategy based on your frontline knowledge of customer needs.
• Operations.
  • You will establish key support metrics and identify how best to measure them.
  • You will establish a workflow to reduce 'time to response' and 'time to fix' that can scale to multiple team members.
  • You will identify where internal tooling might be developed or obtained to improve support efficiency.

Performance indicators

• KPIs - Technical Support

Interaction with other roles

When to create this role

This role silos the pain product knowledge of the engineers working on the product. We should avoid this as much as we can. We should not hire for the role until we hit a wall:

• Examples of good reasons ✅:
  • We want to sell SLAs, but we have tried the above, and none of the solutions are working; they prevent us from moving the product roadmap forward.
  • Engineers spend time answering the same questions over and over the same questions after they have done all they can to fix the root causes, but it's not enough. It's distracting them; they don’t learn anything new.
• Example of wrong reasons ❌:
  • We have 1k issues opened on GitHub, and we can't keep up with them. Here, I would advocate that the solution is either:
    • to break down the product ownership, to become more efficient, and to compete with both MIT libraries, which have a single focus.
    • to deprioritize new features if the issues raised are more important.
    • to foster a culture of community contributions by ignoring issues and focusing on community PRs first.
    • Recognizing a hiring cultural misfit, we take the most pride in delivering a great product, delivering a specific outcome, signaling that this outcome isn't reached, and challenging us to find a good enough solution that yields better outcomes.
    • to recognize that having this many open issues is OK.
  • We want to improve our community contribution stats, but the engineering team doesn’t find it rewarding.

Sizing

At maximum, 1 Support Engineer role for every 3 Product Engineer roles. The lowest we can get away with, the better. Staff when Product Engineers are overwhelmed with their support duties.

Ideally, retain this ratio:

• 2 Product Engineers focused on building core features