一个人被组织提拔，其实不只是因为能力，而是因为信任。
成长之路—靠谱
发表评论
分类目录归档：管理managent
成长之路—《管理你的老板》读后感
最近组织结构调整，接连换了两次新领导。与陌生的新领导没有建立起认同和信任感，会遇到沟通不太顺利的时候。回想自己以前的职场工作的经历，都是先相互看顺眼才去入职，之后努力工作出业绩就好了，从来没有遇到过这类问题。想到自己也确实很不擅长向上沟通，于是经过朋友推荐买了这本书。
成长之路—关于996的思考
最近996被讨论的很火，大家的关注点都聚焦在那几个数字上，但对于想在职场有所成就的人来说，纠结这些数字毫无意义。那么应该关注的是什么呢？对于下属被舆论影响的leader来说，应该思考些什么呢？
OKRs—制定目标和关键成果(Objectives and Key Results)
一种有助于确保公司上下一起聚焦于解决重要难题的管理方法。
成长之路—如何培养技术leader
今年一直在尝试着培养各方向的技术leader，在这之前他们主要负责执行。
成长之路—团队力量与个人成长
本文总结下王老师关于个人、团队、管理上的一些观点：
成长之路—抓大放小
“干工作要注意抓大放小，太过于陷入细节难成大事。”
成长之路—CTO技能图谱
理一下目标和方向，共勉～
研发人员的3个技术方向
产品：
以业务需求为主要驱动力，其涉及到的问题往往来自于复杂的业务逻辑和功能的快速上线需求，即其难点主要来自于对产品的理解把握和需求的快速响应能力，对于大数据高并发的系统要求并非其主要考核点。典型的部门为：社区组、fe、客户系统、mi、客户端产品等。面向内部的一些需求，如一些内部平台的开发也划入此类。
成长之路—对线上心存敬畏
最近遇到一个事，小同学上线出了bug，导致线上出现了一个case，说大不大，说小也不小，因为是半夜12点左右被发现的，晚上紧急上线是需要发邮件找两边经理审批才能上，这位同学担心大家都睡了，不好意思打扰，就打算第二天再上。
成长之路—勇敢
今天想说的勇敢限定在工作推动这个范畴，原因是我一直以为自己是个积极主动的人，也觉得自己在努力推动，但是，其实并不是我想象的那样。
成长之路—统合综效
统合综效的精髓就是判断和尊重差异，取长补短。
统合综效让每一个人都能够真正实现自我，自尊自强，有机会完成从依赖到独立，再到相互依赖的成熟过程。少一些防御意识，针锋相对的自私自利，多一些坦诚相待、相互信赖和慷慨大方，少一些自我封闭、自我防御、权术玩弄，多一些仁慈爱心和关心同情，少一些占有欲望和随意判断。
成长之路—每天问自己3个问题
最近有些事情的推进不是很顺利，团队里很多人看着都很忙，但是都在做我们最应该做的“最重要的事”吗？你有在抢下属的活干吗？计划里排的对应的目标、收益、优先级够清晰吗？让团队振奋人心的战略规划在推动逐步落地吗？
成长之路—《杰克·韦尔奇自传》读后感
讲述了通用董事长杰克·韦尔奇20多年的职业历程，前半部分讲述如何从普通职员一步一步成为董事长以及上任后对通用的文化、核心竞争力的重塑，后半部分大多是资本运作相关。
从Code Review 谈如何做技术
这两天，在微博上表达了一下Code Review的重要性。因为翻看了阿里内部的Review Board上的记录，从上面发现Code Review做得好的是一些比较偏技术的团队，而偏业务的技术团队基本上没有看到Code Review的记录。当然，这并不能说没有记录他们就没有做Code Review，于是，我就问了一下以前在业务团队做过的同事有没有Code Review，他告诉我不但没有Code Review，而且他认为Code Review没用，因为：
技术团队如何发现和培养Tech lead？
在影响团队长远战斗力的诸多因素中，比较有意思同时也非常关键的一个因素是对tech lead 的选择和培养，这也是我们今天的话题。
如何正确地开脑洞
猴子管理法则
猴子管理法则来源
背上的猴子——由威廉姆翁肯 (William Oncken)所发明的一个有趣的理论。他所谓的“猴子”，是指“下一个动作”，意指管理者和下属在处理问题时所持有的态度。其与Donald L. Wass在1999年共同创作并发行了介绍该理论的书籍《Management Time: Who’s Got the Monkey?》。
领导者：管理自己，影响别人
“管理”是建立在合法的，有报酬的和强制性的权力基础上的，但是“领导”更多的是建立在个人影响权和专长权以及模范作用的基础上，首先，领导者必然会有部下或追随者，其次，领导者拥有影响追随者的能力，再次，领导的目的是通过影响部下来达到企业的目标。
合作共赢-既生RD何生PM
产品和技术是永远的矛盾共同体，非技术型产品经理可能会觉得：“即便我们拥有一只很强的技术团队，开发进度始终还是跟不上市场变化的节凑，无法满足产品策划乃至营销方案的需要。”而技术人员也可能会抱怨：“一周一个样，原先的产品设计就没想清楚，现在又要变了，真不靠谱„”。 造成这种局面的原因是什么？如何才能让产品和技术更好的沟通协作？