Meta Engineer Reaches Staff in Three Years by Overhauling Delegation

Ryan Peterman

Advancing beyond senior engineering requires decoupling raw revenue impact from operational scope, replacing passive trust with accountable delegation and structured verification loops.

AI-assisted summary of New Grad (IC3) to Staff (IC6) at Meta in 3 Years | Simon Kindström — original source. Check the original for full context.

Source published: 2026-10-23

Key ideas

Simon Kindström completed a rapid ascent from IC3 (new grad) to IC6 (Staff Engineer) at Meta in three years, requiring an average of one to three halves per promotion level. (0:00)
Meta performance ratings evaluate raw impact and output, whereas promotions evaluate the behavioral scope and operational maturity of how that impact was achieved. (2:21)
Securing the top-tier 'Redefines Expectations' (RE) rating does not guarantee promotion if an engineer is only delivering individual output rather than leading teams and stewarding broader outcomes. (2:21)
The defining transition from Senior (IC5) to Staff (IC6) centers on scaling through pod leads while embracing the rule that 'delegation is not abdication'—maintaining accountability for outcomes through lightweight verification systems. (10:15)

Detailed notes

## Background Published by Ryan Peterman on YouTube on October 23, 2026, this video highlight features Simon Kindström detailing his trajectory from new grad (IC3) to Staff Engineer (IC6) at Meta in three years. According to the description, Kindström walks through each promotion step-by-step, breaking down the specific performance ratings he earned, the number of halves required at each level, and the behavioral changes needed to scale his impact.

## TL;DR Simon Kindström breaks down how he navigated Meta's leveling system from IC3 to IC6 in three years, explaining the core distinction between performance ratings (what you achieved) and promotions (how you achieved it and your operational scope). His early advancement from IC3 to IC4 capitalized on prior internship familiarity and high-impact revenue projects, while reaching IC5 required stepping up to lead team initiatives, interface with leadership, and take accountability even through project failures. Reaching Staff Engineer (IC6) demanded a crucial mindset shift from individual execution to scalable leadership, learning that delegation requires active verification systems rather than passive abdication while maintaining the technical depth to dive into full-stack integration bottlenecks when necessary.

## Atmosphere & style The conversation carries an analytical, pragmatic, and peer-to-peer tone, feeling less like career hype and more like an insider post-mortem on big-tech performance mechanics. Peterman acts as an astute sounding board who understands Meta's cultural expectations, prompting Kindström to candidly unpack both his standout milestones and his early management missteps. The resulting dynamic is thoughtful, humble, and instruction-heavy, demystifying rapid career velocity by framing it around explicit behavioral changes, accountability, and technical rigor.

## Bulletin - [00:00](https://www.youtube.com/watch?v=qICgdxQe7kA&t=0s) Simon Kindström completed a rapid ascent from IC3 (new grad) to IC6 (Staff Engineer) at Meta in three years, requiring an average of one to three halves per promotion level. - [02:21](https://www.youtube.com/watch?v=qICgdxQe7kA&t=141s) Meta performance ratings evaluate raw impact and output, whereas promotions evaluate the behavioral scope and operational maturity of how that impact was achieved. - [02:21](https://www.youtube.com/watch?v=qICgdxQe7kA&t=141s) Securing the top-tier 'Redefines Expectations' (RE) rating does not guarantee promotion if an engineer is only delivering individual output rather than leading teams and stewarding broader outcomes. - [10:15](https://www.youtube.com/watch?v=qICgdxQe7kA&t=615s) The defining transition from Senior (IC5) to Staff (IC6) centers on scaling through pod leads while embracing the rule that 'delegation is not abdication'—maintaining accountability for outcomes through lightweight verification systems.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=qICgdxQe7kA&t=0s) Transitioning from IC3 to IC4 in a single half requires operating at an IC4 standard on day one due to Meta's trailing performance evaluation model. - [00:00](https://www.youtube.com/watch?v=qICgdxQe7kA&t=0s) Completing a prior internship shaved off four to eight weeks of onboarding ramp-up by bypassing the steep learning curve of internal Meta tools like Phabricator. - [00:00](https://www.youtube.com/watch?v=qICgdxQe7kA&t=0s) Joining a nascent team as its second engineer provided high 1:1 manager access and direct exposure to high-leverage revenue projects. - [00:00](https://www.youtube.com/watch?v=qICgdxQe7kA&t=0s) The primary behavioral distinction between IC3 and IC4 is taking end-to-end ownership of an entire project rather than just executing discrete tasks. - [02:21](https://www.youtube.com/watch?v=qICgdxQe7kA&t=141s) Performance ratings track what was achieved (such as tens of millions in revenue), while promotions assess how results were delivered and the scope of behavioral maturity. - [02:21](https://www.youtube.com/watch?v=qICgdxQe7kA&t=141s) Earning an exceptional 'Redefines Expectations' (RE) rating as an IC4 did not immediately result in an IC5 promotion because the work lacked team-wide stewardship. - [02:21](https://www.youtube.com/watch?v=qICgdxQe7kA&t=141s) The COVID-19 pandemic led to a pause in formal ratings and promotions, substituting qualitative annotations such as 'significantly above' for formal performance marks. - [05:07](https://www.youtube.com/watch?v=qICgdxQe7kA&t=307s) Advancement to IC5 was unlocked by taking operational responsibility for 3–4 engineers and managing an ambiguous product space from conception to execution. - [05:07](https://www.youtube.com/watch?v=qICgdxQe7kA&t=307s) Handling commercial project failure with transparent escalations to senior directors and IC8 Principal Engineers demonstrated the leadership maturity needed for the IC5 level. - [06:36](https://www.youtube.com/watch?v=qICgdxQe7kA&t=396s) Early IC5 execution suffered from a passive trust model, highlighting the need to actively track milestones and hold team members accountable. - [06:36](https://www.youtube.com/watch?v=qICgdxQe7kA&t=396s) Scaling to Staff (IC6) required delegating sprint planning and day-to-day coordination to pod leads across teams totaling up to 13 cross-functional contributors. - [06:36](https://www.youtube.com/watch?v=qICgdxQe7kA&t=396s) Staff-level candidates must maintain deep technical chops alongside high-level strategy, exemplified by debugging across the full stack—from mobile clients to backend C++ infrastructure—to unblock critical launches. - [10:15](https://www.youtube.com/watch?v=qICgdxQe7kA&t=615s) 'Delegation is not abdication' served as the central mindset shift for IC6, meaning leaders retain ultimate accountability for results even when delegating execution. - [10:15](https://www.youtube.com/watch?v=qICgdxQe7kA&t=615s) To prevent project derailment without micromanaging, Staff Engineers rely on structured verification loops, such as regular sprint check-ins, rather than inspecting every pull request.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=qICgdxQe7kA&t=0s) IC3 to IC4: Ramping Up Fast and Crushing Revenue Goals

