| cover | coverY |
|---|---|
0 |
- You are doing the responsibilities of areas where you are Primary or Secondary owner (see cal.com/open).
- Staying on top of the errors occurring in your areas. You need to make sure your alerts and notifications are properly configured so you immediately know when critical errors happen. It's a bad sign if a customer alerts a severe problem before we know about it. These errors should be addressed quickly and you should coordinate with the team to get them shipped efficiently.
- You are shaping the technical backlog for your areas. You need to maintain a list of improvements, refactors and fixes that should happen in your areas. Working collectively with Head of Product and Head of Engineering, you ensure these items are properly slotted in when appropriate.
- Typically this best happens when feature work happens or bugs are fixed in the same area where technical changes are needed.
- If you are a lower IC level and feel less comfortable in this area, please reach out to senior engineers for guidance.
- You are active in Threads.
- We thrive on async work but we have folks located in different time zones across the world. A long delay in responding to your teammate could result in them not seeing the message until the next day, resulting in lots of slow back and forth communication.
- For threads you are mentioned directly in, you should actively follow up and give insights where needed. Once initially mentioned, people should not have to feel like they are chasing you down to get a response.
- You are consistently posting your weekly stand-up in Threads on Monday.
- We intentionally don't have daily stand-ups to avoid lots of meetings but we all need to be aware of what each other is working on so work can properly be prioritized and planned. Not posting your weekly stand-up hinders the team's ability to working efficiently in an async manner.
- You write code that is tested.
- You should not be introducing code that isn't backed by some level of automated tests. It's risky and prevents us from building stable systems. If you need assistance getting new code under tests, reach out to more senior engineers for help.
- A common misconception with IC levels here is that people expect that they should aim to move up to the highest band because then that means they're the best. This is not correct as IC bands are based on responsibilities in the team. Higher IC bands usually consist of more management-related responsibilities and high-level engineering tasks, whereas lower levels focus more on building new features, fixing bugs and doing PR reviews.
- As a result of this, we encourage you to look at what each IC band means and consider whether you would prefer a role where you can focus on getting code written, or if you want to move up to higher levels, where you'll then be expected to lead others on the team, research, design systems, document and more.
- IC levels do not determine the complexity of code that you work on. Although higher IC levels tend to focus on the more foundational code, lower IC levels have an equal opportunity to work on core or complex parts of the code, but there is less of a responsibility to design, document and evolve it.
{% content-ref url="ic1-engineer-code-cadet.md" %} ic1-engineer-code-cadet.md {% endcontent-ref %}
{% content-ref url="ic2-engineer-code-craftsperson.md" %} ic2-engineer-code-craftsperson.md {% endcontent-ref %}
{% content-ref url="ic3-engineer-code-connoisseur.md" %} ic3-engineer-code-connoisseur.md {% endcontent-ref %}
{% content-ref url="ic4-engineer-code-wizard.md" %} ic4-engineer-code-wizard.md {% endcontent-ref %}