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