This resource is useful for everyone in engineering at Sourcegraph.
Related
How to be a Tech Lead
[Managing high-performing engineering teams at Sourcegraph](https://sourcegraph.notion.site/Managing-high-performing-engineering-teams-at-Sourcegraph-107a8e112658805095cdd48e4a83a570)
Our aspiration
The following is an idealized archetype of a successful engineer at Sourcegraph. Its purpose is to give you something to strive towards—regardless of your current level.
The most successful engineers check a lot of the boxes most of the time. Nobody checks all boxes all the time and how exactly these items play out may vary by level.
As a successful engineer at Sourcegraph you…
-
Show agency and intuition/taste
- You show agency. You take initiative and proactively try to make things happen. You have the relentlessness and resourcefulness to make sure you will succeed. You make success inevitable.
- You have good intuition (sometimes called taste). You have and invest in growing a sense for what will and won’t work well. Intuition is important both “in the large” (picking important problems) and “in the small” (picking approaches to solving those problems that will work well).
Related: Impact, agency, and taste
-
Are a great programmer
- You can write code in the languages you work with as well as the best in the world.
- You know your tools enough to use them to maximum efficiency. You embrace new tools that make you better.
- You know what you don't know.
-
Continuously improve things
- You leave codebases in a better state than they found them.
- You improve processes.
- You ask “do we still need this?” — about code, features, products, processes.
-
Unblock yourself
- You debug and try alternative approaches.
- You ask for help.
- You know how to continue working while waiting for an answer.
- You are skeptical of red tape and find the simplest ways to get things done.
-
Get better on your own
- You look for ways to get better and improve.
- You embrace advice and feedback from others.
-
Ship value to customers; you don’t write code for code’s sake
- You know that delivering value to the customers what counts.
- You see Engineering as a business function, not an isolated function.
- You understand customer needs and feel the need on your own. (When both are true, work is more productive and more fun!)
-
Communicate effectively
- You know how and when to use different communication channels: Slack, RFCs, issues, code reviews, GitHub comments, commit messages, pull requests, Zoom calls, etc.
- You know that communication counts a lot, especially in an async team. Sometimes, communication is the most important part of the work.
-
Share you work regularly
- You know that sharing progress is not boasting. It’s keeps others in the loop and shares knowledge: “I remember when $name shared how they did $project, maybe we can take this approach”
-
Have a sense of urgency
- You know that we have to move fast. When someone says “next week” you ask “why not tomorrow?”
- You know that urgency is not about hacks. It’s about finding the quickest solutions with the right tradeoffs. You don't build out a full system when a prototype is sufficient… and you don't bring a half-baked solution for a security problem.
-
Are not a solo player
- You know that working together over time is one of the best ways to continuously ship value to customers.
- You know that a team is more than a collection of individuals that share a ticket board. You do your best to work better together.
- You value other functions and know that input from Product, Design, Security, CE, TS and other departments will improve your work.
-
Care about the whole software lifecycle
- You care about software from end to end. It’s more than just implementation. It’s planning, coding, demoing, docs, announcements, getting it to customers, helping customers, and improving software over time.
- You think actively about the consequences of your choices: is this a breaking change? Does this need to be backwards-compatible? Do we need a slow rollout here? How do we test this at scale – can we test this at scale? When and how do we need to loop in the Security team? How do we enable CE? What do we/CE/TS/customers do if it breaks?
Related: Our values