Toc
  1. 管理你的时间:无论如何重要?
  2. 决定与授权
    1. 委托简单任务和频繁任务
    2. 自己处理简单和不频繁的任务
    3. 使用复杂且不常见的任务作为新晋领导人的培训机会
    4. 委派复杂而频繁的任务来发展团队
  3. 充满挑战的局势:拒绝的策略
    1. “是的,并且”
    2. 建立政策
    3. “帮我说是”
    4. 呼吁预算
    5. 以团队的方式合作
    6. 不要轻率
  4. 超越代码的技术要素
  5. 衡量开发团队的健康状况
    1. 发布频率
    2. 代码签到频率
    3. 事件发生频率
  6. 好经理,坏经理:我们对他们,团队合作者
  7. 懒惰和急躁的美德
  8. 评估自己的经历
Toc
0 results found
第六章:管理多个团队
2020/07/20

欢迎来到多团队管理的世界!在讨论管理经理之前,我们将讨论管理多个团队,因为尽管这些事情是相关的,但它们不一定是一致的。但是,你现在可能已经有技术主管向你报告,并且在了解几个团队发生的事情的细节的过程中,忙于直接管理三到四个人的工作可能意味着一件重要的事情:你没有写(几乎任何生产)代码。

当我为上一份工作创建职业阶梯时,工程总监通常是一个人开始管理多个大型团队的地方。让我们回顾一下我的工程阶梯中的一些描述:

工程总监负责技术团队的重要工作。工程总监通常会领导多个产品领域或多个技术功能的工程师。技术负责人和个人贡献者都向他们汇报。

通常不期望工程总监每天编写代码。但是,工程总监负责其组织的整体技术能力,并通过培训和雇用在整个团队中根据需要指导和发展这种能力。他们应该具有强大的技术背景,并花一些时间研究新技术并紧贴技术行业的发展趋势。他们将有望帮助调试和分类关键系统,并应充分理解他们所监督的系统,以执行代码审查并根据需要帮助研究问题。他们应该主要通过在技术上表达精明的声音,向团队中的工程师提出业务和产品方面的问题,从而为架构和设计工作做出贡献。

工程总监主要关注确保复杂交付物的顺利执行。为此,他们专注于确保我们不断评估和完善我们的开发 / 基础架构标准和流程,以创造可为企业带来持续价值的技术。他们负责创建高性能,高速度的组织,随着我们业务的发展和发展,对流程进行度量和迭代。他们是组织招聘,人员管理和计划,职业发展和培训的领导者。必要时,董事将管理供应商关系并参与预算过程。

工程总监的影响力应遍及技术组织的多个领域。他们负责在组织中创建和培养下一代领导和管理人才,并帮助该人才学习如何平衡技术和人员的领导与管理。他们着迷于创建功能强大,敬业度高,积极进取的组织,并且期望他们在组织内拥有保留目标。此外,工程总监负责在战略上平衡以产品 / 业务为中心的近期和长期工作与技术债务和战略技术开发。

董事是强有力的领导者,他们为技术与公司其他领域之间以及跨技术部门之间的跨职能协作树立了榜样。此次合作的目的是创建战略和战术技术路线图,以解决业务需求,效率和收入以及基础技术创新。主管是一个非常有影响力的沟通者,他可以简化技术概念以向非技术合作伙伴解释这些概念,并以启发和指导他们的方式向技术团队解释业务方向。工程总监帮助在 Rent the Runway 技术上建立良好的公众形象,并能够将公司及其地区出售给潜在的候选人。

由于他们既接触技术又接触业务驱动因素,因此董事负责指导组织中所有团队的目标制定过程,帮助这些团队阐明支持业务计划,技术和组织质量的目标。

我竭尽全力确保我们明确指出工程主管不一定每天都在编写代码,因为我认为,负责多个团队的动手管理的人员很难编写代码。至此,你的日程安排可能已经从“制造商”转移到了“经理”。在你的 1-1 之间,与其他工程主管的会议,团队计划会议以及在产品管理或其他业务职能方面与同行的会议之间,你可能很忙。在这一点上要切实可行。如果你没有固定的时间来投入时间,并且你不能切实保证至少每周有几天的时间,那么你编写的任何代码都会非常缓慢。

对我们来说幸运的是,有许多方法可以动手操作,而无需编写大量生产代码。至少作为辅助审阅者,与实践一起进行代码审阅是一件好事。如果你在动手时创建了系统,请与这些系统保持联系,因为你将比大多数记忆更好的细节,并且可以通过代码审查和问题帮助在这些系统中工作的工程师。调试和生产支持也很有价值。你如何动手操作取决于你的技能。如果你在进入管理之前不是一个强大的调试器,那么跳入事件可能会比有用的事更令人讨厌。在进行配对编程或修复较小的错误或功能时,你可能会更有帮助。因此,我们常常减少这些小小的努力是不值得的,

如果你在担任此职位之前没有花费足够的时间进行编码,以使自己深入,流利地使用至少一种编程语言,那么放手的风险会大大放大。我强烈建议你在进入管理之前花时间来精通编程。对我来说,这花了大约 10 年的时间,其中包括我的本科和研究生学位。你的执行速度可能比我快,但是在这方面要仔细检查自己。在花了有限的时间来加快编写,使用标准开发环境并在标准框架中工作的基础知识之后,你是否感到至少使用一种编程语言足够熟练,可以有效地为用它编写的良好代码库做出贡献?和图书馆?最终,即使最深的知识也会萎缩,

有用的流利度还需要对使用这种语言进行高效工作的意义有深刻的了解,希望与其他人一起构建生产软件。如果没有这种构建软件的节奏感,那么你将在此级别上面临工作的关键部分之一的麻烦:调试团队问题并保持团队平稳地生产高质量的软件。

