作为技术专家出身的管理者，是一种优势（你所做的很多决策可能比非技术出身的管理者更加具有可行性和性价比）、也是一种劣势（你可能会过于自恋自己的技术优势）。这取决于你在接下去的职业生涯中，如何取舍你的技术优势。
0、确定目标，人员、技术灵活组合，投入产出最大化驱动。
做任何事情之前，先好好想想要达到什么样的目标。确定目标之后，再根据人员的水平、储备情况，各技术的核心擅长点，确定合理的计划，实现方式，不要基于限定的具体实现方式、特定于某个人来确定方案。举个例子，在id生成的场景中，可以使用数据库机制，oracle的序列，mysql的自增列，也可以应用中实现，具体如何实现需要考虑当时的业务目标，自己运行的系统和给客户做的系统很可能选择不同方案，并发量、有序性、是否严格递增等等都会导致不同方案，最主要的是怎么样能够满足业务要求、同时最小化成本（运维+开发）。
1、能接受的答案永远超过2个。
95%+的情况下，能够解决问题或者让客户满意的答案总是超过2个。比如就某些只需要一个实例的场景而言，可以使用单例模式，也可以使用静态方法，很多时候采用哪种其实都一样。再如是否使用分布式缓存，很多时候，并发量没有到非得使用分布式缓存的地步，绝大部分场景中基于sql的pk完全可以满足要求，这种情况下不要过于固执某种答案，尤其是自己擅长一些方案、不擅长另外一些方案时，除非明确可以证明其存在风险且无法避免。
当然，在某些情况下，比如在一些统计查询中，五六张几百万记录的表进行关联、然后group、分析函数各种统计时，一定是要坚持oracle/postgresql+hash join/parallel+pga，甚至各种固定执行计划的，如果执意要采用mysql或者在应用中比如java中计算的，还是要反对的。
所以，除非明确可以证明其存在风险且无法避免，记住任何时候大部分场景选择哪种方案并无本质性差别，因为业务远达不到会造成明显差别的体量。
2、容忍犯错一两次，只要可控，哪怕明知。
这种情况一般发生在新到一个环境或者一些老员工加入、或者接手、协助一些需要帮助的项目、或者某些PPT领导时，我们会发现有些方案看起来就像开着轿车去工地里运砖头，或者拿着榔头去拆几十层高的楼，但是经过沟通后，相关人员仍然坚持认为没有问题，一定要采用某种方案时。这个时候最好的方式并不是闹僵亦或是到处打小报告。只要范围可控，有时候甚至可以那生产环境在高峰期可能出现问题为代价，也是可以接受出现一两次小事故的。当相同的事故多次出现时，通常别人主动寻求解决，此时只要我们足够的诚心，不仅可以解决问题，建立威信，更重要的是，还能和当事人建立更为和谐的后续合作基础。作为领导，更应如此，方才体现大度。
3、所有的事都是你自己的事。
无论是作为程序员，架构师，技术经理还是项目经理，要想做好一件事，最重要的是记住Linus 谈软件开发管理经验 中说到的，所有的事情都是你自己的事，不要觉得别人有义务配合、协作、支持你完成你想做的事，总之上下游都得打点好，如果到了约定1/2的时间，已知无法完成了，那么如果你可以解决的话，那就自己解决吧，哪怕你是协助他解决的，你们的工作量比例是1/2。如果你觉得这不是你该做的事，那么问问自己想不想做这事（刨除公司付给你工资的因素，你今天的额外付出，明天会有家公司额外付给你的），如果想做，那就去做，至于最后成绩归谁，不要太在意，总有很多人看在眼里。
4、最小化重复的人工动作。
很多事情，很多公司的很多团队都在重复的劳动，低效的生产率、高昂的人力成本，作为管理者，你要意识到，在IT业，最贵的不是购买价格两倍的服务器、不是该买1.5w的mac还是五六千的dell、也不是该不该买个正规的IDE、给员工各种零食小吃，而是开发人员、测试、运维人员的成本，一个初级开发一年的工资成本就要10万了，作为一个优秀的管理者，你应该观察哪些事情是在重复又可以避免的。比如，每次升级总要人工更改一些配置文件，相同的问题新员工或者另外一个项目组的同事总是要问，定期录入证券指数，我们就要好好想想是否可以通过环境变量、域名方式避免第一个问题，是否建立在线共享支持库，花一个下午建立定时任务自动从一些资讯源下载等等。这就像如果你家门口放了一块大石头，你每次进出门都要绕走，我相信绝大部分人宁愿花一天时间也要把这个石头想办法搬走。在日常管理中，一样的道理。
很多人肯定会想，这不是应该开发的事情么，为什么自己作为leader如此悲剧，我只能说有太多的员工缺少责任心、上进心、学习主动性，说的不好听就是混日子。如果你在一个已经习惯了最小化重复劳动的团队，那么你是幸运的，事实上很多外界认为不错的公司存在着很多这些问题。
总之，记住不要为了扩大规模而扩大规模。
5、及时决策。先确定一种规范，哪怕后来证明是错的。
我们总会遇到一些事情需要确定下来，但是在此之前我们没有经验确定怎么样做才是合理的，这个时候你发现其他成员也没有经验，网上也大都是没有实际可以参考的，而事情已经到了必须要做的时候了。这个时候，我们应该做的事尽可能参考周边的例子。比如有一阵子，我们在大面积迁移到SSL的时候，就遇到证书的命名规范和存放路径的问题，因为之前较少使用，所以一下子对于公钥、私钥、CA各自的命名规范、以及存储路径等不确定放在哪里比较合适，因为我们有着上百个实例在运行，同时tomcat/nginx/mysql/RPC都需要这些统一的模式，所以不可能中心存储、也没法使用绝对路径。所以，最后我们暂定为目录根据JDK走，全部放在$BASE_HOME/security下，同时命名规范参考mysql的规则。确定之后，我们就按照这样让测试和运维去执行了，虽然一直这么下来没出什么问题。万一到后面出现问题的话，一定要能主动承认是自己考虑不够到位，并及时进行调整为正确。很多事情，笔者曾见到很多的事情因为没有人愿意决策并推进执行，一年前存在的问题，一年后仍然存在，然后又不停地在反馈事情多、人员少。
6、以身作则。
不管是大公司还是小公司，套路和公关手法通常都是一样的，各种股权、期权、画大饼，我估计很多的开发都听过我们是全员持股、公司是大家的，其实大部分人手里的那点股权或者期权真到兑现那天，稀释的加上辛辛苦苦那么多年失去的外面大公司的收入，并没有让你的收入增加了很多。更何况，95%的创业公司最后都会死去。现在人都很聪明了，所以不要觉得天天画大饼，同学们就会觉得公司真的是他们的。大部分的时候，成员做事的习惯完全是看着顶头上司的行为举止，leader的做事风格决定了下面成员的风格。如果leader每天说我们重视系统质量、产品化、提高稳定性、客户至上、open不限制具体实现，但是生产环境有一二十个版本，不同的部署目录、三方软件版本等等，同时口头上说对于某个方案不限制具体的实现方式、但是真正到做的时候除了最擅长的老套实现外（哪怕存在已知明显的缺陷），其他的都不同意。同时，甚至笔者曾遇到有些领导自己犯的错和bug总找个理由说这个是使用问题、反正就是不承认。类似此类言行不一的事情，基本上出个三五次，下面的人就会形成相同的氛围。所以，作为leader，以身作则不仅可以使你能够树立更好的团队氛围、个人威信，提升整体绩效，甚至对于周边团队来说，当需要进行合作和相互支持时，也为此提前预埋了良好的信誉。
7、大局为重，不要太在意吃小亏。
8、尽量第一次就把事情做完善。
从软件的术语来说，我们可以称之为防御式编程+契约式编程。其实到管理上也是一样的，不管最后确定了哪种实现方案，很重要的是对于不确定的外界因素或者使用习惯，尽量做好防御性措施，比如说我们在外部系统交互的时候，需要考虑到超时情况，涉及到写批处理脚本时，要考虑到各环境的不一致，此时应该尽量通过规范或者环境变量、域名等等进行事先的判断和约定。再比如，我们再一次中间件架构调整的过程中，涉及到十几个jar、五六个配置文件的增删改，因为不同的业务系统需要不同的配置文件参数定制、同时由于众多的B客户预算不同，有些应用全部在一台服务器上、另外一些数据库独立、还有一些外部HTTP和TCP接入独立，因为我们在测试和演示环境升级了很多次了，所以当发给运维进行升级时，升级了3套环境都是有各种问题，每次都要额外花费很多开发、测试的时间。最后，笔者为此专门又花了半天时间，根据现在各种环境的典型情况确定A\B\C各自部署模式下时执行哪几个脚本的方式确保升级的时候，不管部署模式怎么样都只要执行sh脚本即可，不需要人工重复更改配置文件，对于存在不一致的，启动时提示完善的友好信息，接下去升级的时候就省事了很多，基本上运维没怎么在升级的时候打电话给测试和开发，只是升级完了业务基本都验证过了之后，让开发同学检查下有没有其他异常。
除了上面的主动性事情外，在不少的时候，尤其是分布式系统中，通常多个组需要进行相互之间的RPC调用，这就势必涉及到相关接口的约定，有些开发人员在设计接口的时候甚至都没有花该花的1/2精力去思考接口本身能不能自圆其说，纯属为了应付而应付，设计的接口和编写的程序真的没法直视，一点异常都保护不了，有些领导甚至要求出错的时候一刀切的返回"系统繁忙, 请稍后重试"，然后在log里面也把异常堆栈给吃了，美名曰良好的客户体验。这些做法在当初看起来好像是节省了很多事情，但是却留下了大量的技术债务，从当事人来看或许到后面已经事不关己，但是如果你是个较长时间内在任的leader，切记挖的坑最后都是要填上的，而且花的都是你自己的成本。很多看起来是运维的事情，最后不管运维是强势、弱势、水平高的、低的，最后只要异常都是来找开发，虽然有些能忽悠过去的忽悠过去了，但毕竟忽悠也是花费了很多的人力成本。还有很多我去参与优化的系统中，各种日志级别乱的一塌糊涂，要么都是debug、要么都是info，该是error的地方用debug、该是warning的地方用error，等到某一天系统在盘中异常的时候，为了找到排查问题所要的信息，几十个log文件里面来回切换上下文进行拼凑，好不容易花费很长时间把当事问题解决了，还是不吸取经验，又或者临时抱佛脚的方式进行扫一遍，等到下一次发生的时候仍然是重头开始。很多的时候，由于开发人员的经验水平、leader的不重视、各人员存在着各种侥幸心理导致了心里总想着，问题应该不至于发生在我身上。所以，不管是自己亲自做的事、还是团队成员的任务，尽量第一次就把事情做完善，终归来说成本是最低的，作为leader或者manager，这是你的职责。
9、解决短期目标，预留好已知未来目标的实现计划。
原文：http://www.cnblogs.com/zhjh256/p/6486564.html