10x (engineer, context) pairs
10x (engineer, context) pairs | benkuhn.net
又是这个10x的话题。之前也看过不少这种帖子，都是从工具/效率角度去论证，很少有从context这个角度去分析的。我倒是觉得作者这个观点很对，工具/效率差别到不了10x, context就是你解决什么问题是更加重要的来源。
其实这个context也包括技术问题，但是技术问题通常是其中的一小部分，还包括问题定义，如何impact其他人，如何更好地和团队协作等等。有点像创业，我们要的是end-to-end result. 只有在end-to-end result上各个环节都比较强，那么才可能有10x.
不过也说回来，在大公司，IC能做的范围通常也就是pipeline的几个部分，想要10x就要更大的scope.
最重要的是，Jeff 和 Sanjay 还找到了正确的背景——一家高速增长的公司在基础设施扩展问题上受阻——他们擅长构建的东西在其中非常有用。
这些示例中的共同点是您的实际输出不仅取决于您完成给定编程任务的速度。它还要求您：
- 确定正确的问题
- 建立足够的上下文，您可以尝试解决它
- 确定解决问题的最佳方法
- 让所有相关人员相信您的解决方案是最好的
- 构建解决方案 [这一步是实际编程发生的地方]
- 将解决方案投入生产
- 了解您的解决方案出了什么问题
- 根据你学到的东西提出改进意见
- 向其他人解释解决方案
- 随着需求的变化，随着时间的推移维护解决方案
此列表中的所有其他非编程任务在很大程度上取决于您与周围组织互动的方式：
- 无论您身处的环境会激励您和激发您的活力，还是会削弱您的生活意志
- 您关心的问题是否符合您团队的目标/任务
- 您的高级问题解决方法是否与您团队的需求很好地吻合
- 您是否能够建立足够的信誉来解决重要问题
- 您是否能够成功驾驭您尝试在其中构建解决方案的环境（技术和组织）
- 需要使用你的解决方案来解决问题的人是否受到激励而采用它
- 您是否能够向需要使用它的人解释您的解决方案
这些因素在不同角色之间可能会有很大差异，即使在同一团队和公司内也是如此。我见过的“工作效率提高 10 倍”的人都 (a) 非常清楚上述因素，并且 (b) 善于驾驭这些因素将他们推向成功而不是失败的情况。同样，作为一名经理，我认为我最重要的工作之一是帮助人们找到最适合他们的角色和环境。