技术

下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论及实践 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Python一些比较有意思的库 LLM部分技术源码学习 LangChain源码学习 通用分布式计算引擎Ray Python并发 go依赖注入 go collection gc的基本原理 golang性能分析及优化 数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办? 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 容器日志采集 Kubernetes 控制器模型 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

大模型推理服务框架 模型服务化(未完成) 大模型RHLF 大模型训练 大模型推理 从Attention到Transformer k8s设备管理 LLM工具栈 ddd从理念到代码 如何应用LLM 小鼠如何驾驭大象(LLM)? 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 helm tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 机器学习中的python调用c 机器学习训练框架概述 embedding的原理及实践 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 tensorflow学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

k8s设备管理 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 helm 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? Kubernetes events学习及应用 CRI 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 什么是云原生 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时,我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件

《技术领导力300讲》笔记——管理篇

2019年02月14日

简介

技术leader应该具备何种能力

所有的职位不是别人给你的,而是你自己挣出来的

张金宇:市场中,没有企业中的升职、加薪、辞退等“人造的”管理工具。市场只有一个工具:用生奖励强者,用死惩罚弱者。我们把对局部负责的人,叫做员工;把组织个人成为整体的人,叫做经理人;把真正最终对整体负责的人,叫做企业家。

任何行动都是思维的产物。所以我把它们抽象为四种思维方式:效率思维,用户思维,跨界思维,商业思维。无论是哪种思维,都必须对应到公司的商业价值,都应该以产生商业价值为最终目标。 PS: 这段话笔者最受益的是就是一种新的思维方式,在生活领域,你在看一系列现象、人的行为背后,怎么分析能够让你简化理解(通常靠分层),生活领域的应用就是:行动是思维的产物 ==> 外在的行动反映了内在的思维。

德鲁克:管理是一种实践,其本质不在于“知”,而在于“行”,其验证不在于逻辑,而在于成果,其唯一权威就是成就。

极客时间:给员工做画像。PS:其实和任何人相处都是如此啊

管理

许式伟:我认为管理者最核心的能力不是团队管理能力,而是以下这两点:

  1. 如何避开错误的和没必要做的事情,集中精力到最必要和最正确的事情上,从而让团队尽量少做无用功;
  2. 协调能力:如何和其他团队进行高效协同,从而为团队构建最好的工作环境。

对于同一件事,你能从中参悟到什么,理解到什么程度,是一个管理者是否可以持续提高的关键所在。所在作为一个管理者,至少留给自己 20% 的时间在思考,而不是具体做事情,你要不断的反思自己的决策、沟通、影响、开放当中的问题, 是否可以有更好的方法来提高。一个人能做到什么样规模的高级管理者,和他对于自己、对于业务、对于管理甚至对于世界的参悟程度有关系,最终管理的瓶颈是对于自己对于世界的认知瓶颈,而不是技能瓶颈。

两个人互相审视,一定会发现一个盲点,即你身上的问题我知道,而你不自知。

如果节奏没有了解清楚,技术节奏把控不好,很可能会导致技术无法支持现有的业务增长,或者业务收入无法供给辛辛苦苦招聘来的技术牛人,看着一起成长起来的兄弟却要忍痛优化掉,这是每一个技术管理者都不愿意见到的。所以,深度了解公司业务、洞察业务增长节奏,是每一个高级技术管理者必修课。

最快的集成,最快的给出高质量的产品,最快的训练出来高效的跟的上节奏的团队。这才是持续交付与迭代的目标,把团队的速度和交付节奏拉起来,淘汰跟不上的人员,对优秀的人员持续激励。这样才可以得到优秀的团队,做成事情,获得其他合伙人的认可

构建使命式管理结构:团队大了就会出现行为不一致的情况。这时候有两种选择,一种是自上而下命令式管理,一种是水平沟通使命式管理。我会选择后者,尽管看上去不像自上而下流程管理那么清晰,但是,在现在这个瞬息万变的市场,你很难有效的获得最真实的信息。此时,你再厉害的经验和决策,往往也会在信息一收一发当中扭曲变形。

