Cross-org/team collaboration

Sometimes, ideas (and even code) for something your team owns comes from other teams, orgs, or even departments at Sourcegraph. That’s a good thing because everyone can contribute to the innovation and success of the product we all use, and the more we do of that sort of thing, the more of a flywheel we’re generating for improvements and that is one of the real advantages of being developers that make products for other developers.

That said, if the collaboration part of this is not handled well, you can end up in situations where we create duplicative product features, or waste time building things that eventually will need to be reworked, or even shut down.

To avoid this, as an open core company we can look to open source to see how this kind of situation is handled:

1. There should always be a clear Engineering department maintainer team who makes the final decision of whether to accept a suggestion/code from another team. You can refer to the ownership chart to determine which team the maintainer is, and they are the first group you should go to to discuss your idea. In cases where the question isn’t directly dependent on or modifying existing code, you should refer to the “Vision” sections of team strategy pages to determine if there is already a maintaining team for features related to the job-to-be-done you are pursuing.
2. Similarly, if you’re submitting code, they own the merge decision for changes to areas they maintain.
3. When it comes to go-to-market, they also determine pricing and how it fits in with their product area.

The earlier you engage with the maintaining team, the more likely you are to avoid a situation where you’ve gotten ahead of yourself and might need to redo work: unlike open source, there is no forking the project to make your own version. In situations where the ownership is unclear, it might represent a new category, or things are otherwise fuzzy, you should reach out to #prod-eng-directors for help.

Through these simple rules of engagement we can foster innovation at the company, avoid turf wars, and take advantage of the fact that we’re a tool “by engineers, for engineers” and welcome everyone’s contributions to improve the product while avoiding negative outcomes.