从IBM工程师到创业公司CEO，程序员经历教会了我如何领导一家公司

   <p style="text-align:center"><img alt="从IBM工程师到创业公司CEO，程序员经历教会了我如何领导一家公司" src="https://simg.open-open.com/show/fb306ce32dc17d0ff06b7165ee1f7a79.jpg" /></p>    <p>猎云网（微信号：ilieyun）</p>    <p>注：Neil Lustig，曾为 IBM 高级工程师，现为纽约 Sailthru 公司的首席执行官。</p>    <p>在 Neil Lustig 职业生涯早期，曾面临一个选择：继续在 IBM 的卫星办公室做公司最有前途的工程师；还是前往纽约分部，一个更大的平台，但是得从初级销售职务做起。Lustig 的老板跟他说，调去纽约会毁了他在公司和行业内的事业。但是，他的导师意见相反。导师告诉 Lustig，只有在充分接触了解技术和业务两个板块，才能够突破个人瓶颈——并且如果没有丰富的经历，他也将难以胜任领导职务。</p>    <p>于是，Lustig 去了纽约——在销售业大展拳脚。Lustig 花六个月时间就达到了个人年度指标，与花旗银行这类的大客户完成了几百万美元的交易。这些年来，Lustig 从初级销售最终称为 IBM 电商解决方案部门的负责人。之后，每加入一个团队，他就肩负起更多责任。</p>    <p>在本次的独家采访中，Lustig 分享了他的管理心得，以及如何向专业人士学习，成长为一个更加高效的管理者。他列出的每日工程实践，不仅帮助他战略指导了公司，也培养了他的“领导软实力”。</p>    <p><strong>适当分解问题，能够更好地前进</strong></p>    <p>产品，和团队、公司类似，都是解决复杂问题的系统。这是 Lustig 第一次从独立贡献者（指埋头干自己工作，不考虑大局的员工）转向管理者时领悟到的一个重要道理。为了解决新的挑战，他把复杂系统分解为更容易管理的不同组件，然后再处理解决。</p>    <p>当 Lustig 第一次在 Ariba 担任掌控全局的角色时，他从纽约的销售主管摇身变成了欧洲区金融、销售、市场、专业服务负责人。他回忆说：“我都不知道要做什么。要去领导一个由 10 个国家组成的团队，并且还说着不同的语言——简直疯了。借着我当工程师那会常用的软件开发方法，我想：在连续流中你不会重写一个新系统。你会尽可能得将问题分解，然后依次解决。担任 CEO 也是同样的道理。在那个案例中，我从消费满意度着手，因为产品的方向和我们的增长速度都取决于消费者对产品的理解。这样一来事情就好办了，我们可以集中精力，协调人手来一起解决这个问题。”</p>    <p><strong>通过电话，随机测试和传递信息</strong></p>    <p>在课堂上，随机发问可以让最优秀的学生紧张起来。换个角度，如果我们主动提供解决方案，并且通过电话这一端，那情况会如何呢？“我从 IBM 前 CEO Lou Gerstner 和他的管理团队学到很多东西。一个我至今仍在使用的战术，就是亲自打电话给公司了独立贡献者，”Lustig 说，“有一次，那会的 IBM 首席财务官给我打电话。那时我刚进 IBM 不久。他问我遇到什么难题，我说我正在努力搞定全球账户方案中的一个客户。然后他说，‘好的，交给我吧’——于是就挂了电话。”</p>    <p>高级管理层很容易与前端人员脱节，特别是在创业公司扩大规模的过程中。对 Lustig 来说，电话拜访这一习惯与软件开发中的随机测试有点类似。“这是软件测试中的一个常用方法，就是随机输入数据来测试程序。这个方法可以保证系统的完整性，并测试系统在‘外部环境’中是否稳定，”Lustig 说道，“领导者也十分有必要这么做，因为他们实在太容易与现实世界脱节。事实上，只与高层管理人员交流就好比仅在旧金山测试你的应用，这么做很容易局限你的视野。IBM 的高管经常和整个公司员工交流。身处前线的战士们有着不一样且重要的观点。”</p>    <p>在哪怕只有 IBM 十分之一规模的公司里，高层领导也应该每天进行随机电话拜访。当 Lustig 加入 Vendavo 后，他通过组建一个6-10 人的跨部门团队来推行这个方法，这样他就可以亲自了解到所有的 150 名员工。“这么做的目的是减少等级和摩擦感。这样，我会见员工的同时，就不会有同部门的人在场。并且，每个小组里的人都不会与自己团队的管理者相遇——这更有助于让他们感觉到自己是 Vendavo 的一份子，而不是仅仅作为工程团队或销售团队中的一员。”</p>    <p>“现在，作为一名 CEO，我不再认为严肃地坐下来交流可以解决所有问题，”Lustig 说，“有时候，小团队的随意交谈，不仅让我在他们面前显得更平易近人——不是董事会派来谈人员变动的代表——也让我作为一个先例，每个人都可以参考学习。”</p>    <p style="text-align:center"><img alt="从IBM工程师到创业公司CEO，程序员经历教会了我如何领导一家公司" src="https://simg.open-open.com/show/97f193a697ec0aa155e995b13fb2edee.jpg" /></p>    <p><strong>语言投资——学会变换交流方式</strong></p>    <p>工程师会讨论到，一个老练的开发人员到底需要掌握多少种编程语言？但毫无疑问的是，掌握一种以上的编程语言确实好处多多。对于交流方式，亦是如此。懂至少两种以上措辞表达，可以让你通过对比了解每种表达的优势和限制。即便你不能完全理解，你也会对其他表达有更强的理解能力。</p>    <p>Lustig 在从工程岗位转到 IBM 的销售部门时，很快就意识到了这一现象。“第一天，我的经理就交给我一项任务：让我证明，我对人的了解甚于软件，”Lustig 说，“作为一名工程师，这实在难到我了。他告诉我，我需要学会一种交流方式，可以让别人在和我聊完后说：‘这家伙不错，我愿意和他一起工作。’”</p>    <p>每一个 Lustig 曾经尝试过的职位——工程、销售、市场营销——都把他造就成为了一个更好的管理者和 CEO。“语言流利是我作为领导的最大优势。如果你可以根据人们的专长和他们感兴趣的点，改变你的语调、节奏和措辞，那么你就成功了。”</p>    <p>以 Lustig 向他的工程团队、销售团队以及客户团队介绍 Sailthru 的新搜索引擎解决方案功能为例：</p>    <ul>     <li>对工程师：“该功能旨在最小化索引信息所需的时间，从五小时减少到数秒钟。从产品角度来看，这是一个难以置信的提升。这是一个解决大难题的好机会，需要好好将其利用起来。我们将把这项功能作为我们的技术基础。接下来就是你们展现才华的时候了。”</li>     <li>对销售人员：“Elasticsearch 可以让客户以前所未有的方式管理市场营销活动。它可以颠覆行业现状。它不仅可以提高我们的客户满意度分数，可以帮助我们在市场上打败其他竞争对手。”</li>     <li>对客户团队：“这关乎消费者能力和满意度。消费者对 Elasticsearch 期待已久，希望尽快尝试他们许久以来渴望实施的战略。我们可以帮助他们最终实现这个愿望——并监测分享结果。”</li>    </ul>    <p>再有，交流不仅停留在语言表达层面，实际行动在有些团队中能更快地引起共鸣。比如，当 Lustig 在 Ariba 工作时，每年他们都会奖励最佳销售人员一年的保时捷租期。“把保时捷开出来，钥匙交给获胜者是非常直观的行动，”他说，“其余的销售人员会在心里想：‘下一个就是我了。’销售的竞争是激烈的，最直观的行动最有激励效果。但是相同的奖励却不一定对工程团队有效，金融团队更是不可能。不同的部门都应有相应的奖励。”</p>    <p><strong>公开企业战略路线图</strong></p>    <p>当大多数领导说要合作时，其实有个问题仍没有明确——团队要在哪方面合作。他们往往忘记提及，需要多少自主权才能让合作顺利进行。“如果合作是一个进程，控制基础比控制长期结果要更容易。比如，和很多公司类似，Sailthru 的团队定期开会——我们是每月一次——回顾我们的发展路线图，研究每个部门完成的目标业绩，”Lustig 说，“我们会为这些环节创造足够的空间。当我们谈到指标时，我们以对话形式体现，会问：‘是否按计划发展？是否需要调整？’用讨论的方法来取代作报告。”</p>    <p>以下是 Sailthru 每月会议上涵盖的内容：</p>    <ul>     <li>公司目标回顾，以及目前进展</li>     <li>新业务的完成情况</li>     <li>重要更新内容</li>     <li>专题介绍，比如内部满意度调查数据回顾等</li>     <li>大声说出个人为工作所做的贡献</li>     <li>自由发言，可以讨论或提出任意问题</li>    </ul>    <p>Sailthru 的每月路线图会议的实践已经获得成效。“在最近的满意度调查中，90% 的公司员工表示他们清楚自己的日常工作是如何为公司目标做贡献的。”Lustig 说。</p>    <p>最后，公司战略路线图有必要让其他人知道，而且还得让他们熟悉和了解，甚至更多。“我见过很多早期阶段的创业公司的 CEO 和创始人对此十分纠结。一人揽大权的行为，如果只是在 20 个人的小公司，那还好办，产品技术、用户都还在掌握之中。但是当你公司发展到 50 人时，这种专制就会成为公司发展的瓶颈，会放缓了整个公司的发展步伐，”Lustig 说，“当我加入 Vendavo 时，CEO 兼创始人说，我们三个人经验最丰富，应该参与到每一项交易中。但我不这么看。我们有 20 个销售人员。如果让每个人都参与到交易中，我们的年销售额就会达到 1500 万美元。所以，你得信任你的团队，然后向他们公开你的计划。”</p>    <p><strong>保持谦卑，不断学习</strong></p>    <p>这几十年来，Lustig 见过许多技术变革。这让他明白，去年的方法放到今年就不一定有用——更别说来年了。他说：“你去年做的事情很快就失去价值。这个世界上，没有最好，只有更好。”</p>    <p>以下几个方面是 Lustig 时时保持与时俱进的：</p>    <p>公司管理不能拖。就像工程师重审和完善他们的代码库一样，管理者也需要定期重新审视他们的管理。“IBM 的前高管 Jerry York 曾跟我说：‘公司就像中年男人，放任不管就会日益发福，’”Lustig 说，“管理中的惰性等同于代码中技术债务。公司——就好比产品——虽然仍在运作，但是真的有效吗？你应该问自己，如果重新再来，你会雇佣谁？如何建立团队？投资谁？你现有的团队是为去年的业务而建立。今年需要今年的团队。”</p>    <p>拓宽你的基准。作为工程师，Lustig 在公司和行业内总是寻求自己产品与其他同事的基准。Lustig 说，“我有尝试去有意识地标准化我的管理风格和决策。我目前在两家公司担任董事，要每月在两个不同的方向标准化关于“成功”的指标，这对我来说是个不小的挑战。”</p>    <p>分享信息，不如换位思考。Lustig 在工程、销售和市场营销领域的工作给予了他感同身受的能力，这一同情心帮助他很好地处理了各种领导难题。“因为各种原因，不是每个员工都可以像我这样在各个领域都有工作经验。但这并不妨碍你尝试复制这种体验，”Lustig 说，“我们的工程经理常常跟在我们的客户服务团队后面，而且很快高级工程师纷纷自愿来加入。他们开始研究各种对客户有意义的细枝末节，不过当然也是从技术角度出发。事实上，他们需要的仅仅是亲身感受和体验。”</p>    <p><strong>总结</strong></p>    <p>当软件工程师打算从代码跳槽到商务时，他们可以依靠自己的开发技能来指导自己前进。首先，公司好比软件系统，尽管复杂，可以用分解分析的方法将复杂事物一一分解为可以管理的模块单元。通过电话拜访员工，随机测试你系统的完整性与健康。这有助你校准对公司发展进度的了解。开发人员通常掌握至少一种动态编程语言，但是掌握的编程语言越多越好——领导亦如是，熟悉各部门领域的语言有助于管理公司。公开你的路线图，别欠下管理工作，拓宽基准。</p>    <p>“那个说我如果从工程领域跳到销售会终结我职业生涯的老板，其实他想的还不够远。从职业角度分析，他并没有说错——我的确没再回到软件开发领域，”Lustig 说，“但是他所忽视的是，我转型后可能对其他人的职业乃至公司带来的影响。作为工程师，我也许可以继续开发产品，和团队合作，实现指数级增长。但如果要我为其他工程师的早期职业生涯提点建议的话，我会说：真正做到‘全堆栈’，在一定时候踏出软件开发领域，勇敢转型！因为，你已经在软件领域建立了足够的基础了。”</p>    <p>来自: <a href="/misc/goto?guid=4959001286992369904" id="link_source2">www.lieyunwang.com</a></p>