在外企工作十年，从程序员做到一线开发经理，再后来转到公司美国总部，又做回程序员。工作角色的变化促使自己思考，分别站在程序员和开发经理的角度看，怎样的程序员是出色的程序员，怎样的开发经理是好经理。经历团队发展过程里种种好的、坏的变迁，再加上看到、听到其他团队的经验教训，就越来越有感触，掌握全栈技术对一线开发经理很重要。
开发经理的职责是确保软件产品按时保质发布。流程也为这个目标服务， 但流程本身的作用很有限。软件开发流程理论经历瀑布式，迭代式（RUP, 又称统一软件过程）以及现在的敏捷开发（敏捷在现实中几乎就是scrum），理论越来越成熟完善，但落地执行又不简单。 大量文章都在分析为什么敏捷流程在很多开发团队不起作用。比如最近看到 为什么敏捷开发在亚洲实行不了 里说， “敏捷开发需要大家当面直言问题所在，而这有悖于亚洲文化，因为亚洲人特别注意对别人表示尊重、给别人留面子，这一点与西方文化特别不同，而西方正是敏捷思想的发源地。” 从自己的亲身经历看，这纯属扯淡。讲到留面子，和稀泥，打太极拳，老美一点儿也不输给中国人。流程只是个工具，能否因地制宜执行得好，开发经理起到决定性作用。没有普适的流程，针对一个特定的团队，只有合适的流程。 全栈型的经理比较容易领导团队做正确的事情并做得够快。 能做到这一点，是不是scrum都不重要。他不必在各个方面都是专家，但至少需要能预见技术上重要的风险才能及时采取措施处理。一些技术决定对项目成败有关键性的影响，比如技术选型，搭建软件应用的架构，包括分层, 模块化，secruity, transaction, exception, audit，自动化测试等等。开发经理不必把这些工作都承担了，但至少需要把关，保证这些核心的工作没有明显疏漏。因为最终为产品发布负责的还是开发经理自己，而不是某个犯了错的程序员。不全栈，把关自然就不全面。
开发经理的各项工作中，我认为最重要的就是面试招聘。招对了人，工作中即使遇到棘手的问题，技术好素质高的队员自己就解决了。团队不怕小但要精，队员必须能独当一面。不论前台后端，经理至少应该具备足够好的技术品味过滤掉不合格的应聘者。乔布斯有个观点，一旦招了庸才，两年后，就会轮到庸才做面试招聘，很可能再招进来的还是庸才。如果开发经理不全栈，面试就要靠运气了。反过来说，资历好而水平差的程序员，也可以靠运气进好公司的。
程序员为story估时间（story point）的时候，会不会虚报呢？如果认为scrum的打牌可以避免虚报的话，可以看看上面关于留面子的讨论。即使把story的分配放在scrum打牌之后，经常大家心里已经知道哪个人做哪个story, 比如feature enhancement的story自然是这个feature之前的owner来做。打牌的人很容易会“做好人”倾向于多估时间。（再说一次，这不是中国特色，是人性）心理学有个有趣的关于撒谎的讨论，撒谎的前提是1. 我知道 2.你不知道 3.我知道你不知道。如果经理在产品某项技术上是小白，就容易出现估时间虚报的问题——这样的事情我亲见过很多次了。全栈的经理自然不会被糊弄。
程序员经常会在一个技术问题上产生不同的意见，这很正常，技术上很多事情本来就要做取舍。这时候经常需要开发经理介入做决定。经理做合理的决定不但对项目重要，对队员的个人感受也重要。决定不能是随机的选A或选B, 需要有决定的依据。程序员往往都有点小骄傲，经理技术上捉襟见肘的时候，程序员就容易想，“你还不如我呢，凭什么做决定。”
开发经理需要做coding的工作么？我认为是需要的。 英语里有句谚语， He that would command must serve。至少也要做比较多code review的工作。评价队员工作效果是开发经理的重要职责之一。技术不全面的经理经常依靠听队员自我评价（吹牛），数代码行数等这种不靠谱的方式评价工作。错误地认同或不认同严重影响团队氛围。身先士卒的经理容易长期保持住团队良好的氛围。我没有能力定义什么样的氛围才算是好的，起码，我带团队时，成员互相之间心存善意。
澄清一下自己观点：经理一定要全栈或技术精湛才能带好团队么？不是，但是很多管理的难题在全栈的经理眼里都不是问题， 比如上面提到的评价队员工作。带不好团队就无法好好职业发展么? 不是， 我见过太多靠吹牛，人事等各种非技术技巧成功哄骗二线三线经理的了。管理的路越往上走，技术越不重要，而政治越重要。问题是，作为程序员或开发经理，你的目标是把项目做好还是获得上级认可？我觉得这是职业价值观最根本的分歧， 但， 不想讨论。