管理 - 走在管理的路上 （0）

很久以前，我在地里发了这么一个帖子 “为什么大牛们不怎么愿意发帖子或评论”，那是我再向向地里大牛们求助的呐喊，不过也许是大家都太忙了，于是我开始求助于书籍和meet up，通过其他途径来提升自己的认知，丰富自己的经验（抑或听来的经验），一点一点回答过去的自己的一些疑问。主要是一个阶段性总结，也许能给别人带了启发。还有就是作为一个成长的痕迹，当看着过去的自己，不论如何，这是很有意思的一个体验。

目的

这篇文章的目的，我个人Engineering Management Handbook总结的一部分，算作索引。写这个Handbook也是我一直以来想做的一件事情，总结一个自己的框架结构和reasoning，然后不断的去完善，未来也可以当作帮助他人成长的一个工具。反反复复思考了很久，因为工作繁忙，注意力被工作上的事情吸引住了。貌似工作永远很忙，所以，还是看如何去prioritize。还有一点就是写的过程也是一个思考的过程。

目前计划是最开始的版本，是根据自己的经历尽可能少“加工“地梳理一下比较high level的Engineering Management的框架结构和一些要点。这里“少加工”大概意思是，没有做过，没有触及到的工作内容，我尽量不会去谈及。这样的话，可以用这一个“框框”把所涉及的话题限定一下，不然，考虑内容的涉及范围之广，不是几篇文字能覆盖的到的。之后会慢慢的随着自己的认知的提高和经历的丰富不断去优化。

之前在“管理 - 走在管理的路上（续）” 基本上也覆盖到了大部分manager职责，不过是从reasoning到职责，算是一个bottom up的approach的简单介绍，如果仔细分析一下，基本上会涉及以下几个topic。

• People Management
• Technical Leadership
• Project Management
• Product Strategy
• Hiring
  

这些基本上覆盖了Engineering Manager的工作范畴，其中没提到一个比较模糊的部分是build system and process(整个team的一个workflow和process)，还有是对于产品和整个team发展的一个vision。具体工作内容和重点，因为公司和团队的发展阶段而侧重点不同，比如说，在一个startup的manager的工作可能会涉及以上所有内容，而在FLAG的manager可能因为不同组的需求不一样，focus的点可能不一样，比如有些可侧重于 people management和项目的管理，有些更像Tech lead manager (TLM)。其实可以去各个公司的career page去查看manager职位的responsibility，这也是工作的expectation和面试的内容（会在以后hiring部分详细解读responsibility）。因为过去几年一直在startup工作，现在的team也是一个startup氛围，team的structure比较扁平，很多东西（tech & organizational上的）都需要从头自己build或者老板build，做过的不少，见过的也不少，所以以上内容都涉及到了，可能还有其他内容，以后慢慢来添加。

People Management

这个是一个很大的topic，我个人的理解是建立一个好的环境能让团队开心地工作并带了大的影响。工作作为一个人人生当中除了睡觉之外花的最多时间的活动，如果不开心地度过，那该多么的遗憾呢。这里的开心范围可以是，完成项目、解决一个比较challenge的问题之后的成就感，修复一个bug接这一个bug，完成一个项目又一个项目之后，无法用言语描述的似乎可以conquer the world的感觉；抑或帮助别人解决一个问题，或者分享自己的知识帮助别人成长的那种快乐。当然了，还有随之而来升职加薪多多的bonus的快乐。而这些都是不同程度不同维度的impact。每个人的都是独立的个体，都有其特有的一些开心点或者容易不开心的地方，还有自己不一样的motivation。如何了解每个人，如何帮助他们更开心带来更大impact是部分的核心。

Transparency is the key to trust, trust is the foundation of influencing. - 我自己的理解

这部分涉及以下几个要点：

• 深入了解每个人
• 建立一个safe环境，让每个人都能坦诚交流
• 建立尊重和信任
• 帮助IC成长和build career
• 帮助IC带了更大impact
• 绩效管理：leveling expectations, performance review
• 1-on-1:最重要的途径之一，最重要的meeting
  

Technical Leadership

技术对于一个管理者来说重不重要，这似乎是一个经常被讨论的话题。这里讲一些我自身经历的一些经历，给出现阶段我的观点吧。

• 当对项目的技术栈不了解，怎么去评估项目的任务难度和任务量？
• 当对技术不了解，如何了解工程师的技术水平，能承担的任务？
• 当对技术不了解，如何去帮助工程师的技术成长，别忘了，技术是工程师的核心竞争力。
• 当对技术不了解，如何和团队商讨技术栈，保证团队技术方向在正确的道路上？
• 当对技术不了解，如何去技术面试，如和评估interview panel的tech interview report
• 当对技术不了解，怎么做code review，一方面了解每个工程师的技术和沟通（code review），另一方面确保code 质量和engineering practice。如何去把技术，规范和标准的knowledge教授给团队。
  

也许会有人说，可以让那些比较senior比较有经验的人去评估任务难度，任务量，去帮助工程师的技术水平，去面试。的确，前提是团队当中有这样的人，在团队（公司）发展一定程度，EM可以负责是类似与People Manager的职责，但如果team没有那么多senior的人呢？或者是一个小的团队，一个startup呢？在一个技术的startup，恨不得每个人都需要写code吧。

我刚才去查一下Facebook的一些Manager的responsibility，都是要求这么要求：

• Manager Example 1: Highly technical and effective people manager
• Manager Example 2: Be a highly technical, hands-on coder and an effective people manager
• Director Example: Proven software development skills with experience building software developed in Python, Objective-C, PHP, C/C++, Ruby, C# or other programming languages 😂
  