Ryan Peterman kicks off the conversation by diving into Simon Kindström’s remarkable promo trajectory—advancing three engineering levels in three years, even while navigating the COVID-era promotion freeze. Simon’s very first step, from IC3 (new grad) to IC4, took just a single half and earned him a “Greatly Exceeds Expectations” (GE) rating. Ryan points out that because Meta promotions require trailing performance, an engineer pulling this off essentially needs to perform at an IC4 standard right out of the gate on day one.

Simon attributes this rapid start to several key structural and team advantages. Having completed a prior internship at Meta, he completely bypassed the steep initial learning curve of mastering the company's internal tooling, including Phabricator and the internal task systems. He estimates this shortcut “shaved off at least four to eight weeks of of ramp up.” Furthermore, he joined an early-stage team as its second engineer. This granted him direct access and extensive 1:1 mentorship from his manager, who made sure he secured high-impact projects immediately.

Operating on an ads payments team focused squarely on top-line revenue, Simon tackled projects that generated more than three times the team’s goal for the half. However, while raw revenue drove the GE rating, Meta's lagging promotion philosophy required demonstrating the behavioral hallmarks of an IC4: end-to-end project ownership rather than simply closing discrete individual tasks. As Simon explains:

> “One big difference between IC3 and IC4 is taking ownership of kind of like the completion of a project rather than like smaller tasks.”

- **Time to Promo**: 1 half. - **Rating**: Greatly Exceeds Expectations (GE). - **Tooling Advantage**: Intern experience bypassed custom Meta tooling friction (Phabricator, task tracking). - **Team Dynamic**: Second engineer on a nascent team with high manager facetime. - **Measurable Result**: Delivered projects that brought in >3× the half's revenue goal.

---

