牛叉的调试者会坚持不懈地去追求导致 bug 的原因。当我们在应用逻辑层中查找错误时做到这点是很容易的，但是我们都知道 bug 可以藏在很深层的地方，特别是在那些具有许多独立部件且处理延时网络的复杂系统中 bug 可能会藏地更深。一个差劲调试者的标志是，当他们为了查找错误而在一段并发代码中添加日志语句后发现错误无法重现了，就会假设问题因此被解决了。
这是一种偷懒的习惯，但是却很常见。有时，有一些问题看起来很难查明，很多人都没有耐心去为了只发生一次的错误而去深挖他们自己或者别人的代码、日志文件、系统设置，以及其他可以了解某些底层的东西。也不能去责怪他们。被动地去调试只发生一次的问题，有时只是浪费时间，但是这却展示了一个对未知不满的心态，特别是当半夜三更时它出现而你却不知道为什么的时候。
那么作为主管应该怎么做呢?
管理团队是一系列复杂的过程，是黑盒与其他复杂的黑盒之间的交互。这些黑盒有可观察地输入和输出，但是当输出无法按预期输出时，想要知道原因的话需要尝试着打开黑盒，去看看它的内部到底是怎么了。也许有时你是看不到源代码的，或者不了解源代码所用的语言，或者日志文件是不可读的，又或者团队的黑盒子会抵抗外部力量。
团队也具有另一个著名盒子的特性，即盒子里必定发生两个结果之一，而外部观测者只有打开盒子才能知道里面结果的“薛定谔的猫”原理。这个实验的重点是说明观察变化结果的行为，或者观察变化导致一种结果的发生。不融入到团队、不参加他们的会议，不观察他们的站立会议的话，你是不能了解一个团队的，也无法改变团队的行为。你的存在改变着团队的行为，也许你能从中发现正在找寻的隐藏问题，同样地你可能发现至少在一段时间内一个日志语句导致的并发问题神奇地被解决了。
调试系统 vs 调试团队
去调试一个系统，可能你必须想好合理的假设解释为什么系统会进入失败的状态，如果你可以将问题重现的更好，这样你就可以解决 bug (或者至少可以避免它将来再次发生)。去调试一个团队，你也应当尝试着想出团队为什么存在问题的假设。为了不让自己在复杂问题中反而起到捣乱作用你应当尽最大可能这样做。在团队问题中，你还有一项额外的挑战，某些团队问题并不表现为一次失败，而更像是一个性能问题。整个系统是可以运转的，但效率越来越低。机器是正常的，除了时不时会崩溃一下。人们看上去都很高兴，但系统内耗非常严重。
让我们看个例子。我们有一个看起来死气沉沉的团队。你已经从他们的商务合作伙伴还有产品经理那里听到了这样的抱怨，你也认为和你的其他团队相比，这个团队确实看起来缺少了同样的热情。那我们该怎么做呢。
像调试一个严重的系统问题一样去调试它。当我调试一个系统问题时，首先我会看看日志文件，还有其他的系统状态和事故时间的记录。如果一个团队不能按期完成工作，看看记录。看看这个团队的聊天组都聊了什么，还有他们的电子邮件，看看他们的计划，看看代码库的代码评审和签入的代码。我们能看到什么?这些是不是占用了他们太多时间?是不是很多人都不够活跃了?是不是他们在代码评审中的注释里有对代码风格的不同意见?计划是不是被填写地模糊不清，太多了，或者太少了?这个团队是不是看起来沟通方式很乐观，聊天时是否也分享一些有趣的事情，或者他们只讨论业务?看看他们的工作日历。团队是否在一周内被会议占用了太多时间?他们的经理是否一对一谈话了?这些是都是小事，但是它们却能指出一些问题的所在。
也许上面说的那些看起来都没啥问题，但是团队还是没有按照你认为他们能做到的那样把工作完成。你知道这里有人才，团队很友好，他们没有为支持生产线而感到压力过大。发生了什么?也许现在是时候开始做一些调查了。参与他们的会议。你觉得他们让你无聊么?这个团队太无聊了么?大部分时间是谁在说话?在整个团队都参与的会议中，会议的大部分时间是否是大家听领导或者产品主管说话了?无聊的会议是一个征兆。也许意味着由组织者做出的计划很低效。也许会议中信息量覆盖太多。也许意味着团队成员无法帮助团队找到方向，或者为将来目标选择现在做什么。如果不是上级领导存在问题的话，那么可以肯定的是无聊的会议是浪费时间的。
问问团队的目标是什么，他们能说出来么?他们能理解这些目标存在的理由么?如果他们无法理解他们工作的目标，那么团队领导(经理，技术领导，产品经理)在使团队成员认识到他们的工作目的这方面，没有做好本职工作。几乎所有的工作动力都是源自人们能够理解和了解他们工作的目的。他们为了谁在搭建这些系统，对客户、商务或者团队的潜在影响是什么样的。他们是否参与了这些目标的决策，项目是否是为了完成这个目标而进行的?如果不是，那为什么不是呢?当你看到一个团队花费他们全部的时间在开发上，而忽视了应当去关注的产品或者商务部分时，可能是因为缺少了积极性去与他们交涉。
最后你也许该会看看团队的实际动态。大家是否彼此喜欢?他们是否很友好?在项目中是否能够很好地协作或者独立完成各自的工作?休息室中闲聊或者发邮件时是否会开玩笑?他们和其他的相邻部门和他们的产品经理是否有不错的工作关系?在一些专门讨论工作的群组中组员之间是否会有一些私交。团队中有一部分人从来不和其他人交流并且总是在做着独立的项目，这样并不能叫做团队协作。这种情况下，如果团队还能工作的很好的话，那也没什么问题。但是假设不是的话，那就是你的错了。
有时经理的经理选择将这样的问题当作是团队经理需要解决的问题。你需要去衡量这个经理对于他们团队的作用，毕竟当事情发展地不顺利时，这应该是他们的责任去解决问题。这是真的，正如有时候我也可能会加入并帮忙调试复杂系统的问题，尽管我很少写代码，这没什么，加入进去帮助团队调试问题，特别当经理也无法解决问题时。这也许会成为一个机会去教导这个经理并帮助他们成长。这样也会暴露更多的组织基础问题，例如缺少高级商务领导的话就算是再好的经理也不能找到或者独立解决问题。
当组织出现问题时，找寻它发生的原因是对你来说是很好的一种锻炼和经验教训。如果经常这样做，我们在调试方面会更有长进，可以了解哪个部分更容易出现问题，哪个指示器为找到问题提供了最大的价值。通过推进我们自己和我们领导的团队去更深入地查找底层问题，找到问题出现的原因，可以让我们变得更好，也会帮我们在以后能够越来越快地解决问题。如果不知道为什么，我们靠着魅力和幸运去看待我们的管理生涯，我们根据一个人的魅力和幸运去雇佣人和解雇人，当我们从错误中学到东西时，就会发现我们其实存在着一个巨大的盲区。