阿里云狄:对于一个制度刚刚建立,流程还没有跑顺畅,团队残缺,骨干员工业务能力不及格的团队,采用放权式管理是错误的。你必须事无巨细,从第一线的业务细节抓起,手把手的带员工,教会他们怎么正确的做事情,怎样达到你的要求,手把手的培养业务骨干,搭建团队核心架构。当业务流程已经清晰的建立起来了,骨干员工在业务上能够完全领会并且达到我的要求,这个时候放权可以充分调动团队的自主性和创造性,多数技术人员他们喜欢被领导,不喜欢被管理。这些年我看到过太多的案例,管理层自己从不真正深入业务,也缺乏对业务的深刻理解,没有找到问题的本质原因。总是寄希望于招人来解决问题,结果换了一茬又一茬人,问题永远解决不了,而且从来不深刻反思自己是否亲自尝试解决业务问题。很多时候架构反应出来的问题,其实是组织、流程的问题。

哪怕是下属去犯错,你也要眼睁睁的看别人犯错,而自己来承担所有的后果。除非你判断问题超过你的职权范围或者挽回范围,否则你不能直言相告。“看着下属犯错,自己却不能说” 这点是最难的。因为你说了,这些经验就永远是你自己的,下属不在错误中成长,管理者就是永远的瓶颈。

人的技术,高端技术人的日常工作大概是 40% 跟人相关,30% 跟业务相关,剩下 30% 才跟技术相关。我认为掌握人的技术,有两点非常重要:一是懂表达,二是懂尊重。PS:个人感觉

  • 沟通就是先认知,认知对方对这个事儿的理解程度,然后以对方可以接受的语言来表达。
  • 懂尊重,就是要帮助他人成长,好的技术人都容易有英雄情结,视比自己水平低的人如草芥,沟通基本以鄙视为主,所以必须从内心深处尊重其他人,才能建立和发展好一个技术团队。

有时,最终的决定其实并不重要,重要的是要有这样一个决策的过程,以及强有力的执行。

我觉得优秀的人,都至少能达到:1、能够清楚地认识到什么东西是对的。2、在知道是对的情况下,愿意去把事情做得更好。 PS 深化理解

  1. 能够清楚地认识到什么东西是对的

    • 视野
    • 技能
    • 经验
  2. 在知道是对的情况下,愿意去把事情做得更好

    • 自驱
    • 韧性
    • 对low 的容忍度

CTO 是为 CEO 的吹牛而埋单的,但是不要忘记,作为追求利润最大化为唯一目标的经营单位,任何一次的目标定位,都是生死抉择。作为核心决策者之一,理解接受只是最基本的要求,充分参与其中,合理调配资源,并解决问题才是合格的 CTO。

对任何中层管理者,首先,我一定会跟他们分享我对管理的认知。很多管理者对管理的目标、职责以及常用的管理方法还不太了解,其中包括管理的职责是什么,最主要的目标是什么,常用的管理手段是什么,常用的管理手段是什么等问题。一旦有了这样的认知,在一些具体的操作细节上面,他们才会有管理的概念。很多时候我们团队在做事情时可能会忽略一些东西,从而导致整个进展不够顺利,我要做的是帮助他们把事情理顺。

摸清人的禀赋,力求人和事的特性匹配。

未来包含两层含义:成为什么样的人,做成什么样的事。事是是团队乃至企业的目标,要由团队成员来执行;成为什么样的人,就是个人的成长目标,来自于工作、学习乃至生活中的磨练。工作显然是一段带有刻意训练特征的时间消耗,虽然很多工作是出于谋生养家,但是花同样的时间、赚同样的钱,人总是希望做一些有助于成长目标、让你自己获得成就感的刻意训练。

