组织变化发生时，怎样同步才不制造猜测
先同步已经官方确认的客观事实，不掩盖问题；再分别对上、对下和协作者说明目标、稳定性与新的协作方式。
短文
约 3 分钟阅读
写作
把经验变成
可以分享的判断。
技术、工作与领导力，以及不急于归类的现场笔记。
“最后更新”优先使用更新日期；未更新文章按发布日期排序。
人力规划不是比率游戏：从资源出现时开始对齐
人力配比只是动态概念。更重要的是在扩张、收缩和方案变化时，把目标、市场与资源约束及时对齐。
短文
约 3 分钟阅读
收录于专栏 工程协作与交付 · 第 4 篇
1-on-1 不是例会：信息、预期与决策权怎样对齐
1-on-1 的核心是让上下级了解彼此目标与诉求；授权必须随着信息和角色边界发生，而不是把上下文误当作决策权转移。
短文
约 5 分钟阅读
共享核心与本地变化：多地区系统怎样演进
多地区系统既不能把所有差异硬塞进一个核心，也不能让每个地区重复建设。关键是识别稳定边界、保留扩展点，并明确模块所有权。
短文
约 4 分钟阅读
收录于专栏 技术规划与架构 · 第 4 篇
信息同步不是抄送：怎样让对方能作决定
有效同步的目标不是把知道的一切都发出去，而是让特定读者在适当时间获得足以判断、协作或行动的信息。
短文
约 3 分钟阅读
分布式团队如何减少上下文损耗
异地协作最贵的成本往往不是时差，而是上下文反复丢失。清楚的闭环责任、异步文档和有限的重叠时间能让协作更稳。
短文
约 3 分钟阅读
收录于专栏 工程协作与交付 · 第 2 篇
资源不足时，怎样不让团队靠透支运转
资源紧张不是一句"大家再努力一点"能解决的问题。团队需要把承诺、风险和投诉还原为事实，并公开作出取舍。
短文
约 5 分钟阅读
收录于专栏 工程协作与交付 · 第 3 篇
「一定不做」不是懒惰：给承诺设边界
时间管理的核心不是塞满日历，而是根据角色、价值和机会成本明确承诺，也明确哪些事情此刻不做。
短文
约 3 分钟阅读
项目合作发生冲突时，先对齐哪三件事
多数项目冲突不是谁不配合，而是目标、事实或决策权没有被明确。先把这三件事说清，才能让分歧回到可解决的对象上。
短文
约 3 分钟阅读
收录于专栏 工程协作与交付 · 第 1 篇
质量不是某个团队的任务：共同为交付结果负责
每个角色对自己的交付负责，也共同对线上结果负责。质量闭环的关键是监控、快速止损、精确修复与复盘。
短文
约 3 分钟阅读
产研关系不是"配合"：先站到同一个阵营
好合作建立在信任、信息互通和共同解决问题上；目标冲突时不要私自承诺，而要带着完整信息上升对齐。
短文
约 3 分钟阅读
工程规范怎样既减少返工，也不制造官僚流程
好规范不是把每一步都变成审批，而是让最容易失真、返工和出事故的关键交接点变得可见、可讨论、可复用。
短文
约 3 分钟阅读
收录于专栏 技术规划与架构 · 第 3 篇
当一个人失去动力，管理者能做什么
动力不是靠口号或压力制造的。管理者能做的是分辨问题来自环境、角色、回报还是个人状态，并提供诚实而有限的支持。
短文
约 3 分钟阅读
收录于专栏 工程协作与交付 · 第 5 篇
管理者离代码多远才合适
管理者离代码的距离不该是固定的，而应由目标决定：近到能看懂架构、风险和阻塞，远到把力气花在定义问题、打通协作、向上拿权限上。
短文
约 6 分钟阅读
代码为什么会变坏：从局部便利到系统债务
代码劣化并不主要来自某一次"写得差"，而来自局部变更不断绕过共同边界；真正要维护的是设计与协作的一致性。
短文
约 2 分钟阅读
收录于专栏 技术规划与架构 · 第 2 篇
当团队说不清独特价值时，工程师还能做什么
技术不能凭空制造卖点，但工程师仍能帮助团队更准确地理解用户、缩短验证周期，并把隐含的约束变成可选择的问题。
短文
约 4 分钟阅读
陌生领域的第一张地图：怎样理解一条完整价值链
进入陌生业务或系统时，不要急着从局部方案开始。先画出使用者、流程、输入输出、关键约束和价值，才能知道该问什么。
短文
约 4 分钟阅读
一线技术管理的三种产出
一线管理不是替团队多做一点事，而是持续产出更好的判断、可预期的交付，以及能自我修复的协作系统。
短文
约 14 分钟阅读
收录于专栏 团队建设与管理 · 第 1 篇
印尼十四日记
2023 年 2 月在雅加达的十四天：一座被折叠、被切开的城市，高楼和路边摊各自过着各自的日常。
短文
约 3 分钟阅读
评估潜力时，我们真正该看什么
潜力不是履历或一次表现的标签。比起判断一个人“够不够聪明”，不如观察他怎样学习、行动、思考，以及从挫折中恢复。
短文
约 6 分钟阅读
收录于专栏 成长与自我评估 · 第 1 篇