好的技术领导,不好的技术领导

受Ben Horowitz的《Good Product Manager, Bad Product Manager》启发,一个简短的技术领导力的指南。

团队合作

好的技术领导就像团队成员之一,他们认为只有团队成功了,才是自己的成功。他们分担脏活、扫清障碍,便于团队100%地运转。他们设法扩大团队的技术能力,确保关键系统的了解不局限在一两个人的脑子里。

不好的技术领导为自己做广受关注的工作,带有动机地做能为自己带来好处的工作。他们局部优化,普遍使团队成员做一些 以高的工程师组织代价给团队带来好处 的项目。

技术愿景

好的技术领导有一个总体的、产品的技术方向愿景,确保团队理解它。他们授权其他团队成员的特征区域(feature areas),让他们自己做决定。他们认为团队成员是聪明的、信任他们、依靠他们来处理项目的重要部分。

不好的技术领导抵制澄清技术方向,并代替团队做决定。他们把关键的经验知识保留在脑袋里,而不能通过创作和传播有用文档来扩大效果。

创办公司的成功和失败教会我的经验

0bded94

15年前,我带着创办公司的雄心来到了硅谷。我没有技术经验,也不认识太多行业里的人。一年后,我合伙创办了一家软件公司,CenterRun,并在3年之后带领她成功被Sun Microsystems【注1】收购。

然后,我又开了一家公司。

我的合伙创始人Mike Schroepfer来自CenterRun,和我一起组建了第二家公司。这一次,我们有记录可循,技术纯熟,认识很多人。但是我们未能带来令人信服的东西,一个月后,悲伤地分道扬镳了(我去了Clearwell,Mike去了Mozilla)。

这两个经验——一个成功的,另一个失败的——使我认真考虑有志于成为企业家所面对的普通问题:我该如何创办一家公司?不是每个人都想这个问题;一些人刚开始就有一个清晰的想法,并坚持去做。但是对于很多人,在他们的概念成型之前,有一个前期探索的过程。

回头看看,我们在这两个案例试着采用了同样的办法。我们辞去工作,夜以继日地工作。我们身处想法的洪流当中,招募了一大批认识的聪明人,和他们讨论新兴趋势和痛点。我们就人们使用的技术大迁徙进行头脑风暴,并考虑如何从中获益。

但是重要的是,我们的心态不同了。当我们开始CenterRun时,我们完全一无所知。我们以前没有一个人(Mike,我和我们的第三个合伙人Basil Hashem)做过这样的工作。因此我们无所畏惧——我们没有考虑困难,因为我们真的不知道困难是什么。当我们第二次创业时,我们感到了更多的压力和试探。

这导致我们第二次创业时做了很多不同的事情。第一次,我们在一家咨询公司/孵化器的地方工作,那里充满了像John Lilly, Mike...

工程师不愿讲话

如果说,我能从 一个5人的产品团队扩大到包含工程师和产品经理共计125人的过程中 学到东西,那就是 工程师不愿意在其他人面前分享有价值的反馈。当场询问反馈,除了得到茫然的眼神,你什么也得不到。我从午餐、party和非正式聚会中成功获取的信心要比在会议上得到的多得多。但是在有600名员工的HubSpot,我们需要扩大团队的方法。这就是我为了团队健康发展、一直在寻找能够帮助我们收集虚拟反馈的原因。

太冷、太热、恰到好处

大约两年前,我们还是由25名开发人员组成的小团队。尽管我们觉得彼此能够方便地看到或听到其他人在做的事情,我们还是尝试了idonethis.com——一个按日汇报工作内容的工具。团队抵制使用。

首先,这个策略被视作太多的努力和时间。自动收集和通知到每个人,使得它本身非常有竞争力。人们只是讨厌阅读汇报、讨厌写汇报。因此,我们放弃了。今天我们每天重复300次,我们仍然知道日常汇报不适用。

随着成长,我们将 所有人直接向我汇报 过度到了 建立技术领导和团队成员代表。当我意识到我们需要记录一些沟通来确保我不会遗忘任何东西时,这是一个重要的时刻。我们为每个人开通了Google Docs,但很快就变得不可管理。

我们决定让一小部分人先试用15Five,很快就陷入困境了。使用汇报软件对于团队每个成员来说是可选的,但是一直被只有3个人的小团队技术领导完全采用了。在逐个沟通之后,我们开始挑选一小部分人放弃在Google Docs上写笔记,在不到6个月里人数就增加到团队的3/4。15Five的每周节奏比较符合我们,因为它给 每个组完成不同工作 以及 选择重要事项汇报给其他人...