成敏:很多人刚刚成为技术管理者的时候,内心大都会比较焦虑。相信不少同学都会觉得时间变少了,确切地说,是做技术的时间明显变少了。而当需要做的事情变多以后,该如何选择优先级,比如应该先做技术攻坚,还是先协调资源,或者先去招人?这时就很容易迷失方向。作为技术管理者,要先去做杠杆率最高的事情,为你的团队负责。很多公司都强调以结果为导向,很多人其实并没有真正理解结果导向的意义,或者意识到了,但却找各种各样的理由松懈自己。比如有的同学会有这样的心态:虽然结果不好,但我已经尽我所能了,可能是因为人手不够,或者外部团队不配合等客观原因才导致了这样的结果。可以说是一种人性的本能,但作为技术管理者,你要带领团队完成目标,就要去引导他们更进一步去思考:既然存在这些客观原因,那你为此做了什么事情?是否对此提出了你的解决方案?在我看来,积极地推动所有可能影响到结果的因素,尽力打造最好的结果,这才是结果导向的意义。在具体的执行过程中,我们其实可以把它抽象成一个过程,即先明确目标,然后诊断问题、确定思路、细化方案、实施执行,最后反馈调整,不断反复循环。虽然这个过程已经为大众所知,但多数人在做事的过程中,还是会经常不自觉的忘记这个过程中的某些环节。对于管理者而言,还需要对自身有要求,最好是拥有多面手的能力,不要局限于管理或技术。你能做的事情越多,那你对杠杆率更高的事情就会有更多的选择

去做更多的事儿,解决更多的问题。让小伙伴通过解决问题来提升能力。在具体实践中,首先需要思考,提供给他们解决的问题是否适合他们需要提升的能力,然后,通过相应的问题,给予相应的磨炼来提升他们的能力与经验。我们还需多做一步,就是跟他们多交流,并让他们刻意训练一些方法与习惯,以此去影响他的基础素质与精神。这是一个比较好的培养人才的逻辑。

王海亮:目标一般为解决业务问题或提升效能等最终目标,而不是完成某个功能或搭建某个技术框架等过程目标。目标要大胆,就像特斯拉创始人埃隆·马斯克那样,事情要做到十倍好,只有大胆的目标,并且相信能做到,为此去找方法,才能激发团队的创新,不止于在原有的思维或经验中徘徊。绝大多数人都是在原有的思维和经验中线性思考,比如项目要早点上线,就想着要么加班,要么增加人员,陷入到自己的心智模式中,只有给他更大胆的目标,很难用原有的思路和方法解决时,才能促使他去改变、去创新。

池建强:缺乏计划会让产品失掉节奏感,员工失去方向,并且很难专注。尽管经常计划赶不上变化。

陈崇磐:随着团队规模的扩大,团队成员就会面临两个重要的突变:从做事到管事,再从管事到管人。从“做事”到“管事”,是“自己做事”到“驱动做事”的区别,也是动手到动嘴的转变。此时应该考察的是心理成熟度,而不是业务能力。从“管事”到“管人”,是“成就自己”和“成就他人”的区别。既然管人,就要有通过成就他人来成就自己的格局。而一旦管人,在事情推动上会由管事的直接推动变成管人的间接推动。

俞圆圆:在我们承担起团队管理职责的同时,我们能否保持这样的自律: 每年学习一种新的编程语言;每年深入关注一个新的技术领域。

成敏:公司本身的高速发展,是对团队最好的管理,也是对员工最好的激励,自然也能吸引更多的核心人才留下

有的人擅长从 0 到 1,有的人擅长从 1 到 N,作为高级技术管理者,要了解自己的认知边界,要么不停挑战自己不停进化,要么急流勇退。

梁胜:我接触过很多技术团队的管理者,在我看来,他们对具体事情的关心远远不够,就是他们只关注大方向。如果教练来了之后,只是给运动员定个 PKI,比如“今年要进入三强”或者“三分球进球率要达到 80%”,这样的教练有什么用呢?你去看看那些知名的教练,他们可是每天盯得很紧的,一个动作做得不对都会马上来纠正。

