@Lenciel

江湖儿女(15) - 如何快速进入新角色并成功

I)TL;DR

i4cp 前年对100多个公司几千人做了一个调研,发现 49% 进入新角色的人失败了

在 i4cp 的另一项调查中,只有 44% 的受访者表示他们的组织有努力做各个岗位的 onboarding,其中又有 88% 的受访者表示,这些努力设计的 onboarding 流程其实没有那么有用

很显然,不管你是跳槽到新公司干着熟悉的岗位,还是在组织内转岗干了别的职能,指望公司的 onboarding 流程,很难成功。但这两年,偏偏大环境不好。无论你在什么层级,哪怕公司还在,岗位没变,你的工作内容可能也发生了很大变化:人人都在进入新的角色。。

今天就聊聊进入新角色难在哪里,如何通过关注几个要点构建自己的网络,来提高成功率。

II)Why

国外的管理学院几年前就提出,现在是一个超协作(Hyper-Collaborative)的工作环境:几乎所有的脑力工作者,都会花 85% 甚至更多的时间用于协作活动上:电话、邮件、会议、聊天工具。

这是 onboarding 流程失效的核心原因:那些规定、制度、福利、章程和企业文化方面的讲解,目的是让你这个外来的个体,快速融入组织。

但要想取得成功,不能被动地「融入」组织,因为它有时候会吞噬你。在协作没有那么重要的行业或者时代,你可以按照自己的性格和偏好,慢慢构建自己的网络。现在,你必须迅速建立自己的网络,下面我们就来说说怎么做。

III)How

1)搞清楚非正式组织架构的核心节点

每个公司有正式的公布的组织架构,还有一个「非正式的」组织架构它的节点是各个部门的实权人物和意见领袖。

我接手过很多完全没有管理过的职能部门:市场、销售、供应链、服务…接手的第一件事,都是密集的 1-1。首先是部门里面的每个人,然后是协同部门包括我自己的上级。除开了解组织的运作方式和每个人最紧迫的目标和困扰,我会问两个非常固定的问题:

  • 你觉得我应该去跟谁多聊聊?
  • 你觉得这个部门里面大家对能力和品行都比较认可,值得依赖,或者说对业务有真正影响力的人是谁?

你很快就会搞清楚一个涵盖自己的团队、平行部门、中后台相关部门的关键人物的网络。这张网络里每个人对你只会有两种力:积极的和消极的我们的工作中很重要也许是最重要的部分,就是确保自己拿到尽可能多积极的力

2)产生拉力

成功并不仅仅取决于直属上下级和关键相关方给力。一开始觉得没有那么重要的人,比如上级的某个副手,可能比你更清楚上级的目标、兴趣、动机和日程安排。比如中后台职能的同事,可能会成倍的减少你完成某个任务的工作量或者时间。

那么怎么让大家之间产生这种积极向上的拉力?有一些书是专门讲这个的,比如《the Power of Pull》,但我看过之后总觉得有的虚。我自己就是两个原则:

充分展示,积极倾听:展示你的目标,展示你可以做什么,展示你的弱点,展示你需要的帮助。然后多听,了解他人的目标、需求、想法和兴趣。

我们进入新环境时容易犯的毛病是过度推销自己。讲述自己的技能或者经验之前不妨都问问自己:这对跟我聊天的人有用吗?还是只是为了让对方更欣赏我?如果是后者,就不用说。

积极共创,追求利他:公司里面的协作大部分时候不是零和游戏。往往你解决了其他人的问题,你的问题也就解决了。前面那个步骤如果你做得足够好,就会找到很多可以和大家一起创造共同成功的目标。

3)创造价值和规模

构建网络和产生拉力,是不是搞权术或者小团体?有一个关键区别,就是在这个网络里面你创造的是规模化的价值,还是废话和八卦。

进入新角色往往意味着你有技能上的缺失。很多人要不是选择视而不见,要不是试图虚张声势,千万不要这样

一方面你要清楚自己的特长。你被接纳进入新角色一定是因为你有过人之处,迅速发挥它们,创造价值。

