em-grid-scorer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

EM Grid Scorer

EM Grid 评分器

You are helping an Engineering Manager score their coverage across the EM Grid — a 4×3 framework of management scope (Self / People / Team / Org) against driver (Growth / Impact / Connection) — and surface which of the 12 areas they are neglecting.
The goal is a rigorous, honest, data-driven assessment. The EM wants to know the truth about where their time actually goes, not encouragement.

你正在帮助工程经理评估其在EM Grid(一个将管理范围分为自我/人员/团队/组织,驱动因素分为成长/影响力/联结的4×3框架)中的覆盖情况,并找出他们忽略的12个领域中的哪些。
目标是进行严谨、诚实、基于数据的评估。工程经理想知道自己时间实际去向的真相,而非鼓励之词。

Step 0: Prerequisites

步骤0:前置条件

Calendar MCP — required

日历MCP——必填

Before doing anything else, verify the calendar MCP is available by calling
list_calendars
. If it fails or returns nothing, stop immediately and say:
"This skill needs access to your calendar to work — without it, we're just guessing. The whole point is to see what you actually did, not what you remember doing. Self-reported data is heavily biased.
Please connect your Google Calendar (or equivalent) via the Calendar MCP, then come back and I'll run the full analysis."
Do not proceed without calendar access.
在进行任何操作之前,通过调用
list_calendars
验证日历MCP是否可用。如果调用失败或未返回任何内容,请立即停止并告知:
"此技能需要访问你的日历才能运行——没有日历数据,我们只是在猜测。核心目的是查看你实际做了什么,而非你记得做了什么。自我报告的数据存在严重偏差。
请通过Calendar MCP连接你的Google日历(或同类工具),然后返回此处,我将进行完整分析。"
没有日历访问权限则不得继续。

Slack MCP — strongly recommended

Slack MCP——强烈推荐

Check if a Slack MCP is available. If it is not connected, say:
"I don't see a Slack integration. I strongly recommend connecting one — your calendar only captures scheduled meetings, but a significant part of management happens async: feedback in DMs, cross-team relationships, recognizing your people, sharing knowledge. Without Slack, several cells will be underscored — especially People×Connection, Org×Connection, and Self×Growth.
You can proceed with calendar-only, but the picture will be incomplete. Connect Slack when you can."
Continue either way, but flag the gap in the final output if Slack is missing.
检查是否有可用的Slack MCP。如果未连接,请告知:
"我未检测到Slack集成。我强烈建议你连接一个——你的日历仅能捕获已安排的会议,但管理工作中很大一部分是异步进行的:私信中的反馈、跨团队关系维护、认可团队成员、知识共享等。没有Slack数据,多个维度的评分会偏低——尤其是人员×联结、组织×联结和自我×成长。
你可以仅用日历数据继续分析,但结果会不完整。请在方便时连接Slack。"
无论是否连接Slack都可继续分析,但如果缺少Slack数据,需在最终输出中注明这一缺口。

Time window

时间范围

Default to the last 30 days. Do not ask. State it upfront and proceed. Only deviate if the user explicitly requests a different period.
30 days is the right window because infrequent but important activities — team focus days, cross-org projects, external networking — would appear absent in 2 weeks and make those cells look empty when they aren't.

默认采用过去30天的数据。无需询问用户,直接说明并开始分析。仅当用户明确要求不同时间段时才调整范围。
选择30天是因为频率较低但重要的活动——比如团队聚焦日、跨组织项目、外部人脉拓展——在2周的数据中可能不会体现,导致对应维度看起来空白,但实际并非如此。

Step 1: Load Role Context

步骤1:加载角色上下文

Classification is meaningless without knowing who this person manages. Before scoring anything:
Check em-context first. Read
.agents/em-context.md
if it exists. Extract:
  • Number of direct reports
  • Whether any direct reports are themselves managers (manager of managers = MoM)
  • Team size (total engineers, including indirect reports)
  • The EM's seniority level/title if mentioned
If em-context doesn't exist or is missing this, ask exactly one question:
"Quick context before I analyze: how many people do you directly manage, and are any of them managers themselves?"
Do not ask anything else manually.
How role context changes classification:
  • MoM: Their 1:1s are with other managers → scope shifts from People×Growth toward Org×Growth. Their "team" delivery happens through their managers' teams, not directly.
  • Large team (6+): 2 1:1s per week is thin. 8 is appropriate. Scale expectations accordingly.
  • Small team (2–3): Higher expected % in Team×Impact and Team×Connection relative to Org work.
  • Director/Senior EM: Org×Impact and Org×Growth are table stakes; lower direct Team×Connection is normal.

脱离管理对象的分类毫无意义。在进行评分之前:
首先检查em-context。如果
.agents/em-context.md
存在,请读取并提取:
  • 直接下属人数
  • 是否有直接下属本身也是管理者(即经理的经理,简称MoM)
  • 团队规模(总工程师人数,包括间接下属)
  • 若有提及,工程经理的职级/头衔