于人:技术管理实践包括

  1. 定战略

    • 定范围:用户需要的 && 团队擅长的 = 可以做的
    • 定赛道:未来空间足够大 && 细分领域数一数二 = 选择一个作为战略
    • 定路径:定路径是定战略的一部分,不能推给执行阶段
  2. 抓战术

    • 抓大。同一时间,只有一件事情是最需要关注的,需要占用你 70% 的精力来对待。对于这件最重要的事,一定要扎到过程里,管理每个里程碑,持续跟进,及早发现问题。PS:何谓重要?首先取决于事情本身的重要程度,但在实践中,重要的事儿多了去了,去做最重要的事儿通常意味着舍弃。
    • 万事可测量
  3. 选人才

      措施
    千里马 要花80%的精力
    小白兔 放在合适的岗位上,但不能放在管理岗位上
    野狗 谈一次,不行就果断放弃
    狐狸 干掉
    老黄牛 根据制度满足待遇,引导成为千里马

    领导者容易犯一个错误,喜欢在“小白兔”身上投入大量的管理精力,期待小白兔的业绩发生质变。其实软件开发行业很看重天赋,天赋能保证生产力的量级。价值观强而业绩弱,只能说明能力已经触达其天花板,而能力上限的问题很难靠管理就轻易解决。让“小白兔”承担其无法胜任的工作,领导者可能是好心办了坏事。

    搭团队,要注重补短板;而用人,恰恰要取长板,一定不能反着来。把补短板用在了下属个人成长上是极其错误的。PS:所以如果你一直发现不了一个小伙伴对项目、团队的长处,就要放弃掉。

  4. 带队伍,带着做,带着说,带着想。

    胜任力=意愿+能力。管理方式需要与员工的胜任力匹配,一定不可错位。

向上管理

工作想要卓有成效,下属发现并发挥上司的长处是关键

如何做好向上管理

  1. 领导对你的信任是基础。凡事都有两面,信任也是会被不断消耗的,技术管理者时刻保持清醒是必须的,对所负责的事情怀有敬畏之心
  2. 信息对称是前提。信息对称绝对是一个需要日常长期保持的工作。技术领导者们在信息不对称的情况下,常常会出现自我感觉良好或者感叹怀才不遇的情形。却没有去尝试对称领导的想法和公司的战略,只是想一味的说服领导,被拒绝后还不忘吐槽一番,这是典型的没把向上管理认识清楚的表现。
  3. 谋定而动。向上管理肯定不是一次就能成功的
  4. 向上管理不是单纯的直线向上,还需要协助决策领导解决周边障碍

认识人—— 心理成熟度

陈崇磐:心理成熟度 - 创业公司识人利器

心理年龄 简述 职场中的表现 整体评价
幼儿 不知道自己不知道 碰到问题只会求助,而且在求助的时候,连自己的问题都无法准确描述
分不清自己与世界的边界,也分不清人与人之间、岗位与岗位之间的边界。只能通过哭和外界对他困难的理解,帮助他解决问题
 
少年 知道自己不知道 没有足够的能力解决碰到的所有问题,所以在求助时会对问题有一个准确的描述,甚至自己已经做过某些尝试但还是没能解决
正如已经尝试搬了板凳但还是够不到柜顶上的玩具
少年缺少的是专业技能而不是问题意识,一般也能够解决能力范围内的问题。
因此如果遇到少年,我通常会结合他的生理年龄也就是工作年限,来判断对方的学习曲线,再结合团队的缺人程度决定是否合作
青年 知道自己知道 青年往往是团队中的业务骨干,知道自己碰到的是什么问题,也往往能找到解决问题的办法。
青年也会倾向于证明自己,让别人意识到他的“知道”,因此在工作上会有不错的主观能动性
抛开其他因素,由底层个人英雄主义延伸出的职业发展障碍,可能成为青年换工作的深层次原因,
因为他觉得自己是英雄无用武之地,没人知道他的“知道”,实际上可能是他无法突破技术思维,造成眼高手低。
成年 不知道自己知道 对问题的认识是否突破了“自己”这个边界,考虑问题的出发点是“自己”,还是“自己 + 相关的人”  

PS:可以看到一个成长路径是:无法表述问题 ==> 表述问题 ==> 解决问题 ==> 解决技术范畴之外的整个问题。

心理年龄 如何识别 整体评价
幼儿 你们几个之间是怎么分工协作的?比如几个 Java开发之间、前后端之间等。 如果候选人对分工和彼此的边界都不能准确描述,我会把候选人定位为幼儿层级,直接 pass
少年 你经历的项目中,有没有遇到让你刻苦铭心的困难,你是怎么解决的? 这个问题一方面可以通过遇到问题的难度判断候选人的专业技能;另一方面可以得知对方是否有尝试过自己解决问题,了解候选人针对问题的主观能动性和韧性
青年 你过往的工作经历中,最让你有成就感的事情是什么? 如果对方的答案是落在个人英雄主义的范围,满足于以个人能力赢得团队的尊敬,进而认为自己在团队中不可替代,我就会将他归到青年的层级,否则就会归到最高层级,也就是成年
成年 你心目中最理想的工作环境是什么? 这个问题可以很好地衡量出对方考虑问题的角度,如果他在意的都是与自己利益相关的东西,比如待遇、氛围、能学到东西等,我会将他划分到青年层级而不是成人层级

