---

0. 前言

这周是 Covid 痊愈之后的第一周，为了保证公司同事们的安全，我在家上了五天班，下周准备回办公室了。

在家上班的好处

• 不需要在开会前急急忙忙地找 booth（Canva 办公室里面有隔音的小房间专门用来开会）
• 每次开会都有两个屏幕（booth 里面没有外接显示器）

在家上班的坏处

• 久坐，懒得动
• 经常加班，工作和生活没有明确的界限

我的喜好

经历了一周在家上班之后，我已经迫不及待地想去办公室见人了……

虽然在家总体来说比在办公室方便，但是我觉得从**「身体健康」**的角度来说，还是办公室好些。

如果每个人可以有固定的工位，而且可以在自己的位置上开会，那就完美了，省的跑来跑去。

我之前有几天在办公室基本上就是全天待在 booth，因为两个会议之间只有半小时甚至十分钟，从 booth 跑回自己的位置，屁股还没坐热就要去找个新 booth，而且万一找不到地方就更尴尬了，会都没法开。

---

1. 这周干了点啥

Coach - Calibration Session

这周第一个重要任务就是参加 Group Coach Calibration Session，这个会议的作用是在 Performance Review 的自评和 Coach Review 完成之后，在整个大组里面公开讨论每个人的绩效评级。

Canva 的绩效是五分制：

1. Missing
2. Approaching
3. Thriving
4. Excelling
5. Redefining

这个会议的参与者是管理者们 + 人事部门的一个代表（People Partner），通常要开一整天。

会议形式是按照员工级别来，由低到高，先讨论非 Thriving 的那些人（表现特别好或者特别差的），由 Coach 陈述这个人的背景信息（来了多久了，当前的职位是什么），以及为什么应该拿到这个分数，其他在场的人可以提出异议或者补充例子，如果意见统一就过了，意见不统一的话要由更高级别的 Leader 和 People Partner 裁决。

讨论完非 Thriving 的人之后，会再看一遍 Thriving 的人，如果你觉得这人应该打更高或者更低的分数，也可以提出来大家讨论。

每个参加会议的人只能留到自己级别的讨论之前，比如我需要在讨论我这个级别的分数之前退场。

我的想法

作为新 Coach，最害怕的就是因为自己文档没写好或者开会的时候发言不够有说服力，导致团队成员的利益受损。

我的三个 Coachee 里面有一个打了 Excelling，所以我需要特别去准备一下自己要怎么说，以及别人可能会提出哪些问题。

上周一（就是我得 Covid 的那周），我们 Subgroup 开了个 pre-calibration 会议，先让大家陈述一遍理由，那次我头比较晕，所以说的不是很好，Coach 让我再去整理一下思路。

这周二我又重新把所有的资料读了一遍，因为这个打分是基于我来公司之前的半年发生的事情，所以我只能通过看材料来重现当时的场景。

周二晚上我给 Coach 发了我的思路，他说整体不错，又给了一些反馈意见，并且告诉了我在讨论阶段通常会遇到哪些问题，可以提前准备一下。

周三正式开会的时候，我之前发言的几个人都说的挺好的，大家也有一些讨论；到了我的时候，我讲完大家都没啥问题，zoom chat 里面有一些赞同的评论，算是非常顺利地过了，Coach 也发来祝贺，说「You did so well, people don’t have any questions」。

呼~算是成功完成了一个重要任务！

Hiring - Interview

这周五完成了自己在 Canva 的第一次面试，跟组里同事一起做的 Backend Interview。

我作为 Coach 的任务是让我的下属们能够在面试时独当一面，所以我跟同事说我们的分工就是我负责开场结尾，你负责中间的技术部分。

面试进行的还是蛮顺利的，同事准备的很充分，我们配合也很好。

面试结束之后，面试官要在 24 小时之内提交 Feedback Form（我和同事是独立打分，不能有任何沟通），这些文档在最终决定是否要招这个人的时候是关键的依据。

我之前看过大家写的 Feedback Form，都非常用心，所以我也是在面试的时候一直记笔记，写材料的时候把重要的细节都放进去。

这种面试流程跟我之前的公司不太一样，以前我们是面试完了之后两个面试官直接开个会讨论到底要不要招这个人，如果都觉得 ok 会稍微多写点笔记给下一轮的人看，假如觉得不 ok，笔记也会写的比较简短。

现在回想一下，之前公司流程的好处是效率高（节约了每个人写 Feedback 的半小时），坏处则是会有偏见（尤其是一个面试官在讨论时有 Strong Opinion 的时候，另一个可能会放弃自己的想法）。

另外，Canva 的流程是，不管面试过没过，都会给面试者打电话沟通 Feedback，这一点我觉得很棒，就算没过也知道自己是为什么没过。

Team Delivery Process Review

这周的第三个任务就是理顺团队流程，这件事情是最最难办的，而且也是我在试用期期间本来不太想碰的一块。

首先我自己的 Coach 对流程就没啥兴趣，他是技术出身，觉得只要能把事情做成就行了，不需要搞那么多花里胡哨的，他对 Scrum 这种形式也没啥好感。

我呢？我的想法是，假如在没有什么流程的情况下大家能把事情做成，那也行啊，我也没必要去搞这块。

但是有几件事情的发生让我改变了我的想法：

