老张是公司的技术骨干，基础扎实，能力出众，一直担当技术攻关的主力。经过管理层讨论，决定让老张担当一个新部门的技术leader。
老张志满意得，摩拳擦掌准备大干一番，然而随之而来的一系列事情却让老张措手不及。
一天早上，前端组的小李和产品经理老曹发生了争执，小李说你又改需求，老曹说这本来就是要实现的内容，是你没有把需求梳理好。
老张过来调解，一听双方说得都有理，立刻犯了难，到底要听谁的好，说小李不对吧，寒了自己成员的心，把老曹顶回去，那产品经理也会有意见，年底在老板面前说说坏话，技术部又要扣绩效了。这个时候产品部的老大也过来了，首先先查了需求评审的记录，发现老曹的需求细节并没有考虑到现有的功能，而小李基于现有的逻辑作需求实现，双方一来二去就出现了分歧。于是直接指出了双方的问题，并要求双方要遵守需求准则，在开发前就应该沟通清楚细节，考虑历史包袱和修改风险，并定下进度里程碑保证需求能准时上线。老张一听立刻就想起了自己还在做需求时候的也是经常和产品扯皮，到最后只能加班加点赶着上线。认为产品老大的解决方案很合理，决定让部门里的开发同事都按这个做法核对需求。
过了一段时间，后端的小王和小吴互相指责对方，小王说小吴代码写得烂，小吴说小王对他的工作指三道四，自己提交的分支乱七八糟。老张不得不再过来调解，发现后端组并没有一个标准的项目规范，于是赶紧开了个会，把前后端的代码规范、分支管理、脚手架工具都安排得妥妥当当。
好不容易项目新版本上线了，结果客户反馈线上功能有严重bug，老张立刻就急了，这可关系到年底的绩效和老板对自己的评价。赶紧火急火燎地去安排开发和测试排查。没想到等了老半天，还没有解决问题，反馈的客户越来越多，老板已经打电话来问情况了。老张等不及了，决定自己下场动手。首先检查问题功能本身，在预发布环境下没有问题，再测试接口，也很正常。老张瞬间判断到应该是线上服务器的问题，但是运维那边反馈服务器一切正常。这时候一个老员工找到了问题，原来是在低版本的客户端下访问该功能的接口会触发安全部门的攻防策略。
老张心想，这种事可不能有下次了，又开了一次会，把安全部门的人叫过来，完整梳理了攻防策略的文档，并吩咐下去，以后开发必须要留文档记录，而且不能只关心自己工作内的事情，每个人都应该清晰认知对项目发布的整个流程。
往后的日子里，老张逐渐明确了自己的定位，开始主动找老板沟通KPI，去给团队定方向，越来越往管理者的角色靠拢过去……
老张其实是我以前一个领导，我一开始是真的觉得他很菜:)，好歹见证了他怎么一步一步过来的。