我们不是要找不食人间火的圣人,或者只付出不求回报的老黄牛,因为也不现实。但我对这个问题的理解是:自己的获得往往是结果而不是理由,是终点而不是起点。如果以结果作为起点,往往是因果倒置。

针对每个团队成员而言,专业技能决定他能解决什么样的问题,而心理年龄决定他能解决多大的问题。汇总成一个团队,专业技能的短板决定了这个团队能不能做起一件事,而心理年龄的长板决定了能把这件事做到多大。

笔者一直对团队内小伙伴只有模糊、直观的评价,然后对自己是否缺人,缺什么样的人,找不出一个系统性的表述,最后只能是给什么人用什么,“随波逐流”,而不是主动把控。当碰到这个现象时,一定是因为你对问题没有深刻的认识

如何管理(或者说帮助)团队中较弱的人:弱同事应该还是属于自己做事的阶段。如果是,还是应该分析一下他“弱”在哪里:专业技能(如Java语言技巧)、思维方式(如逻辑思维能力)、做事方式(沟通技巧,汇报意识)、还是态度(主动积极),对症下药。前面两点决定是否适合当前工作,后面两点决定是否适合当前团队。

有一定的领先优势了,这时,面临的问题是如何突破自己,但现实情况是,团队中大部分人都还没有达到突破的能力或者还未找到突破的方向。

自私确实是人的天性,不是自己的东西,很难谈什么责任感,更不用说主动性了。因此,团队管理就是要努力地培养大家的责任感,主人翁意识,想做到这一点,就需要增强团队成员的参与感,让他们知晓并理解所做事情的价值、来龙去脉,不断地强化使命感。

人最重要的特质是自驱,自驱的表现就是工作年限和工作能力一定要匹配,若是不匹配,通常成长性不是很好。

什么样的人适合管理

王昊:管理者的三个价值观

  1. 以实现为目标,不以技术先进为目标。技术先进不先进不重要,能做出来最重要。
  2. 以团队实现为目标,不以自己实现为目标。自己的团队能做出来最重要,是不是我做的不重要。
  3. 以帮助团队实现为目标,不以自己提升为目标。我级别升不升不重要,我们团队能做更多的事最重要。

管理者需要背目标,一旦不能实现,即使问题出在其他地方,那也是他的失职,得受得了这个委屈,这也是工程师和管理者很大的不同。

万玉权:很多管理人员会进入一个误区,他会去享受权利带来的快感,却不知道怎么培养团队成员。在我看来,一名合格的领导者,不在于自己的能力有多大,而在于能够培养出多少更优秀的人才;也不在于自己能够做多少事,而在于能带领团队做多少事。

《软件架构设计》所谓独立就是能掌控事情,无论模块、系统、项目,不需要上级操心,按时按质交付。做到这一步,意味着团队的每个人在自己所处的层次都是可“托付”的,否则就会频繁出现“补位”。组长干组员的活儿,经理干组长的活儿。层层错位,最后整个组织缺乏“顶层设计”

团队

管理大师彼得·德鲁克说:“组织的目的,就是让平凡的人做出不平凡的事。”

杰克·韦尔奇曾经说过:Before you are a leader, success is all about yourself. When you become a leader, success is all about growing others.当你在赛场上踢球时,你应该考虑做一名优秀的球员;当你成为一名优秀的球员时,你应该考虑做一名优秀的教练。

一旦团队上了一定的规模,团队就会从单纯的需求实现走向团队运营,而运营是需要方向的。如果不是一个能给团队指明更好方向的人,他最终会沦为一个需求翻译器,产品经理说怎么做就怎么做。他更多的只是负责保证产品的质量、开发的速度,最终被肢解成一个很琐碎的人

