技术

下一个平台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 组件

《技术管理36讲》笔记

2020年03月22日

简介

“管理”作为一项综合能力,是你未来的职业发展所不可回避的,至少你都需要和管理者合作。只不过因为你的角色不同,需要掌握的程度不同。你所有的职业发展,都会围绕着技术和管理这两条腿在走路,一条腿是走不远的。只要是在职场中,就有一个基本法则在发挥作用,那就是“价值兑现”,即,你能收获多少回馈,取决于你能输出多少价值。这里的回馈不仅是指物质回馈,还包括成长感、成就感、幸福感等精神回馈。做技术不重要,做管理也不重要,把技术和管理当成你职业的两条腿,在职场中输出自己最大的价值,才是最好的,才真正属于你。

要不要做管理

对公司而言,真正有价值的是你为公司解决了多少问题,而不是完成了多少工作,工作本身没有意义,解决问题才有意义。对于你自己而言,真正有价值的不是你获得了多快的晋升,多高的加薪,而是你获得了多少持续高强度训练的机会。而这两者,本质上是统一的。

  1. 你是否认同管理的价值呢?认为招聘面试、辅导员工、向上汇报、开会沟通、流程梳理、资源协调、进度推动、绩效评估等大部分管理工作,都是琐碎的“杂事”,很难从这些工作中获得价值感和成就感,甚至还对于这些工作挤占了写代码的时间而不满。认为管理的工作不如技术工作有价值,通过技术手段来解决问题才是最酷的事情。即使有很多人都认为你适合做管理,而如果你自己不认为管理是有价值的,你是不会开心地长久做下去的。
  2. 你是否对管理充满热情,并享受这些工作呢?

    1. 你是否主动地向自己的上级了解过团队的工作目标呢?
    2. 你是否主动关心过新同事该怎么培养,以及如何更好地帮助他们成长呢?
    3. 你是否享受去负责一个大项目的协调和推进?它的成功发布是否会给你带来强烈的成就感呢?
    4. 你是否思考过什么样的流程和机制可以应对团队工作中的那些疏漏呢?
  3. 你是否看重在管理方面的成长呢?

    1. 更大的责任。在互联网领域,管理者带一个团队,更多是意味着要承担更大的期待和责任。基本体会不到行使权力的快感。这是不是如你所期待呢?
    2. 更立体的视角。码代码是最简单的事情
    3. 更灵活的思维方式。在各种不确定因素中,却要去追求一个明确的目标,这对于很多新的技术管理者来说,思维方式会受到很大冲击。你想扩展你的思维方式吗?

你能收获什么呢?

  1. 你到了一个更大的平台上,你的能力和视野将得到大幅度提升。这会给你带来明显的成长感。
  2. 你不但能力变强了,你还有团队了,你能搞定更大、更复杂的事情,做出更大的成绩。这会带给你更强的成就感。

如果说你前面问我“适不适合”,主要是指“你是否可以很好地胜任”,以及“能否拿到自己想要的回报”。那么,此时你就知道要回答好这两个问题,是需要首先回答另外两问题的,即:这个选择是否更符合“你的初衷”,以及是否更能激发“你投入的意愿”

PS:如果找不到合适的方向和环境,投入会渐渐没有效率,挫败感会反噬。

丹尼尔·平克在《驱动力 3.0》一书中有说:“服从让我们撑过白天,而投入才能让我们撑过夜晚。”这告诉了我们一个很简单的事实:外驱让我们可以做好本职工作,而内驱才能让我们成就卓越。

研发leader成长手册(一)

乔新亮:技术钻研到什么程度,才可以放心聚焦管理技能呢?当你的技术深度,足以辅导团队做技术选型和决策时,就可以聚焦管理了。促使我转向管理岗位的直接原因,是我意识到:有许多工作价值,只能靠团队的力量实现,个人能力再强大也于事无补。我认为,管理的价值会随着团队规模的扩大而增加,在一般情况下,会超过大部分技术专家的价值。对于管理工作来说,聚焦的终极目标是组织成功,这是个体系性问题。要学会在一定程度上,忘记个人的辛苦和努力,因为那只能代表你的个人成长。

