几乎每种行业都有基层主管(或基层管理人员)，而软件行业的基层主管一般是项目经理、技术经理、开发经理、组长等。其职责是资源协调、风险预估、项目管控、团队建设，说白一点大多数的企业现状就是项目负责人带领团队攻下一个又一个项目的过程。很多公司以项目成败作为项目负责人考核的唯一标准，因为项目规模、成本、客户满意度等容易量化，并且是直接跟公司的利润有很大关系;而相反团队建设却难以衡量，如何衡量一个普通技工晋升成高级技工到底是基层主管的培养还是原员工本身就具备高级技工的技能。因此，难免出现以项目额度论英雄的局面，这样往往造成一将功成万骨枯的悲壮场面，并不利于团队的发展。卡耐基曾经说过，带走我的员工，把我的工厂留下，不久后工厂就会长满杂草;拿走我的工厂，把我的员工留下，不久后我们还会有个更好的工厂。
我的观点是，从短期目标来看，项目成功是解决温饱问题的指标，如果温饱问题未解决，还如何谈吃得好，如团队经常疯狂加班赶项目就是温饱尚未解决的一种表现;从长远角度来看，团队建设是迈向“吃得好”的改进过程，或着说是一种手段。
一只狮子带领一群绵羊的团队会战胜由一只绵羊带领一群狮子的团队
如果你是一只绵羊，配备一群狮子般的团队也是枉然。说到这里，我曾经从一个电视节目看到十多只年轻狮子攻击一头河马，由于缺乏领队，结果导致河马成功逃过一劫并且一头狮子牺牲这样难以置信的场面。后来，同样这群狮子在一只经验丰富的狮子带领下，战胜比河马更强壮更凶猛的对手。基层主管往往来自基层的优秀员工，在成功转型之前必须先把自己的宝剑磨利。
在NBA赛场上，5个科比组成的球队可能会输给联盟任何一只球队
一个项目一般需要若干个成员组成团队——售前、需求、设计、开发、测试、部署等。而现实情况往往是，要么项目急、要么人员未到位，或者两种情况都有，那么开发人员由于在公司所占比例大，可能会兼做需求和测试。这样造成的后果是，需求把握不明确，测试不到位导致软件质量差，客户不断投诉。正如下象棋一样，必须了解各种棋子的角色和作用，以及它们应该摆放的位置。否则拿车当兵使，后果可想而知。
当项目出现危机，基层主管的第一反应是?
如果第一反应是“这个问题是哪个兔崽子造成的”，意味着该主管的思维是先追究责任。有一次，需要向客户演示现有的开发成果，由于各种原因导致离演示的前一天发现很多功能都未完善，如果照这样演示给客户看的话简直是演猴戏。当时，基层主管唯有向上汇报，而高级主管的第一反应是，评估完善这些功能需要多少时间?现在增加资源是否能够缩短工期?需要哪些资源才能完成?并且在该项目所有成员目前表示，他不想追究任何一个人的错误，首要任务是先分析如何能够解决问题。事后，他再向基层主管了解如何改进才能避免同类问题的发生，通过这种方式相当于给基层主管上了一次深刻的管理课程。
聆听团队的意见
善于聆听是良好沟通的铺垫。如果你的团队成员在他岗位上老老实实的干了几个月，突然他有一天告诉你(或者从其他成员了解到)，他觉得自己的工作没意思。这其实不完全是分工的问题，很大程度上是沟通出现问题。试问，他是觉得没意思，而不是不合适，即他胜任这份工作，可惜觉得缺少了什么，可能是缺少锻炼机会、想换个项目等等。主动去了解团队成员的意向，因为把他们放在感兴趣的岗位会发挥他们潜在的能力。当然并不是每个人都能找到适合自己的岗位，恰当的给予激励会鼓舞士气，保持工作的热情。某些基层主管把开空头支票当激励，结果失信于团队。
最大限度地发挥团队的力量是每个基层主管的职责
最大限度地发挥团队的力量的前提是得深入了解每个团队成员的技能和喜好。特别是软件工程师，很多不善于语言表达也不会表现自己，更多的需要基层主管去观察。如A君喜欢钻研技术但是缺乏经验，如果有技术难度较高地先分配给他，帮他分析解决方案，更重要的是给他信心。
不要说我以为
基层主管不同于普通员工，一旦犯错就勇于承担。如果说“我以为…，想不到会…，结果造成…”，是一种借口，是不成熟的表现。
让团队主动反馈
基层主管要了解他管理的不是一群机器，是一支优秀的队伍。如果把团队训练成机器，最终会累死基层主管。例如，你需要挨个挨个的去问他们工作进展的怎么样，或者索性让他们写日报周报来反馈。这样得到的结果就是一切看起来很美好，而实际情况就可能隐藏一个个定时炸弹。如果并非团队成员的主动反馈，“被反馈”往往是走走形式，例如某某说“A功能完成了，B功能差不多了”。到了第二天、第三天还是“B功能差不多了“。主动反馈是简要说说工作的问题和解决方法，如某某说“A功能解决方案是…，B功能遇到…问题，C功能预计明天可完成”，并且更重要的是，不是等到你去问他才反馈。