Provide secure, accurate, and delightful access to Sourcegraph for both external and internal customers.
These tenets guide how we make tradeoffs on the team. These are designed to be timeless and make our vision actionable during day to day decisions.
- Security over speed: We strive to make our services as fast as possible, but we will never compromise correct enforcement to achieve a performance boost.
- We prefer simplicity over complex engineering: Permissions have to be correct for our customers to trust us. Complex systems increase the likelihood something will break, which will erode trust in Sourcegraph. We start with the simplest solution and scale it until it breaks before exploring more complex solutions.
- We don’t build on brittle foundations and we don’t implement short term hacks. We must always respect our customer’s code permissions and building band-aid solutions increases the likelihood of leaking data and losing customers.
- Non-addative - Sourcegraph is not a permissions layer. We inherit permissions from other systems (code hosts, Auth providers, etc) and leverage those to surface repositories. We do not edit or add read or write access to anything the user should not have access to.
Service management is a broad area of ownership. To provide more clarity into what its stands for, we will break this down based on product domains. We will also provide a list of features and services from a technical engineering ownership perspective.
The IAM team is responsible for both authentication and authorization to Sourcegraph, including login, sign-in and sign-up pages and user management for on-prem and managed instances.
The IAM team also owns code-level authorization, which is enforced based on the repository permissions on the code host level or with explicit permissions API.
Capabilities that provide customers with transparency and access control to how Sourcegraph is used within their organizations. This includes but is not limited to organization/team management, role-based access control, and other features targeted towards admins on our customer’s side.
The end-to-end experience of managing customers’ subscription lifecycle includes the subscription as the entity, its changes over time, and the impact on Sourcegraph product offering and AAR. This includes both providing transparency to the customers and internal tooling to support Customer Engineering and Finance and Sales teams.
Both technical and presentational sides of pricing. This includes both the presentation of pricing tiers to the customers with the process of selecting an appropriate plan and underlying technical implementation of the pricing model and its connection with billing and payments, plus impact on subscription management.
The process on paying for Sourcegraph subscription.
Customer-facing and internal tools and features that provide transparency to how customers consume entitlements within their current subscription, including entitlements limiting enforcing capabilities.
For a detailed list of features and services owned by the IAM team, check out the Engineering Ownership page.
The IAM team works alongside several other teams at Sourcegraph. You can find more information about their teams and goals on the respective pages:
We work in 2 week cycles.
|30min sync||Demo Day||30min sync||30min sync|
|30min sync + check what’s in estimation queue||30min sync||60min Grooming||30min sync|
Goal: continuously improve how we work. We do that by using the retrospective to look back at the past 2 weeks. What we want to find out is what went well, what didn’t go well, and how we can improve.
The agenda for the retrospective is this:
- 10min: fill out the prompts in this Google Doc
- What went well?
- What could have gone better?
- Do you feel supported?
- Do you feel like you’re moving into the right direction of your team?
- What processes/other things should we revisit/refine/propose?
- Other thoughts/questions?
- 5min: celebrate what went well (read out all items)
- 2min: vote on items
- 28min: talk through items, start with the highest votes
- 5min per item, use a timer, be strict
- Once 5min are up: ask if 2 more minutes
- If possible: collect action items
Goal: The goal for the grooming session is to get as many items in our backlog prioritized and estimated. We estimate together enough tickets so that we’re all on the same page on how to implement something and how long it will take, so that we can plan it in future sprint.
Requirements for the meeting:
- DRI for a project prepares by creating as many tickets as possible
- Product comes in with requirements from customers and tickets
Agenda for the grooming meeeting:
- Open the IAM board
- What’s in the backlog? Something missing?
- What’s estimated? What’s not estimated?
- Go through top N of unestimated tickets that Product thinks we will work on next
See the IAM planning doc for the specific agenda we use in each planning meeting.
A good planning meeting should answer the following questions:
- What’s the availability of everybody for the next 2 weeks?
- Is there a release happening? If so, when?
- Any other special events? (kickoff meetings, meetups, …)
- Who’s on Support?
- Leftover work:
- Are there things left-over from the last iteration? If so, why?
- Planning next 2 weeks
- Step 1: gather input:
- What does Product need us to do in the next 2 weeks?
- Ideally these requests are prioritized and “ready to be implemented”
- Are there any customer issues we need to work on?
- Other requests from outside?
- What does Product need us to do in the next 2 weeks?
- Step 2: plan:
- What do we want to work on?
- Go through each person, define what they’ll work on, what they commit to do
- Check if it matches their availability
- What do we want to work on?
- Step 1: gather input:
- What will we demo at the end of the iteration?
- For users with urgent help requests reach out to our support team at firstname.lastname@example.org.
- For emergencies and incidents, alert the team using Slack command
/genie alert [message] for iam.
- For internal Sourcegraph teammates, join us in #iam to ask questions or request help from our team, or ask
- For feature requests, please reach out to our product manager, Ryan, at email@example.com and include
IAM Feature Request:in your subject line.
We conduct regular user research and usability testing. This helps us understand how our product is being used, identify pain points and opportunities, and better understand our users.
Research is typically planned, organized, and executed by the product team.
Anyone on the team can join a research session as an observer and notetaker. Observing and notetaking during user interviews and testing sessions is an amazing way to get a first-hand look at how others use our products and ideas, and your role as a notetaker is a huge help for the team.
See ”So you’re about to help us with user testing” to learn what to expect during user research sessions and how to take great notes.
We are a globally distributed team with 16+ hours of time zone difference. Asynchronous communication is a key for achieving high visibility and close collaboration within the team. In addition to general Sourcegraph async communication guidelines, we agreed to the following recommendations within the IAM team.
While the team is following multiple Slack channels, #iam-internal is the place for all work-related discussions, including status updates, questions, requests for help, team announcements, etc. Please remember that Slack is not a source of truth. To make the relevant information easily discoverable over time, use other channels (for example, GitHub, Handbook, Google docs, etc.) and reference them on Slack via links. It’s worth thinking about Slack as a synchronous—rather than asynchronous—communication channel.
GitHub is the IAM team’s single source of truth for team backlog, work planning, and execution. Please include all tasks related to status updates and questions within GitHub issues and keep the state of the sprint board up to date.
Please keep all discussions related to ongoing code changes within GitHub pull requests. You will find more guidelines for making pull requests and asking for code review in the Making pull requests and asking for code reviews section.
We use Figma for high- and medium-fidelity design and prototyping. High-fidelity design artifacts and their annotations should be considered a source of truth for design implementation, copy, and interaction behavior.
Use comments in Figma to ask questions and share feedback. If a decision or missing information is uncovered in comments in Figma, that context will be added to the design artifact itself as an annotation.
Google doc is a great choice for kicking off async collaboration, proposing RFC, writing a one-pager problem definition, or documenting a decision. To make the context in Google docs more discoverable, we agreed to:
- Public Information - Convert it to a handbook section/page linked from the main IAM team handbook page once
- Information internal to Sourcegraph - Create Google Doc within the IAM Team Google drive or if different location is more appropriate (for example RFCs) create a shortcut to this document within the IAM Team Google drive. If you decide to add a link to an internal Google doc directly in the handbook page, please ensure that sensitive information is not exposed in the link title.
Please refer to our values of open and transparent for more context about the difference between public and internal information.
We are using Loom to record short videos for bug reports, demos, and for multimodal communication. This way, we can provide more context to the rest of the IAM team.
All team members, including product manager, engineering manager, and product designer, have agreed to share regular status updates on the #iam Slack channel. The recommended cadence is either daily or every second day, based on the needs and personal preferences. These updates should be focused on current sprint or quarterly goals, risk and blockers, requests for help, and any personal information you would like to share with your team.
To keep the updates standardized, we are using the following template:
👉 Status update 👈 What is my priority: <content> What went unexpected: <content> Where do I need help: <content>
Each sprint is followed by a short sprint review meeting on Google Meet. During this meeting, we review the state of sprint goals, demo the features we delivered and discuss topics related to the sprint’s scope. We also review the state of our retrospective actions items. This is an open meeting. Our stakeholders and members of other teams at Sourcegraph are always welcome to attend. Each review has a designated facilitator, usually an engineer from the IAM team, responsible for filling in the agenda and facilitating the meeting.
The team is doing retrospectives on a biweekly basis at the end of each sprint. We are using Google Docs to capture feedback and action items.
The action items from the retrospective are migrated to GitHub and usually have an owner assigned responsible for leading the action to its completion. The retrospective actions GitHub issues that require engineering effort are going through team’s regular grooming process and later are part of a sprint scope.
We review the backlog of action items during each sprint review. We discuss the outcomes of the items from this list completed in given sprint and the team makes recommendations about what action items should be added to the next iteration.
Our team tracks paid time off (PTO) using our PTO by Roots and sharing transparently with the team via our #iam-internal slack channel. This transparency ensures that we accurately plan sprints and on-call rotations. We encourage team members to add their PTO to this calendar as early as possible.
We encourage our team to take as much time off to feel refreshed and energized at work, as outlined in our benefits section. Sick days and other urgent PTO does not need to be added to this document.
- Everyone (including engineers, EM, PM, PD) should set up a reliable way to receive pull request review notifications, examples are emails, Slack notifications (through GitHub Scheduled reminders). In some cases, direct pinging required reviewers could inform reviewers about the urgency and may help expedite receiving reviews.
- Pull requests in the draft state indicate work in progress and not ready for review, while occasionally the author may ask for early feedback in explicit forms, examples are direct pings, mentioned on the pull requests.
We use the same OpsGenie schedule for both on-call and support rotation, and use the SlackGenie automation to automatically rotate team member for the
@iam-support Slack handle.
- #iam-internal - internal channel for IAM team for all day to day communication within the team.
- #iam - external channel for IAM team where other Sourcegraphers can ask for help or leave questions for the team.
- #repo-iam-team-internal - a good channel to use whenever we’re unclear on whether something should be owned by Repo Management or IAM.
Playbooks and procedures
This section contains links to IAM specific interview types.
Your onboarding will take up to three months. During this time, you should acquire the necessary domain knowledge and experience that will allow you to succeed in the role of software engineer within your seniority level. This process is a team effort, and your success depends not only on your actions, but also on full support from your team and manager.
We are applying 30/60/90 day patterns and breaking down the onboarding process into three milestones, each with defined themes and outcomes to keep things organized and clarify what you should expect.
The central theme for the first month is learning. During these 30 days, your goal is to acquire the foundational domain knowledge about our product, processes, architecture, and codebase to help you feel comfortable and effective in a software engineer’s role in the IAM team.
You will be exposed to a ton of new information - you will meet many people, read multiple documents, and, most importantly, solve small, well-defined technical challenges. We understand this might feel overwhelming, so please relax and do not stress. This first month is the time for learning and growth.
We will give you more ownership and opportunities to make an impact. While learning will still be the central theme, you can expect more complex problems to solve. You will also get your first project assigned, requiring you to collaborate with other teams, think about planning, execution, risk management, technical design, and other factors.
With the domain knowledge and business context you have acquired so far, it’s an excellent opportunity to start making an impact on the team. We expect your honest feedback about our current processes, tooling, architecture, code base, product goals etc. Please be proactive in sharing your ideas on how we can improve in the spirit of continuous improvement.
Time is running fast, and you learned a lot. You feel productive and autonomous, and your contributions make a real impact on the team. It’s time to provide you with more technical leadership opportunities.
We would like you to take the role of a Directly Responsible Individual (DRI) for a given project. DRIs are empowered and accountable for the success of the initiative they lead. The scope and complexity of the problem will depend on your seniority level. While you likely won’t be the only person working on this project, it’s up to you to make sure it gets done and that you have all resources necessary. Being a DRI might sound challenging and stressful, especially during your first months at Sourcegraph. Don’t worry; your buddy, peers, and team’s triad (Project Manager, Project Designer, and Engineering Manager) are here to help and support you. The goal is to give you the sense of responsibility, ownership, and experience of wearing different hats.
Finally, we would like you to start shadowing your team members during on-call rotation and participate in responding to and resolving production incidents. This experience will prepare you for performing on-call duty once you finish your onboarding process.
Here you can find a list of questions asked by other team members during their onboarding. As a distributed, async-first team, our goal is to provide you with the answers to all these questions in an asynchronous form.
If the answer is not available below, your buddy and the whole team will share their knowledge with you. We highly encourage you to contribute to this list and add tasks to our onboarding improvements to continuously improve the IAM team domain knowledge database and onboarding process.
- How Sourcegraph is designed? - Deep dive into our architecture
- On-premise, managed instances, and the Cloud - What are main differences and similarities? What should I care about from the perspective of the IAM team?
- Life of a commit - How does my code end up in production?
- Decisions/trade-offs we accepted in our development process:
- Why do we have a single repo for all services?
- Why do we have a distributed monolith?
- How does our continuous deployment model work?
- Why we are using GraphQL API?
- Overview of the Cloud infrastructure setup.
- Overview of the frontend/UI layer at Sourcegraph.
- Overview of the GraphQL API layer at Sourcegraph
- I am debugging an issue on production - where can I find logs, metrics, events, and traces?
- What is the difference between login connection and code host connection? How do we authenticate and authorize users on the Cloud?
- Authorization of GraphQL calls - how do we know the call was made by a legitimate user?
- How do we add repositories to Sourcegraph, and how does the repository state management work?
- How do we fetch, sync, and enforce code host repository permissions?
- How does subscription and license management work?
- Database schema overview
- How do we deal with incidents?
- What is our on-call strategy?