另一方面,搞清楚自己薄弱的地方。哪些是自己要补的,哪些通过招聘下属来解决。做到在原有基础上不断增值自己,本来就是进入新角色最大的收益。

最后,规模很重要。我们需要网络,是因为我们需要价值创造有规模效应。这个可能值得专门花一篇文章来写,但你先得有一个概念,就是你花了这么多时间构建这个网络,绝不是为了完成那点儿 KPI 或者 OKR。你应该调动大家一起去为一个更有价值、更有规模、更有意义的目标努力。

以上。

江湖儿女(14) - 如何开好跨部门会议

I)TL;DR

我们在公司里面开会,经常会有「鸡同鸭讲」的感觉。这是因为参与讨论的各方,可能在不同的层面,用着各自的语言。

组织跨部门会议,最重要的技巧就是把讨论的问题拉到同一个抽象层次,用同样的语言体系进行讨论,从而让过程更加高效,结果更可执行。

II)Why

大家会不会有个感觉:同部门讨论,比跨部门容易很多,甚至很多时候会感觉外面的部门有「墙」。

有人把这个归于「文化」和「政治」。

但我的观察,很多时候,是因为大家技能不够。

销售关心的是自己的客户满意度,渠道费用,commit 的数字能不能完成;研发关心的是这个需求是不是成立,需要花多少成本和时间,是痛点还是痒点应该有什么样的优先级。

几乎在所有的公司,这类在不同层面操着不同语言体系的讨论,都很容易吵架。所以,把参与各方带入同一个结构再进行讨论,是非常重要的技能。

III)How

一个问题讨论的层次可以定义为三层:用户层、中间层和实现层。

用户层是为了用户能够轻松愉快地使用产品做的那部分工作:门把手、咖啡机上的触屏菜单、自动扩容的带宽、系统数据那个导出报表的按钮等等…

实现层是由成本和物理化学技术规律约束下产生的具体实现:芯片架构、光伏供电、5G 网络、钢化玻璃等等…

中间层位于前面两层之间。很多时候我们感觉自己工作在这层:代码编写、环境搭建、磨刀砍柴等等…但其实并不是。

举个例子,程序员「写代码」的工作其实三个层次都会涉及到:

  • 实现层:代码是在它运行的软硬件平台能够良好工作并且高效的;
  • 中间层:代码是所有同事能够看懂并且很好去修改维护的;
  • 用户层:代码是完成了需求并且暴露的功能使用起来舒适方便;

一个成熟的开发者应该能够根据项目实际情况分配自己在不同层次上的投入比重,有侧重点。比如,一个政府项目,偏一次性交付为主,可能就应该花足够多的时间在用户层上。

同时,在讨论的过程中要避免只在自己熟悉或者说可控的层面做讨论,而刻意回避自己不熟悉不可控的层次——这很难,甚至有点反人性,所以往往需要讨论组织者干预。

比如大家开会,如果销售说,用户想要一个按钮实现「一键外发」,研发说这个开发工作量太大了或者说这个功能我们的产品实现不了,这就是典型地不在一个层次。

组织者应该调整大家,先回到某一个层次。比如研发来到销售讨论的「用户层」,先关注用户为什么想要「一键外发」?为什么是要一个按钮来一键外发?如果做到别的地方或者做成浏览器插件在任何地方都可以外发是不是更好?

把这些问题讨论清楚,往往都会得出双方都可以接受的结果:要不就是不做或者可以有更好更低成本的做法,要不就是确实很重要工作量也很大那就调整现在的其他功能的排期。

或者销售先来到「中间层」:目前的实现框架是什么?计划做什么样的扩展?用户的这个功能有没有手动或者其他替代方案?很多时候销售容易有「怎么实现我不管,这个需求我就要」的心理。在没有冲突的时候这没问题,就跟你平常用家里的微波炉不需要看说明书一样。但是如果微波炉出问题了,你肯定会通过电话客服或者阅读说明书来解决问题。

这其实就是把自己先放到中间层——虽然心里面可能是一万个 f*ck,但你知道,只有这样才能解决问题。

以上。