还需要极强的沟通能力,要能够和不同背景的人有良好的沟通能力,能够用对方的思维方式和话语体系来描述他不理解的专业问题。

初级熟练员工需要手把手完整的指导如何去做,高级员工需要使命式沟通,如果沟通方式相反,反而会让初级员工不知所措,高级员工觉得无法成长,而起到反作用。

技术架构升级就是对人的升级。

有意识地进入某一个圈子,找到能听懂你说话的人,大家经常一起切磋交流,共同成长。恰当的时机可以采用协作的方式,因为这样可以推动你的成果提升到一个新档次。

明确而认知一致的目标,对于团队所有成员保持统一的工作步调的意义,是非常显而易见的。相反,目标不一致的情况下,让员工保持良好的节奏和状态就变成了奢望。对于多任务优先级的判断,也便没有了最核心的依据。此时要想在沟通中达成一致意见,沟通成本非常高。

  1. 要么没目标,要么就是目标不清晰,要么是没有被有效解读和传达。管理者除了要明确目标,还必须把握该目标的核心衡量指标,即,这个任务最核心的指标是进度(赶时间)、质量(稳定可靠)还是效果(功能完善),只有这个问题明确了,在碰到突发情况的时候,我们才能把握住决策方向,优先满足最核心的期待,让结果更加有效。
  2. 在团队中,两个员工出现往相反方向努力的情况并不常见,但是团队每位成员对一项任务的优先级有不同的理解,却非常普遍。此时信息同步和整体协调就显得尤为重要。
  3. 目的还不明确的时候,手段的有效性是无法评判的。
  4. 清晰的目标,本身就是激励,目标缺失的团队和员工,是很难有效激励的。
  5. 一个团队,阻碍实现目标的最大困难是什么,能解决这个困难的便最适合作为当前团队的管理者。
  6. 快速执行的现象有两类:一类是看上去很忙;另外一类是真的忙得很有效,其区别,就在于核心目标的达成度

一定要花很多时间和精力,搞清楚自己在做什么,要训练自己的眼光。你把这个问题想透了,并且能够很好地传递给团队的人,那你就是领导者,你的团队也必然很有动力。

肖德时:推动进展的能力。创业公司的使命目标千奇百怪,但归根到底,无非是为了能业务增长。工作不是兴趣,兴趣不是工作。工作是一份事业,是一份职责。但是如果稍加不注意,就会丢掉很好的磨练完整事情推进的机会。技能总是要打磨的,如果不去推,你是永远不清楚事情的复杂度的。创业公司不是大企业,无法提供特别完整的基础设施和福利,那就要给员工提供有挑战性、有生产力的工作氛围。只有看法没有方案,那就根本无法起到推动的作用,而有方案,就可以去执行,错了成本也低。推动进展的能力是领导力中比较核心的能力,必须要磨练

很多创业公司早期,技术团队都是按照技术方向来组织的,但随着规模的扩大和业务的发展,很多公司会选择组织架构调整,按照业务方向来组织团队。你作为管理者就需要明确,团队的核心目标是什么。如果是以技术维度来组织团队,核心目标就应该更偏向于技术所产生的效率和质量。而如果以业务维度来组织团队,核心目标就应该更注重于塑造技术对对业务产出的贡献,以及团队成员在业务中能够获得的成就感。

王海亮:团队要按优先级处理紧急重要事情,但管理者要更关注重要但没被定为紧急的事,因为团队往往会将很重要但不好实现的事情定为重要不紧急,而这些事情又往往会关系到团队或业务未来的发展。

胡键:打造组织的过程跟搭建系统有异曲同工之妙,都是先确定整体结构,再确定相互交互,最后辅以若干工具(基础设施典型包括:版本控制、问题跟踪、持续集成、部署流水线)的过程。只是在组织搭建的过程中关注的对象是活生生的人,而不是冰冷的组件和对象。和软件架构一样,组织的结构也需要根据组织本身的发展不断进化,妄想一步到位必将自食恶果