周志明:离开技术、放弃编码的决定,很可能会像你高考之后放下的数学、生物、地理等知识那样,一旦放手,以后就很难有机会再重新捡起来。久而久之,你对代码、技术、产品状态与团队研发状态的理解,就会渐渐和团队成员产生偏差错位,从而丧失在细节上给予指导的能力,丧失在专业问题上提出接地气解决方案的能力,只能在短期内无法验证对错的大战略方向上提意见,在会议、流程及团队管理措施上下功夫,在职业经理人式的宣讲与汇报上寻找存在感。如果是这样,那么你就从团队的导师变成了管理者,最后你跟团队的关系,就会从携手并肩奋斗的伙伴,完全演变成了只能靠公司制度与管理职位的权力来维系的雇佣关系。PS:tag 技术管理

关于技术和管理,个人价值体现在自己能力与领导对你期望的匹配,管理能力是一个深度与公司环境绑定的事。在一个公司管理做的好,去另外一家公司可能完全不是一回事。在应对变化的时候还是得靠自身的技术能力、学习能力、执行能力,还有带人成事的能力。这里不是说管理能力不行,是想表达要学会摒弃那些环境因素与外界因素。你离开上一家公司的时候,去面对新一家公司的时候,能带走的与能带来的只是你个人身上的能力和资源,没有其他。

谈谈技术能力在程序员界有一个悖论持续在困惑着很多技术人:在写代码的人的困惑是一直写代码是不是会丧失竞争力,会不会被后面年轻的更能加班写代码的人汰换。典型代表就是工作 5 年左右的核心技术骨干,此时正处于编码正嗨但也开始着手规划下一个职业发展阶段的时候。

  1. 到底什么是技术能力?两类日常工作
    1. 重复琐碎类工作,专门处理其他组技术同学对组内业务的疑惑进行解答,我们称之为 daily 支持。你可以、就事论事,把这个问题回答了结束;也可以解答完这个问题后即整理成文档,把排查步骤写清楚,提升自己和同组人的工作效率;也可以将此排查问题的方法和逻辑固化为小工具给到咨询的同学去用,让他以后可以自助排查解决;将此问题背后根因找到,从业务原理或者产品功能上去找解法,寻求彻底根治。
    2. 抽象复杂类工作,典型特质就是需要只能感受到现象,很难找到根因,没有明确目标和固定解法,需要自己做方案定策略。比如 在复杂的系统链路中往往会出现联调效率十分低下的问题,每个研发同学都在抱怨各种各样的问题,但就是没法去根治。你可以找到抱怨的同学,问一问具体的问题是什么,然后针对性解决;也可以更加广泛收集问题,然后列出来表格,归类分析并安排负责人跟进解决,最后定期跟踪进度。也可以深入分析表格的中的问题并对问题进行抽象,从架构调优和产品功能的角度去寻找原因,并寻找解决这些问题带来的业务价值,并确定目标拆解路径,最后按照任务推进和跟踪进展;进一步,从更全局角度去思考此目标与年度目标的关系,与组织发展的关系,思考如何扩大此事的效益,思考如何通过这些事的解决锻炼和培养团队同学。
  2. 技术能力层次模型

新leader常踩的坑儿有哪些?

  1. 过程导向、被动执行。团队方向感缺失,团队做不出有效的业绩,无法带领一个团队。
  2. 大包大揽、唯我最强。没有梯队,团队成员积极性受挫,由于得不到团队成员的有效支持,自己又忙又累,做不了更大的业务。
  3. 单一视角、固化思维
    1. 习惯性卡住。遇到问题和困难,很容易被卡住,到处都是绕不过去的鸿沟。
    2. 认知层次低。由于被单一惯性思维所支配,认知层次和考虑问题的维度无法提升。
    3. 难堪重任。由于创造性地解决问题的能力不足,难以承担具有挑战性的工作。
  4. 自扫门前雪、固守边界。项目推进不畅,从而影响全局的结果。自我设限,因此个人成长受限。个人影响力无法扩展。
  5. 患得患失。

