Mission

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 by 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

• Developer Experience KPIs

Cultural fit of the role within the organization

This role silos the pain product knowledge of the engineers working on the product. This is far from ideal. We should not hire for the role until we feel the pain is harmful. For example:

• 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, 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, issue signals 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.

Interaction with other roles

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
• 2 Product Engineers focused on maintenance