Feedback is a gift. We aim to use this document to give ourselves and our teammates consistent and honest feedback and to help us all improve.
We’re part of a unique team filled with smart individuals working hard to change the world. This living document describes how we think about a career development trajectory that is fair, easily understood, transparent, and competitive[1].
understood adj \ˌən-dər-ˈstu̇d\:
transparent adj \tran(t)s-ˈper-ənt\:
competitive adj \kəm-ˈpe-tə-tiv\:
We’ve broken career development down into Skills, Scope, and Experience[2].
How do Skill / Scope levels work?
There are five levels of Skill and Scope. We are all assessed at a single level with two possible modifiers: approaching or exceeding for those who are just stepping into a particular level or completely mastering it, respectively. See “Putting it all together.”
How are levels determined?
The examples listed for each level are meant to be examples of evidence you’re at that level; it’s not an exhaustive list -- there are many other ways to demonstrate a particular level beyond the ones included here.
It’s also expected that you totally and consistently embody the characteristics of a particular level over a significant period of time. For example, accurately estimating a few projects doesn’t necessarily mean you’re seen as “a person who accurately estimates projects” yet.
They’re also intended to be cumulative. If something is mentioned in “Skillful”, it’s expected that you will still have that (or have improved upon it) when you reach “More Skillful.”
What is a reasonable timeframe for achieving these levels?
We hire incredible people with high expectations, then we set our expectations higher. These specific skills reflect those expectations and are tightly aligned with our development principles:
Writes some production-ready code and some code that isn’t quite ready. Learning the ropes of our tech stack as well as our development practices. Starting to transfer the skills they’ve learned independently or in school to a larger, shared environment. Becoming comfortable with communicating project statuses, making estimates, breaking tasks into smaller chunks, and owning small tasks or projects. Fellows and interns will typically start at this level, with the goal of working towards Skillful during their fellowship / internship.
Often writes production-ready code. Code reviews are sometimes perfect, but sometimes require a bit of explaining and effort from reviewers. Is becoming proficient with our tech stack as well as our development practices. Has started getting into the mindset of continuously shipping.
Writes production-ready code every day. Is beginning to master parts of our tech stack while also teaching others. Seeks out and follows best practices and spreads our development culture. Naturally tends to ship, then iterate quickly without needing to be cajoled by others. Communicates well and debates product priorities with a good understanding of our company values. Can accurately estimate their own projects such that others in the organization can depend on them.
Is absolutely, totally dominating the skills and stack necessary to build our product. Teaches others on a daily basis either by direct instruction, blogging, speaking, or setting a strong cultural example. Learns new technologies and techniques for their own sake. Embodies shipping beats perfection by getting significant product improvements to users consistently and within a schedule that can be depended on by the rest of the team.
Guru level of amazingness. Is a leader and contributor in our tech stack’s community. Does and teaches, always. The person who pops into your mind when you think of the most productive and impressive engineers you’ve ever worked with. Able to jump into any new area, no matter how unfamiliar or poorly defined, and quickly turn it into a maintainable and working product, while tackling any problems along the way. Will be rare, even on our amazing team.
These are summaries, as there are a lot of specific skills that will contribute to each employee’s level. It’s not a checklist meant to be exhaustively completed step-by-step by each of us. We don’t grade each skill individually, but we clearly care about all of them as well as any other unlisted forms of being awesome.
“Anybody can fix anything" means you'll have strong influence over the areas and amount of code you own. Unlike Skill, which focuses on the specific strengths and abilities you’ve developed throughout your career, Scope reflects the ways in which you’ve used those skills to improve Khan Academy. It rewards those who have taken large amounts of responsibility for significant portions of our codebase and managed to deliver high quality. We value responsible owners' ability to abstract difficult problems away from the rest of the team.
It is possible for a developer or designer to make it all the way up the Scope charts without ever becoming an official manager. Developers are explicitly not required to become managers in order to increase their Scope.
Skills and scope are tightly interdependent. Taking on a larger scope will generally require improving your skills. But it also requires putting yourself in a position to apply those skills to larger-impact projects. If you’re interested in increasing your scope (and feel ready to do so), work with your manager to help identify opportunities to take on larger responsibilities.
Is beginning to ship fixes and small features, though often needs guidance from experienced teammates and mentors. Becoming comfortable with communicating project statuses, making estimates, breaking tasks into smaller chunks, and owning small tasks or projects. Fellows and interns will typically start at this level, with the goal of working towards Contributor during their fellowship / internship.
Independently ships fixes and features that require days of focus on their own, but often relies on direction from experienced teammates for larger projects and features. Consistently communicates their project statuses and is becoming comfortable with setting estimates and owning larger projects.
Even though we often work together, Owners can handle significant, multiple-months-long features all by themselves. They tackle hairy technical or design problems without blinking while keeping issues abstracted away from the rest of the team. If the patch they just submitted is causing a problem, they’re quick to fix it, add a new unit test, and communicate exactly what went wrong. Others on the team know to go to Owners for help with multiple specific parts of the product.
Architects are the go-to person for at least one major product investment and a significant chunk of the codebase — at other companies their area of focus may be seen as an entire separate product. They are consistently setting vision, leading other developers, training newcomers, managing contributions, and regularly fixing bugs, no matter how trivial or messy. They are able to take an ambiguous idea, full of tangled dependencies and uncertainties, and turn it into a multiple-months-long product investment, seeing it through from start to finish.
Chief architects completely and repeatedly own the design and execution of entire products or systems that may take months or years to build. They lead several other developers, either as a manager or peer. They are the type of person that can be set free with a poorly defined problem, go into a cave with their team, and show up on the other side with a shippable solution. The expectations for becoming a Chief Architect are incredibly high.
Developers acquire skills at radically different rates. We've all known extremely young programmers who can run circles around 20-year veterans, and 20-year veterans who are able to completely sidestep problems that would send young programmers scrambling for weeks. That said, there are bands of experience inside of which the market does tend to compensate differently. For example, companies our size almost always have a single, fixed starting level for new CS graduates, regardless of skill (probably because they can't really identify "skill" until the dev has been working for a while). After someone has been at Khan Academy for over a year, skill matters much more than experience in determining your level.
Experience bands measure (full time software development experience) or (internships with Khan Academy). Coops and internships at other companies don't count. See “Putting it all together.”
Intern / Engineering Fellow
0-1 years
1-5 years
5-10 years
10-15 years
15+ years
Most technical career ladders don’t value educational content like we do.
The Khan Academy exists because Sal dedicated years to producing some of the best educational content available, in any form. We are not just a tech company focused on hiring the best developers -- we are an educational tech company focused on creating incredible experiences for the learner. We highly value contributions from team members with a strong intuitive grasp of our content and how it should be taught, regardless of their professional development experience.
We love when anybody on the team pushes the envelope of our educational content. This can come in the form of creating videos, novel new ways of interacting with exercises, or even taking ownership of our content's alignment with the needs of our teachers.
When assessing Skill and Scope, extra emphasis will be placed on contributions to Khan Academy’s curriculum and content.
Most technical career ladders don’t reward developers for taking the time to evangelize and share their work.
Being open and sharing our work is at the heart of our development philosophy. We work on exciting stuff -- the type of stuff that energizes passionate, smart people and makes them want to help in any way possible. The more you blog about our work, share our progress, and connect with the development community, the more likely we are to attract top talent and become an exemplary dev team.
This type of stuff increases your market value, thus justifying our paying you more money, and when you do them as a representative of Khan Academy, they reflect well on us, establishing our reputation as being the kind of place where the elite celebrity developers work, which, in turn, attracts more great developers.
When assessing Skill and Scope, extra emphasis will be placed on evangelism and the creation of public artifacts.
Senior Engineers and Staff Engineers
To help you relate your Skill and Scope to your career in the broader industry, we have mapped standard job titles to Skill and Scope to help you and others understand where you are in your career.
The title Senior Engineer can be used by anyone who has reached both the “More Skillful” and “Owner” levels. It’s up to you whether you choose to publicly use this title (e.g., blogs, Linkedin, team page, etc.) or not. The primary purpose of the title is to help you understand where you are in your career. Because of where the Senior Engineer title is mapped to Skill and Scope, it’s meant to represent a significant milestone. While we tell people that it's reasonable for this to take 4-5 years to reach to help set expectations, our skills and scope are determined by ability and not experience, and it may take much longer. Above we suggest that “More skillful” and “Owner” each typically require 2 to 4 years of experience to reach. We’re suggesting 4 to 5 years here as not everyone wants to aggressively pursue increasing both skills and scope simultaneously and that’s okay. We're a little different than other companies in that we don't hand out the "senior" title based solely on years of experience; it's mapped directly to skills and scope, and improving those are the way to achieve this title.
A Staff Engineer is anyone who is “exceeding Super Skillful” and “exceeding Area Owner” or an equivalent combination of skill and scope. For example, if your scope were slightly lower (e.g., “Area Owner”) but skill were slightly higher (e.g., “approaching Ludicrously Skillful”) you would still be considered a Staff Engineer.
Engineering Managers
As one’s scope increases it may make sense to transition into an Engineering Manager role.
At KA, the transition into management is not a promotion. This role represents a different and parallel career path. Both management and engineering provide growth and leadership opportunities, but management is a distinct discipline — different than the rest of engineering. Fun, exhausting, rewarding. Managers have their own Skills and Scope doc, and required reading list.
We have great respect for the importance of engineering management but also work hard to not require pursuing management as a career path. There is ample need for skills and scope outside the realm of management — folks should never feel they must become managers to advance.
Skills, Scope, and Experience are combined to find a level which will correspond to our salary structure.
Manager’s review
A manager (or perhaps multiple managers, depending on the employee) will use this document to estimate Skill and Scope. For new hires, this can be particularly tricky; this will be based on our best guess of their Skill and Scope as judged by their previous work (see “Slotting New Employees” below).
Reviews are based on performance since the employee’s last assessment. See “When do reviews happen?” below.
Peer reviews
Employees being reviewed can request specific or anonymous peer reviews from any fellow teammates. For now, this will be done on a bit of an ad-hoc basis, and it is up to the employee to request peer reviews when their evaluation time rolls around. As time goes on and our team grows, we will most likely be increasing the frequency of peer reviews and refining their process.
Managers can also request peer reviews for anybody they’re assessing. This is highly encouraged, and reviewers can always be kept anonymous from reviewee. Managers will take all peer reviews into account before assessing level.
Self reviews
Employees are also encouraged to review themselves in preparation for one of their frequent 1:1 meetings. By sharing your self review with your manager, you can balance out any major discrepancies early instead of waiting for a (possibly surprising) review in October.
When do reviews happen?
Reviews automatically happen once per year (for us, this means October). Reviews may also happen once in the middle of the year (April) for exceptional circumstances or for those who joined at a time that doesn’t jibe with an October review (example: somebody who started late in the summer, didn’t have an October review, and would otherwise be forced to wait well over a year since their start date for next October to roll around).
Slotting new employees
We don’t have the information necessary to properly review somebody when they first join. This means that new employees are “slotted” into their first Skills and Scope assessments based on our best guess, which will take into account their work at previous jobs and projects. This slotting may be done cautiously, because (like Google and Facebook and others when bringing in new hires), we want to value what employees do at KA and let them prove themselves instead of basing compensation on what they’ve done in the past. Once new employees are slotted and have been a part of the team for a few months, experience in past jobs will matter very little, if at all, during reviews — and we’ll use upcoming reviews to adjust any changes that need to be made in slotting.
Will things always work this way?
Note from the future: when we’ve grown a bit larger and have at least 4 or 5 official managers, we will likely not entirely rely on managers to assess their team members’ levels. We may follow Google’s promotion model, as described by Craig here:
“It's not likely to be a problem now, but for larger companies, having the manager assess levels can lead to problems, especially for people whose work is across teams. Their manager may not value their work outside the main project, as much as the company as a whole does. I don't know if that's something we want to protect against now, or not. What we did at Google was have a promotion committee (later, many promotion committees) that would evaluate promotion packets. The packets had a self-evaluation, a manager evaluation, and peer evaluations, and the committee would decide whether promotion was warranted. The process could be used for any kind of leveling; it doesn't have to be promotion.”
Your final level
Your level is defined by a combination of your skills and scope. We also make adjustments for years of experience and industry benchmarks. The exact algorithm may be adjusted in the future, however the evaluation process is applied uniformly across all members of a team.
[1] Proper attribution: we’re following the spirit and in some places the letter of Stack Exchange’s developer model, Google’s system for employee reviews, McKinsey’s evaluation culture, and Fog Creek’s system...but chock full of Khan Academy-specific goodness.
[2] Are you an engineering manager? Know this doc well, but there’s also a forked Skills and Scope section just for you!