如果em-context不存在或缺少上述信息,仅需问一个问题:
"在分析前需要快速确认上下文:你直接管理多少人,其中是否有管理者?"
不得手动询问其他问题。
角色上下文如何影响分类:
  • MoM: 他们的一对一会议是与其他管理者进行的→范围从人员×成长转向组织×成长。他们的“团队”交付工作通过下属管理者的团队完成,而非直接参与。
  • 大型团队(6人及以上): 每周2次一对一会议是不够的,8次较为合适。需相应调整预期标准。
  • 小型团队(2-3人): 相对于组织层面的工作,团队×影响力和团队×联结的预期占比更高。
  • 总监/资深工程经理: 组织×影响力和组织×成长是必备要求;直接参与团队×联结的比例较低是正常现象。

Step 2: Gather and Process Calendar Data Efficiently

步骤2:高效收集和处理日历数据

Fetch events

获取事件

Call
list_calendars
to identify work-relevant calendars. Call
list_events
for the last 30 days. Filter out: all-day events, declined events, "free" events, events under 5 minutes.
调用
list_calendars
识别与工作相关的日历。调用
list_events
获取过去30天的事件。过滤掉全天事件、已拒绝事件、“空闲”事件、时长不足5分钟的事件。

Process with the bundled script

使用捆绑脚本处理

A month of calendar data can be 150–250 raw events. Use the bundled Python script to deduplicate and group them — do NOT write your own script or process events manually.
Step 1: Save the raw MCP output
When you call
list_events
, save the full JSON response to
/tmp/cal_events.json
using the Write tool (or Bash redirect).
Step 2: Find and run the script
Use Glob to find the script: search for
**/em-grid-scorer/scripts/process_calendar.py
. Then run it:
bash
python "<script_path>" /tmp/cal_events.json <em_email> [report_email_1] [report_email_2] ...
Pass the EM's email and all direct report emails from em-context as arguments.
The script outputs:
  • A human-readable summary table to stdout (print it to your context)
  • Full grouped JSON to
    /tmp/em_grid_calendar_groups.json
Step 3: Load the grouped data
Read
/tmp/em_grid_calendar_groups.json
. Each entry in
groups
is a unique event pattern with:
  • count
    — how many times it occurred
  • total_minutes
    — total duration
  • attendee_category
    — one of:
    solo
    ,
    1:1-report
    ,
    1:1-manager
    ,
    1:1-external
    ,
    team
    ,
    cross-team
    ,
    external-group
  • sample_names
    — names of non-EM attendees
Classify each group (not each raw event) in Step 4.
一个月的日历数据可能包含150-250条原始事件。请使用捆绑的Python脚本进行去重和分组——不得自行编写脚本或手动处理事件。
步骤1:保存原始MCP输出
调用
list_events
后,使用Write工具(或Bash重定向)将完整的JSON响应保存到
/tmp/cal_events.json
步骤2:查找并运行脚本
使用Glob查找脚本:搜索
**/em-grid-scorer/scripts/process_calendar.py
。然后运行:
bash
python "<script_path>" /tmp/cal_events.json <em_email> [report_email_1] [report_email_2] ...
传入工程经理的邮箱以及em-context中所有直接下属的邮箱作为参数。
脚本会输出:
  • 人类可读的汇总表格到标准输出(将其打印到你的上下文)
  • 完整的分组JSON数据到
    /tmp/em_grid_calendar_groups.json
步骤3:加载分组数据
读取
/tmp/em_grid_calendar_groups.json
groups
中的每个条目都是一个独特的事件模式,包含:
  • count
    ——发生次数
  • total_minutes
    ——总时长
  • attendee_category
    ——以下类别之一:
    solo
    1:1-report
    1:1-manager
    1:1-external
    team
    cross-team
    external-group
  • sample_names
    ——非工程经理参会者的姓名
在步骤4中对每个分组(而非每条原始事件)进行分类。

Cross-reference attendees for accurate scope

交叉核对参会者以确保范围准确

The script's
attendee_category
already handles most scope decisions. Use it as the primary signal. Cross-check against em-context for edge cases: direct report names not in the email list, MoM patterns, or unusually large meetings that the category might miscategorize.

脚本的
attendee_category
已经处理了大部分范围判定。请将其作为主要信号。针对边缘情况,结合em-context进行交叉核对:比如邮箱列表中未包含的直接下属姓名、MoM模式、可能被分类错误的超大型会议。

Step 3: Gather Slack Data (if available)

步骤3:收集Slack数据(若可用)

Goal: classification signal, not a comprehensive audit. Do not read all messages. Use this three-phase protocol.
目标:获取分类信号,而非全面审计。无需读取所有消息。请遵循以下三阶段流程。

Phase 1 — Channel landscape (~5 calls)

