A guide for Sourcegraph engineers

What’s a Tech Lead?

Tech lead (TL) is a role a Sourcegraph engineer can fulfill on a Product Planning Project. So what does that mean?

The TL of a project is the Directly Responsible Individual (DRI) and as such owns the engineering success.

Here is a subset of the things a TL does:

• Engineering vision: set the engineering vision & scope of the project.
• Plan: define a plan for how to deliver the project, ensuring that the correct tradeoffs are made in terms of scope, resources, delivery time.
• Ship: this might be the most important tasks of a TL: they make sure the code gets merged, is feature-flagged, goes into a release, lands in the hands of customers, turns into feedback, and then takes care of post-release feedback/bugs/praise.
• Communication: communicate progress of the project to stakeholders, EMs, VP of Engineering as much as needed and as clearly as possible.
• Feedback: get feedback and input from Product and Design as much as needed for the project and as early as possible.
• Lead by example: set a high standard for quality and work ethic. Help other engineers on the team to do their work by planning & scoping their work, reviewing their contributions, suggesting improvements, and holding them accountable.
• Track: Keep track of the progress and team members’ work.

But: how exactly a TL does these things depends on the project, the team, and the TL.

Here are some ideas and guidelines for how to do these things as a TL at Sourcegraph.

Set the engineering vision

Anything goes here, really. You can write a Google Doc, a tracking issue, an RFC, or a normal GitHub issue.

What’s important is that you have something you can share with your team members, your EM, Product, Design, and other stakeholders to communicate

1. What are the goals and the customer impact of this project (“build an admin dashboard to show all foo widgets to help expansion at strategic customers”)
2. What is the timeline (“~8 weeks of work for 2 engineers”)
3. Who is involved - who are the team members, what are the dependencies on Design? a. 💡TIP: Try to avoid cross-projects dependencies. They have a high cost, and are always harder to keep track of than inside a small group of teammates sharing all the context. See if you can implement the part that depends on another project internally instead.