非一线工程管理者的一对一沟通

标签: dev | 发表时间:2023-02-26 00:00 | 作者:
出处:https://itindex.net/relian

一线工程管理者主要管理/领导工程师完成实际的工程任务,而非一线的工程管理者需要领导一线管理者,更多的关注团队本身,因此两者在做一对一沟通的时候需要有不同的关注点。原文:One-on-Ones for (Engineering) Manager of Managers [1]

如果没有耐心看完全文,可以直接拉到底部看结论。

我之前已经写了很多关于一对一的文章,基本上覆盖了和一对一沟通有关的所有一般性话题。到目前为止,所有文章都适用于团队的(工程)管理者(manager)及其上级管理者(manager of managers)。为什么我会更多的考虑这个方向?因为(工程)管理者的上级管理者相对比较小众,没有太多关于这些角色的具体知识分享,就连有关工程管理的书籍也缺乏深刻见解。你有可能会发现自己被迫领导一个更大的组织结构,需要领导那些正在管理/领导其他人的人,然而这一角色并没有合适的名称,你可能会像我一样自然而然的成为"管理者的上级(manager of managers)"。这篇文章就是为你所准备的,你可以找到一些关于怎样成为(工程)管理者的上级管理者的具体细节。当然,如果你只是好奇,也可以阅读本文。

那么,"管理者的上级"和"团队管理者"之间的一对一沟通有什么不同呢?为了理解这一点,需要看看这两种类型的管理者/领导者的不同目标。

(工程)管理者的上级有什么不同点

在团队管理者的组织架构下,我会配置:

  • 由个人贡献者组成的单一团队的(工程)管理者,或者
  • 在某些情况下,当没有(工程)管理者或大部分管理职责已经委托给TL时,配置技术/团队Lead,或者
  • 由个人贡献者组成的多个团队的(工程)管理者,其中所有的管理和领导活动都由一个(工程)管理者完成。技术Lead(如果有的话)是更资深的工程师,在团队中承担更多的技术领导职责。

另一方面,管理者的上级是需要领导其他团队管理者的人(见上文),通常下面会有:

  • 高级(工程)经理(Senior EM)
  • 工程总监(DoE)
  • 工程副总裁(VPoE)
  • 工程/研发主管(HoE HoD)
  • 首席技术官(CTO)

现在我们澄清了相关术语,接下来考虑它们的目的。团队管理者的目标是改善、促进、帮助、疏导所领导的人员的个人贡献。管理者的上级管理者的目标是被领导的管理者所领导的团队和组织。两者差别巨大,"增加了新的抽象层次(经理)" [1]

一对一沟通是如何处理这种差异的呢?通常情况下,一对一谈话将围绕管理者所领导的组织,而不是他们的贡献(尽管这也会体现在沟通背景中),所以你需要问这样的问题:

  • "团队的健康状况如何?"
  • "是什么阻碍了你的团队实现既定目标?"
  • 避免提出下面的问题: "你的个人贡献任务做得怎么样?"等等。

不仅要对属下的管理者负责,还要对他们领导的所有人负责。 [4]

上级管理者一对一沟通的特点

担任的职位越高,要处理的人的问题就越多。所以在一对一交流中,要做好心理准备。有一个有效方法可以用来处理这些问题,从而可以分配一些时间在一对一沟通的其他方面。这个方法我听说了很多次,最近一个有人(开发主管)强调他们处理的跟人有关的问题比其他人多的例子,就是在我现在的公司。这是不单单是我的经验,似乎也是有效的事实,其他一些领导者也表达了同样的观点 [4],所以你可以考虑一下:)。

当你被推到高级管理/领导角色时,会被期望自己负责定义更多愿景,而从一线管理者那里得到的反馈会更少。"没人会觉得有责任给你反馈" [2],所以你需要自己确定公司的发展方向。作为一名上级管理者的关键区别是,你将在与你领导的团队以及同事进行一对一交流的过程中寻求反馈(形成愿景或方向)。我想再次提醒你,随着你的资历越来越高,在考虑如何实现目标时,需要考虑越来越多的同事的目标。

如果你还没有在不同的工程领域(如开发、测试、运营等)之间切换,或者你还没有在其他领域的多样化职责的经验(例如。当你是开发人员时,就可以进行自动化测试),你将不具备其他人的专业知识。在这种情况下,当你要领导一个更大的组织时,可能不具备某些团队领域的专业知识,管理这些团队需要更严格的把握(对管理和进展的各个方面提出问题,即使是那些看起来进展很好的方面)。