万玉权:团队理想状态,从之前只是为了完成任务的做事方式,到现在变成了有明确目标、自驱动的做事。大家都会自下而上的主动去想这件事情到底要怎么做才能做好。同时,好多可做可不做的功能就会在这个环节中被过滤掉,最后的效果是,团队做事情会比原来更有深度。所有任务都要确定目标,都要做到有数据来量化,不管是哪个岗位。但要注意防止唯 KPI 论的出现,剔除不符合价值观的行为。最终,我们要达成的目标是,变管理为服务,变管控为赋能,将想象力与创造力归还给员工,使员工发挥自驱能力去完成目标。

陈晨:团队重组基本上是每一个发展壮大的团队都无法避免的选择,将团队从原本的按技术方向水平划分,重组为按业务方向垂直划分是一个不错的选择。按技术领域划分有几个问题:当产品出问题的时候,你很难去找到一个负责人,负责把这个问题解解决掉;产品经理会很郁闷,他至少要跟三个团队打交道,一个简单事情的推进都要开一堆会。一个好的管理者必须要把团队之间的依赖关系弱化,否则团队一旦过载,一个团队进度就会依赖于另一个团队的进度,继而产品进度就会受到影响。面对这种情况,技术团队之间就极有可能互相推诿,久而久之,团队之间的摩擦变多,信任关系也就越来越差,而这对于公司的文化是致命的。

黄勇:打造一支高效的研发团队,我们至少需要关注四个方面:组织架构、研发流程、绩效考核、团队文化,这四点缺一不可

刘俊强:技术管理者应该未雨绸缪地将未来发展所需事务列举出来,也就是说要有技术管理者的远见,你需要关注的一个象限是“重要不紧急”,另外需要培养团队成员来处理的两个象限事务是“重要紧急”和“不重要紧急”。

找人

王海亮:技术团队的组建分两个方向,比如刘国梁团队与西游记团队,刘国梁团队是通过层层筛选,都是精兵强将,而西游记团队则是各有亮点,互为补充。效率 = 有效工作量 / 工作时间。那么,管理者要干什么呢?管理者要去建立并不断的优化制度、流程与机制,去创造这个场景,并将团队带入到场景中,然后自己出来,将场景交给团队。

在团队构建初期以期权和现金的模式吸引高级技术人才,中期以高于市场同等价位迅速扩张,迅速淘汰保留优秀的中层人才;长期通过异地研发中心等方式拉平整体研发成本。高级人才的招聘要高级技术管理者自己亲自上阵,并不只是人力的事情,三顾茅庐,将心比心。

初创时期,此时人才招聘宁缺毋滥,一个不够优秀的人才你还要花很多精神去管理他,而在初期你同时要做很多事情,已经焦头烂额,不寻找到能自我驱动的人才,其实是给你自己挖坑。公司发展平稳阶段,需要建立合适的文化和体系,让这些牛人有合适的氛围,继续打磨原有的产品和技术框架的同时为未来的业务拓展打好基础。注意不要给过多的资源,一直要保持着技术团队“半饥饿”状态,这样在前期积累的狼性才可以持续保持。

邱良军:在创业期和团队组建初期,我们往往只需要专业能力较强的人,先“把事情做对”。随着业务的发展,企业的壮大,再慢慢通过管理能力来让每个人“做对的事情”。随着我们事业的继续扩展,企业向集团化发展,就需要有更强能力的人来把握未来,“为未来做事”。

如果你的下属时刻要你监督的话,意味着你选错人了

人才层次 人才画像
技术人才 专业能力、逻辑思维、学习能力等
基层管理 技术宽度、沟通协调能力、项目管理、延迟满足感
高级管理 原则性、对自己的责任范围不设限、内驱
创业型 创业精神、自带一定资源、行业洞察、价值观认同

人才层次与本教程提到的NLP思维层次、心理成熟度等内核是一致的,做事对 ==> 做对事 ==> 什么样的价值观、认知体系决定你做什么事儿。

用人

于人:搭团队,要注重补短板;而用人,恰恰要取长板,一定不能反着来。

改变自己是神,改变别人是神经病

马连浩:用人的关键在于用人所长,而非改人之短。但是,看一个人的缺点,是比较简单的,通过一两件小事就能得出大概结论。而看一个人的优点,却非常困难。在现实的技术团队中,往往存在上述各种类型的员工,做好技术人才的画像,将合适的人放到合适的位置,是形成高绩效团队的前提。给不同类型的技术工程师安排工作任务,就如同打仗排兵布阵一样。