最后,即使你不打算编写太多代码,我也强烈建议你每周至少有一个固定的半天时间,完全没有会议或其他义务,并尝试将这段时间至少部分用于某些创意追求。你可以为工程博客撰写博客文章,准备会议讨论或参与开源项目。采取一些措施来消除这种创新性的痒,否则你可能很难以经理的身份去抓。

询问首席技术官:我想念代码!

我正在管理两个复杂的团队,而我的管理职责迫使我退出技术职责。我发现我非常想念代码。这是否表明我不应该成为经理?

几乎每个从大量动手的技术角色转到管理工作的人都有一个过渡期,在过渡期中,他们经常质疑自己是否犯了错误。此外,许多人担心他们在此过程中会失去所有宝贵的技能。问问自己,你是否已经将管理不是工作的想法内部化了。科技行业充满了鄙视管理的人,认为这不像编写代码那么重要。但是管理是一项工作,它是必要且重要的工作,尤其是现在,这是你的工作。

编写代码充满了胜利,特别是对于有经验的开发人员而言。你使测试通过,看到了新功能,你可以编译一些东西,解决了一个问题。管理层没有明显的捷径,特别是对于新经理而言。当你和你的计算机同时不必面对所有这些凌乱而复杂的人时,自然会感到对简单时期的渴望。当你刚开始全职工作时,你可能在上学时也有类似的怀旧之情,因为当你离开学校时,你确切地知道可以从中学到什么。可以在较简单的时期感到怀旧,也可以对自己放弃的事物感到恐惧。但是你不能一次完成所有操作。要成为一名出色的经理,你需要专注于管理技能,这就需要放弃一些技术重点。这是一种折衷,你必须决定自己是否可以胜任。

管理你的时间:无论如何重要?

当你承担太多管理职责而几乎没有时间编写代码时,你可能会开始觉得自己的一天被别人的异想天开作为人质。你开始看到会议堆积如山:一对一,计划会议,状态更新。站起来。坐下 打架打架!

等等,不,在作战室没有战斗!

现在是时候了,现在你可以确定如何管理时间。否则,你会发现自己的日子已经一去不复返了。你仍然有作为经理的责任。你仍然拥有一些可交付成果,除了参加会议以外,还需要做更多的事情,例如为团队设定目标,帮助你的产品团队在产品路线图上提供详细信息以及确保分配的任务实际上已经完成。如果你不注意的话,最后一项任务完成后的跟踪可能会成为你一天中最大的时间消耗和分心时间之一。

时间管理是个人的事情。有些人很有条理,而这些人制定了复杂的策略来管理日历和待办事项。我为这些人鼓掌。我通常不是其中之一。但是,我发现 David Allen 的书 《Getting Things Done 》[1] 中的构想很有用,即使你不采用整个过程,我也建议你阅读它。

同时,无论你采用何种战术,我的一般时间管理理念都将为你服务。时间安排归结为一件重要的事情:了解 重要性 紧迫性 之间的区别。你的几乎所有任务都将落在这两个元素的图表上。大致上,它们位于四个象限之一(请参见表 6-1)。

不紧急 紧急
重要 战略性:腾出时间 明显的工作
不重要 明显避免 诱人的分心
表 6-1:优先安排时间

如果这很重要而且很紧急,那么你就可以这样做。你懂我在说什么。你正在协助解决重大故障。绩效评估报告将于明天提交。你想向一位优秀的候选人提出要约,而他的另一项竞争要约在两天内到期。如果你将球丢到该类别的任务上,则会损失一些明显的东西。你不太可能对完成这些事情的需求视而不见。

当你开始失去重要性时,就会出现时间管理挑战的很大一部分。人们通常更清楚地感到紧迫感而不是重要性。回复电子邮件就是一个很好的例子。分散注意力很容易被电子邮件吸引,因为红点告诉你有新内容,因此你迫切需要确认它。但是,电子邮件真正紧急的频率是多少?电子邮件可能是传达紧急的,对时间敏感的信息的最糟糕的手段。感觉很紧急,但并不紧急。这就是为什么这么多精确的时间管理提示会鼓励你在一天中的特定时间阅读和回复电子邮件的原因。我们也倾向于用 明显 代替 紧急 在确定某物的价值时。如果你的日历上有会议,那很明显你当时应该在哪里,但是那次会议真的很紧急吗?还是你正在使用它来避免思考最佳的时间利用方式?

有很多事情并不紧急,这很紧急。例如,整个互联网。新闻,Facebook,Twitter。聊天可能感觉很紧急,但是在并置团队的情况下,聊天几乎像电子邮件一样糟糕,无法传达真正紧急和重要的信息。我们已经将现代技术工作场所中的许多通信方式从电子邮件转移到了 Slack 和 HipChat 等聊天系统中。这有其优点和缺点,但是必须注意,移动通信与消除通信不是一回事。文字和信息不断流动,它们只是移动到不同的地方,而聊天中不断变化的信息细流会使你分心。

你可能将大量时间花费在紧急但仅次要的事情上,而牺牲了重要但非紧急的事情。一项重要但并非紧迫任务的示例实际上是为会议做准备,以便你以健康的方式指导会议。健康的会议需要所有各方的参与,而有利于短期但富有成效的会议的文化要求参加者做一些前期工作才能参加准备好的会议。作为多个团队的经理,你可以通过将高效的会议文化推向团队来赢得很多时间。让人们负责以任何合理的方式进行准备。事先询问议程项目。任何涉及一群人的标准会议,无论是计划中的,回顾性的还是事后调查的,

与上一级别相比,此级别的主要变化之一是老板希望你足够成熟,可以独立管理自己和团队。这意味着你的经理相信你能够在所有紧急但并非紧急的事情变得紧急之前,特别是在对你的经理变得紧急之前,主动处理所有这些重要但不紧急的事情。没有人会告诉你如何管理日历,以给自己时间来做。我已经看到经理们在这一点上失败了,因为他们无法以一种有组织的方式来处理所有不同的任务。