"跟进所有小事情,直到确定哪些事情不需要跟进" [1]。例如:

  • 正在进行招聘吗?
  • 经理们在指导团队吗?
  • 目标制定好了?
  • 目标review过了?
  • 项目状态是什么?
  • 已经看过生产事故的事后分析报告了吗?
重要方面和特点

(工程)管理者的上级管理者比较小众,没有太多关于这些角色的具体知识分享。我已经介绍过适用于所有类型管理者/领导的一对一沟通,这是基础概念。

  1. 上级管理者的一对一对话将围绕所领导的组织,而不是管理者的个人贡献。"你不仅要对下属管理者负责,还要对他们领导的所有人负责。" [4]
  2. 上级管理者一对一沟通的特点:
  • 在一对一对话中,需要处理更多关于人的问题,而不是其他类型的问题。
  • 与领导的团队和同事进行一对一交流的过程中寻求反馈(形成愿景或方向),因为下级管理者会觉得没有责任做这种反馈。
  • 如果在某些团队的特定方面没有专业知识,管理这些团队就需要围绕管理和进展的各个方面提出问题。

总结

A. (工程)管理者的上级管理者是一个小众群体,没有太多关于这些职位的具体知识分享。

B. 你可能被迫领导一个更大的组织架构,领导那些正在管理/领导其他人的人。

C. 在团队管理者的组织架构下,我会配置:

  • 由个人贡献者组成的单一团队的(工程)管理者,或者
  • 在某些情况下,当没有(工程)管理者或大部分管理职责已经委托给TL时,配置技术/团队Lead,或者
  • 由个人贡献者组成的多个团队的(工程)管理者,其中所有的管理和领导活动都由一个(工程)管理者完成。技术Lead(如果有的话)是更资深的工程师,在团队中承担更多的技术领导职责。

D. 管理者的上级是需要领导其他团队管理者的人(见上文),通常下面会有:

  • 高级(工程)经理(Senior EM)
  • 工程总监(DoE)
  • 工程副总裁(VPoE)
  • 工程/研发主管(HoE HoD)
  • 首席技术官(CTO)
  1. 团队管理者的目标是改善、促进、帮助、疏导所领导人员的个人贡献。
  2. 管理者的上级管理者的目标是所领导的团队和组织。
  3. 两者有巨大的差别,"增加了新的抽象层次(经理)" [1]
  4. 一对一对话将围绕管理者所领导的组织,而不是他们的个人贡献。
  5. "不仅要对你的下属管理者负责,还要对他们领导的所有人负责。" [4]
  6. 上级管理者一对一沟通的特点:
  • 在一对一会面中,会处理更多关于人的问题,而不是其他类型的问题。
  • 与领导的团队和同事进行一对一交流的过程中寻求反馈(形成愿景或方向),因为下级管理者会觉得没有责任做这种反馈。
  • 如果在某些团队的特定方面没有专业知识,管理这些团队就需要围绕管理和进展的各个方面提出问题。
  • "跟进所有小事情,直到确定哪些事情不需要跟进" [1]。例如:
    • 正在进行招聘吗?
    • 经理们在指导团队吗?
    • 目标制定好了?
    • 目标review过了?
    • 项目状态是什么?
    • 已经看过生产事故的事后分析报告了吗?

参考文献

[1] Camille Fournier, "The Manager’s path", 2017, book

[2] Will Larson, "An Elegant Puzzle: Systems of Engineering Management", 2019, book

[3] Dr. James Stanier, "Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs", 2020, book

[4] Marcus F., https://lnkd.in/dghjKmQB, youtube videos


你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。
微信公众号:DeepNoMind

参考资料

[1]

One-on-Ones for (Engineering) Manager of Managers: https://medium.com/@despot.jakimovski/one-on-ones-for-engineering-manager-of-managers-acf90dc1832f

- END -

相关 [工程 管理 沟通] 推荐:

非一线工程管理者的一对一沟通

- - IT瘾-dev
一线工程管理者主要管理/领导工程师完成实际的工程任务,而非一线的工程管理者需要领导一线管理者,更多的关注团队本身,因此两者在做一对一沟通的时候需要有不同的关注点. 原文:One-on-Ones for (Engineering) Manager of Managers. 如果没有耐心看完全文,可以直接拉到底部看结论.

44 个工程管理课 | defmacro