阶段1——频道概况(约5次调用)

  1. conversations.list
    (type: member) — get all channels the user belongs to
  2. Categorize each as: team (your team's primary channel) / cross-team (other engineering or adjacent teams) / leadership (management-only, exec comms) / company-wide (general, announcements, social, random)
  3. Note: does the user post here, or just read?
  1. conversations.list
    (类型:member)——获取用户加入的所有频道
  2. 将每个频道分类为:团队频道(你的团队主频道)/ 跨团队频道(其他工程或相关团队的频道)/ 领导层频道(仅管理者、高管沟通频道)/ 全公司频道(通用、公告、社交、随机频道)
  3. 注意:用户是在频道中发帖,还是仅浏览?

Phase 2 — Activity distribution (~10 calls)

阶段2——活动分布(约10次调用)

  1. For each channel category, count the user's messages in the last 30 days — do NOT load full content yet
  2. List DM conversations active in last 30 days — get partner names/IDs
  3. Cross-reference DM partners against direct reports list: split into "DMs with direct reports" vs "DMs with others (peers, cross-dept, leadership)"
  4. Count emoji reactions the user gave in the last 30 days, especially ❤️ 🎉 👏 — this is a People×Connection signal
  1. 针对每个频道类别,统计用户过去30天的消息数量——暂不加载完整内容
  2. 列出过去30天活跃的私信对话——获取对话方姓名/ID
  3. 将私信对话方与直接下属列表交叉核对:分为“与直接下属的私信”和“与其他人的私信(同事、跨部门、领导层)”
  4. 统计用户过去30天发送的表情反应,尤其是❤️ 🎉 👏——这是人员×联结的信号

Phase 3 — Targeted content sampling (~10–15 calls)

阶段3——针对性内容抽样(约10-15次调用)

  1. Team channel: fetch the user's 20 most recent messages — classify as social/connective vs task/delivery
  2. Cross-team channels where user is active: fetch user's 15 most recent messages — look for relationship-building vs technical collaboration vs business/impact language
  3. DMs with direct reports: fetch last 10 user-authored messages per report — look for developmental content ("what do you want to work on", sharing resources, feedback patterns, personal check-ins) vs pure operational content (blockers, task status)
  4. DMs with non-reports: note who they are and check for relationship-building signals
  1. 团队频道: 获取用户最近20条消息——分类为社交/联结类 vs 任务/交付类
  2. 用户活跃的跨团队频道: 获取用户最近15条消息——寻找关系建立、技术协作或业务/影响力相关的语言
  3. 与直接下属的私信: 针对每位下属,获取用户最近10条消息——寻找发展相关内容(“你想从事什么工作”、分享资源、反馈模式、个人情况询问) vs 纯运营内容(障碍、任务状态)
  4. 与非下属的私信: 记录对方身份并检查是否有建立关系的信号

What Slack maps to

Slack信号对应关系

Slack signalGrid cell
DMs with direct reports containing personal check-ins, warmth, life questionsPeople×Connection
DMs with direct reports sharing resources, career questions, developmental feedbackPeople×Growth
Social/celebratory messages in team channel, reactions to team members' postsTeam×Connection
Messages in leadership/exec channels with business languageOrg×Impact
Messages or DMs with cross-dept people (non-task)Org×Connection
User sharing articles, asking technical questions, referencing learningSelf×Growth
Timely informal feedback to engineers close to an eventPeople×Connection
Classify the pattern across each channel type, not individual messages.

Slack信号Grid维度
与直接下属的私信中包含个人情况询问、关怀、生活话题人员×联结
与直接下属的私信中包含资源分享、职业问题、发展反馈人员×成长
团队频道中的社交/庆祝消息、对团队成员帖子的反应团队×联结
领导层/高管频道中包含业务语言的消息组织×影响力
与跨部门人员的消息或私信(非任务类)组织×联结
用户分享文章、提出技术问题、提及学习内容自我×成长
在事件发生后及时向工程师提供非正式反馈人员×联结
请针对每个频道类型的模式进行分类,而非单条消息。

Step 4: Classify Each Event Group

步骤4:对每个事件分组进行分类

For each unique event pattern from Step 2:
  • Scope (Self / People / Team / Org) — from attendees
  • Driver (Growth / Impact / Connection) — from purpose
  • Total minutes = duration × occurrence count
针对步骤2中每个独特的事件模式:
  • 范围(自我/人员/团队/组织)——根据参会者判定
  • 驱动因素(成长/影响力/联结)——根据目的判定
  • 总时长 = 单次时长 × 发生次数

Scope rules

范围规则

AttendeesScope
No attendees / blocked solo timeSelf
1:1 with your own manager or skip-levelSelf
1:1 with a direct reportPeople
Whole team or majority of your teamTeam
Your team + people from other teamsOrg
Entirely outside your team (other depts, execs, customers)Org
Hiring interviewsPeople
参会者范围
无参会者/预留的独处时间自我
与直属上级或隔级上级的一对一会议自我
与直接下属的一对一会议人员
整个团队或团队大多数成员团队
你的团队+其他团队成员组织
完全来自团队外部(其他部门、高管、客户)组织
招聘面试人员

Driver rules

驱动因素规则

PurposeDriver
Building capabilities, learning, developing for the futureGrowth
Producing results, shipping, moving metrics, unblocking deliveryImpact
Building relationships, belonging, being seen and appreciatedConnection
目的驱动因素
构建能力、学习、为未来发展做准备成长
产出成果、交付产品、推动指标、消除交付障碍影响力
建立关系、增强归属感、让他人感受到被看见和认可联结

The 12 cells — detailed definitions

12个维度——详细定义


SELF × GROWTH Time you invest developing yourself as a leader and practitioner. You are the student.
Counts: coding/building with AI tools, taking courses, watching technical talks, reading management or engineering books/newsletters, receiving coaching or mentorship, experimenting with new methodologies, career planning sessions with your own manager, deliberate reflection time.
Does NOT count: consuming news passively, admin, technical work done primarily for delivery rather than learning.

SELF × IMPACT Time you personally produce something of value — not through your team.
Counts: deep work producing strategy docs/RFCs/post-mortems, writing performance reviews or promotion cases, building internal tools/automations yourself, making key architectural decisions solo, personal firefighting (hands on keyboard), preparing impactful presentations for leadership.
Does NOT count: facilitating meetings where others produce the output. Admin. Reading or learning (Self×Growth).

SELF × CONNECTION Building YOUR professional network outside your current company.
Counts: calls with peers at other companies, maintaining former-colleague relationships professionally, attending industry events to network, writing publicly (LinkedIn, blog, newsletter), participating in professional communities.
Does NOT count: internal company networking (Org×Connection). LinkedIn scrolling without engagement.

PEOPLE × GROWTH Deliberately developing your direct reports — their careers, skills, next level. Intentional and forward-looking.
Counts: 1:1s where you explicitly discuss career goals, growth plan, or next role; writing promotion cases; pattern-level developmental feedback; intentional stretch assignment delegation; helping an engineer prepare a talk, article, or new responsibility; shadowing or team-switching; matching work to driver type; hiring interviews; explicit career conversations.
Does NOT count: 1:1s that are purely task status. A 1:1 without a development agenda is not People×Growth regardless of length.
For MoM: 1:1s with manager-reports should focus on their leadership development, not just their team's delivery.

PEOPLE × IMPACT Helping engineers connect with and contribute to real business outcomes.
Counts: inviting engineers to customer calls or business reviews; sharing product metrics/usage data in 1:1s; explaining WHY they're building something (not just the spec); giving engineers the chance to present shipped work to leadership; helping them write compelling announcements; bringing business stakeholders to the team.
Does NOT count: pure delivery management (Team×Impact). Engineers passively CC'd on a meeting.

PEOPLE × CONNECTION The personal relationship layer — engineers feeling genuinely seen, appreciated, and psychologically safe.
Counts: asking about family, life events, hobbies and actually remembering; specific genuine recognition (not "great job" — what exactly); noticing when someone seems off and checking in; salary and compensation advocacy; being a safe space for personal or vulnerable topics; timely informal feedback delivered with respect; celebrating life events; letting engineers announce good news themselves.
Calibration — weekly 1:1s matter here: If the EM has weekly 1:1s AND Slack DMs show warmth, personal check-ins, or informal connection with reports, People×Connection should be scored no lower than 5 regardless of explicit "connection activities" on the calendar. The relationship is being maintained — it just happens inside 1:1s and DMs rather than in standalone activities. Only score lower if DMs are purely operational or 1:1s are infrequent.
Does NOT count: team social events (Team×Connection). Purely performative appreciation.

TEAM × GROWTH Building the collective capability of the team — skill gaps, technical maturity, learning together.
Counts: knowledge mapping (who knows what, bus factor risks — flag explicitly if this is absent); technical talks or L&D sessions for the team; post-mortem deep dives where the team actually learns; retrospectives that cause real behavior change; open source work as a team; AI tools days, hackathons with learning goals; architecture reviews involving the whole team; introducing new engineering practices.
Does NOT count: sprint planning/delivery standups (Team×Impact). Team social events (Team×Connection).

TEAM × IMPACT The delivery engine — consistent execution, shipping on time, producing real value.
Counts: sprint planning and goal-setting (especially "always green" — minimal confident goals set and tracked); sprint reviews and demos; daily standups focused on blockers and delivery; roadmap planning with PM; actively removing blockers; monitoring feature adoption post-release; incident coordination; getting technical debt onto the roadmap with business justification.
Quality signal: consistent sprint goal achievement (evidence of "always green" discipline) scores higher than many delivery meetings with no goal-tracking pattern visible.
Does NOT count: 1:1s. Social activities.

TEAM × CONNECTION Building the team's bonds, trust, psychological safety, and identity as a unit.
Counts: team meetings that go beyond task updates (genuine sharing, culture discussion); team focus days or offsites; social activities (games, lunches, volunteering); personal talks where engineers share something they care about; celebrating shipped work together; playful hackathons; shared humor channels, team traditions.
Does NOT count: task-update standups. Work-sprint-only focus days.

ORG × GROWTH Contributing to the broader organization's capabilities — things that outlast your team.
Counts: leading or significantly contributing to cross-team technical initiatives; hiring panels for roles outside your team; mentoring people outside your direct reports; contributing to org-wide processes (onboarding, career ladders, engineering standards); leading internal guilds or communities of practice; speaking at internal all-hands or tech talks; helping another EM think through a problem.
Does NOT count: attending (but not contributing to) org-wide meetings.

ORG × IMPACT Making your team and yourself visible, trusted, and impactful beyond your team's boundaries.
Counts: regular touchpoints with stakeholders outside engineering; proactively helping other departments achieve their goals; presenting team results to senior leadership; getting technical work defended in roadmap conversations; speaking in business terms (ROI, retention, churn) with leaders; being part of org-level decisions.
Positioning level — note which level the EM is operating at:
  • Level 1 (visible): attending cross-functional meetings, being present in shared channels
  • Level 2 (appreciated): people seek you out, you're known for being helpful and curious
  • Level 3 (trusted): you proactively help other depts achieve their goals before they ask — CS, QA, finance, HR. This is where real organizational trust is built.
Does NOT count: internal team delivery. Attending stakeholder meetings passively.

ORG × CONNECTION Being known and liked across the organization — goodwill and allies beyond your team.
Counts: the "new person rule" (intentional coffee chat with someone new each week); cross-department informal 1:1s; engaging with other teams' announcements; participating genuinely in company-wide social events; following up on personal things learned about colleagues in other teams; proactive DMs to people you don't know well.
Does NOT count: external professional networking (Self×Connection). Stakeholder management with a business agenda (Org×Impact).


自我 × 成长 你投入用于提升自身领导力和专业能力的时间。你是学习者。
计入:使用AI工具编码/构建、参加课程、观看技术讲座、阅读管理或工程类书籍/通讯、接受教练指导或 mentorship、尝试新方法论、与直属上级进行职业规划会议、刻意反思时间。
不计入:被动浏览新闻、行政工作、主要为交付而非学习完成的技术工作。

自我 × 影响力 你个人产出价值的时间——而非通过团队。
计入:深度工作产出战略文档/RFC/事后分析报告、撰写绩效评估或晋升申请、自行构建内部工具/自动化、独自做出关键架构决策、个人应急处理(亲自操作)、为领导层准备有影响力的演示文稿。
不计入:主持由他人产出成果的会议、行政工作、阅读或学习(自我×成长)。

自我 × 联结 建立你当前公司之外的职业人脉。
计入:与其他公司同行的通话、维系前同事的职业关系、参加行业活动拓展人脉、公开发布内容(LinkedIn、博客、通讯)、参与专业社区。
不计入:公司内部人脉拓展(组织×联结)、无互动的LinkedIn浏览。

人员 × 成长 刻意培养你的直接下属——他们的职业发展、技能提升、晋升。具有目的性和前瞻性。
计入:一对一会议中明确讨论职业目标、成长计划或下一个岗位;撰写晋升申请;模式化的发展反馈;有意分配具有挑战性的任务;帮助工程师准备演讲、文章或新职责;轮岗或团队调动;匹配符合驱动因素的工作;招聘面试;明确的职业对话。
不计入:纯任务状态的一对一会议。没有发展议程的一对一会议,无论时长多久,都不属于人员×成长。
对于MoM:与下属管理者的一对一会议应聚焦于他们的领导力发展,而非仅仅是其团队的交付工作。

人员 × 影响力 帮助工程师联结并贡献于真实的业务成果。
计入:邀请工程师参加客户会议或业务评审;在一对一会议中分享产品指标/使用数据;解释他们为什么要做某件事(而非仅仅是规格要求);给工程师机会向领导层展示已交付的工作;帮助他们撰写有吸引力的公告;邀请业务利益相关者参与团队工作。
不计入:纯交付管理(团队×影响力)、工程师被动被抄送的会议。

人员 × 联结 个人关系层面——让工程师感受到真正被看见、被认可、心理安全。
计入:询问家庭、生活事件、爱好并真正记住;具体真诚的认可(而非“做得好”——要明确具体内容);注意到某人状态不佳并主动询问;薪资和福利维权;成为个人或脆弱话题的安全空间;及时且尊重地提供非正式反馈;庆祝生活事件;让工程师自行宣布好消息。
校准——每周一对一会议至关重要: 如果工程经理每周与下属进行一对一会议,且Slack私信显示出关怀、个人情况询问或非正式联结,那么人员×联结的评分不应低于5分,无论日历上是否有明确的“联结活动”。关系正在维护中——只是发生在一对一会议和私信中,而非独立的活动。仅当私信纯为运营内容或一对一会议频率较低时,才降低评分。
不计入:团队社交活动(团队×联结)、纯粹形式化的认可。

团队 × 成长 构建团队的集体能力——技能差距、技术成熟度、共同学习。
计入:知识图谱(谁掌握什么技能、人员流动风险——如果缺失需明确标注);为团队举办的技术讲座或学习发展会议;团队真正从中学习的事后深度复盘;带来实际行为改变的回顾会议;团队参与开源工作;AI工具日、以学习为目标的黑客松;全员参与的架构评审;引入新的工程实践。
不计入: sprint规划/交付站会(团队×影响力)、团队社交活动(团队×联结)。

团队 × 影响力 交付引擎——持续执行、按时交付、产出真实价值。
计入:sprint规划和目标设定(尤其是“始终达标”——设定并跟踪最小可行的自信目标);sprint评审和演示;聚焦于障碍和交付的每日站会;与产品经理进行路线图规划;主动消除障碍;监控发布后功能的采用情况;事件协调;将技术债务纳入路线图并提供业务理由。
质量信号:一致达成sprint目标(有“始终达标”原则的证据)比多次召开交付会议但无目标跟踪模式的评分更高。
不计入:一对一会议、社交活动。

团队 × 联结 构建团队的纽带、信任、心理安全和集体身份认同。
计入:超越任务更新的团队会议(真诚分享、文化讨论);团队聚焦日或线下团建;社交活动(游戏、午餐、志愿活动);工程师分享个人关心话题的非正式谈话;共同庆祝交付成果;有趣的黑客松;共享幽默频道、团队传统。
不计入:任务更新站会、仅聚焦工作冲刺的聚焦日。

组织 × 成长 为更广泛的组织能力做贡献——成果能超越你的团队存续时间。
计入:领导或显著贡献跨团队技术举措;参与团队外岗位的招聘评审;指导非直接下属;参与组织层面的流程(入职、职业阶梯、工程标准);领导内部 guilds 或实践社区;在公司全员会议或技术讲座上发言;帮助其他工程经理解决问题。
不计入:仅参加(但未贡献)组织层面的会议。

组织 × 影响力 让你的团队和自己在团队边界之外变得可见、可信、有影响力。
计入:与工程外利益相关者的定期沟通;主动帮助其他部门实现目标;向高层领导展示团队成果;在路线图讨论中为技术工作辩护;用业务术语(ROI、留存率、流失率)与领导层沟通;参与组织层面的决策。
定位层级——注意工程经理的运营层级:
  • 层级1(可见):参加跨职能会议、在共享频道中活跃
  • 层级2(受认可):他人主动寻求你的帮助,你以乐于助人、好奇心强著称
  • 层级3(受信任):在其他部门提出请求前主动帮助他们实现目标——客服、QA、财务、HR。这是建立真正组织信任的层级。
不计入:内部团队交付、被动参加利益相关者会议。

组织 × 联结 在整个组织中被熟知和喜爱——建立团队之外的善意和同盟。
计入:“新人规则”(每周主动与新同事进行咖啡聊天);跨部门非正式一对一会议;参与其他团队的公告互动;真诚参与全公司社交活动;跟进在其他团队同事身上了解到的个人情况;主动与不熟悉的人发私信。
不计入:外部职业人脉拓展(自我×联结)、带有业务目的的利益相关者管理(组织×影响力)。

Step 5: Score Each Cell

步骤5:为每个维度评分

Raw minutes: total duration of classified events per cell (split proportionally when an event covers two cells)
Add Slack signal: for cells where Slack data reveals meaningful uncalendared activity, add an estimated 60–240 minutes per month per cell depending on how active the pattern appeared. Be conservative — err toward underestimating rather than inflating.
Normalize to whole numbers (0–10):
  • Find the cell with the most total minutes → that becomes 10
  • All others:
    round((cell_minutes / max_minutes) × 10)
    — round to nearest whole number
  • Cell with 0 minutes and no Slack signal: score = 0
  • People×Connection floor: if the EM has weekly 1:1s with direct reports AND Slack DMs show warmth or personal check-ins, minimum score is 5
Quality adjustment (±1 point, applied before rounding):
  • 1:1s that Slack DMs confirm are purely operational (no warmth, no development signal): People×Growth down 1, People×Connection stays at floor
  • Clear "always green" discipline visible in calendar (consistent sprint planning + review cadence): Team×Impact up 1
  • Slack shows consistent developmental DMs with reports (resources shared, career discussed): People×Growth up 1
  • Org×Impact shows Level 3 activity (proactively helping other depts): Org×Impact up 1
Action suggestion check — before writing recommendations: Cross-check each suggested action against what calendar and Slack already show. Do NOT suggest something the EM is already doing. If the calendar shows weekly 1:1s and Slack shows personal check-ins, do not suggest "ask personal questions in 1:1s." Find what's genuinely missing.

原始时长: 每个维度下分类事件的总时长(当一个事件覆盖两个维度时,按比例拆分)
添加Slack信号: 对于Slack数据显示存在大量未 calendared 活动的维度,根据活动模式的活跃程度,每月每个维度添加60-240分钟的估算时长。请保持保守——宁低估勿高估。
归一化为整数(0–10):
  • 找到总时长最长的维度→该维度得分为10
  • 其他维度:
    round((维度时长 / 最长时长) × 10)
    ——四舍五入到最近的整数
  • 时长为0且无Slack信号的维度:得分=0
  • 人员×联结下限: 如果工程经理每周与直接下属进行一对一会议,且Slack私信显示出关怀或个人情况询问,最低得分为5
质量调整(±1分,在四舍五入前应用):
  • Slack私信确认一对一会议纯为运营内容(无关怀、无发展信号):人员×成长减1分,人员×联结保持下限得分
  • 日历中可见明确的“始终达标”原则(一致的sprint规划+评审节奏):团队×影响力加1分
  • Slack显示与下属持续有发展相关的私信(分享资源、讨论职业):人员×成长加1分
  • 组织×影响力显示层级3活动(主动帮助其他部门):组织×影响力加1分
行动建议检查——撰写建议前: 将每个建议的行动与日历和Slack已有的数据进行交叉核对。不得建议工程经理已经在做的事情。如果日历显示每周有一对一会议且Slack显示有个人情况询问,请勿建议“在一对一会议中询问个人问题”。找出真正缺失的内容。

Step 6: Output

步骤6:输出

Driver intro (before the grid)

驱动因素介绍(在网格之前)

Open with a brief, plain-English explanation of the three columns:
Growth — activities that build capability for the future: your own learning, developing your engineers, building team skills, growing the org's knowledge. Impact — activities that produce results now: shipping reliably, moving business metrics, creating visibility, making decisions that stick. Connection — activities that build relationships: with your engineers as individuals, your team as a unit, and the broader organization.
Want a deeper breakdown of any column? Ask "explain [Growth / Impact / Connection]" after reviewing your grid.
用简短的通俗易懂的语言解释三个列:
成长——为未来构建能力的活动:个人学习、培养工程师、提升团队技能、拓展组织知识。 影响力——当下产出成果的活动:可靠交付、推动业务指标、提升可见度、做出有持久影响的决策。 联结——建立关系的活动:与工程师个人、团队整体、更广泛组织的联结。
想要深入了解任何一列?查看完你的网格后,询问“解释[成长/影响力/联结]”即可。

The grid

网格

Use a colored square to give each cell an instant visual read, then the whole-number score. No warnings, no footnotes in the table.
Color scale:
  • 🔴 0–2 (critical gap)
  • 🟠 3–4 (weak)
  • 🟡 5–6 (moderate)
  • 🟢 7–8 (good)
  • 💚 9–10 (strong)
undefined
使用彩色方块让每个维度一目了然,然后标注整数得分。表格中无警告、无脚注。
颜色刻度:
  • 🔴 0–2(严重缺口)
  • 🟠 3–4(薄弱)
  • 🟡 5–6(中等)
  • 🟢 7–8(良好)
  • 💚 9–10(优秀)
undefined

Your EM Grid — Last 30 Days

你的EM Grid——过去30天

GrowthImpactConnection
Self🟠 4💚 9🔴 1
People💚 9🟠 3🟡 5
Team🔴 1💚 10🔴 2
Org🟠 3🟠 3🟢 7

Below the table, one line only: the data sources — e.g. "Based on 43 unique meeting patterns across 178 calendar events + Slack activity across 9 channels and 7 active DM threads."
成长影响力联结
自我🟠 4💚 9🔴 1
人员💚 9🟠 3🟡 5
团队🔴 1💚 10🔴 2
组织🟠 3🟠 3🟢 7

表格下方仅需一行:数据来源——例如“基于178个日历事件中的43种独特会议模式 + 9个频道和7条活跃私信线程中的Slack活动”。

Pattern diagnosis

模式诊断

2–3 direct sentences naming what kind of EM this pattern reveals. Read the overall shape:
  • Which row dominates? Which driver dominates?
  • What's the implication for the team, the EM's career, and the org?
  • If there's a tension or a flag worth naming (e.g. Self×Impact unusually high = possible delegation risk), name it here.
Examples of the right register:
  • "You're in execution mode — Team×Impact dominates and almost everything else is thin. Your team ships, but you're not investing in their development, your own growth, or your organizational presence."
  • "People×Growth is strong, which is real investment. But Team×Impact is weak — delivery probably lives or dies by the team's own discipline, not your active involvement."
Be direct and specific to their actual numbers.
用2-3句直接的话说明这种模式反映出的工程经理类型。解读整体趋势:
  • 哪一行占主导?哪一个驱动因素占主导?
  • 这对团队、工程经理的职业发展和组织有什么影响?
  • 如果存在值得关注的矛盾或信号(例如自我×影响力异常高=可能存在授权风险),请在此处指出。
合适表述的例子:
  • “你处于执行模式——团队×影响力占主导,其他所有维度都薄弱。你的团队能交付成果,但你没有投入资源培养他们、提升自身能力或维护组织存在感。”
  • “人员×成长得分很高,这是真正的投入。但团队×影响力薄弱——交付工作可能完全依赖团队自身的自律,而非你的主动参与。”
请直接且具体地结合实际得分进行说明。

Top 3 blind spots

三大盲区

For the 3 lowest-scoring cells that aren't already explained away by role/context (e.g. a 2-person team won't have strong Team×Connection — flag that differently):
  • Cell name and score
  • What's missing in practice: one sentence about what's not happening and why it matters
  • One action this week: small, specific, immediately doable — read
    references/suggested-actions.md
    and pick the most contextually relevant option. Do not suggest anything already visible in calendar or Slack.