如果单纯从这些职责上读，都是先有strong techical skills，后是people manager。

这部分涉及以下几个要点：

• 对于整个团队的技术栈有个比较长远的vision，这个时候需要项目架构和系统设计上给予支持
• 确保技术规范工程流程（engineering practices）的严格执行
• Encourage learning/mentoring through code review and tech talk，让每个人都能在code review过程中学到engineering practices和新知识。
• 确保CI/CD运转良好
  

项目管理

这部分内容很产品关联很大，可能因公司业务性质而有所不同。这里就关注从产品经理拿到要做的项目开始，讨论一下执行，测试和发布的产品。项目可以是一个的product feature，或者一个code base的tech debt，抑或是架构优化等。发布迭代周期，比如说两周甚至一周一个版本发布。项目可以是一个engineer不到一周完成，到比较大项目需要多个人多个团队多个发布周期才能完成。
.--
这部分涉及以下几个要点：

• 清楚了解产品策略和目标
• 和产品经理商讨Roadmap确定要做任务的优先级
• 寻找能带来大的impact的项目，“挖合适的坑种合适树”。因公司团队和产品而异，有时候需要engineer自己找项目。
• 合理计划和安排任务，当涉及不同team的时候会比较tricky。比如说一些项目可能会涉及：后端，前端mobile和web，video team，QA，release，marketing 等团队。
• 讨论测试和发布日期
• 更加细节的day to day operation，保证整个团队高效运作。比如说帮助解决any blocker（product spec，不清楚的地方，或者改需求了，IC之间的work dependencies等），每个人的任务量，triage QA新报的bug。
  

最重要的一点就是prioritization。尤其是在资源有限的时候，focus is key。

Product Strategy

听过很多故事，某某feature被砍掉，甚至之前花了一年做的一个项目被抛弃。这个时候是非常让人沮丧的，然后作为manager，非常重要的职责就是深刻了解产品策略，尽可能让每个人做的事情的意义不仅仅是作为学习的一个途径而已。

.--过去让我很frustrated的地方是，我可以把这个产品需求做出来，但为什么要做呢？很多时候没有人care这部分，spec上顶多又一两句话解释why，但没有让我深刻了解why，我没有被convince这个东西到底有啥用，进而“没有意义”，IC只是一个工具而存在，过去这是让我很沮丧的。这部分其实属于People Management的范畴，前提是manger首先要明白这个why。

当然这写讨论是一个bottom up的approach讨论方式，不是因为不让IC不沮丧而很重视产品策略（的确也是）。只有产品的成功，大家的努力才有意义。

这部分涉及以下几个要点：

• 深刻了解并帮助优化product strategy
• 帮助优化product ideation process，比如说idea的来源，有时候可能是top down，有时候是IC提idea/feedback，甚至提idea和并执行，end-to-end。这个时候又和People Management联系起来了，让IC的工作变得更加有意义。
• 帮助roadmap优先级，比如可能一个小的feature并没有那么高的优先级，但可以很快做出来，有时候需要tradeoff。
• 对于某些产品需求，提供技术上的可能性的context，这个时候需要Technical Leadership skills。
• 帮助团队内对于产品感兴趣的工程师了解产品或者build这个career track
  

做项目是成长和晋升的途径。Manager相对更加了解产品策略，更加了解prioritization，更加知道哪些是比较重要的项目，能带来大的影响的项目。

您好！
本帖隐藏的内容需要积分高于 50 才可浏览
您当前积分为 0。
使用VIP即刻解锁阅读权限或查看其他获取积分的方式

游客，您好！
本帖隐藏的内容需要积分高于 50 才可浏览
您当前积分为 0。
VIP即刻解锁阅读权限 或 查看其他获取积分的方式

以上内容只是很粗略的介绍了engineering manager的high level工作内容。其中并没有提供很多reasoning，我的计划是以后针对每一个部分要点详细会介绍，提供一些后的逻辑，也是不断polish自己idea/reasoning的过程。

P. S.

本来计划是写不少于800字就好，但没想到那么长，自己可能都不会再看lol。

用时6个小时左右。最近几个月每个周末的一天都从家沿着水边（Embarcadero）慢跑到金门大桥下的Hopper’s Hands，单程七迈，来回十四迈左右，于是有了两个小时的在脑海中打草稿时间。从午饭后一直到现在，天色已经黑好，窗外bay bridge上一闪一闪的红色的警示灯，让我想到了寄托着盖茨比一生信念的绿灯，我的信念是我一定会把剩下的作业写完。

任思绪飞扬，只检查一遍错别字。更新的话，我尽量在这里更新，但请以Google Doc为准：管理 - 走在管理的路上 （0）

. check 1point3acres for more.18:00 11/08/2020

lz就是那个身材精瘦肌肉分明皮肤黝黑披头散发身穿蓝色短裤不论晴雨每天沿着Embarcadero跑步的眼镜哥吗？！（误。。。

楼主推荐这本书吗

yyy77 发表于 2020-11-10 14:36
楼主推荐这本书吗

什么书？

mark 感谢分享

感谢分享

NellyCat 发表于 2020-11-13 03:09
lz就是那个身材精瘦肌肉分明皮肤黝黑披头散发身穿蓝色短裤不论晴雨每天沿着Embarcadero跑步的眼镜哥吗？！ ...

我经常碰见那个哥们 😂

手机上Mark一下 长文打开电脑再看…
歪个楼 最近每个周末的一天都从SOMA到south beach然后沿着Embarcadero走一大圈 不知道有没有跟lz擦肩而过过后哈哈哈（误

楼主写得太好啦  期待后续的更新

我也是一个管理者 我其实最头疼的事情是给组员做评估
你能分享一点这方面的经验么？