工作型管理者的产品杂记

本文是翻译,版权归原作者所有


从工程师到管理者所经历的最大变化之一,是重新认识我平常看待的问题:我们打算怎样搞定?做为工程师,我把问题分解为:我们需要开发的软件是什么,为了完成目标、我们需要解决的技术壁垒是什么。做为管理者,我把问题分解为:我们完成目标的过程是什么。

当我担任管理者角色、去问“我们打算怎样搞定?”、得到的答案是“我不知道”时,我有些沮丧。但这是不公平的——总有一些我们不知道答案的问题。让我感到沮丧的是当答案来得太快、当某人说“我不知道”时,因为他们正错过了一些东西,那就是他们觉得需要找到答案。我不知道,因为在我们知道想法是否可行之前,我们不得不写一些代码。我不知道,因为决定在其他人手里,等等。

你知道!如果决定在其他人手里,那么问题的答案就演变为:我们打算问问其他人,他们想要什么以及他们打算如何做决定,然后再去做这件事。如果我们不知道想法是否可行,那么问题的答案就演变为:我们打算探索技术可行性,一旦我们掌握更多情况、我们将进行下一次迭代计划。“我不知道因为……”是没有错误的,因为它就是某种答案,它让团队以过程的形式作出了决定。“我不知道。”——以句号结尾——还算好些,如果你把它理解为“我不知道,所以我们打算通过学习来完成”。这是我不喜欢的“我不知道,让我们继续吧”。

但我正有些不公平。做为管理者,在过程这一层回答问题是我的职责。然而我非常努力地把人们划分开,或许我还应当努力地接受人们在什么时候建立了他们角色的绑定。当你在尽量创作时,保持专注、抵御分心是有必要的。当你在团队工作时,你应该依赖团队成员的各种技能、以放手项目的某些部分。保持低调是不错的。(有时候;有时候团队里的每个人必须抬头并对环境作出响应。)

说来话长,我体会到在工程师和管理者的角度之间有着太多的不同。很难同时站在两个角度,从两个角度行动就更难了。

在我的新项目,我重回到开发,进入工作型管理者的角色,我正在执行我还在管理的相同任务,这是一种古怪的方式。当我开始管理时,我把自己从编程上剔除出来,使自己不会因新角色和不得不要做的大量学习而分心。回到编程,我可以辨别出我做的是正确的。

在这两种心态、这两种非常不同的工作模式之间切换,是有挑战的。无论哪种角色,我想具有前瞻性,只不过一个是面向人的管理者,一个是面向代码的工程师。我投入了小块时间,尽量保持最佳频率的沟通,留意出现的问题,因此回报是非直接的、有滞后的。直接的和立即出现的回报就是:工作代码。只要我知道哪种方式是正确的,这种受限制的专注就能够更加稳步地向前推进。

但我是一名工作型管理者。现在是调查这种奇怪日志信息的时间吗,或考虑我应该和谁讨论产品机会吗?没有标准来比较目前分开的两种任务的优先级

如果我打算找些时间做开发,那么我对面临的两个选择有点儿担心:

  1. 数小时后坚持编程。

  2. 做为管理者,开始提出一些问题。

我一直都在做这两种选择。为了减轻抛出问题的影响,我尽量使之透明。这或许是有效果的:我不能在 X 上做到最好,因为我正在尽量做 Y。但是我将不会真正知道这在后来是否起到了作用,关系反馈的回转会花些时间。

顺便一提:我一直在学习目标和关键结果(OKR)方面的东东,它是一种季度绩效分析结构,对于它是如何要求人们倾向于完成既定目标的70%而不是100%深有体会。如果你完成了 100%,那么你将兑现了自己在季度开始所制定的机会。你已经移除了重点发展的方式。【注1】

无论如何,不断向前、向上,希望我能够一切好运。

译文:工作型管理者的产品杂记 》| 腊八粥