经理不会编码吗？他们不应该是你的经理

不会编程的经理在2005年左右是美国企业界过时的产物。我接触过的最好的经理大约80%的时间都花在编码、架构或做需要工程能力的技术工作上。如果你的经理认为编码“低于”他们，那么他们需要一剂谦卑的馅饼。没有他们，您的组织可能会过得更好。

与开发人员相关的污名由来已久，那就是我们都是不能处理人际关系的极客。由于我们代码猴的天性，我们需要“人”，他们可以为我们参加会议，并有效地将我们的努力传达给上级。

虽然上面的内容仍然很有趣，但它已经过时了。随着开发人员社区在过去20年中呈指数级增长，其成员之间的个性多样性也随之增长。换句话说，不难找到具备管理职位所需软技能的开发人员。

虽然经理不需要是团队中最有才华的开发人员，但他们至少必须具备技术素养。当团队成员带着技术方案去找他们的老板时，经理应该能够给出有价值的反馈。

在哈佛大学的这项研究中，来自美国和英国的3.5万名员工接受了工作满意度调查，并收集了影响他们工作幸福感的因素。结果表明，对员工满意度影响最大的单一因素是他们的老板是否具备技术能力。我身体力行，所以在Qvault应用程序中，所有的工程领导将永远负责推送代码。

将称职老板的想法与人们非常熟悉的经历进行对比：进入非技术型中层管理人员解决工程问题，结果却被困在教学会议上，因为老板从未听说过酒吧-子系统。

一个好的经理会同情那些向他们汇报工作的人。如果老板不编写代码或很长时间没有编写代码，他们就不会理解团队面临的日常问题。一个好的工程领导者不仅要了解现代问题，而且要把在不断变化的创新环境中积极寻求技术解决方案作为自己的职责。

我很赞同这样的想法，即首席技术官将有大量的业务和产品相关工作要专注，但他们不能让自己的技术印章出错。要办好创新型公司的工程部门，最高层要牢牢把握实施难点。如果这仅仅意味着检查架构图和检查拉式请求，那么就这样吧，但是没有什么比实际操作的工程工作更能保持敏锐了。

你和非技术领导有过节吗，或者你完全不同意我的观点？通过我的一个社交档案让我知道。