会议可以属于紧急但不重要的类别,你可以决定在不需要的地方不参加会议。在此特定级别的管理上过度部署此策略时要非常小心。保持团队成功前进并快乐参与的责任在你肩上。当你停止参加他们所有的内部会议时,你可能会错过会帮助你及早发现问题的线索,这主要是因为存在太多无聊的会议。在会议期间,环顾团队中的房间并注意他们的参与。如果其中有一半人正在睡觉,凝视太空,在手机或笔记本电脑上无视会议程序或以其他方式脱身,则会议浪费了他们的时间。你参加这些会议的部分原因是要注意团队的动力和士气。一个快乐的团队会充满活力和参与度。一个不快乐或没有动力的团队会感到筋疲力尽或无聊。

回到重要但不紧急的事情。在这个清单上,对未来的思考很重要。毫无疑问,你知道应该做些但已经推迟的事情。也许是为你要招聘的职位写工作说明。也许它完全在制定招聘计划。它可能正在审查一个项目的当前工作,以确保没有明显的问题正在蔓延,或者正在与另一个团队的经理交谈,该团队存在关于如何在共享问题上前进的冲突或意见分歧。这可能是在培养重要的事情清单,但是你已经有一段时间没有考虑了,因此你知道该注意什么。如果你不花一些时间专注于这些问题,它们将以负面的方式潜伏在你身上。作为多个团队的经理,你负责平衡思维的广度和深度,

当你浏览新的义务时,开始问自己:我做的事情有多重要?它是否因为紧急而显得重要?我这星期花了多少时间在紧急事情上?我是否有足够的时间抽出时间来处理不紧急的事情?

成为经理的最艰难,最短的教训

作为经理,我对我的团队需要的事情有一个清晰的清单。我正在监视的事物,我试图修复的事物,我试图为他们找到的事物。了解正在发生的事情以及整个团队需要提高效率是我的工作。

也许你可以看看情况,然后说:“我们现在有一个截止日期,而我们需要的是下个月的另一位工程师。那个工程师就是我。”

但是你更有可能查看情况,并意识到你的团队需要的是经理。因为你需要再雇用 X 个人。因为 Y 有很多潜力,但需要一些指导。因为产品或设计或其他团队没有给你所需的东西,所以你需要去获取它。因为过程很重要,而你所拥有的过程是不充分的或完全是错误的。

如果你的团队比经理更需要经理,那么你必须接受成为经理的定义,就意味着你不能成为工程师。我知道有些人会同时管理这两者,但是你需要决定,如果要吸引一个,那将是哪个。

当我沉迷于成为一名工程师时,我会感到难过,但是当我沉迷于成为一名经理时,我会给别人一个选择。这不公平。

因此,在第二天结束时,我感觉自己编写的代码不够,无法量化自己所取得的成就,我告诉自己,我正在尽自己的能力成为一名优秀的经理。今天就足够了。

凯特·休斯顿

决定与授权

这些天结束时你感觉如何?如果你像许多新的专职经理一样,可能会觉得很累。即使你没有编写很多代码(或任何代码!),整天,当你回到家时,你发现自己没有精力决定晚餐吃什么,没有兴趣爱好和渴望吃舒适的食物,也许喝啤酒,然后呆呆地盯着计算机或电视,直到该睡觉了。

即使你的工作时间并不多,管理多个团队的头几个月也感觉像是一场死亡游行。你曾经集中的注意力在每天度过的各种会议之间被切成薄片。在管理多个团队的头几个月中,我反复失去了声音。我每天都没那么多闲聊。我的一个朋友最近成为工程总监,她不得不开始请助手点午餐,因为她发现自己会忘记吃东西,而且当她意识到自己需要食物时就没有精力决定吃什么。

因此,首先,这是一个坏消息:解决这种情况的唯一方法就是解决它。实际上,我希望大多数人都会经历一段时间。如果你根本没有经历过,要么算上自己非常幸运,要么仔细检查一下,以确保你真的在关注所有需要注意的事情。根据我的经历,既要经历这种过渡又要管理其中的人,如果你觉得自己不知所措,那你可能会错过一些东西。

从现在开始,描述管理感觉的最佳方法是板纺。如果你不熟悉它,则板式旋转是一种杂耍的奇特形式,杂耍者有多个杆,每个杆都在其顶部旋转。杂耍者必须注意每个板块,然后才能放慢速度以使其跌落下来。板块就是你要监督的人员和项目,你的工作是弄清楚每个人在什么时间需要多少关注。重要的是你要以学生的思想来进行这种旋转。你仍在学习如何旋转印版,并且由于将它们忽略太久而将其丢在地板上。磨砺你何时触摸哪个盘子的本能。

现在好消息来了:随着时间的流逝,你会变得更好。你的直觉会有所改善。你将开始认识到项目进展缓慢,准备退出的人们以及表现不佳的团队的预警信号。我在上一节中建议你仔细考虑退出会议,部分原因是你可以在这些会议上了解健康和不健康的动态。这也是为什么我强烈建议你与直接向你报告的每个人保持定期,可靠的 1-1 会议的惯例的原因。如果人太多,则可能需要缩短会议或每两周而不是每周举行一次,但是由于忙于其他事情而跳过 1-1s 是错过一个员工警告信号的好方法。要退出。

我称此部分为“决策与授权”,那么授权适合什么地方?委派是使自己摆脱一次过多旋转的感觉的主要方式。随着任务的来临,问问自己:我需要成为完成这项工作的人吗?答案可能取决于几个因素(请参见表 6-2)。

频繁的 很少
简单 委托 自己做
复杂 委托(认真) 培训委托
表 6-2. 决定何时委托或自己做