- -
这很有趣,很累,很有意义——但最重要的是它是新的. 以前对你有用的东西现在不起作用了. 您必须掌握一套新技能,并在此过程中改掉一些坏习惯. 这是一个简短的指南,可帮助您入门. 与工程师交谈以尽早解决问题,然后尽可能解决它们. 与每位工程师沟通下一个他们需要解决的最重要的问题. 当开发团队无法达成共识时,成为决胜局.

#思想大碰撞#如何管理缺乏人际沟通技巧的开发人员

- - CSDN博客推荐文章
       奖励可以产生效率,调整看事情的角度是必要. 下面是一份双周刊,在一个免费的网络社区,对编程技术爱好者关于堆栈交换遇到的常见问题的问答部分.        在一家大公司,管理一个应用程序开发人员的小团队,处在其生命周期的中点,这很不幸的意味着,30/70分割其他技术工作这是常见的编程任务.

C++ 工程实践(3):采用有利于版本管理的代码格式

- tisyang - 博客园-陈硕的 Blog
陈硕 (giantchen_AT_gmail). 版本管理(version controlling)是每个程序员的基本技能,C++ 程序员也不例外. 版本管理的基本功能之一是追踪代码变化,让你能清楚地知道代码是如何一步步变成现在的这个样子,以及每次 check-in 都具体改动了哪些内部. 无论是传统的集中式版本管理工具,如 Subversion,还是新型的分布式管理工具,如 Git/Hg,比较两个版本(revision)的差异都是其基本功能,即俗称“做一下 diff”.

TOC之关键链项目管理遇到软件工程7原则

- - CSDN博客推荐文章
编著者:张克强    微博: 张克强-敏捷307. 美国著名软件工程专家鲍伊姆(B.W.Boehm,也又另译为勃姆)在总结软件工程准则和信条的基础上,于1983年提出软件工程的7条基本原则,也是软件项目管理应该遵循原则. 勃姆认为,这7条原则是确保软件产品质量和开发效率的最小集合,相互独立但结合得相当完备.

如何与PM沟通

- - 曉生
1.要学会听取别人意见,也许PM提出的问题你并没有考虑到,集思广益,可以得出有更好的方案. 值得肯定的是,你设计时已经能学会从产品角度考虑,引导用户操作,而不是单纯的好看. 只要不是单纯审美上的PK,都可以讨论,不是吗. 2.让产品阐述自己的需求点,明确重点. PM们七嘴八舌肯定不对的,要引导他们梳理出统一的意见.

团队沟通杂感

- - 人月神话的BLOG
随时随地的短时间的,快速迭代的培训和教练作用远远大于正规的系统培训. 系统性培训一个是针对性往往弱,另外一个就是对团队成员有较高的要求,即自我强烈的系统性学习欲望. 走动时管理目的是及时的发现各种问题和团队技能之欠缺点,有针对性的进行沟通和经验传递,这需要团队管理者有敏锐的洞察力,不能脱离到团队工作事务之外.

谈产品人的沟通

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  经常听产品经理说自己是打杂的,虽然这种说法有自我调侃的意味,但用这词来形容产品经理的工作也颇为贴切. 产品经理在一个公司中扮演的角色决定了他要做的事情多而杂,在一个产品诞生的过程中,从idea的诞生,产品的规划,UI设计,前端制作,程序开发,然后测试上线,上线后产品的优化等,产品人员一方面要全身参与,另一方面也要一直跟进.

我们需要怎样的沟通工具(一)情境沟通

- danaodai - 爱范儿 · Beats of Bits
自从进入了2011年,Kik、WhatsApp、Beluga、GroupMe、TalkBox等等几乎每周就有一个新的聊天工具冒出来,又看到 WhatsApp 获得八百万美金的 A 轮融资,我相信无论开发者们还是VC都相信的一个市场机会是,在移动互联网时代,一款完全基于移动设备的,并充分利用其能力而设计的沟通工具是一个很大的市场机会.

管理

- - 人月神话的BLOG
对于中小企业而言现在管理上欠缺的不是人治或者说儒家佛家等东方管理思想,而真正欠缺的是西方法治的科学管理方法. 现在很多中小企业花很多钱去听什么东方管理思想的培训是误入歧途,东西方管理思想需要融合,但是基础还是科学的管理方法和模式. 而在这个里面最重要的仍然是流程管理,知识管理,质量管理,项目管理这些内容,而不是简单的纯管理.