可悲的现实,大部分技术领导者可能并不称职大部分技术领导者是不称职的。以下列举的几种错误模式在技术领域随处可见,基本都可以对号入座:

  1. 闷头干模式。延续独立贡献者的工作方法,所有方案自己做,所有代码自己写。
  2. 路由器模式。上级任务往下转发,任务结果收集汇报。
  3. 高压模式。对上过度汇报,对下持续增加,辅以不科学的价值宣导。
  4. 不决策模式。不对任何需求 say no,或者决策全部下放,并让下属承担决策后果。
  5. 有业务无工程模式。高度关注短期业务交付,不管工程质量。 如何进行管理呢?探讨一下
  6. 如果说技术领导者只能做好一件事的话,就是做招聘,挖掘人才。一定要给团队招一个正向的人,即与团队目标一致、文化一致,能力一致。如果团队里某个人的专业素养不能支撑住在团队生存的时候,他必然会进化出一种其他方面的能力帮助自己在团队里生存。比如他可能特别“会汇报”、特别会“写 PPT”、特别会“搞东搞西”的一些事情来帮助他自己生存。
    1. 那重视人才意味着什么?你每周花几个小时做招聘 / 面试 /1-on-1 沟通?你是否对每次面试都严格要求?会不会因为项目压力降低要求?你能欣赏和你不同的想法和观点吗?你有信心充分地授权,并敢于为此负责吗?
  7. 如何带团队。带团队肯定要定战略、做规划。
    1. OKR 应该体现团队为谁服务(for who); OKR 应该体现聚焦(即取舍),资源有限,集中精力办大事。OKR 应该要尽可能量化(不必 100%),用来校准方向,且量化不应被用来考核绩效。OKR 的承接应该遵循 Single Threaded Leadership 原则。OKR 的负责人没有,或者 OKR 的负责人有一堆,都是错误的。OKR 应该公开,且根据实际情况沟通调整。
  8. 如何建设工程文化?以下是我的一些做法:要求代码开放,要求 code review,要求 unit test;搭建 CI 看板;技术领导者每天参加 code review绩效考核 / 晋升考核中纳入“技术素养”的要求;定义阶段性技术目标,降低系统复杂度(如:下线服务,架构治理)
  9. 故障 Review 的重要性。从中可以看到这几个方面的信息:系统架构是否存在问题(例如:存在不合理依赖);研发流程是否存在问题(例如:代码提交没有单元测试覆盖);运维应急能力是否存在问题(例如:是否第一时间操作扩容),一方面是在看系统,一方面也是在看人。
  10. 建设开放透明的文化,一些反例:
    1. A 同学把自己写的代码设置为 private,他人不知道其工程能力,老板也不在乎,但是他非常会写 PPT 汇报。
    2. B 同学找 C,D 单独沟通获取了大量的信息后,和老板单独汇报(选取对自己有益的信息),促成了老板做出对自己有利的决策。
    3. B 同学就某个想法找 C、D 聊完后,包装成自己的观点,和老板单独沟通,给老板造成他能力强的印象。
    4. X 领导在一年中多次改变团队目标,但是未和团队解释这些变化的原因,导致团队士气低落。
    5. 晋升季的时候,B 同学被晋升了,但是领导没有向大家清晰的公开晋升标准以及 B 同学何以满足这些标准,导致团队各种猜测。

技术管理的患得患失

通晓多种编程语言的程序员,真香?如果我用一句话来定义程序员的工作,那就是“解决问题”。优秀的程序员不一定要编写出色的代码。他需要使用手上的最佳工具来解决业务问题。

核心原因是把管理摆在了和技术对立的位置,同时由于管理能力还没有强大到可以作为自己的核心竞争力,因此忧虑自己的技术会落后,从而失去生存能力。造成的后果:犹豫反复,无法全力以赴去做好管理,成长缓慢;对技术的看法太狭隘,从而影响技术判断力的提升。所谓的留后路,其实也是不学习,不成长,懒惰的表现,这是一种固定思维,而不是我们鼓励的成长思维!有时候“背水一战”是对管理者的最好的鞭策

技术能力不等同于编码能力:做技术管理,你并没有放弃技术,而且也不能放弃技术,放弃了技术是做不好技术管理的,你只是在一定程度上,放弃了编码而已。那么,都没时间编码,怎样才能做到不放弃技术呢?

  1. 首先,把技术提到更高视角来看待。做技术的时候,把技术做好就是最大的目标;而做了管理之后,你会把技术作为一个手段来看待,看它究竟能为目标带来什么。这很像在学习组装电脑,即便已经不需要关心主板、内存、CPU 的内部运行逻辑,但你还是要很清楚它们的功能是什么,接口什么样,以及从哪些维度去衡量一个主板的好坏、内存的好坏、CPU 的好坏,也得清楚在整台电脑中,哪个部件可能会是短板,等等。所以,技术转管理并不意味着不关心技术,只是更关心更大的目标和整体结果了。
  2. 其次,换一种学习方式来掌握技术。你要深刻地认识到,亲自写代码固然是很好的学习技术的方式,但是作为 leader,你需要快速掌握更多的技术,并且快速判断该如何搭配使用,所以你一定得有更高效的学习方式才行。技术管理人的技术水准的提升和保持,主要看能从周围人的身上汲取到多少信息和知识,而不再只是靠自学
    1. 建立你的学习机制。你可以想想在团队内建立什么样的学习机制,可以帮助你借助团队的力量来提升技术判断力,并结合自己的情况来创建。定期做交流和分享。
    2. 请教专家。在了解某一个领域的情况时,借助你的平台,找你能找到的最厉害的专家高手进行请教,他们之所以成为高手,一般都能给出高屋建瓴、醍醐灌顶的认知。
    3. 共创。在这个知识型工作者的时代,和自己埋头思考相比,共创成果往往会出乎你想象,特别能增长见识,你可以看看在团队中如何建立共创机制。

