背景故事
我的一个朋友曾担任技术主管，在他们的大部分职业生涯中，我们称他们为Jo（不是真实姓名）。 几年前，Jo担任了很少涉及编码的管理职务。 他们不再以开发人员的身份全职工作，并且不再扮演技术主管的角色。 乔现在领导一个由六个或七个大型开发小组组成的组织。
在技术主管的定义中 ，我建议技术主管应至少编写30％的时间来编写代码。 Jo设法找到了一些时间来编写代码，但这并不一致-大约一周一个小时。 在每周40小时内，这不到3％。 乔错过了编写代码的机会。 Jo不再是开发人员，Jo不再是技术主管。
你有什么影响？
每个角色都有一套职责，以及履行这些职责的权限。 此权限可为您提供一定程度的控制权。
例如，开发人员可以控制他们设计和编写的代码和测试。 其他人可能会对代码产生影响 。 影响因素的示例包括体系结构或产品和/或平台约束，团队代码标准和代码审查。 最终，开发人员可以控制自己的代码。
每个公司都有特定的组织设计。 开发人员（和其他员工）在此结构内工作。 组织设计会影响软件交付的有效性。 具有完全不同部门（例如，开发人员和测试人员）的严格层次结构很难进行协作。 对于许多开发人员而言，无效的组织设计是一个痛点，因为它使交付软件变得更加困难。
开发人员对组织设计的控制为零。 他们也许可以影响它，但最终还是由经理控制 。 一些开发人员可能会尝试更改此设置，但是大多数开发人员会抱怨。 我过去曾听过开发人员的话：
谁的绝妙主意是建立这样的开发团队？
另一个例子。
我无法完成任何事情，因为我依靠这些人来完成工作，而他们坐在另一层楼上。
开发人员可以抱怨，这是一种无效的影响方式，尽管还有许多更有效的方法。 在作者 《 影响力：说服的心理学 》一书中，罗伯特·西尔迪尼（Robert Cialdini）概述了六个关键的影响策略：互惠，承诺（和一致性），社会证明，喜欢（ 晕轮效应的一种形式），权威和稀缺性。
开发人员只会影响他们的工作环境。 他们不控制它。 注意：当然，当公司规模很小到足以使开发人员也承担一般组织管理职责时（例如在初创公司中），这是一个例外
影响力的交易控制
从开发人员转为技术主管，再从技术主管转为总经理的Jo与我分享了一个有趣的见解。
您知道我曾经作为开发人员抱怨的那些事情吗？ 好吧，现在我可以更改它们了。
程序员将“非技术”路径视为没有提供的路径。 当程序员担任领导角色时，他们既继承职责又有权控制更多的工作环境。 开发人员在这些约束下工作。 技术负责人拥有更改这些约束的更大权限，而经理则拥有控制和更改这些约束的更大权限。
这对成为技术主管的开发人员有何影响？
当开发人员放弃对影响力贸易的控制时，他们的影响力范围就会扩大。 他们可以开发整个技术解决方案，而不必开发单个功能。 技术主管的影响力也在技术和业务方面之间增长。 当开发人员参与得太晚时，技术主管对如何使用技术解决业务问题具有更大的影响力。
我建议技术负责人不要放弃所有编码。 取而代之的是，它花费了更多的时间来编写代码，以换取更大的影响力。 影响力范围更广，不仅对您有帮助，而且您的团队还可以在一个更好的工作环境中编写更好的代码。
翻译自: https://www.javacodegeeks.com/2014/12/why-you-want-to-give-up-coding.html