文 | 少个分号 （转载请注明出处）
公众号：TechLead 少个分号
知乎：少个分号
微信号：shaogefenhao
网站：shaogefenhao.com
从写代码的架构师，变成带人的管理者，这条路，说简单也简单——没人拦着你；说难也难——坑特别多。
我原以为自己技术还可以，懂分布式、也做过系统重构，切换成管理岗后，应该能轻松带飞。
后面才发现：技术能力，是门票，不是通行证。
今天就来聊聊我从架构师转管理者这一路，踩过的 5 个坑。你可能也踩过，只是没说出口。
01 坑一：架构有没有“标准答案”？——屁股决定脑袋
刚做管理的时候，我最爱的一句话是：“这个架构不合理。”
看到哪个项目选型不好、技术债多、模块耦合，我上来就怼：“重构吧，这不行。”
结果业务方一脸懵：“你能先别动我的数据先上线吗？”
我才意识到一个真相：架构没有对错，只有立场。
-
做电商的，看重高并发、稳定性； -
做 SaaS 的，要多租户支持和低成本； -
做 2B 项目的，要快速交付、客户验收优先。
你以为对方架构不合理，其实是他屁股不和你坐一个方向。
技术是工具，架构是妥协，选择的是 trade-off，不是绝对优雅。
02 想做“整洁架构”？先准备好手弄脏
刚开始带团队的时候，我天天跟他们讲《整洁架构》《代码整洁之道》《DDD 分层模型》。
我梦想着一个“干净”、“优雅”、“像艺术品一样”的系统。
结果是——项目 delay，业务方天天催，开发吐槽：“你不让我们调 SDK，只能搞适配器，真浪费时间。”
我意识到一个事实：干实事就会弄脏手。
现实项目里，你会遇到：
-
三方接口又臭又长还不能改； -
产品提需求一天变三次； -
为了上线 KPI 被迫临时堆代码；
这时候你再谈“纯净架构”，团队想打人。
整洁是理想，不是标准；先能跑起来，再慢慢清洗。
03 坑三：做管理还在炫技术？业务影响力 > 技术卓越
有段时间我特别想证明自己“还很强”，生怕别人说我做管理后“手生”了。
于是每次评审会上，我都挑战团队设计、参与 coding、提各种建议。
问题是——业务推进慢了。
我天天泡在技术细节里，没空和产品对齐节奏、没空帮团队争取资源，结果是领导说我“投入不聚焦”。
直到有天我发现：团队最需要我解决的问题，不是技术，而是“怎么帮我们把事推进”。
做管理后，我要处理：
-
产品目标有没有冲突？ -
设计有没有时间对齐？ -
技术选型是否影响上线周期？
这些东西，说起来都不“炫”，但不做没人做。
从“技术专家”变“推动者”，不是堕落，而是升级。
04 坑四：架构也要会“讲故事”，不然没人听你方案
以前我写架构文档，一定图多、流程细、术语一大堆。
我以为这叫专业。
但发现业务同事根本不想看，产品经理压根搞不懂，只会问一句：“那我们上线会更快吗？”
我恍然大悟：架构也要有卖点。
你再复杂的设计，如果不能用一句话讲清“对业务的好处”，就是失败的提案。
举个例子：
-
原来要部署 3 小时，现在变 5 分钟； -
原来扩容要重启服务，现在一键自动伸缩； -
原来一个功能只能复用 30%，现在能复用 80%。
这些就是卖点。
别光想着“写文档”，你得想的是：我要让谁支持？他们关心什么？我怎么让他们听懂？
05 坑五：技术难，人更难
以前我带小团队，最多就是教人写代码、审个 PR，问题不大。
后来人多，问题来了：
-
有人天天迟到，但技术不错，能不能说？ -
有人总抱怨产品垃圾，怎么劝？ -
有人想升职，但不配怎么办？
这时候我想套模板，但发现：管理不是算法，解决不了人性。
人是模糊的、情绪化的、有历史包袱的。
你跟他说 “多沟通” 没用，他要的是“你有没有理解我被忽视的感受”。
你说 “我们看事实”，他要的是“你站不站在我这边”。
技术是黑白，人是灰色。
从管系统到带人，你要重构的是自己的认知，不是代码。
写在最后
很多人觉得从架构师变成管理者，是“脱离技术”、是“变水了”。
其实不是。
真正的管理，不是离开技术，而是站在更高的维度解决技术难题背后的“人和事”。
-
架构不是纯粹的审美，是不同角色利益的妥协； -
方案不是用来“装逼”，是用来“推进”； -
带团队不是变成“甩锅侠”，而是处理每一个模糊的决策点。
从架构师到管理者，不是放弃技术，而是升级你的战场。
#技术管理 #管理 #职场 #冲突管理 #问题解决 #领导力
作者服务
作者提供咨询服务，如果您遇到管理或者职场的问题，欢迎一起聊聊。
作者专栏
作者整理了相对系统的关于人性和组织的专栏，能从底层给予管理和职场提供逻辑依据。