[02:21](https://www.youtube.com/watch?v=qICgdxQe7kA&t=141s) IC4 to IC5: The Difference Between Ratings and Promotions

Simon’s promotion from IC4 to IC5 spanned three halves and was marked by an exceptionally rare achievement: landing two “Redefines Expectations” (RE) ratings. Within Meta’s rating scale—Meets All, Exceeds, Greatly Exceeds, and Redefines—RE is the highest possible tier and one that the vast majority of engineers never see in their entire careers. What made Simon's first RE especially unusual was that he earned it during his very first half as an IC4, right after getting promoted. Ryan notes that it was as if Simon had immediately leapfrogged IC4 entirely to do IC5 or IC6 work.

Simon explains that ratings and promotions evaluate two distinct dimensions of performance: ratings measure raw impact, whereas promotions evaluate the behavioral standard and scope of *how* that impact was attained. In that first IC4 half, Simon’s team set a revenue target in the tens of millions of dollars; the projects Simon personally drove overachieved even that ambitious milestone, justifying the RE rating. However, he was still operating primarily on his own projects rather than stewarding other people's outcomes. Explaining why this historic rating did not translate into an instant promotion, Simon observes:

> “There's a difference between promo and ratings where ratings is more so about what you achieved and promos are more so about how you achieved it.”

During the subsequent half, Meta froze formal performance ratings and promotions due to COVID-19. Instead of standard ratings, engineers received qualitative annotations. Simon received a “significantly above” annotation, the functional equivalent of a GE rating.

```mermaid flowchart LR accTitle: Rating vs Promotion Evaluation Criteria at Meta accDescr: Diagram illustrating that performance ratings evaluate impact and output, while promotions evaluate behaviors and operational scope.

subgraph RatingEval["Performance Rating"] A["Impact & Output"] --> B["What you achieved\n(e.g., Millions in revenue)"] end

subgraph PromoEval["Promotion Readiness"] C["Behavior & Scope"] --> D["How you achieved it\n(e.g., Leading & growing others)"] end ```

---

[05:07](https://www.youtube.com/watch?v=qICgdxQe7kA&t=307s) Earning the IC5 Promo by Owning Team Scope and Navigating Failure

By his third half as an IC4, Simon secured his second RE rating along with his promotion to IC5. This advancement came from a fundamental evolution in how he operated. His team shifted focus from backend infrastructure back toward product engineering, taking on a completely uncharted product area. The organization split into two virtual teams, and Simon was handed operational responsibility for one half—consisting of himself and three or four other engineers.

This transition marked Simon’s first time taking a team from an ambiguous, unscoped concept through to project completion. He was no longer just an individual contributor delivering output; he was accountable for the collective delivery of the team and the engineers executing within it. When the product ultimately failed to meet commercial success metrics, Simon’s behavioral maturity stood out. He managed the fallout through transparent escalations to senior directors and IC8 Principal Engineers, earning substantial leadership credit for high-level technical communication and accountability under pressure. Simon summarizes this turning point:

> “This was that big step change in terms like my scope and responsibilities where now I'm no longer responsible for my own output and my own success I'm now responsible for the project success and the people within it.”

- **Half 1 (IC4)**: RE rating driven by tens of millions in revenue overachievement; no promo due to lack of team-level scope. - **Half 2 (IC4)**: COVID-19 half; formal promos and ratings paused; received a "significantly above" evaluation (GE equivalent). - **Half 3 (IC4)**: Second RE rating and promotion to IC5; managed 3–4 engineers end-to-end on a new product space with director-level escalations.

---

[06:36](https://www.youtube.com/watch?v=qICgdxQe7kA&t=396s) IC5 to IC6: Learning to Scale and Bridging the Full Stack

Simon completed the leap from IC5 to IC6 (Staff Engineer) in two halves. Stepping into the IC5 level, he recognized several critical gaps in his execution. While he was nominally responsible for other engineers, he realized he had not yet mastered the mechanics of holding them strictly accountable or tracking project milestones reliably, admitting that he relied heavily on a passive "trust model and just like hoping that everything works out."

To correct this, Simon had to learn how to actively scale himself as his team expanded. He took charge of two pods comprising seven engineers, which later grew to eight dedicated engineers on his team alongside a secondary cross-functional initiative pulling in 13 people. Rather than attempting to micromanage sprint planning and day-to-day coordination himself, he delegated operational ownership:

> “Now, instead I, you know, assign um pod leads that do it for me, right? Or like for for the team, right? where I am involved guiding coaching um but I let others take that uh which is another beautiful thing because now they are growing in return right now they're successful and they can make it towards um whatever goals they have.”

Balancing high-level strategy with the deep technical contributions expected of a Meta Staff promo packet proved to be the defining challenge of his second half as an IC5. While he handled roadmaps, hypotheses, and milestone planning for his pods, a critical payments project was on the brink of missing its launch date. The architecture was an intricate chain spanning Instagram client apps (iOS and Android), Instagram server backends, Meta’s core backend, a C++ payments infrastructure engine, and external third-party payment partners. With the integration completely stalled across organizational boundaries, Simon rolled up his sleeves as Tech Lead, spending intensive hours stepping through code with breakpoints across every tier of the entire stack to diagnose and resolve the bottleneck.

[10:15](https://www.youtube.com/watch?v=qICgdxQe7kA&t=615s) Closing the Gap to Staff: "Delegation is Not Abdication"

Reflecting on his transition to Staff Engineer, Simon Kindström describes the balance required at the IC6 level: demonstrating the ability to span a broad scope across multiple workstreams while retaining the depth needed to jump into the hairiest technical problems when necessary. Ryan Peterman points out the critical vulnerability engineers often face during this jump—being capable of handing off work, but failing to ensure that the work actually succeeds. When asked what single shift closed that gap during the half he made Staff, Simon recalls a core lesson imparted by his manager: “My manager used to say delegation is not abdication.” As Simon explains, “It means that you may delegate whatever you want but in the end you were responsible for the outcome.”

Early on, it was easy to fall into the trap of simply hoping for the best once a task was handed over. As Peterman frames it, “I assumed that this person would get it done and I hoped they would.” To break that habit, Simon internalized true accountability and instituted concrete processes to catch risks before they derailed projects. This included implementing regular touchpoints, such as weekly sprint check-ins, to monitor progress across workstreams. Making the leap from Senior (IC5) to Staff (IC6) forces an engineer to accept that they cannot review every line of code or execute everything themselves. Instead, success hinges on trusting team members to run with their projects while maintaining visibility and verifying outcomes without devolving into micromanagement.

```mermaid flowchart TD accTitle: Delegation Framework at Meta accDescr: Diagram illustrating the shift from passive abdication to responsible delegation with verification.

subgraph Abdication["Abdication (Anti-Pattern)"] A1["Hand off task"] --> A2["Assume and hope for success"] A2 --> A3["Lack of visibility / Missed issues"] end

subgraph Delegation["Accountable Delegation (IC6 Mindset)"] D1["Delegate scope and ownership"] --> D2["Establish verification loops (e.g., weekly sprints)"] D2 --> D3["Trust team while tracking progress"] D3 --> D4["Ensure end-to-end outcome"] end ```

- **Accountability for Outcomes:** At the Staff level, handing off a project does not absolve the lead of responsibility; the delegator remains ultimately accountable for the final delivery. - **Verification Systems:** Instead of micromanaging or reading every pull request, Simon established cadence meetings and lightweight sprint processes to track project velocity and catch blockers early. - **The IC5 to IC6 Shift:** Moving beyond Senior requires moving away from doing everything personally, learning to trust team members to support distinct projects while verifying their trajectory.

## Notable quotes > [02:21](https://www.youtube.com/watch?v=qICgdxQe7kA&t=141s) There's a difference between promo and ratings where ratings is more so about what you achieved and promos are more so about how you achieved it. — Simon Kindström

> [00:00](https://www.youtube.com/watch?v=qICgdxQe7kA&t=0s) One big difference between IC3 and IC4 is taking ownership of kind of like the completion of a project rather than like smaller tasks. — Simon Kindström

## Mentioned Simon Kindström, Ryan Peterman, Meta, Instagram, Phabricator, COVID-19, C++

## Video description Simon Kindström went from new grad (IC3) to Staff Engineer (IC6) at Meta in three years. In this highlight he walks through each promotion: the ratings he got, how many halves each one took, and what had to change in how he worked at every level.

Watch the full conversation: https://www.youtube.com/watch?v=IrkUStdQZkw

[Source](https://www.youtube.com/watch?v=qICgdxQe7kA)

中文简报

重塑委派机制，Meta工程师三年晋升至Staff级别晋升至资深工程师以上职级，需要将纯粹的营收影响与业务运作范围解耦，以负责任的委派和结构化的验证机制取代被动的信任。 Simon Kindström详细拆解了他如何在三年内通关Meta的职级体系，从IC3晋升至IC6。他阐明了绩效评级（你达成了什么）与职级晋升（你是如何达成以及你的业务范围）之间的核心差异。在早期从IC3晋升至IC4期间，他充分利用了此前实习积累的熟悉度以及高影响力的营收项目；而升至IC5则需要主动牵头团队项目、与管理层对接，并在项目遭遇失败时承担起责任。晋升至主任工程师（Staff Engineer，IC6）更是需要完成从个人执行到可扩展领导力的关键心态转变，认识到委派需要积极的验证机制而非被动放任，同时还要保持深厚的技术功底，以便在必要时深入排查全栈集成瓶颈。 Simon Kindström在三年内完成了从Meta的IC3（应届生）到IC6（Staff工程师）的快速晋升，每个职级晋升平均耗时一到三个考核半年度（half）。 (0:00) Meta的绩效评级评估的是纯粹的影响力和产出，而职级晋升评估的则是实现该影响力过程中所展现的行为边界和业务运作成熟度。 (2:21) 如果工程师仅仅是在输出个人成果，而非带领团队并统筹更大范围的成效，那么即便获得顶级的“远超预期”（RE）评级也无法保证获得晋升。 (2:21) 从Senior（IC5）跨越到Staff（IC6）的决定性转变，核心在于通过小组负责人（pod leads）实现规模化扩展，同时恪守“委派不等于放任”的准则——借助轻量级的验证机制对最终结果保持负责。 (10:15)

Reading summary

Simon Kindström's advancement from new grad (IC3) to Staff Engineer (IC6) in three years at Meta demonstrates that while performance ratings evaluate raw commercial impact, promotions depend strictly on expanding operational behavior, scope, and accountability. Accelerating Early Growth Through Structural Advantages (0:00) Kindström's initial promotion from IC3 to IC4 in a single half was aided by structural placement and previous familiarity with Meta's environment. Having completed an internship at the company, he avoided an estimated four to eight weeks of onboarding friction associated with proprietary internal tooling such as Phabricator and Meta's task tracking systems. Joining an early-stage ads payments team as its second engineer also provided direct manager mentorship and immediate access to high-impact projects. While operating on revenue-focused projects allowed Kindström to deliver more than three times his team's half-year goal, earning the "Greatly Exceeds Expectations" (GE) rating and rapid promotion required trailing proof of IC4 behaviors. Specifically, he had to demonstrate complete end-to-end ownership of project completion from day one, rather than merely resolving isolated, discrete tasks. Disconnecting Performance Ratings from Promotion Criteria (2:21) Kindström's progression highlights Meta's institutional distinction between performance ratings and promotions: ratings quantify what an engineer achieved, whereas promotions assess how that impact was delivered and the operational scope demonstrated. During his first half as an IC4, Kindström secured the company's highest rating—"Redefines Expectations" (RE)—by driving projects that exceeded a team target in the tens of millions of dollars. However, this historic rating did not yield an immediate promotion to IC5 because he was still functioning as an individual contributor driving his own output rather than guiding the success of other engineers. Following a subsequent evaluation cycle in which Meta paused formal ratings and promotions due to COVID-19 (where Kindström received a qualitative "significantly above" annotation), he earned a second RE rating and his IC5 promotion in his third half. This advancement was unlocked only after he assumed operational responsibility for a newly formed sub-team of three to four engineers. Leading Through Ambiguity and Managing Setbacks (5:07) Kindström's promotion to IC5 marked a qualitative shift from individual execution to collective responsibility. Leading his sub-team on an uncharted product area, he was tasked with steering an ambiguous concept through to completion. Although the product ultimately failed to meet its commercial success metrics, Kindström earned crucial leadership credit for how he handled the project's trajectory. Rather than obscuring shortfalls, Kindström managed the fallout through proactive, transparent escalations to senior directors and IC8 Principal Engineers. Demonstrating accountability, technical communication, and risk management under pressure satisfied Meta's behavioral expectations for senior engineering scope, establishing that leadership maturity matters more for promotion than unblemished commercial success. Scaling to Staff via Accountable Delegation (6:36) Advancing from IC5 to IC6 in two halves required Kindström to abandon a passive approach of simply trusting and hoping work would finish. As his scope expanded to two pods of eight dedicated engineers and a 13-person cross-functional workstream, he adopted the operating principle that "delegation is not abdication." Recognizing that delegating a task does not relieve the lead of final responsibility, he assigned pod leads to handle day-to-day coordination while establishing lightweight verification mechanisms, such as weekly sprint check-ins, to track velocity and catch risks without micromanaging. Attaining the Staff level also demanded balancing high-level roadmapping with hands-on technical depth. When a multi-tier payments project faced critical launch delays across organizational boundaries, Kindström personally stepped through code across the entire stack—spanning iOS and Android client applications, Instagram servers, Meta backends, a C++ payments engine, and third-party partners—to locate and resolve the integration bottleneck. Kindström’s rapid trajectory illustrates that advancing to Staff Engineer requires evolving from personal high-output coding to accountable leadership, where an engineer scales their impact through delegated execution while retaining the technical depth needed to debug complex systemic failures.

精炼阅读摘要

Meta 软件工程师 Simon Kindström 在接受 Ryan Peterman 访谈时阐述了其在三年内从应届生（IC3）晋升至主任工程师（IC6）的进阶逻辑，核心在于从关注个人代码产出转向承担团队交付责任，并在规模化委派中建立闭环验证机制。绕过上手摩擦并从任务走向端到端闭环 (0:00) 在 IC3（应届生）升至 IC4 阶段，Simon 仅耗费一个绩效半年度（half）并获得“大幅超出预期”（Greatly Exceeds Expectations，GE）评级。Simon 指出，由于此前在 Meta 实习过，他跳过了内部工具链（如代码审查工具 Phabricator 及任务跟踪系统）的学习曲线，为入职争取了四到八周的时间优势。同时，作为新生团队的第二名工程师，他获得了直属主管高密度的 1:1 指导并直接切入广告支付团队的核心增收项目，最终交付成果超出半年度营收目标的 3 倍以上。尽管营收成果支撑了高绩效评级，但在晋升标准上，Meta 依据滞后表现（trailing performance）原则，要求工程师证明自己具备 IC4 的行为特质。Simon 强调，IC3 与 IC4 的本质差异在于工作重心的转移：工程师不能仅停留在关闭孤立的细小开发任务，而必须展现出对整个项目全生命周期交付的端到端所有权（ownership）。绩效评级与职级晋升在维度上的核心解耦 (2:21) 晋升至 IC4 后，Simon 在首个考核期就斩获了极罕见的最高等级“重新定义预期”（Redefines Expectations，RE）评级，但并未立刻获得职级晋升。Simon 对此解释称，绩效评级与职级晋升衡量的是两个不同的维度：评级侧重于“产出结果是什么”（what you achieved），即创造的直接业务影响（例如团队数千万元营收目标的大幅超额兑现）；而晋升考量的则是“如何达成这一结果”（how you achieved it），重点评估工程师展现出的行为范式与业务范围（scope）。由于他当时仍主要聚焦于个人负责的项目，缺乏带领和培育其他工程师的组织范围，因此即便手握顶级评级也无法越级晋升。在随后的 COVID-19 考核冻结期，他获得了相当于 GE 水平的定性评价，进一步印证了在 Meta 的晋升通道中，单纯堆积个人业务增益无法替代组织维度的职责跃迁。在业务不确定性与团队管理中承接范围责任 (5:07) 由 IC4 升至 IC5（高级工程师）的关键转折发生在其第三个半年度。当时团队从后端基础设施转向探索未知的全新产品领域，组织被拆分为两个虚拟团队，Simon 负责带领其中由 3 至 4 名工程师组成的分支。这是他首次带领团队将模糊、未定义的概念推进至落地执行。尽管该产品最终未达到预期的商业化指标，但 Simon 在面对交付挫折时展现出了高级工程师的行为成熟度：他主动且透明地向资深总监（Directors）和 IC8 首席工程师（Principal Engineers）进行汇报与升级沟通，承担整体交付责任。Simon 指出，这一阶段代表了职责范畴的阶跃式转变——工程师不再仅对自己个人的输出与成功负责，而必须对整个项目的成败以及团队内部成员的交付结果共同担责，这种在压力下的沟通与统筹能力直接推动其晋升至 IC5。主任工程师的杠杆效应与全栈深度下沉 (6:36) 在从 IC5 迈向 IC6（主任工程师/Staff Engineer）的过程中，团队规模逐步扩大至 8 名专属工程师及 13 人的跨职能协同项目。Simon 认识到此前仅依赖被动信任和侥幸心理的管理漏洞，转而通过培养 Pod Leads（小组负责人）进行层级化授权，由其主导日常 Sprint 规划和团队协调，自己则退居至业务指导和路线图规划层面，同时为下属创造晋升空间。然而，IC6 的评定不仅要求管理杠杆，还要求展示深厚的技术攻坚深度。在一次涉及 Instagram 移动客户端（iOS/Android）、Instagram 后端、Meta 核心服务、C++ 支付底层引擎及第三方外部支付机构的多团队关键支付项目中，交付进度严重滞后。Simon 介入并下沉至最基层代码，耗费大量时间跨全栈多个技术层级逐行设置断点排查并消除系统瓶颈，展现了宏观战略把控与跨系统复杂技术排错的双重能力。区分责任授权与放任弃管的闭环控制 (10:15) Simon 与 Ryan Peterman 在探讨冲刺 Staff 职级时强调，“授权不等于弃管”（delegation is not abdication），这是跨越 IC5 至 IC6 门槛的核心认知转变。Peterman 提到，工程师在晋升过程中常出现“将任务交出后便单方面默认并寄希望于对方能够完成”的认知误区。Simon 借由主管的经验阐明：委派具体工作绝不免除负责人对最终结果的底线责任。由于 IC6 无法也不应逐行审查所有代码或亲力亲为，为避免陷入微观管理或放任自流的两极，必须建立起制度化的验证闭环。Simon 通过推行周度 Sprint 检查机制等轻量化流程追踪各工作流动态，在保障团队成员自主发挥空间的同时，提前捕捉潜在阻碍并确保整体成果如期交付。 Simon 的职业轨迹展示了大型科技公司在资深职级晋升上对“可度量业务结果”与“组织行为范围”的双重硬性要求。然而该案例高度依存于特定的结构性催化剂，包括早期作为初始成员获得的业务敞口与主管辅导密度，其模式在缺乏类似高增长业务或导师支持的环境中是否具备普适性仍留有疑问。

Source quotes

[2:21] Simon Kindström: There's a difference between promo and ratings where ratings is more so about what you achieved and promos are more so about how you achieved it. [0:00] Simon Kindström: One big difference between IC3 and IC4 is taking ownership of kind of like the completion of a project rather than like smaller tasks.

Original transcript

[0:00] Let's talk about the the promos. So, [0:03] three promos in three years and this was [0:05] including the promo block with co that [0:08] we can talk about in a bit. You know, [0:10] let's be super transparent about all the [0:12] ratings and everything if you're [0:13] willing. The first promo from 3 to four [0:16] that was in 1/2 and that was a GE [0:18] rating, right? [0:19] >> Correct. [0:20] >> Yeah. I see. I mean for that to happen [0:22] you basically needed to start [0:24] immediately as an IC4 because you need [0:27] at least six months of trailing [0:29] performance before you can get promoted. [0:31] How did you start as an IC4 on that [0:34] team? I do think there are a couple [0:37] important factors to it, right? One is I [0:40] was a previous intern at Meta, which [0:42] meant that I didn't have to go through [0:44] the ramp up of learning the tools, [0:47] right? And I often see that that is one [0:48] of the biggest hurdles as people join a [0:50] big company like Meta where everything's [0:53] custom. I'd kind of like already learned [0:55] how to use Fabricator, the internal task [0:57] tool, etc. So, I probably shaved off at [1:00] least four to eight weeks of of ramp up. [1:03] One thing that really set me up for [1:04] success is that I actually ended up [1:05] joining um a very new team, right? So I [1:08] was the second engineer which did mean [1:09] that I did get a lot of one-on-one time [1:11] with our manager, right? So he helped me [1:14] a lot throughout that, right? To ensure [1:17] that, you know, I got that early [1:18] momentum and had impactful projects, [1:20] etc. I would say the the rating um was [1:23] actually primarily due to my impact, [1:26] right? So we were an ads payments team [1:30] that was focusing primarily on revenue, [1:32] right, as our goal. I was just a second [1:33] engineer. We didn't have a lot of [1:34] engineers, right? And the projects that [1:37] I worked on, right, these were the ones [1:39] that brought in more than three times of [1:41] our half goal. And one important thing [1:43] to note about promos at Meta is that [1:45] they're lagging, right? So you really do [1:46] need to show that um the behaviors of [1:50] the next level. One big difference [1:52] between IC3 and IC4 is taking ownership [1:55] of kind of like the completion of a [1:57] project rather than like smaller tasks. [1:59] And if something didn't go right and [2:02] like the results weren't there, then you [2:05] know taking ownership of figuring out [2:07] why it didn't go well and you know [2:09] obviously I'm new. I'm I'm seeking a lot [2:12] of assistance from others, but the [2:14] willingness and the kind of pushing that [2:16] forward um is the behavior that likely [2:18] got me to IC4. When it comes to IC4 to [2:22] IC5, this was interesting because this [2:25] took three halves, but there was the co [2:27] half which may or may not have blocked [2:29] the promo and you had two RE ratings [2:32] which most people would never achieve [2:36] that rating in their career even once. [2:38] It's a very rare rating. And RE stands [2:40] for redefineses expectations which for [2:43] reference there's there's meets all [2:45] which is great. There's exceeds even [2:48] better. There's greatly exceeding [2:50] expectations, which is pretty much the [2:52] upper bound of doing well, and then [2:54] there's redefined. Um, so the first half [2:56] you got re rating as a IC4. Not only is [3:00] that impressive because it's RE rating, [3:01] but you had just gotten promoted. So [3:03] it's almost like you [3:05] >> you leapfrogged IC4 almost. You were, [3:08] you know, doing like IC5, IC6 stuff [3:10] maybe immediately. What drove that RE [3:14] rating, that first one? [3:15] >> There's one primary thing that drove it. [3:18] uh which is impact right [3:20] >> of course [3:21] >> ratings overall especially at early [3:23] levels is primarily about how much [3:25] impact you can achieve. Yeah. Right. So [3:27] uh our second half in the team we've [3:29] actually recruited a few people which [3:30] was a big part of uh recruiting them and [3:32] onboarding them which is part of the [3:34] rating. But our second half we had a [3:36] goal of let's just say many many dozens [3:39] of millions of dollars um that we had to [3:42] increase the revenue metaphor right the [3:44] projects I drove and worked on um [3:48] overachieved even that half goal that [3:51] had a very heavy lean as to why the [3:55] redefineses. [3:56] >> So you mentioned no promo. How's that [3:59] possible? You get the absolute highest [4:00] rating that almost no one gets that you [4:03] don't get promoted. Why is that? There's [4:05] a difference between promo and ratings [4:07] where ratings is more so about what you [4:11] achieved and promos are more so about [4:14] how you achieved it. As a four, right, [4:17] the expectation is that you can drive [4:18] your project forward, right? That that's [4:20] kind of it. But as a five, you need to [4:22] take more ownership of other people. And [4:25] I was starting to to touch on that a [4:27] little bit, right? In terms of like [4:28] onboarding others, [4:30] >> but I wasn't responsible for their [4:31] success or the success of their [4:32] projects. my behaviors didn't align with [4:35] those V IC5 uh because I didn't take [4:38] that larger um responsibility and scope. [4:42] >> I see. So then and then in the next half [4:44] uh that was the COVID half, right? [4:46] >> Correct. Yeah. So during that half, [4:48] right, there was kind of like a star, I [4:50] guess you could get like a annotation in [4:53] your uh performance review, right? That [4:55] said like the first half of of COVID you [4:58] were significantly above, which is [5:00] practically equating to a GE rating, [5:02] right? uh because we didn't do any [5:04] official ratings. We didn't do any [5:06] promos that half. [5:07] >> So I got the re um my third half um or [5:11] third half is IC4 plus the IC4 to IC5 [5:14] promo, [5:15] >> right? [5:15] >> Um and I think the important thing here [5:17] is that my behaviors actually started to [5:19] change. Um so the team like I mentioned [5:21] at the start, we were kind of pivoting [5:22] between different responsibilities, [5:24] right? And now we've switched from being [5:27] um a bit more of an infra team back onto [5:29] product. uh and we took on a new product [5:31] space, right? We ended up um splitting [5:34] the team into two two virtual teams or [5:36] two teams and we and I took [5:39] responsibility of one half of it, right? [5:41] So for four people plus me or three [5:45] people plus me um I was now responsible [5:47] for going from idea completely unscoped [5:51] space to completed projects and that was [5:55] a first for me. uh that required a lot [5:57] of growth in terms of like how I [5:58] operated but this was that big step [6:01] change in terms like my scope and [6:04] responsibilities where now I'm no longer [6:06] responsible for my own output and my own [6:08] success I'm now responsible for the [6:10] project success and the people within it [6:12] >> right [6:13] >> right [6:14] >> um and in the end the product wasn't [6:16] actually as successful but we dealt with [6:20] it really well in terms of like how we [6:21] behaved [6:22] >> um we ended up having a bunch of [6:24] leadership escalations up to director [6:26] level, you know, um with um IC8s and [6:30] stuff, you know, me being an IC4 at the [6:32] time, um I was getting a lot of credit [6:34] for that, um communication. [6:36] >> And then the last thing is, you know, [6:37] growing from five to six. You did that [6:41] very quickly. Two halves. [6:43] >> So, it took me two halves. Um and if we [6:47] look at just like some of the behavior [6:50] issues that I had kind of like um as got [6:54] promoted to five and kind of like [6:55] looking forward as like what was missing [6:57] for for six right is that like [6:59] >> while I was responsible for others um I [7:03] had like fully gro that right I wasn't [7:06] very good at like [7:08] >> holding them accountable in return right [7:11] to ensure that like things are on track [7:13] and like I wasn't very good at just [7:15] tracking things, knowing where things [7:17] were, etc., right? So, [7:19] >> I was still operating a lot on like a a [7:21] trust model and just like hoping that [7:22] everything works out. Um, so that was a [7:24] big gap in general. Given more [7:26] responsibility, I'm now leading um two [7:28] pods uh with seven people uh in total. [7:32] So, the the scope is increasing for me [7:33] as a result. Um, which means that I need [7:36] to learn how to scale myself, which is [7:38] another important skill set to learn as [7:41] you're growing from being responsible [7:42] for a small amount of people to a large [7:44] amount of people. Um, you know, maybe as [7:46] we're doing sprint planning now. [7:47] Previously, I did it. [7:49] >> Now, instead I, you know, assign um pod [7:53] leads that do it for me, right? Or like [7:56] for for the team, right? where I am [7:59] involved guiding coaching um but I let [8:02] others take that uh which is another [8:05] beautiful thing because now they are [8:06] growing in return right now they're [8:07] successful and they can make it towards [8:10] um whatever goals they have we the two [8:13] pods I had before right about seven [8:14] people we had recruited some more we [8:16] ended up splitting the team officially [8:17] into two parts right so I now was [8:20] responsible for one part of the team [8:21] which was eight people right so [8:23] responsible for ensuring that you know [8:24] they hit their goals um and we did we [8:26] exceeded those goals [8:28] U but at the same time we spun up a [8:30] separate project uh which ended up [8:32] including um 13 people. So I was kind of [8:34] like tailing both of these at the same [8:37] time. So that really stress tested my [8:39] ability to to scale myself, [8:40] >> right? [8:41] >> Specifically in that five to six [8:43] journey, right? Like it's the scaling [8:45] yourself. But something that is often [8:48] discussed during kind of like someone [8:51] preparing their promo packet for five to [8:52] six is like what's the deep technical [8:56] contribution right [8:58] >> during my second half here I think I was [9:00] able to balance these two quite well [9:03] right where the high level stuff of like [9:05] setting the road map of uh this project [9:08] right ensuring that like we have we have [9:09] clear milestones um same thing with the [9:13] with the other team where you know we [9:14] have uh we have set the goal goals. We [9:17] have um hypotheses for how we might hit [9:20] those goals um and then coaching the [9:22] people to move in that direction. On the [9:24] big project that we had um we were [9:27] getting really close to the um the [9:30] milestone, but we were really struggling [9:32] to kind of like get it over the that [9:35] line, right? Mhm. [9:36] >> It was it was a payments product um that [9:38] crossed between IG to Meta's main [9:41] backend stack onto the um payments back [9:45] end which is in C++ um onto a third [9:48] party payments partner right [9:50] >> and we just couldn't make it all happen [9:53] right so [9:54] >> I went in as a TL I spent many many [9:57] hours just like digging deep into the [9:59] code which meant that I had to go from [10:01] the Android iOS code onto the um ID IG [10:06] servers back end onto the the meta main [10:10] back end onto C++ and had like break [10:12] points all over these code bases, right? [10:15] Would just show that like I was able to [10:17] work at a very wide span but also just [10:19] like very detailed um and and go deep [10:23] and solve the the hairiest problems that [10:24] we had. [10:25] >> You were able to hand off things but [10:27] maybe not assure their their success. [10:29] What was the the the one thing that you [10:32] switched in that half where you that [10:33] really made the big difference and [10:35] closed that gap? [10:36] >> My manager uh used to say delegation is [10:39] not abdication. It means that you may [10:42] delegate whatever you want but in the [10:44] end you were responsible for the [10:45] outcome. [10:46] >> I assumed that this person would get it [10:48] done and I I hoped they would. [10:50] >> Right? But as I grew, I internalized [10:55] this more and I also set up processes [10:57] that helped me catch these issues. [10:59] Whether it's like a weekly um me um [11:03] sprint meeting or something where like [11:04] you catch up with people and see like oh [11:06] are they progressing, you can no longer [11:08] achieve everything yourself even more so [11:10] five to six where like now you need to [11:13] >> uh you might not even be able to review [11:14] all the code anymore, right? You need to [11:17] trust that the other people in your team [11:19] can support the different projects, [11:22] >> but you still verify through them. Just [11:24] maybe not micromanage. [11:26] >> Exactly.