任务的复杂程度和频率可以作为确定是否以及如何委派的指南。

委托简单任务和频繁任务

如果任务很简单且很频繁,请找一个可以交给他的人。简单而频繁的任务的示例可能包括运行每日站立,每周编写团队进度的摘要或进行次要代码审查。你的技术主管或其他高级工程师可以承担这些任务的责任,甚至可能不需要培训就可以做到。

自己处理简单和不频繁的任务

如果你自己做某件事比向他人解释要快,并且几乎不需要做,那么即使你认为自己在做任务,也要袖手旁观然后做。从为你的团队预订偶尔的会议票到运行生成季度报告的脚本,任何事情都可以。

使用复杂且不常见的任务作为新晋领导人的培训机会

编写绩效评估和制定招聘计划等任务仅由你自己承担。但是,这些也是你想要传递给新晋经理的技能。你可能需要一位技术主管陪同你编写实习生的绩效评估,或者让一位高级工程师提供反馈,说明他认为明年需要多少新人来支持一个项目。在完成这些任务之前,从上方寻求帮助,直到你感到舒适为止,但是一旦感到舒适,就开始聘请上升的领导者来学习如何完成任务。

委派复杂而频繁的任务来发展团队

诸如项目计划,系统设计或在停电期间成为关键人物之类的任务是最大的机会,你需要在团队中培养人才,同时还要使团队运作得更好。优秀的管理者会花费大量时间在这些领域中发展团队成员。你的目标是使你的团队能够在没有你大量投入的情况下进行高水平的运营,这意味着他们将需要能够接管这些复杂任务并在没有你的情况下运行它们的人。

你的团队在学习如何独立运作,还是要让他们依赖关键功能?列出你只有自己真正知道如何为团队做的任务。其中一些可能是适当的,例如编写绩效评估或制定招聘计划,但其中许多对于教你的团队实现自我很重要。项目管理。新加入团队成员。与产品团队合作,将产品路线图目标分解为技术可交付成果。生产支持。这些都是团队成员需要学习的所有技能。教他们可能需要一些时间,但从长远来看,它将节省你的时间。不仅如此,教会你的团队如何做这些事情是你工作的一部分。作为经理,你有责任在组织中培养人才,

授权是一个开始缓慢的过程,但已成为职业发展的基本要素。如果你的团队在没有你的陪伴下无法良好运作,那么你将很难晋升。培养你的才华并将决定推向那个才华,以便你可以找到新的有趣的板块来学习如何旋转。

询问 CTO:警告信号

现在,我经历了几次团队意外挣扎的经历,一个人没有警告就退出了。我是否可以寻找任何警告信号来尽早发现这些问题?

经过一段时间的管理,肯定会有信号开始引起你的注意。这是我学到的一些知识:

  • ** 通常会变得健谈,快乐和订婚的人开始提早离开,迟到,在工作日休息,在会议中保持安静,不闲聊。** 此人有重大个人问题或准备退出。通常,人们会在遇到个人问题时(例如生病的亲戚,人际关系问题或健康问题)告诉某人,但并非总是如此。如果这是在重大调整(例如晋升,团队重组或其他事件)之后发生的,则该人可能会觉得自己被忽略了。无论出于何种原因,你都可能希望进行坦诚的交谈,并设法在她辞职之前找到问题的根源。
  • ** 这位技术负责人声称一切进展顺利,但经常跳过 1-1,很少在其状态更新中提供详细信息。** 这个人可能藏着什么。通常,他所隐藏的是进度远远比他预期的要慢,或者他正在构建超出项目范围的东西。帮助他及早制定清晰的项目计划,并为在事情发生变化时如何调整计划设定期望,这样他就很难隐藏缺乏进展的情况。还可以帮助他阐明项目的目标和范围,这对于某些新技术领先者来说可能是艰巨的。在管理头顶上的新员工时,你可能会遇到类似的情况。这也与花费大量时间倡导新语言 / 平台 / 流程而不是完成工作的人有关。
  • ** 团队在会议中完全没有精力。** 实际上,会议就像是一场总的谈话,产品经理和技术主管会进行所有讨论,而团队的其他成员则静静地坐着或仅在需要时讲话。缺乏参与会议的倾向往往意味着团队没有参与工作或感觉自己在决策过程中没有发言权。
  • ** 团队的项目清单似乎每周都会变化,具体取决于当天客户的异想天开。** 这个团队除了讨好客户之外,没有考虑过其他目标,因此可能需要更好的产品或业务方向。
  • ** 一个小的团队内部在理解上非常分散。工程师声称对他们不使用的系统不了解,并且缺乏了解这些系统的好奇心或开放性。** 与较大的团队或公司相比,该团队在他们的日常工作和所接触的系统上有更强的识别力。他们可能无法根据大型团队或企业的需求更改系统。

充满挑战的局势:拒绝的策略

经理的工作涉及通过创造可以进行工作的肥沃环境,使员工轻松完成工作。她专注于团队,以便他们可以做自己最擅长的事情。她在团队中培养友情和友谊,并帮助人们学习新技能。在所有这些方面,她都是推动者,教练和冠军。

但是要创造这种环境,她有时必须拒绝。她必须对团队拒绝。她必须对同伴说不。她甚至必须对老板说不。这些拒绝中的每一个都以其自己的方式很难,并且一个强大的经理必须制定有效的策略来拒绝。我已经确定了一些。

“是的,并且”

当你是经理时,对老板说不,看起来很少是简单的“不”。相反,它看起来像即兴喜剧的“是的”技术。“是的,我们可以做那个项目,而我们要做的就是推迟当前正在规划中的另一个项目的启动。” 在保持积极态度的同时仍要阐明现实的界限,这将使你进入高层领导的主要联盟。对于大多数工程师来说,这种肯定的否定是一项非常难的技能。我们习惯于表述项目的缺点,而要摆脱“不行,这不可能”的习惯很难。开始掌握“是,然后拒绝”的策略,尤其是在与老板和同事互动时,并了解它通常如何将有争议的分歧转化为优先考虑的现实谈判。