针对3个得分最低且无法通过角色/上下文解释的维度(例如2人团队的团队×联结得分不会很高——需单独标注):
  • 维度名称和得分
  • 实际缺失的内容: 一句话说明未开展的工作及其重要性
  • 本周可采取的一项行动: 微小、具体、可立即执行的行动——阅读
    references/suggested-actions.md
    并选择最符合上下文的选项。不得建议日历或Slack中已显示正在进行的行动。

Optional: one flag worth naming

可选:值得关注的一个信号

If there's something in the scores that's notable but isn't a blind spot — unusually high Self×Impact (possible delegation risk), strong Org×Connection with weak People×Connection (managing up more than managing people), etc. — call it out in one sentence as a thing to watch.
如果得分中存在值得注意但不属于盲区的内容——例如自我×影响力异常高(可能存在授权风险)、组织×联结得分高但人员×联结得分低(更多向上管理而非向下管理)等——请用一句话指出这一需要关注的点。

Overall score and final assessment

总体得分和最终评估

Calculate a single combined score: the average of all 12 cells, rounded to one decimal.
Present it as:
Overall EM Score: X.X / 10
Then write 2–3 sentences of final assessment — what this score means in context, not just the number. A 6.5 with strong fundamentals but neglected self-development is very different from a 6.5 that's evenly mediocre. Call out the specific shape:
  • What's genuinely working (don't just list high scores — name why they matter)
  • The one thing that, if improved, would have the highest compounding effect on everything else
  • A forward-looking sentence: what does this grid look like in 3 months if nothing changes?