如果你把“编码时间减少”叫做放弃技术,那我得告诉你一个残酷的现实,无论你做不做管理,这事都不可避免。现实是,你要么做技术管理,用更高的视角来看待技术;要么你继续做工程师,也要用更高的视角去看待技术。

俗话说:“人穷则反本”,当人们遇到困难和挫折的时候,就想回到老路上去,这是人之常情。只是,你不得不面对的一个现实就是,即便回头去继续做技术,也不再是原来那个听指挥听安排就好、做好执行就 OK 的一线工程师,工作“升维”已不可避免。一方面,每个人的内心都有成长的诉求;另外一方面,公司和团队也需要你承担更复杂、更具挑战性的任务。

从借助自己的技术到借助大家的技术。做技术的时候,了解自己能做什么就好了。但是无论是做管理者还是架构师,你都需要带人做事了,这个时候你就需要熟悉团队里每个人的技术情况,知道谁能胜任做什么事情,适合做什么事,然后借助大家的技术去做事

在编写代码的时候,要记得代码是要有可读性的。这体现在别人升级代码要花多长时间才能看明白,修改起来是否简单、安全。考虑维护成本是技术管理者和架构师视野宽阔、能力成熟的体现。再次是机会成本,这是技术管理者做决策时要意识到的。即,当你把人力、时间花在这件事上,同时就等于放弃了另外一件事,而没有做另外这件事将带来什么样的影响呢?就是你要考虑的机会成本,你可能会因为这个思考而调整技术方案的选择。最后,希望你还能意识到协作成本,即多人协作所增加的时间精力开销。一个方案的协作方越多,需要沟通协调的成本也就越高,可控度越低。

归根结底,从技术实现者到技术应用者的转变,不断提升的是技术的使用能力,而技术实现能力由于投入的时间越来越少,会逐渐减弱。例如古代带兵打仗的将军,需要了解步,骑,弓等不同兵种的特性,判断战场局势,知道何时何地何人发起致命一击,但不一定亲自去拉弓射箭。既然你选择了做更大的事情,就不得不适当放弃一些细节,放弃一些技术实现能力,不断提升你的技术判断力,让团队行走在正确的方向上。

有效执行

如果确定是要拿项目结果,就需要做出确保结果的安排。要想让员工分担我们手头上的工作,要么靠梯队,要么靠机制。所谓靠梯队,就是团队里有胜任度非常好的人,可以帮我们搞定这件事,并且这个人已经是这方面可靠的梯队人才。如果靠梯队有困难,就只能靠机制了。所谓靠机制,就是设计一套方案,来专门应对某个场景出现的问题,这套方案可以指导和“搀扶着”员工做好这类工作。自己开发 ==> 交给员工开发 + 自己沟通检查成本 ==> 降低检查成本。作为管理者,如果你想抽出时间干别的,梯队和机制的建设会把你解放出来。

任务执行检查清单

有效执行四要素 细则 备注
目标不清 目标不够明确具体,至少没有具体到执行人员可以执行的程度
下级对目标的理解看似一致,实则有偏差,尤其是对进度、质量和效果的拿捏上
目标发生变化了,没有及时同步给相关的人员
每个人对“清晰”的理解会有所不同
责任不明 是否有明确且唯一的总负责人
各负责人对于“负责”的理解常常是不一致的
总负责人无效
把上级作为“客户”来看待,并另寻总负责人和这个“客户”来对接需求。
推进不力 过于依赖人的主动性,没有成形的机制
机制虽有,没有人确保执行,或大家不愿意执行
机制虽多,没有抓住关键环节
 
沟通不畅 沟通是否主动,还是总在等待
沟通是否达成一致,并就结论double check,并通报
沟通不足,广播出去了就默认对方收到了
 