建立政策

当涉及到你的团队时,你想帮助他们了解达到“是”的要求。也许你正在与一位想为项目切换到新的编程语言的工程师打交道,而你的团队不使用这种语言。对于这种语言为什么是工作的完美工具,他有一些很好的争论,但是你不愿意仅仅因为它是完美的就添加新工具。你可能会很想说不,给出理由,然后离开,有时这会起作用。但是你可能会发现自己反复讲同样的“不”,并给出相同的原因。“不,我们需要更多的人知道这种语言。我们需要了解将这种语言投入生产的意义。” “不,我们需要制定日志记录标准;我们需要考虑一下测试的样子。” 当你开始重复自己时,你有制定合理政策的基础。该政策包括必须接受的严格要求才能说“是”,以及一些考虑该决策的准则。制定政策可以帮助你的团队提前了解达到“是”的成本。

“帮我说是”

政策很有用,但并不能涵盖所有情况。下一个策略“帮助我说是”类似于策略写作,但是对于没有明确策略的一次性实例效果更好。有时你会听到一些想法很不周到的想法。“帮我说是”意味着你要提出问题,并挖掘对你来说似乎很可疑的要素。通常,这种提问方式可以帮助人们意识到自己的计划不是一个好主意,但有时他们的思路会令你惊讶。无论哪种方式,对思想的好奇地询问都可以帮助你说不,同时教你。

呼吁预算

当涉及到团队和同事时,你可以使用的一种策略是吸引时间和预算。用简单的方式列出当前的工作量,并显示出没有多少回旋余地。有时,这与“现在不行”相结合,这是另一种消极激进的拒绝方式。“现在不行”表示你可能同意这个想法,但目前不能这样做,因此也许将来会使用。这通常是正确的,因此很容易退回到“暂时不”模式。但是,正如我之前讨论的那样,当你隐含地承诺“现在不行”意味着你将认真地“以后”做某事时,你需要确保以后会真正发生。

以团队的方式合作

说到你的同龄人,有时候你和你的同龄人(尤其是跨职能部门,即你的产品或业务同龄人)需要一起行动以拒绝。这可以适用于任何级别的否。有时,你会使用技术授权以对产品团队有利的方式拒绝。有时你会向财务部门求助,以帮助你对某些预算超支说不。扮演好警察 / 坏警察可能有点不诚实,因此请谨慎使用,但将自己的权限放到否定上会很有用,然后在将来需要你自己的否定支持时可以帮忙。

不要轻率

当你知道你需要拒绝时,最好快点说出来,而不是延迟并拖延该过程。如果你有权拒绝,并且你不相信会发生什么,请帮自己一个忙,不要为整个过程感到痛苦。有时你会错,因此当你发现自己太快不能回答时,为犯该错误表示歉意。你将没有足够的精力仔细地调查和分析每个决策,因此,对于低风险,低影响力的决策,请练习快速做出否定(以及快速做出肯定!)。

询问 CTO:我的技术负责人没有管理

我有一位技术负责人,他应该负责一个项目的初级工程师,该项目将我们的应用程序从 Objective-C 重写为 Swift。我刚刚发现,初级工程师仍然没有创建项目计划,也没有回答我在设计审查中给出的任何反馈。如何在无需介入的情况下让技术负责人进行管理?

委派失败。听起来你的技术主管不理解你要让她负责确保初级工程师跟进设计反馈并创建项目计划。所以第一步是要问技术主管为什么这些事情还没有发生。

你将获得的答案可能是综合的。第一,技术负责人忙于自己的工作,不记得跟进初级工程师。发生这种情况,你必须提醒她,必须与她的代码和其他职责一起安排指导和监督此人的工作。

第二,技术负责人在不希望按时间表进行工作时可能不知道该如何推动初级工程师。询问她如何尝试从他那里获取信息,并查看你是否有机会提出不同的建议。有时,新技术负责人不愿将人员推向项目计划,因为他们不觉得自己有权力,当他们索要某些东西时会感到沮丧,而另一个人却从来没有交付过。

最好的办法是与你的技术负责人一起工作,使她具有技巧和信心,可以向团队其他成员索取报告。这将比介入并自己问他们要慢,但是你将教会团队尊重她的要求并教她如何独立领导团队。

超越代码的技术要素

此级别的管理变得混乱。我们聘用的经理部分基于他们的技术技能,但是我们许多人认为这项工作并不是真正的“技术”。毕竟,经理可能不会写太多代码或进行太多系统设计,对吗?

假定此级别的工作基本上是非技术性的,这是一个错误。事实证明,运行有效的工程团队不仅仅具有纯粹的管理技能,而且在此级别的管理将要求你学习一些新技能,如果你了解软件工程的实践和纪律,这些技能最容易学习。你现在将把技术重点转向观察和改进开发人员正在其中运行的工作系统。特别是,你现在需要关注整个团队的技术健康信号。但是那些健康信号是什么?

流行的管理书籍 《首先,打破所有规则》 [2] 讨论了你可以回答的几个问题,以帮助预测团队的生产力和满意度。其中包括:

  • 我知道工作对我有什么期望吗?
  • 我是否拥有正确完成工作所需的材料和设备?
  • 我有机会每天做我最擅长的事情吗?

对于大多数工程师而言,这些问题的答案可以通过他们推送代码的速度和频率来区分。如果他们需要做的工作很明确,他们就知道要编写什么代码。如果工具,票证,自动化和过程可用并且易于使用,则它们可以编写代码。而且,如果他们不会因过多开会而分心,也不会沉迷于支持和事件管理,那么他们将有机会每天编写代码。这些健康信号 - 代码发布的频率,代码签入的频率以及事件的频率不高 - 是团队知道该怎么做,拥有该工具并且每天都有时间进行的关键指标。

