This page outlines the vision, strategy, and goals of the Delivery team.
Enable any Sourcegraph prospect or customer to use Sourcegraph in a way fits within their environment and allows them to easily access the value that our product provides. Make it as easy as possible for customers to access the value of Sourcegraph’s latest developments through a simple upgrade process.
Sourcegraph can be run by any user with a standard engineering background, at any scale, with ease. Configurations to the deployment are simple, easily made, and do not complicate upgrades. Sourcegraph customers appreciate the ease of upgrades and are keen to access Sourcegraphs latest updates. Customers are able to self-serve for deploying, upgrading, and troubleshooting deployments of Sourcegraph.
Setting up and running Sourcegraph is trivial but superbly flexible, supporting customers spanning both the full range of technical capability and the full range of required configurability.
Customers are no more than 1 release behind the most recent release of Sourcegraph. Customers can seemlessly migrate between our supported deployment options with their changing business needs.
These are the principles that guide the work we do in delivery. Sometimes adhering to one causes us to compromise another, but they guide our decisions on what matters.
- We find and support the best deployment, configuration, and upgrade solutions to support the majority of our current and future customers
- We cannot cater to every customer’s wants and needs, and trying to would undermine our ability to serve all of Sourcegraph’s current and future customers
- We prioritize work that will best support the majority of our customers and prospects, sometimes compromising what we can offer to individual customers whose needs are not aligned with our strategic decisions
- We typically refer to our primary persona as a “site admin” - they’re the person or team responsible for deploying Sourcegraph, including any configuration required to make it fit into their existing environment and meet the security requirements
- The site admin is often the linchpin of a successful deal, but they rarely have a hand in kicking off the use of Sourcegraph (and so can be less emotionally invested), but they are responsible for the deployment, which unlocks the value, whether that be during POC or production deployment
- The ease of the site admin’s experience is critical to success as blockers for them block every other user, but site admin experience levels vary massively
- Many site admins are normal engineers, rather than specialists in the types of technologies common for system deployments
- We aim to provide solutions that make immediate sense to any engineer responsible for deploying, configuring, and supporting Sourcegraph
- Since we cannot always provide something super simple and intuitive (sometimes unavoidable in the complex world of distribution technologies) we provide documentation that anyone with even a very basic technical understanding can follow
- We aim to use technologies that are commonplace, but sometimes we will deviate when the solution we can provide will better serve our customers and can still be offered with sufficient guidance and support
- Where is the team’s area of ownership in terms of its maturity? Is it new and basic, or complete and lovable? Are different features at different levels?
- What did we achieve in the last few months?
- What key learnings did we recently make?
- What is on the critical path for growth?
- How does the product fit within Sourcegraph as a whole?
⚠️ Please see below in Strategy and plans for more information on which problems are actually in scope of the team.
- The primary customer and support problem is one of the ease with which Sourcegraph can be installed and upgrades
- This spans multiple sub problems, but a high level overview of the pain can be read here
TODO add more specific customer/support problem information
🎯 Increase the percentage of customers adoption new releases within 1 month
🎯 Reduce the average number of issues raised relating to POC or Production deployments
More detailed plans related back to the themes and goals. If your time frame covers more than a quarter, it would be valuable to give some indication of time within the plans in this section, to help others appreciate the likely ETA of value.
Note that the time periods are rolling time periods and the plans here are reviewed and updated monthly.
- Redcued friction in deployments and upgrades
- See more information in the problem statement [WIP]
- Expected to be a continuation of the work in the short term, though it’s hoped that value will be delivered incrementally.
What are we explicitly not working on? Are there frequent requests from customers or other teams we are choosing not to take on? Making that explicit makes other teams understand the strategy and reduces back and forth.
If there is a time component (e.g. “We’re not working on this this Q but likely to pick it up next Q”), call it out.