资深工程师的自我检核清单

在先前的文章中，我们分别谈了《软体工程师的职涯路径概览》以及《软体工程师如何在职涯持续成长?》，在这期的主题文，我们会更专注在资深工程师这个角色上，更详细来谈要成为资深工程师，有什么需要具备的软与硬实力。

我们将会用检核清单的形式，因此推荐读者们可以用这个清单来自我检核，看看自己还有哪些面向需要再多提升。

自我检核清单

行为面

[ ] 专注在最重要的事情上
[ ] 不只从自己角度出发思考
[ ] 放手授权
[ ] 确保团队在对的方向上

技术面

[ ] 培养出技术深度与广度
[ ] 把关团队的标准
[ ] 系统性思考
[ ] 持续探索新技术

行为面详细说明

专注在最重要的事情上

前 GitHub 首席工程师 Jaana Dogan 先前退休后，最近重回业界加入 Google。先看到她分享一则推文，在谈高效主管的共同特征 (连结) 。

她的原文写道：

All the effective execs I know had one common trait: They knew their job was to make a few very important decisions, rather than making 100s of small ones. They spent their time developing technical depth to make those decisions. They built and organized their teams accordingly.

如果要用中文理解的话，她的观察认为，高效率的主管的共同特点是「他们知道自己的工作是做出几个非常重要的决策，而不是做出数百个小决策」。因此，高效主管会花时间培养技术深度，以做出这些决策。而要成为资深工程师，也需要有这种思维上的转变。

Jaana Dogan 提到的「做出几个非常重要的决策，而不是做出数百个小决策」即是一种行为上的区别。如果你总是花大量时间在小的决策上，而没有留精力给重要的决策，或者没有花时间培养深度技术来做重要决策，就很难迈向资深。

进一步说，在充满噪音的现代，能够准确判别什么「不该」花时间，并专注在最重要的事情上，会是资深工程师不可或缺的。当能有效判断，就可以避免出现 Elon Musk 曾说过的 The most common mistake engineers make is optimizing a thing that shouldn’t exist (工程师最常犯的错误是优化那些本不该存在的东西)。

不只从自己角度出发思考

在成为资深工程师前会将重心放在自己，但是成为资深后，关注点就不能只是自己，而是要在整个团队。在《软体工程师的职涯路径概览》中，我们有提到，成为资深工程师，意味着要为团队的成果负责，因此协助团队成员提升能力、改善团队成员做事方式来提高生产力，解决团队遇到的问题，都是资深工程师的范畴。

当不只看自己，意味着要能够从别人的角度看，包含从团队成员的角度看。先前听一位 Google 资深工程师分享，在他刚当上资深工程师时，对于团队成员犯的错，总会以质问的角度来看，去一层层追问来厘清问题出在哪。虽然他这样做是为了团队好，但因为他这么做，完全没有考虑到团队成员的感受，对方犯错已经很不好受，还要这样被质问，变成加倍不好受。

这样的后果是，团队的成员开始尽可能避免跟该资深工程师有交集，因为担心被质问，所以总是会想闪避该资深工程师。这反而导致该资深工程师很难带好团队。后来他调整方式，在团队成员犯错时，他先去接住对方，用同理的角度让对方知道，他能懂犯错时会有的慌张，在处理完情绪后再讨论如何避免未来再发生同样问题，当他这样同理团队成员后，反而更能有效带团队成长。

从团队的角度看，要提升团队成员的整体能力，一个有效的方式，是持续给团队成员回馈。给回馈时，要切记「在公开场合赞扬，在私下场合回馈」的原则，并且尽可能给建设性的回馈。这是因为给建设性的回馈，意味着跟对方说哪些地方要改进，在公开场合说，有时对团队成员来说会是伤害，因此推荐尽量私底下约一个 1:1 来给回馈。

不只是给团队成员回馈，也要主动寻求团队成员给自己回馈，不论是从工程经理问，或者是从其他工程师问。具体来说，可以适时问其他人「有没有对我的任何回馈?」。不论是自己给团队成员的回馈，或者是团队成员给自己的回馈，请务必确保在回馈之后，有具体的行动方案，不要只停留在回馈，而是要真的在后续改善。

放手授权

成为资深工程师，不代表要把所有事情都揽在自己身上，因为重点是要把事情做好，资深工程师要懂得让团队成员有能力来分担重要的工作。

这样做有两个好处，第一个是避免自己燃烧殆尽 (burnout)，毕竟每个人的时间都是有限的，如果有越来越多任务要做，又事事抓在自己手上，一个不小心就会燃烧殆尽。

第二个好处是能避免团队成员失去成长机会。很多时候，有些资深工程师，因为担心团队中的人把事情搞砸，或者是会延后交付，所以资深工程师会想说自己来做比较稳、比较快。但如果从长期的角度来看，这对团队反而是不利的。如果要让团队成员能成长，有时候需要让成员自己体会过成长的痛；身为资深工程师，比起直接做掉，让成员练习主导，同时在旁确保不会有无法容许的错误，会从长期角度看更有益处的。

更进一步说，在带团队成员做技术讨论时，即使你已经有观点，也不要急着先发言。让团队成员练习分享自己的技术观点。过去看过非常多例子，当资深工程师讲完话后，其他工程师就都没有发言，或是不敢发言。这对团队成长也是有害的，除非是真的非常紧急，不然推荐先预留时间让团队成员发言。

在《软体工程师如何在职涯持续成长?》一文提到的，要让别人可以取代自己。从资深工程师的角度，要尽可能鼓励团队成员、表达对他们的支持，以及创造机会让成员能取代自己。过去我们看过最好的示范，是在跨部门讨论时，资深工程师让团队成员当主要分享者，而当进到问答环节，如果团队成员招架不住才跳出来挡。这样能创造让团队成员练习的空间，但又能确保团队成员不会因此受伤。

确保团队在对的方向上

前面两点分别谈了在思考时要以团队为角度，以及要授权让团队做事；然而，从团队的角度看，还有一点不能忽略的，就是资深工程师要确保团队在对的方向上。就像产品经理是负责产品的方向，资深工程师会负责团队中的技术方向，例如要不要换去用某个新技术、要不要做某个重构等，确保团队都是一齐朝该方向前进。

要确保团队在对的方向上，一个要点是去问「为什么我们要做这件事?」，借此来确保团队做的事情，是真正能带来价值的事。

同时，需要确保有清楚沟通该方向。在沟通方向时，不该只是沟通表层，还要让团队知道背后的原因。举例来说，如果要做一个大规模的资料库迁移，不只要讲要做迁移，还要让团队知道为什么这件事情重要，当团队知道事情的重要性，会更容易齐心朝该方向一起努力。

与此同时，要时时与团队成员沟通期待，要让成员知道你对他们的期待到哪里，并清楚界定团队中的工程师，每个人该负责什么、什么时候该交付。常见的做法，是透过每天的站立会议，来确保团队有在轨道上；以及每次任何会议后，要有清楚的待办事项以及负责人。