最近两年，随着技术团队的横向扩大，及组织结构的纵向调整，无论从主观感受，还是客观环境，每次行动的变革幅度都比较大，但变革的内容在往某种确定方向不断积累，最终呈现出一些直观感受，而让我感受最为深刻的要属一年一度的企业组织能力诊断。

在这项诊断的报告中，系统、客观地体现出战略与组织能力的匹配程度，尤其对于管理者而言，那些在执行中 “看不清楚的”、“看不到的”、“做没做的”，都能通过问卷收集的形式定量分析，并得出具有参考价值的数据结论。

今年，单论报告结果而言，无论招聘与培训，还是升迁与绩效，甚至奖惩与淘汰的纬度，都比去年有较大幅度的提升，然而 “金无足赤，人无完人”，在所有的数据中，唯独 “技术氛围” 这一项不升反降，而且下降服务还相对较大。

怎么可能呢？今年的分享频率比去年大，还不够？技术大会都有参加，回来也都分享了呀？……这样的疑问似乎瞬间占满了每位管理者的脑海。为了探索根源，我们通过调取数据，进行理性分析后看到，在 “积极分享、节奏固化、互动频次” 这三个选项上的得分还是不错的，而唯独 “架构选型、技术驱动” 等选项的分值较低，导致最终平均值的低下。

面对这样的结果，我们在少许的沉默之后，终于有人无法压抑内心 “那上万头草泥马的狂奔”，拉高嗓门喊到：

真不明白，我们所使用的技术架构哪里不好了？不仅满足公司当下的业务需求，甚至已展望至2-3年后的战略意图，这难道不是最佳的架构选型吗？怎么样的技术驱动力才算好？难道为了技术而技术，就是体现技术氛围好的最佳方式吗？

记得马云曾在某次采访中说过：

道家讲究和谐，儒家讲究规矩，佛家讲究包容。我从太极中悟到：事情并没有好与坏，关键是看你怎么看。

咱们先从管理者的角度看，或许这已是最佳的技术氛围，技术选型紧贴互联网，分享情怀紧跟刚需，多务实，多接地气，把业务伺候的服服帖帖，公司业绩稳定增长，难道这样的公司没有技术氛围吗？

切换下视角，咱们再从程序员的角度看，那句话怎么说来着 “不想做老板的员工不是好员工，不想做架构的程序员不是好程序员”，对于每天忙于交付业务的技术小伙伴而言，在类似996这样的工作强度下，每天抽出时间仰望下技术未来或自己感兴趣的技术点，单从理想与抱负的角度来看应该值得称赞，这种表现也恰恰是程序员掩盖焦虑感的一种惯用手段。

面对这种焦虑，外加互联网巨头在技术上的大肆宣传，大部分中小型企业不仅在融资和招揽人才上处处受阻，还要经受有些程序员 “有半桶水极晃悠” 的挑战，这些人虽说基础扎实，学习能力较强，精通专业术语，时不时还来几句听似很牛X的架构语调，但对业务没兴趣，对技术痴迷，对服务器等硬性资源无节制使用，开口闭口都是那句：

你们这太LOW了吧，某某某公司用的是C技术，再说如果遭遇XXX情况，你怎么应对呢？如果YYY你怎么升级？来，如果用A技术就能解决扩容性的问题，再用B技术就能平滑切换啦……

不信？基于我遇过的案例编一个段子吧，一起瞅瞅这种经历是否有过。

某某传统企业做技术规划，开始微服务拆分，张三将某核心系统的功能服务陆续拆分为N多个微服务，并为了提升性能，增加扩展灵活性，将编程语言从Java替换为Go，将数据库从MySQL替换为MongoDB。

在研发阶段，似乎一切都相当顺利，但到了发布环节，由于微服务的过度拆分导致运维成本的大幅上升（已达到无法承受的程度），而且异构语言所产生的兼容性问题根本无法在短期内解决。于是张三开始奚落其他团队不敢拥抱新技术，其团队小伙伴甚至还嘲笑其他团队只会用JAVA写 “IF ELSE”，最终这个规划草草收场，不了了之。

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/qmlgCqCvavbDAjND94lKmQ

创作场景

为了技术而技术，是不是一种体现技术氛围的方式？