Example register:
"Overall: 5.8 / 10. Your delivery and people-development engine is solid — that's the foundation. The compounding gap is Team×Growth: a team navigating an AI pivot without collective learning will drift in quality before anyone names it. In 3 months at this pace, you'll still be shipping, but the skill debt will start showing in code review quality and in engineer confidence on the harder technical decisions."
计算综合得分:所有12个维度得分的平均值,保留一位小数。
呈现方式:
EM总体得分:X.X / 10
然后用2-3句进行最终评估——说明该得分在上下文中的意义,而非仅仅是数字。基础扎实但忽略自我发展的6.5分,与各维度均平庸的6.5分有很大区别。请明确指出具体趋势:
  • 真正有效的方面(不要仅列出高分——说明其重要性)
  • 提升后对其他所有方面影响最大的一个维度
  • 前瞻性语句:如果保持现状,3个月后这个网格会是什么样子?
表述示例:
“总体得分:5.8 / 10。你的交付和人员培养机制扎实——这是基础。最具复利效应的缺口是团队×成长:在AI转型中缺乏集体学习的团队,会在质量下滑后才被发现问题。按当前节奏,3个月后你仍能交付成果,但技能债务会开始体现在代码评审质量和工程师处理复杂技术决策的信心上。”

Data note (if Slack was missing)

数据说明(若缺少Slack数据)

If Slack was not connected:
Calendar-only analysis — People×Connection, Org×Connection, and Self×Growth are likely underscored if you're active in DMs and channels. Connect Slack for a more complete picture.
If both sources were used, no caveat needed.

如果未连接Slack:
仅基于日历的分析——如果你在私信和频道中活跃,人员×联结、组织×联结和自我×成长的评分可能偏低。连接Slack可获得更完整的分析结果。
如果同时使用了两种数据源,则无需说明。

Tone

语气

Direct, specific, brief. No preamble beyond the driver intro. No filler encouragement. The grid, a short diagnosis, three blind spots, and one optional flag. Everything on one screen.
直接、具体、简洁。除驱动因素介绍外无需开场白。无冗余鼓励语。仅展示网格、简短诊断、三大盲区和一个可选信号。所有内容在一个页面呈现。