衡量开发团队的健康状况

当你专注于开发团队的健康时,请戴上技术帽来设计将使事情保持前进的系统和流程。创建开发人员完成工作所需的工具。帮助他们集中精力,以便他们可以轻松确定下一步需要做什么。询问每个过程以确定其应提供的价值,并始终问自己是否可以进一步自动化。考虑使用这些方法来衡量团队的健康状况。

发布频率

第五章 我谈到了技术团队的常见功能障碍不是发布代码,而发布频率是对此最直接的度量。如果你的公司不喜欢频繁发布代码的价值,对不起。在这个现代时代,代码更改的频率是一支健康的工程团队的主要指标之一。以产品为中心的团队的优秀工程经理知道如何创建团队可以快速移动的环境,而快速移动的一部分需要将工作分解成小块。即使你的公司不满意,你也必须努力帮助你的团队实现产品的最佳发布频率。以免你认为这不适用于你,因为你正在构建的产品(例如数据库)的发布频率不高,

你为什么不更频繁地发布?看一下你的团队。如果他们不连续或每天不发布,发布过程是什么样的?多久时间?在过去的几个月中,关于发行版本的问题多长时间出现一次?出现问题时会是什么样?由于问题,你不得不推迟或推迟发布多少次?延迟或回滚有什么影响?你如何确定代码是否准备好投入生产?这需要多长时间?谁主要负责确定这一点?

我敢打赌,如果你老实地看一下一个不经常发布的团队,你会发现裂缝。执行发布的过程需要很长时间。工程师不会对代码质量感到主人翁,他们将所有工作留给了质量检查团队,这造成了很多来回通信延迟。在发行不当的情况下回滚代码需要很长时间。在发布过程中出错,导致生产事件(或破坏的开发版本)。团队中的许多弊端来自无法经常释放。

现在,你可能会说:“谢谢你的建议,但是我没有时间用我们必须交付的产品路线图来解决这个问题。” 或者,“我们的系统并非旨在频繁发布。” 或者,“我们不时地改变事情并不是那么重要。”

就是这个 你的团队是否正在全力以赴?你的工程师面临挑战并在成长吗?你的产品团队对正在取得的进步感到兴奋吗?人们是否能够将大部分时间都花在编写新代码和发展系统上?如果是这样,那太好了。不理我。你已经掌握了一切。如果不是这样,则说明你遇到了问题,而忽略了这个问题,后果自负。

重要的是要记住,作为一名技术主管,虽然你可能不会编写太多代码,但是你仍然要负责完成工作的技术方面。你还负责保持团队的快乐和生产力,而解决此问题的方法通常不是拉拉队,提高他们的薪水或对他们的称赞,而是使他们提高生产力,挑战他们更快地开展工作,做得更好,并帮助他们找到使他们的工作变得更加有趣的时间。你必须成为倡导者,并推动技术流程的改进,即使你不是自己全部实施,也可以提高工程师的生产率。

推动更频繁发布的好处在于,它通常会发现许多有趣的挑战。没有一种增加释放频率的真正方法,因为频率问题在团队之间会有所不同。你几乎肯定需要解决一些自动化元素。开发人员工具启用对你的代码库有意义的功能切换是另一个常见的挑战。考虑构建代码以在不破坏向后兼容性的前提下向前发展,滚动系统升级以及实施小的更改而不是大的补丁程序—所有这些事情都可能需要解决。即使你不做工作,你也有责任领导这里的工作。缩短产品路线图的时间,以支持不断提高的工程效率,并为激励他们加快团队前进速度的团队设定目标。

代码签到频率

很难有一个敏捷的团队不了解将工作分解成小块的价值。你可能需要向大学以外的新员工讲授此技能,但即使是高级开发人员有时也需要在这里进行推广。我不会倡导任何特定的软件开发方法,但是我发现不编写测试的工程师通常很难分清工作,学习如何进行测试驱动的开发(即使他们不这样做)。实际练习每天都可以帮助他们提高这项技能。

我专注于此主题,因为作为新经理,对于告诉可能已经编写了比你更长或更长的代码的人,他们的风格需要更新可能非常不舒服。避免冲突在我们大多数人中根深蒂固,感觉像个人风格的事情可能特别困难。如果你的公司希望产品开发能快速发展,那么想花几周时间只写代码而不将其推到共享版本控制中的工程师,将使你的团队变慢,并引起问题。你没有管理研究团队。(是吗?那么跳过本节!)可以期望定期更新进行中的工作,这是可以的。

事件发生频率

团队所生产软件的稳定性如何?质量在提高,变差还是保持不变?确定要构建的产品所需的软件质量水平,并随着时间的推移调整该度量标准,对于你(经理)来说是一项技术难题,需要帮助解决。如果你要为规模不大但正在发展的企业构建全新的产品,那么关注功能而不是稳定性可能更为重要。另一方面,如果你拥有关键任务系统,则稳定性和事件最小化可能是你的重中之重。此处的目标是以某种方式平衡风险,即事件发生频率和事件预防都不会变成一项工作,使开发人员不必每天花几天时间编写代码。

你可能在一家拥有开发人员支持他们编写的代码或系统的公司工作。这个过程有一些缺点。重要的是,期望团队中的成员经常在晚上和周末待命,这是导致倦怠的重要原因。尽管存在这样的风险,但它具有派遣最优秀的人来帮助解决问题的作用,即具有响应性。作为经理,你现在可能很想摆脱这个角色。我很同情,但是如果你的团队准备进行自己的事件管理,那么你应该将自己提升为升级支持。你不一定会如此频繁地管理事件,但是如果支持系统的人员需要你,则可以使你经常出现。

