我比较幸运,无论是读书时期的兼职零工,还是毕业后的正式工作,和老板(直属领导)关系都还行,没有发生一些不愉快的事情。不过对身边发生的一些见闻感触很多,对一个优秀的管理者的样子有一点自己的思考和理解。这里写几个亲历的故事,大家不妨看个热闹。
小老板的故事
高中毕业的时候在老家的小城市找了一份暑期兼职,工作的内容就是在手机零配件批发部给手机维修师傅送货。那个时候还是功能机时代,手机维修的需求很多,手机维修需要一些屏幕、听筒、排线等配件。城市不大,骑个自行车市区 10 -20 分钟内大部分地方可以送到,所以老板喜欢招一些年轻小伙儿送货,人力便宜还身手敏捷。当然也有中年人做这个,临时混口饭吃。
我们店的老板姓陈,每天坐在店里接电话出货。大家都叫他老陈,为人很和气,不管是客户还是员工遇到的问题都尽力帮忙解决,跟他干还是比较开心。手机和配件这个行业在当时的小城市属于暴利行业,一块商务电池进价 20 元,给维修师傅的价格是 60 元,最终顾客需要支付 100 - 200 元不等。
隔壁陆陆续续开过几家新的批发铺子,都不太长久。有一次中午吃饭认识了一个隔壁的送货小哥,我叫他黄哥,给我说干啥都不容易,他们那个老板很烦,经常数落他们。客户(维修师傅)有时候摸不清需要更换什么配件,往往弄错,于是他们就来回跑。浪费时间不说,空跑也不挣钱,老板就责怪他们为啥不问清楚再送,如果维修师傅经常这样,就加钱或者不送了。我感到很惊讶,这算啥事儿啊。我们之前也遇到这些问题,就给老陈吐槽这事儿。老陈说你们来回跑怪累的,我这就去买一些包,下次你就把常用的都带上,有个包放收据啥的也方便。工作中这样的例子很多,有啥事儿就给老陈说,一起想想如何改进也就解决了。
优秀的管理者,应是挖渠人。利用自己的位置和资源帮助解决问题,让员工工作流畅,就像春耕时期引水灌溉一样,及时疏通水渠中的石头和杂草,而不是怪水流的太慢。
Thoughtworks 的一个同事
刚到 Thoughtworks 的时候被分配到国内某项目,负责前端开发,构建一个报表页面。我们组就两个人,一个前端,也就是我,还有一个后端。项目比较简单,我很快构建好了 React 的前端页面,因此在 Interview ++(内部的一种绩效评价机制)中的评价还行。后端那个兄弟使用 Spring Boot 构建 API ,并需要连接 LDAP 获取公司的员工信息。他的工作并不顺利,花了大概两周才完成了 API 构建而且质量不佳。后来我参加他的 Interview ++,得知他有 10 年以上的工作经验,之前一直都是写 C++ ,因为没有合适的项目来这个项目上写 Java。他的 Interview ++ 评价很不好,“技术能力一般,和工作经验不匹配” “不主动交流” “接受反馈的能力不好” 等。因为项目上只有两个人,我们私下关系比较好,他虽然不是很健谈的人,但是具有非常好的沟通能力,理性和独立思考。我能理解他被给负面反馈的原因,无非是他工作在一个不适合他的位置,当技术能力无法满足项目需要时。
在团队眼里,优点就会被弱化,缺点被放大。很多人可能会说,写得好 C++ 的人写 Java 也会很快上手。但是客观事实是,计算机语言虽然很容易跨越,但是领域很难。长期从事嵌入式工作的人在没有人指导的情况下,在两周内上手 Spring Boot 这种 “低级“ 技术很困难,因为需要很多服务器编程的背景知识。在某个平行宇宙,他会不会上了一个他擅长的项目,被当做大神膜拜。
“不主动交流” “接受反馈的能力不好” 这些反馈还算不算缺点呢?优秀的管理者,应是引水人,把员工放到合适的地方,用合适的期望评价工作产出。需要遵从科学发展观,再好的水也不能逆势倒流。
一个客户的故事
”我说过好多次了,提交代码前需要本地跑通,现在流水线又挂了“”我昨天就强调,没用的代码要删除,不要留在项目里面“”你这个代码能不能写的规范一点,这么乱“晨会开了半个小时后,我无奈的放下耳机。在国内的一个项目上,我被派到一个团队和客户一起工作,这几乎是每天早上的状态。每天主持晨会的人是客户一个工作了很久的人,他似乎很恼怒,责备负责管理供应商的人为什么招聘了这么多能力差的人。
我入场后,分配的第一个工作是改造一个旧项目,这个项目因为某些设计遗留问题,遇到了性能瓶颈,需要优化。一个负责相关业务的人来给我讲了一下背景,然后给我开通了一个代码仓库的权限,我就这么开始工作了。当我开始下载好代码后,头皮发麻,这个项目没有任何文档介绍如何启动。甚至我不知道这个项目在整个系统中处于哪个位置,我开始四处求助。我找遍了整个办公室的人,得到了很多收获。
想要把项目跑起来,本地需要安装 Redis、数据库等依赖,不过需要从同事那里先拷贝一些特别的配置,并注释几行代码。
想要了解整个项目的背景,找了同事 A、B、C 终于拼凑出了这个项目的概况。
项目没有任何规范,全凭自己发挥,至少有三种加解密的工具类,多种序列化方法。
想要部署到 Dev 环境,发现每个人建有自己的流水线,部署方式各不相同。
最终这个项目做的非常头疼,技术经理没有打通整个工作流,整理相关的文档、规范、部署方法,让开发把主要力气用在开发上。每个人都需要摸索一套自己的做事方法,做东西很难说高效和”规范“ 。优秀的管理者,应是治水人,像都江堰的鱼嘴、堤堰,疏、堵相适宜。设计工作流、协作体系,制定规范。
总结
站在员工的视角,看待一个优秀的领导者,可能有不同的看法。不过,可能有几个共同点,大体是差不多的。管理者,不必是一个专家,但一定能带领团队找到方向;不必时时和蔼可亲,但是需要客观公正;不必是事必躬亲,但需要人尽其用,才尽其专。“太上,不知有之;其次,亲而誉之;其次,畏之;其次,侮之。” 最高境界的领导,会让团队认为工作产出都是他们自己努力的结果。制度和流程自然运转,深入每个人的工作习惯中了。
本文转载自:ThoughtWorks 洞见(ID:TW-Insights)
原文链接:好领导,本来应是挖渠人
评论 3 条评论