第二个问题是,跨职能、授权的产品团队的目的是共同努力解决难题。
然而,在如此多的公司中,每个经理-工程师经理、设计师经理和产品经理-都会创建自己的组织目标,然后这些目标会层层传递给他们的员工。
虽然这听起来可能是合理的,而且对公司其他部门来说不一定是问题,但实际上这意味着这些员工-当与产品团队中跨职能的同事一起工作时-都在为自己的目标而工作,而不是为了团队目标而协同工作。
更糟糕的是,在许多公司中,还有额外的复杂性和稀释,因为他们还试图实现个人目标,所以工程师不仅从她的经理那里继承了这些目标,而且她还必须为自己的个人目标而努力。
最后,也是真正的问题根源,我看到的绝大多数公司都在努力从OKR中获得任何价值,在行动中很大程度上缺乏领导力的作用。
他们真的认为这个想法是让团队确定一组目标,然后让他们追求这些目标,我们将看到我们在季度末的情况。
他们认为赋予产品团队权力,特别是这种技术,是关于更少的管理。但实际上它是关于更好的管理。
难怪这么多公司从这项技术中获得的价值如此之少?
大多数领先的科技产品公司都使用OKR技术或其中一种变体,这已经不是什么秘密了。这些公司取得了多大的成功也不是什么秘密。
那些成功的公司并不是因为他们使用OKR而成功,他们使用OKR是因为它的设计是为了利用授权的产品团队模式。
正如我用多年的文章和演讲试图阐明的那样,授权的产品团队模式是建立和运营技术产品组织的一种根本不同的方法。
您不能让您的旧组织基于功能团队、路线图和被动的经理,然后覆盖来自完全不同文化的技术,并期望这会奏效或改变任何事情。
因此,就真正获得OKR的好处而言,有三个关键的先决条件:
领导者需要挺身而出,尽自己的一份力量,将产品战略转化为行动。
这是需要更多讨论的第三个项目,因此在即将发表的关于团队目标的系列文章中,我们将讨论领导力在有效团队目标中的作用。
接下来,我们将讨论领导者如何通过与团队共享他们希望团队在追求他们被要求解决的问题时的雄心壮志来管理风险组合。
重要的是要注意到,有时这不是关于雄心壮志的水平,而是我们需要偶尔做出所谓的高度诚信承诺,我们需要讨论这些承诺是如何制定和管理的。
关于团队目标的一个常见误解是,只有一个产品团队应该致力于特定的问题。相反,我们很多最好的工作需要团队之间的协作,我们将讨论几种重要的协作形式。
与任何以技术为基础的艰难努力一样,我们需要积极管理这项工作,始终牢记通过教练和仆人领导进行管理,而不是倒退到指挥和控制式管理,从而失去授权的好处。
伴随着授权而来的是责任,我们需要讨论这在实践中意味着什么。
最后,我们将总结出从团队目标中获得真正价值的最重要的几点。
特别感谢克里斯蒂娜·沃特克(Christina Wodtke)和菲利普·卡斯特罗(Felipe Castro)审阅了本文的草案。