AB
1
Distinguished Engineer Program at Cedar
2
How to read this documentEach level builds on the competencies from the previous level (within it's track) - a L5 EM2 builds on the competencies of a L4 EM1, not a L4 IC

An EM1 assumes L4 engineer competencies or higher, although after starting on the EM track, technical ability is not expected to grow so they may get rustier as we go up EM ladder.

EMs and ICs can exist at the same Cedar level. Going from an L4 IC to an L4 EM1 is a role change not a promotion, although they may share some expectations.

At the highest level, ICs are expected to deliver high quality code in a timely fashion to deliver business value. EMs are expected to ensure the outcome their teams commit to while also ensuring their teams' happiness and growth.

All members of Engineering (ICs, Managers & supporting staff) are expected to share, uphold and exemplify our engineering values and company values

The competencies and expectations for a given level are the minimum expectations for an individual at that level. Progress from one level to the next can be interpolated in each area of competencies between their current and next level. This means there is room for growth within levels as well as between levels.
3
GlossaryTask complexity: In terms of story size XS - XXL

Trusted reviewer: an expert consultant, someone who can handle code reviews or moderate changes to a system

Code owner: advise on/plan out major changes to a system, talk about future direction for a system, both from a technical and product standpoint.

PR Feedback examples:
Minor - small readability suggestions, maybe asking for an additional test.
Moderate - might call out missed edge cases, change a bit about the structure/design patterns.
Large: might be about the overall approach.
4
WhyWe want to acknowledge people’s contributions by giving them appropriate titles

Roles help to define decision making and mentorship goals

Roles clarify expectations and responsibilities, both internally and to the outside world

We want to be fair and objective across the team
5
What this is not! Title is not an attempt to put you or your skills, responsibilities, or growth in a box. That is impossible.

Years of experience is not a hard rule, more a benchmark for how long it takes a median engineer to get to certain levels

Roles are not one size fits all. Each employee will have an individual development plan.

Ultra precision here is not feasible or desirable.
6
Individual Dev Plans Framework to enable conversation, not constrain it (Individuals may have primary and secondary role e.g. TL responsibilities, skillsets across roles, or desire to try other career paths e.g. product)

Individual dev plans will be constructed with your manager and you talking, customized to you, with primary role from framework in mind but with potential flex into other roles as part of growth

Any significant changes in primary role need review for calibration across teams

Dev plans should start with a broad exploration of an employee's goals, and afterward, bring in the DEP to align those goals to Cedar expectations. See our Dev Plan template for mode details guidance.
7
Performance Reviews Semiannual reviews: April (vertical) and October (360) will address and ask you to relfect on your growth within this framework.

This framework is not prescriptive - it neither guarantees nor bars promotions - but rather functions as a guide to growth and development within the Engineering organization

Promotions happen once an individual can demonstrate consistent performance at that level through impact at Cedar. This framework is not a checklist so although they do not need to achieve every single criteria listed, they must meet the scope and impact criterias in some clear fashion. If you meet all the competencies and expectations of a role, you will generally qualify for a promotion, and if not, your manager will have a clear explanation for you (i.e. there is a specific deficiency to address before promotion can be granted)