有一段时间没有上CSDN了。前两天，下班之前浏览了一会儿。一不小心点进了CTO版块的一段讨论(http://xujunjie.cto.csdn.net/Hot_Discuss.aspx?Name=xujunjie&pointid=2469)。看得我心惊肉跳。本不想写些什么，但有时候如鲠在喉，不吐不快。
主题是这样的：
总是恨不得自己上阵
有时候和同事一起做项目，同事做的经常感觉不能如自己心意，总是恨不得自己去做。但是全部自己做又是不可能的。
大家有过这样的情况么？
好了，让我们来点评一下这些CTO们的回答吧。
1楼：
现代企业的管理者，首先是一个教育家。他能把自己的思想和技术传授给自己的团队和组织。
如果实在不行，就找些人来教育他们如：激励（针对士气、工作极积性）、培训（技术能力）。
不到万不得矣，别动。
到了万不得矣，也别动。
稳住，淡定……，我一直对自己这么说：无非就是面对损失承担责任嘛！
作为一个现代企业的管理者，整天就想着“无非就是面对损失承担责任嘛”。这是什么样的“管理者”呢？一定是在大型国企的吧？
反正只是“面对损失”。损失是在我的对面，不是我这一边的。“面对”嘛，我自己没甚么损失。
如果什么都“别动”的话，那真是一个“教育家”了，不过教育家还是要动动嘴皮的吧？
2楼：
经常给下面的人做点培训,每个人的思想都是不一样的,
项目上也难免会有很多不如人意,
把好的思想给他们,要给他们好的技术更为重要.
遇见... ...
这个回答中规中矩。不知道他遇见过什么？
3楼：
嗯，也是我总想让他们按照我的思维开发，其实每个人都有自己的一套开发思维的，自己也不一定是最好的，只是习惯了而岂，有时可以抱着“事不关已，高高挂起”的心态，只要他在规定的时间内实现需求的功能就可以了。
我不知道什么样的企业喜欢“事不关已，高高挂起”的CTO。不过他自己知道“自己也不一定是最好的”已经不错了。不过我相信他不知道“自己一定不是最好的”。
4楼：
淡定。
做该自己做的事情。
把握重点、原则，其他的事情做的差点也由他们去。不过，要对他们的成果或者事情的结果做出评价，指出问题所在，有的甚至是提出好的建议或者解决方案。
对于人员，最好有个培养计划，培养计划要满足工作。
时间一长，他们自然会长进。
我不知道什么是“淡定”，手下的人做得差也由他们去。三鹿的老板就是这么死的吧？（具体的情况我不知道，只是我从报纸上看到的）
5楼：
这种情况不能一概而论，没有明确的目标前，不要事先给自己限定角色。能打胜仗的除了隐身模后、运筹帷幄的儒生外，也不乏身先士卒，勇冠三军的猛士。
如果你的目标是按时交付，该动手就动手吧，动手也是培训后进者的一种方式。
如果你的目标是锻炼队伍，培养新人（特别当需要培养一个独当一面者，取代自己的角色时），那就忍忍吧， 多观察， 多点评，多引导，多包容， 给他们从错误中学习的机会。
总之，我们谈框架，往往仅局限于技术层面，其实，项目规模和目标（不仅是合同上写的，同时也是项目相关人员的共同愿景），组织结构，开发人员的构成也是框架的一部分，框架决定行为模式。
为什么“不要事先给自己限定角色”，您不知道CTO是什么角色？
“如果你的目标是按时交付， 该动手就动手吧”，不敢苟同。如果我的目标永远是按时交付，那么我是不是每次都要动手呢？
不过有些建议不是没有道理。
6 Ignore
7楼：
对，别总恨不得自己要上阵。
要不干胸就赤膊上阵得了。
想想：咱也是干技术出身的。在自己的领域，一般工作效率是普通高级程序员的两倍。和和……怕啥。
听着有些“有些”水浒英雄的味道。不过宋江是不会赤膊上阵的。CTO的水平也许是普通高级程序员的两倍，但是一个公司CTO不可能和高级程序员一样多吧？如果我是您，想想我都怕。
8楼：
他们做的你不如意，说明你的想法和要求还不够细。毕竟每个人的想法不一样，想要他们做出来的东西和你想的一样，那就要把你的想法完完全全的告诉给他们。
错。每次我都一一不停地告诉每个人，那么规范有什么用呢？
9楼：
要想走得快,一个人走.
要想走走远,一起走……
一个人走没什么问题。 要看下面的人能不能跟上。Microsoft的人您知道几个？除了Bill Gates?
如果大家都走得比您慢，要和他们一起走，您就要被拖死了。
10楼：
管理者的绩效更多来自于团队其他成员的绩效。所以，切记应该沉得住气。
这个时候应该先反思一下如何帮助团队成员提高绩效，如果亲力亲为可以实现这一目标，那亲自上场也无妨。
这个时候更多的应该思考一下：
问题是什么？
目标是明确的吗？
团队成员有具体的操作指导吗？
如果有指导可以改进吗？没有指导需要建立吗？如何建立？
有明确检验结果好坏的标准吗？
团队建立之初，大家意见一般是不一致的，管理者应该建立统一的指导框架和原则，如果能细化为指引，落实为流程更好。和团队成员一起不断反思不足，逐步改进。
如果在做项目的时候还在考虑“目标是明确的吗？”，“团队成员有具体的操作指导吗”，那这位CTO就会…，他还会是CTO吗？
11楼：
该出手时就出手！
我如果开公司找保安部的头，我会找您。CTO？就算了吧。
12楼：
5楼说的是。但，为了以后赶进度不会这么累，还是尽量地能放手就放手，多给他们空间。老是以自己的思维绑加他们的思想，一方面过头了会催毁他们的自信心，到头来，反而让你更累，另一方面，你的想法不一定都是正确的哦。大家应该都知道什么叫“程序员思维”，这是贬义词！
我还真不知道什么是“程序员思维”。只是我的错。
不过，为了“以后赶进度不会这么累就放手”，那就是您的错了，只会更累。
13 ignore
14楼：
与人合作是一门学问。
废话。
15楼：
管理的4大要素：目标、组织、流程、考核与协调。作为一个领导你一定是有一技之长而且综合能力因该是最强的。应该肩负着团队成败的第一责任人。
我们搞技术出身的通病是“恨活”，就是看不得别人干活。啥活都自己干了还要伙计干啥？何况我们不是啥方面都是专家。
我的心得与教训：
1.管好目标和结果，淡化过程
2.用好下属的黄金法则：有才有德-充分授权；有才无德-压价约束；有德无才（可能你认为是大多数）-辅导而不是替他做事；无德无才-开除！
一切前提，要有良好的管理素质与工作心态
“淡化过程”本质是错误的。等到结果的时候才知道错误，那已经晚了。任何一本软件工程的书都会告诉您过程控制的重要性。
16楼：
多折磨他们，不满意你就让重做。
这位CTO是在关塔那摩做项目的把？无语。
看到这些CTO的发言，我有些疑惑。软件业发展了几十年，软件业也已经步入更年期了。就像当年的制造业一样，现在的西方国家纷纷把纯粹的软件外包出去，而更多的是专注于软件服务上。而我们的CTO们似乎还不太懂得什么是软件工程。人家的麦当劳新店天天开业，我们还在讨论手下有人烧饼没他做得好，他不得不亲自做。
其实这个问题根本无需回答。软件工程这种成熟的理论早就给出答案了。剩下的只是如何运用的问题。
所有的回答中都没有提到文档，即规范的重要性。没有规矩，不成方圆。全世界的“巨无霸”都是相同的味道，就是因为配方和过程都是一样的。所有的代码应该看起来都是一样的，没有注释的话，您不应该能区分那段是甲写的，哪段是乙写的。这就需要设计上的规范，代码上的规范，等等。这些规范是在项目开始之前或是前期就存在的，否则的话，就不应该开始。
我们都知道元帅手下有大将，大将手下有副将，或偏将。那么对应的CTO手下就应该软件架构师，系统设计师，开发工程师。元帅应该是坐在中军帐中指挥将军们的，不是跑到前线指挥 一列小兵开炮的。同理，CTO不会去看看开发工程师的代码符合不符合规范，那是系统设计师的任务。要是您说你们人少，只有几条枪，没有件架构师，设计师，那么您也别把自己当什么CTO了。
还有CTO并不是教育家。这个世界上没有几个CTO能做这种事。他们更多的工作是制定并执行计划，不是教育别人。他们可以把自己的部分思维和习惯放进规范中，当然要摒弃错误的和过时的。这和其他人没什么两样。每个人都可以提出好的规范，前提是要经过团队的讨论和确定。
至于CTO也想写代码，设计架构，这当然可以。不过一样要遵循大家公认的规范。
成熟的软件管理经验多的是，您可以自己选择的去看，在这里我就不深入下去了。
也许这些讨论的并非真正的CTO。不过并不否认这种现状的存在。