有关事件管理的分析应包含以下问题:“我们当前的设置是否使我的团队能够每天做自己最擅长的事情?” 当事件管理仅对事件做出反应而不是减少事件时,它可能会变成一项任务,使你的团队无法做到最好。工程师随时待命,他们因处理大量的问题而精疲力尽,除了解决事件的后果外,一无所获,然后将工作交给轮换的下一个可怜的人。如果这描述了你的团队在事件管理和呼叫上的方法,那么你的团队就无法每天做自己最擅长的事,并且每次他们进行呼叫时,他们可能更讨厌自己的工作。在这种情况下,

过分强调事件预防也会降低你的团队每天做自己擅长的事情的能力。过度专注于构建无缺陷的系统,或者通过减慢开发过程来推动错误预防,这几乎和移动得太快并释放不稳定的代码一样糟糕。当降低风险变成几周的手动质量检查,过多和缓慢的代码审阅,不频繁的发布或漫长的计划过程时,增加的分析可能会使开发人员无所事事,而不必降低发生事件的风险。

好经理,坏经理:我们对他们,团队合作者

戴安娜(Diana)刚刚加入了一家中型初创公司,负责运营这个长期被忽视的移动团队。她被告知进入该团队时一团糟,因此她的第一步是迅速聘请在 BigCo 为她工作的一群新人。他们不太适合文化,团队很快变成一群开发者,他们认为自己比组织的其他成员更好。尽管技术得到了改进,但他们似乎与产品团队发生了很大的冲突,最终应用程序的发展并不很快。一年后,戴安娜(Diana)厌倦了公司并辞职。她的新团队的其余成员很快就会跟进,使公司回到最初的位置。

新经理很难创建共享的团队标识。他们中许多人默认使用围绕其工作职能或技术细节建立的身份。他们通过强调与其他团队相比这种身份的特殊性来团结团队。当他们走得太远时,这种身份将使团队感觉优于公司的其他成员,并且团队对其优势的兴趣远大于公司的目标。以这种方式组建团队很容易受到许多功能障碍的影响:

  • 易失去领导者。 组队往往容易失去领导者。当你雇用建立了集团的经理时,如果经理离开公司,该集团很可能会解散并离开公司。这个问题使得通过首先创建团队来解决经理引起的问题变得更加困难。
  • 抵抗外界的想法。 小组内的人倾向于抵制那些并非来自小组内的想法。这意味着他们错过了学习和成长的机会。团队成员缺乏成长常会导致团队中最好的成员不仅离开团队,而且离开公司。因为他们认为自己是最棒的团队,但仍然感到无聊,所以他们不喜欢仅通过改组一个新团队就可以找到的增长。
    帝国大厦。倾向于我们对他们的风格的领导者往往是帝国的建设者,他们寻求机会发展自己的团队和职责,而又不关心整体组织的最佳选择。这通常导致与其他领导者竞争人员和控制项目。
  • 僵硬。 这些团体倾向于与团体外部的变化作斗争。重组,取消的项目以及转移重点都可能导致其身份核心部分的中断。无论是从职能团队转移到跨职能团队,延迟 iPad 应用程序还是优先开发新产品,更改都可能破坏团队与公司之间脆弱的联系。
    作为经理,请注意不要将你的团队集中在更广泛的团队上。即使你被雇用来组建团队,也要记住,由于一些基本优势,公司已经走到了这一步。在尝试更改所有内容以适应你的愿景之前,请花点时间了解公司的优势和文化,并思考如何创建一个与这种文化相适应而不是与之相适应的团队。诀窍不是要着眼于坏处,而是要找出现有的优势并加以培养。

尼尔还加入了一家混乱的初创公司。当他看到自己需要更换团队时,他谨慎地解雇了人员,并花点时间确保新员工总是由在公司工作了一段时间的人来审核。他花了大量时间与产品上的同行紧密合作,并提出了强调跨职能协作的前进之路。他专注于设定明确的目标并将其传达给团队。事情开始缓慢,但是随着时间的流逝,整个组织会变得强大起来,技术和产品都得到了极大的改善。

持久的团队是建立在公司自身的共同目标之上的,他们与公司的价值观保持一致(有关此主题的更多信息,请参阅第 9 章中的 『应用核心价值观』 )。他们对公司的使命有清楚的了解,并且看到自己的团队如何适应这一使命。他们可以看到任务需要许多不同类型的团队,但是所有团队都具有一组价值观。通过在团队,其个人与整个公司之间建立牢固而持久的一致性,这种 基于目的的绑定 使团队能够:

  • 能够抵抗失去的个体。 尽管集团很脆弱,尤其是对于失去领导者,但以目标为导向的团队往往对失去个人和领导力非常有韧性。因为他们忠于大型组织的使命,所以即使遇到亏损,他们也可以看到前进的道路。
  • 力求找到更好的方法来达到目的。 以目标为导向的团队更愿意接受新思想和价值变化,以帮助他们更好地实现目标。他们不关心想法的来源,而是关心实现目标的价值。这些团队的成员有兴趣向职能之外的其他人学习,他们积极寻找机会进行更广泛的合作以创造最佳结果。
  • 一线团队专注。 领导能力强的领导者了解向他们报告的人不是他们的第一团队。相反,他们的第一支团队是公司中的同行。一线团队的重点帮助他们在决定团队需求之前,先考虑整个公司的需求。
  • 愿意为自己的目的而改变。 这位协作领导者深知变革将为更广泛的目的服务。团队将改变结构,人们将需要转移到业务需求所在的地方。利用这些知识,这些领导者可以创建更灵活的团队,并了解为更大视野而服务的频繁变化。