极客时间:我经常把团队成员分为四种:有心有力、无心无力、有心无力、有力无心。

分任务

分任务是最不好培养的技能之一,因为锻炼的机会非常少,所以需要珍惜这样的机会。啥叫好任务呢,我觉得就是能让人快速上手的活。在适当的时候,要指定人去干他不擅长的任务,目的无非是让员工能定期审视自己,了解自己的边界。

自己的体会:兵法上说“以正合,以奇胜”,一方面你要有一部分不对守住基本盘,使自己立于不败之地。但胜利依靠一支奇兵,打奇袭、迂回、突击战。

洪强宁:架构师主要在解决 Scalability 的问题,一方面是人的 Scale,比如业务需求变复杂后,单人不足以承担,做到韩信那样“多多益善”是不容易的。另一方面是量的 Scale,解决用户的指数增长带来的问题。当你的着眼点更上一个层级,更多的理解业务需求,然后思考如何解决宏观问题、提炼通用组件、设计协作方式等问题的时候,你就是一名架构师了。

裁人

奈飞文化手册:我们没有钟形曲线、排名或配额,比如“每年要削减最低的 10%员工”。这不利于促进合作,我们永远也不支持这种过于简单的基于规则的方法。我们通过一种称之为“留存测试”的方法来关注管理者的判断力:如果团队里面有人想要离开,管理者会不会竭尽全力挽留他?对于没有通过该测试的人,我们会迅速而尊敬地给他一份丰厚的离职金,这样我们可以寻找替代者,让我们成为一个更好的梦之队。

有人可能猜想梦之队的关注点在于不要犯错误。事实恰恰相反。当我们寻求进步的时候,我们会尝试各种可能,犯下大量的错误。“留存测试”是一种对某个人整体贡献的判断。

当我们拥有梦幻般的同事,大家合作起来也非常愉快的时候,我们肯定可以做的更好。我们冷静而有信心,渴望获得提高。与我们想成为的伟大相比,我们还差得很远。

沟通

陶真:很多矛盾其实跟沟通方式有关。在最开始建立信任的时候,是要非常小心的,不能指手画脚,可以从问问题开始。假设自己的想法是错的,让他们去帮助我了解,我自己是不是想错了?当他们在寻找答案的过程中,突然意识到这个想法其实是对的时候,这个就变成是他的主意,这时候他是会非常开心的,他也不会觉得是我给他贡献了一个主意,因为我只是问了他问题,就让他自己说出了好像他自己想说的话。其实说服别人的最好的方法就是,让他自己想到你的好主意,然后他也不觉得这个主意是你想到的

高琦:使团队成员相互了解其他人的工作,而不是仅让一个人负责一个独立模块,每个人能够对其他人的工作提出意见。团队透明度的提升对打绩效帮助很大,使得相互之间的评价变得更客观,对绩效的结果也更容易接受。 数据指标作为参考只适用于发现极端的情况,比如筛选出表现非常出色的员工和表现非常不理想的员工,如果用数据来衡量一般表现的员工之间的差别,会非常容易出现误差。

极客时间:和队友尽快建立个人联系非常重要

考核

谷歌使用 OKR 作为目标管理框架,360 度环评作为绩效考核工具。PS: OKR 是一个目标管理工具,也就是如果你有自己的“目标管理”方式,也可以不“随波逐流”。就我个人而言,OKR更适合自驱力强的人的自我管理方式(Leader也可以通过OKR校正他的工作方向),我估计其本身就是从优秀的团队和人员中提炼出来的工作习惯,对一般员工难有比较大的价值,因为他们总可以为没实现目标找到原因,而不是事先解决掉妨碍目标的因素。

王东:现在很多公司都在用 OKR,但我们考核的可能不是你 OKR 的达成率,而是你 OKR 的挑战性或者精彩性。一定要弄清楚重点是什么,必须要在重点事情上拿结果;二是要提出和做到有挑战的事情。

小结

个人体会:

  1. 从来不是重要和不重要的事排优先级,而是重要与重要的事情排优先级

大佬们提到的书

  1. 《目标》
  2. 《重新定义管理:合弄制改变世界》

扫码购买优惠15元

笔者个人微信订阅号