This is a discussion epic raised from the increasing support load in certain developer teams (Database, Geo, Gitaly) and perceived, preventable user frustration during user escalations. # Problem statement - Our product is complex, and our growing customer base demands an increasing array of environments and use cases. - Many self-hosted customers are unable to set up GitLab or its various subsystems themselves in a way that would satisfy their needs, and end up with suboptimal solutions. - At the same time, many choose not to engage Professional Services (PS) until after their solution proves inadequate, and even offer resistance when we are trying to advise. - Our existing support structures (Solutions Architects, Customer Success Managers, Support, Developer teams) are not able to provide satisfactory solutions early enough in the product adoption cycle, leading to high-level escalations for technical issues. In other words, they aren't set up to perform the work of PS. - Scope of GitLab has grown, and it's not possible for single persons to be experts in all of its areas. Moreover, customers often request help in areas outside our purview (for example, setting up PostgreSQL or running cloud services). - Escalations come at a high cost to GitLab. # Proposals - Bundle a time-limited engagement from PS with purchase of self-hosted GitLab to prevent customers losing time and experiencing frustration (and GitLab experiencing escalations). Possibly tied to size. - To deal with the huge scope, grow specialists within each support group who can advise "locally" without escalation. This should be formal enough to track the needs of the organization eg timezone coverage. - Set up and maintain training material for key areas. - Clarify escalation paths and responsibilities (who can help with what) to reduce turnaround time. - Review and document what topics we commit to help customers on. Review the skill pool available for this and hire and train people appropriately. - Lean into https://handbook.gitlab.com/handbook/product/product-principles/#convention-over-configuration so that GitLab is easy to install and run with minimum customization. - Provide more documentation that is _prescriptive_ instead of _descriptive_ for special cases, such as the [Monorepo guide](https://docs.gitlab.com/ee/user/project/repository/managing_large_repositories.html). In many cases we document the control surface well, but we do not provide strategic guidance on _how_ to use the product and why. ## Expertise areas we lack in customer-facing settings - `git` itself: monorepos, efficient specific workloads, handling special cases eg accidentally committed files - PostgreSQL management - Cloud services such as Kubernetes, AWS etc (for example, autoscaling) cc @jcaigitlab @juan-silva @alexives @nhxnguyen @cdu1 @lbot @christiaanconover @glen_miller @mjwood @sranasinghe @joshlambert