弄清楚你的团队和公司的目的可能会花费一些时间。尤其是在初创企业中,对于当前的目标,甚至有时是潜在的使命,常常会有一些困惑。如果目标模糊且任务不明确,请尽最大努力了解公司文化,并考虑如何建立团队以在该文化中良好地运作。通过跨团队和跨业务职能部门的协作,你的团队将了解更大的情况并赞赏他们作为该情况的一部分的使命。

懒惰和急躁的美德

我喜欢拉里·沃尔(Larry Wall)的想法,即“懒惰,不耐烦和傲慢”是工程师的美德,正如他在 《Perl 编程》[3] 中所阐明的那样。这些美德一直保持着领导作用,我鼓励所有经理学习如何将这些特质转化为优势。

作为经理,当你一对一地与人打交道时,你当然可能不想急躁。如果针对个人,不耐烦可能是不礼貌的。而且你不想显得懒惰,因为没有什么比为一个经理打工更糟糕的了,在你杀死自己来交付项目的过程中,经理似乎很轻松。但是,如果不耐烦和懒惰直接作用于流程和决策,那就太好了。应用于过程的不耐烦和懒惰是需要重点关注的关键因素。

随着你逐渐成为领导职位,人们会向你寻求行为指导。你想教他们的是如何专注。为此,我鼓励你从两个方面开始现在就进行建模:弄清什么是重要的,然后回家。

我不能忍受看着人们用蛮力和时间而不是思考浪费精力去解决问题。但是,几乎可以肯定的是,鼓励你一直在所有时间上工作的任何文化都是这样做的。如果不使用自动化来简化你的工作,那么它有什么价值?我们的工程师实现了自动化,因此我们可以专注于有趣的东西 - 有趣的东西是占用你大部分大脑的工作,而且通常一天又几个小时都无法做到。

因此,请耐心等待,找出重要内容。作为领导者,每当你看到某项工作感觉效率低下时,请提出质疑:为什么对我来说这效率低下?我们正在做的事情有什么价值?我们能否更快地交付该价值?我们能否将这个项目分解为更简单的项目并更快地完成它?

这种质疑的问题是,通常当经理问是否可以更快地完成某件事时,他们明确或隐含地想知道的是,团队是否可以更努力地工作或花费更长的时间才能在几天之内完成任务。这就是为什么我鼓励你发展并显示懒惰的价值的原因。因为“更快”并不意味着“小时数相同但总天数更少”。“更快”意味着“在更少的总时间内为公司带来相同的价值”。如果团队每周工作 60 个小时来交付原本需要一周半的时间才能完成的工作,那么他们的工作速度并没有提高,他们只是给了公司更多的空闲时间。

这是回家的地方。回家!并在晚上和周末的所有时间停止向人们发送电子邮件!相信我,强迫自己脱离对心理健康至关重要。如今,倦怠是美国劳动力中的一个实际问题,而且我认识的几乎每个工作时间过长的人都在某种程度上经历了倦怠。这对个人来说是可怕的,对他们的家人来说是可怕的,对于团队来说也是可怕的。但这不仅仅是防止自己的职业倦怠,还在于防止团队的倦怠。如果你的工作时间比其他人晚,那么即使你不希望团队在任何时候都回复这些电子邮件或在这些时间都工作,即使你不希望团队在任何时候都发送这些电子邮件,他们也会认为你这样做很重要。过度劳累使他们的效率降低,

当你是一名新任经理时,还没有想出有效完成工作的技巧时,你可能会发现自己需要花更多的时间才能完成所有工作。暂时还可以。但是,我鼓励你想出一种工作时间的方式,而不鼓励你的团队这样做,或者让他们感到必须按时进行。在下一个工作日将周末和隔夜电子邮件排队。在非工作时间将聊天状态设置为“离开”。休假,并且在此期间不回复电子邮件。并不断问自己与你的团队相同的问题:我可以更快地这样做吗?我是否需要这样做?我为这项工作提供什么价值?

懒惰和急躁。我们专注于回家,因此我们鼓励回家,因为这迫使我们不断专注。这就是伟大的团队的规模。

评估自己的经历

  • 你上次查看自己的日程安排是什么时候才开始,但并没有为你或你的团队带来太多价值?回顾过去几周。期待接下来的几周。你完成了什么,你希望完成什么?
  • 如果你仍在编写代码,这与你的其余时间表如何匹配?下班后你在做吗?是什么促使你继续度过这段时间?
  • 你委派给一个团队的成员的最后一项任务是什么?它是简单还是复杂?你委派的人如何处理新任务?
  • 谁是你团队中正在崛起的领导者?你如何指导他们担任更大的领导角色?你正在给他们执行哪些任务以使他们为承担更多的责任做好准备?
  • 编写,发布和支持代码的过程是否在你的团队中正常运行?上一次什么时候发生此过程的一部分明显事件?发生了什么,团队对此有何反应?该过程多久遇到一次这些特殊情况?
  • 你上一次推动团队缩减项目范围是什么时候?削减范围时,你削减的是功能,技术质量,还是两者兼而有之?你如何决定?
  • 你上次在晚上 8 点以后或周末发送电子邮件的时间是什么时候?你发送该电子邮件的人有没有回复?你需要他或她回应吗?

下一章:管理经理


    1. David Allen, Getting Things Done: The Art of Stress-Free Productivity (New York: Penguin, 2001).
    ↩︎
    1. Marcus Buckingham and Curt Coffman, First, Break All the Rules: What the World’s Greatest Managers Do Differently (New York: Simon & Schuster, 1999).
    ↩︎
    1. Tom Christiansen, brian d foy, Larry Wall, and Jon Orwant, Programming Perl, 4th edition (Sebastopol, CA: O’Reilly, 2012).
    ↩︎
打赏
支付宝
微信
本文作者:CodingRabbit
版权声明:本文首发于CodingRabbit的博客,转载请注明出处!