多任务并行该如何应对?“重要紧急四象限”耳熟能详了,这个“四象限”对于盘点各项工作的优先级是否好用呢?大家都很清楚“重要紧急的工作要排在最前面”“重要的工作要像大石头一样做长远安排”“紧急的工作要立即着手”“不重要不紧急的工作直接丢弃”等应对策略。可是令大家最困惑的是,到底怎么判断一项工作重要不重要,紧急不紧急呢?这个前置步骤才是最难以判断的。

在实际的工作中,我们经常做的并不是梳理轻重缓急四象限,更常见的情形是,我们要把日常的工作分为两种情况:一种是计划内的,也就是按照我们的规划进行的;另外一种是计划外的,即突发的情况和任务。我们的应对策略其实非常简单:

  1. 对于“计划内工作”,看收益是否足够大。收益越大就越重要,也就越需要给予相匹配的优先级、资源和关注度;收益相对不大,就放入“To do list”,作为待办任务处理。
  2. 对于“计划外的工作”,看损失是否足够大。损失够大,就按照紧急任务安排,以止损为核心目的;如果损失可控,就转化为一个可以安排到“计划内”的工作

个人体会:“重要紧急四象限” 很有名但一直用不起来,说明不贴合实际。 我们在学习、提炼套路的时候,也注意识别、避免这类华而不实的”思维框架“。

沟通

上级更倾向于告诉你,他们想要什么;而不会主动告诉你,他们愿意用什么来交换。这不是他们“唯利是图”,也不是他们“只让马拉车不让马吃草”,而是因为评估影响并给出应对方案是你的工作,这是你最清楚且拿手的,而上级判断不出对你既有安排的影响到底多大。所以,很多上级管理者跟我说,他们默认是需要沟通的,而不是默认不沟通,最怕大家最后给他们一些“surprise”。

诚意正心:遇到冲突时,跳出自己的角色来判断是非对错,通过审视初心来做决策,很容易让自己充满力量。当然,这无关管理方法论,更多的是对职场法则的认知和理解,也正是这个最基础的哲学,给予我应对冲突的基本逻辑判断。

你的角色是由上级和公司对你的具体期待决定的,而不是你的头衔。常常有跳槽的管理者问我“技术总监都做哪些事儿”之类的问题,这显然是混淆了头衔和角色。因为即使是同一个头衔,在不同公司所需要承担的角色可能是千差万别的,所以,不要指望按照头衔去筹划自己的工作,就可以满足上级和公司的期待。那么,如何厘清自己的“角色”呢?我的回答是:和你的直接上级去约定(如果你的直接上级对你有充分的管理权限的话)。比如,我每次空降的时候,都会问未来上级一个问题:“长期我们很难约定,仅就我入职后的前三个月或前六个月,你觉得我做好哪三件事,你会对我的工作比较满意?”如果对方都没有想过这个问题,你不难发现,对方聘请你的意图是不清晰的,只是觉得应该有一个技术管理者而已。如此,未来合作关系崩掉的可能性会比较大。

管理沟通常见的五类问题

  1. 视角问题:沟通仅从自己出发,对管理者的角色和视角认知不够。
  2. 姿态问题:总是在防卫,随时准备战斗。防卫姿态对于管理者做好工作不会有正向价值,长此以往,就等于关闭了别人提供帮助的大门,任其自生自灭,这显然是个双输的结果。所以,工作中最好还是以做事为主,少考虑一些个人感受。如果就事论事地去沟通问题,反而会赢得更多合作者的尊重。
  3. 方式问题:先给人贴标签,对人不对事。
  4. 意识问题:沟通没有形成闭环。不能默认对方一定能收到,而且不能默认对方理解的和你想的是一致的。切忌把事实、判断、感受、责任、原因、方案等统统揉到一起来说了:你讲事实他说原因,你说原因他说感受,你说感受他说逻辑,你说逻辑他说责任,你说责任他说解决方案,你说解决方案他说困难……最终就成了“鸡同鸭讲”,互相的不理解和不认同。
  5. 初衷问题:只给抱怨不给建议。

方法

管理工作的底层逻辑正在从管控到激发

每一种管理方法或管理手段,都是以一定的人性假设为基础的,你认为人是什么样的人,你就会用什么样的手段来管理他。在现实的管理情境中,管理者要抛开对人性的判断,而是要在”抑恶扬善”、”抑懒激勤”的方面来制定管理措施。

把长线项目里程碑化,把日常工作项目化,让员工走一步有一步的成果,会提升员工的成就感。

员工越来越追求工作背后的价值和意义这件事是不可忽略的。所以,作为管理者你需要有能力为员工梳理清楚这个问题。