1. 我们每周有三次 Update 进度的 Team Meeting，之前这个会是由我 Coach 主持的，他现在把这个交接给我了，但是我每次开会都找不到大家说的东西……
2. 我们现在进入了一个新的 Cycle，需要把上一个 Cycle 的事情做完，然后 Kick-off New Goal，Coach 给我的时间节点是这个月底大家手头的事情做完，但是目前有一个同事的进度不是很理想。
3. 新的那些 Goal 需要用 Group Goal Delivery Process，我的任务是搞清楚我们自己的 Jira board 跟 Group 的 Jira board 怎么关联起来，也就是流程相关的。
4. 跟组里 PM 沟通，发现 TA 也不知道我们组的进度怎么看 lol

然后我想了下，现在我来了不到三个月，我可以选择不管流程——相信大家能做好自己的事情，也可以选择利用新的 Goal 需要从头开始做这个契机，把流程理顺。

从团队健康和 Goal Delivery 的项目管理角度来看，我觉得我作为 Coach，有责任去 own 这件事情，即使这意味着我跟我的 Coach 可能会有一些分歧。

我是怎么做的

我首先跟每个人去聊了一下他们是如何管理自己的项目进度的，发现没有一个人能说清楚= =

接着我又去找 Coach 聊，问他现在是什么流程，然后我把他说的流程按照我的理解复述了一遍，确保我的理解没有问题。

我找其他组的 team lead 和负责我们大组 delivery process 的同事们聊，看他们是怎么做内部流程的，有哪些 best practice 我可以参考。

我通过画图的形式，做了个 Design doc，里面有四块：

1. 为什么 Why we need to discuss team delivery process, what are our objectives (Transparency, Scalability, Delivery Value)
2. 工具 Understand our tool - Jira, what is Scrum, what is Kanban, what are the ticket types
3. 现状 Our current delivery process
4. 方案 Proposed delivery process - Option 1, 2, 3.., pros and cons

周四画了一整天，画完我又找组里人一个个去聊，看他们是否理解我这个图，他们有没有更好的想法。

然后我跟大家说，我们下周五开组会的时候聊一下，聊完以后匿名投票表决，而且定了方案以后我们还是会有定期的 Retro 可以去改进流程的。

---

2. 思考——我应该做什么？

这周相比于之前的几周来说，稍微多一些自己的时间和自由度让我去思考自己的工作重心应该放在哪里。

跟 Coach 聊天的时候，他给了两个 Improvement Area，一个是 Technical Task，一个是 Documentation Writing。

和我自己之前的感受差不多，我说 Technical 这块我会继续赶上进度，多看一些 PR，Documentation Writing 的话就是多练 + 多问 Feedback。

当然，组里同事的工作进度我也要心里有数，尤其是那个看起来有点 delay 的 project。

团队缺什么？

根据我的观察，我们组缺的不是 Technical Expert - 我 Coach 和其他几个组员的技术都挺强的。

我们组缺的是 Vision，Metric 和 Process。

整个产品的定位到底是什么，Roadmap 在哪里，success metric 是什么，想明白了这些问题，才能决定哪些事情做，哪些事情不做，哪些事情先做，哪些事情后做。

Process 的缺乏则体现在，每个 dev 自己知道自己在干嘛，自己去把握项目进度，但是所有的这些信息，没有体现在 Jira board 上，我有时候打开一个 task，发现 description 和真正的 scope 出入很大，我没法通过看 board 来了解每个人的工作量，他们接下来准备做什么，是否要调整工作优先级。

如果团队里面要加新人，要有 UX 进来，那我就要保证我们的 process 不是 dev driven，而是 business value driven。

说实话，用不用 scrum，我也不纠结，我觉得我需要每个人把自己做的事情写在 ticket 里面，ticket 不超过两周，给个 estimate target date，然后把自己接下来两周准备做的事情也写个 ticket。

至少每次开会，我能把大家说的事情和 board 对应起来。

而且跟同事们聊下来，发现大家对整个团队的工作方式，或多或少都有一些希望改进的地方。

Transparency 可以 enable inspectability，我们在复盘的时候才能发现团队的瓶颈和痛点在哪里，是需求不清，还是 dev estimate 过于乐观，还是 code review 时间太长……

我的优势是什么？

我的优势是能倾听每个人的需求，加上自己的观察和经验，把各路信息整合到一起，再根据团队里面的人物性格和团队文化，找到一条能够把事情推进下去，解决团队痛点的道路。

建流程只是第一步，我的最终目标是搞清楚我们组的 Value 在哪里，工作的优先级是什么，让每个人知道自己做的事情有何意义，让这个团队里面每个人都能发挥自己的潜能。

我觉得我是个很追求意义感的人，如果我不知道我为什么在做一件事情，我可能就没什么动力……觉得自己只是在被任务推着走。

但是我也知道，很多 dev 更喜欢去钻研技术的细节，而不是去纠结团队流程和产品价值。

小团队小项目可以由一两个业务骨干撑起来，可是关键团队成员一旦走了，这项目到底还能不能继续运作下去，就是要靠流程去支撑。

我的思考，更多的是从系统层面来考虑团队的抗压性、稳定性、成长性。

之前好像看到过一句话，说 idea 不是项目成功的关键，execution 才是。

我的短期目标（3 个月）就是在团队大方向不明确的时候，先把 execution 的流程跑通。

As an engineering coach, you’re responsible for delivering the goals and milestones your team has committed to.

The needs of your team dictate your work. It’s up to your judgment on how best to spend your time maximizing your and their impact.

---

3. 结语

下周又可以去公司吃吃喝喝找人聊天了，期待一下：）