Skip to content

搞英语 → 看世界

翻译英文优质信息和名人推特

Menu
  • 首页
  • 作者列表
  • 独立博客
  • 专业媒体
  • 名人推特
  • 邮件列表
  • 关于本站
Menu

科技界最重要的团队

Posted on 2026-01-16

stay-saasy-black-ogimage.jpeg

在B2B软件公司里,最重要的团队是工程和销售。就这么简单,没有例外,也无需多问。你要么在开发产品,要么在销售产品,其他一切都是次要的。

道理很简单:

  • 卓越的工程技术(快速、可靠)是无可替代的。优秀甚至卓越的设计可以借鉴或借用;而产品与市场的完美契合最终可能靠运气或反复试验来实现。
  • 优秀的工程设计能够比优秀的项目管理/设计更快地推动工程设计。
  • 更深层次地讲,最优秀的工程师往往在产品或设计方面也很出色。最优秀的销售主管往往拥有敏锐的市场洞察力。但如果没有工程团队,你最好的产品经理也毫无用处(除非他们自己开始写代码)。如果没有销售团队,你最好的市场营销人员也毫无用处(除非他们自己开始销售)。
  • 良好的销售业绩对于巩固产品市场契合度 (PMF) 至关重要,而建立品牌则是关键——向更优质的客户销售产品,让他们满意,从而打造你的品牌——品牌是商业中最强大的复利力量之一。
  • 销售执行是SaaS规模化发展的引擎。在某些情况下,产品驱动增长(PLG)无需真正的销售活动也能成功,但这毕竟是极少数情况。
  • 其他所有功能虽然都很重要,但并不会推动公司核心价值交付的实现。

这个道理如此显而易见,它完全可以用来检验你是否真正了解自己在SaaS领域所做的事情。如果你遇到一个连这两个团队为何能推动世界运转都无法凭直觉理解的人,那么你显然还没有真正涉足这个行业。

工程和销售的重要性似乎是一个微不足道的观察,但实际上它蕴含着许多非常重要的运营启示。

认清自己的位置

很多人都搞不清楚这一点,所以我直说了——如果你不在销售或工程部门,你就需要清楚自己的定位。作为一名产品经理,我会用我希望我的团队(理想情况下)如何与工程团队合作的方式来描述这一点:

  • 我们最终只能通过工程技术来创造价值。如果没有客户洞察、优秀的设计或产品需求文档(PRD),工程技术或许勉强能够完成任务。但如果没有可运行的代码,我们就无法创造任何价值。
  • 作为工程团队(以及在较小程度上销售团队)的专业合作伙伴,我们必须专注于能够最大限度提升这些团队交付成果的领域——无论是为工程团队找到实现客户价值的最有效途径,还是探索如何加快销售周期,亦或是精准定位如何让我们的产品在市场营销中掀起巨大波澜。我们需要推动这些团队取得更大的成就。
  • 与工程团队合作时,我们需要格外迅速,节省他们的时间至关重要。例如,如果我们可以用一周的人工项目管理时间来验证一个假设,而这需要工程团队花费一周的时间才能完成,那么我们很可能会接受这种权衡。
  • 如果我们的团队无法为项目创造价值(例如,项目经理确实不称职,而且我们核实了这一点),并且工程部门不希望他们参与,我们应该另找他人与他们合作,或者直接将项目经理撤出该项目。工程部门才是客户。
  • 我们的工作是为客户提供最有价值的代码,并实现盈利。我们与工程团队共享一部分资源(公司研发预算)。我们需要仔细审查资源使用是否合理,而不是钻空子,因为团队和工程团队之间存在直接的利益权衡。

但这并不意味着你应该对工程部(或销售部)言听计从。如果销售部或工程部能力不足,你需要处理这个问题。

但你需要假设,在其他条件相同的情况下,他们的当务之急——编写和发布代码、达成交易、续约客户——对于整个企业而言,都是至关重要的,甚至位列前茅。例如:

  • 如果销售团队正专注于完成季度业绩目标,那么此时就不是进行绩效考核的时候。
  • 如果工程团队正在处理生产事故,那么您的下一个 Figma 模型审核将会延迟,直到事故解决为止。
  • 如果我们只剩下最后的 20 万美元,除非我们急需项目经理,否则我们通常会把这笔钱花在下一位工程师身上。

销售与工程执行

如果你实际领导的是销售或工程部门,那么你肩负着很大的业绩压力。

随着公司发展壮大,你的工作也会随之演变,变得更加复杂,标准也更高。你也需要不断提升自己的工作能力。如果你身处人力资源团队,这或许只是纸上谈兵。但如果你是公司最重要的两个团队之一,而你的能力提升速度又不够快,那么你很可能要为扼杀一个原本蓬勃发展的业务负全部责任。

销售和工程的重要性导致了一个自相矛盾的局面:

  • 短期来看,这些团队的职位往往非常稳定。即使现状存在一些漏洞,也没人愿意去冒险。
  • 从长远来看,如果你表现不佳,这些团队的就业保障非常低。首席执行官、董事会和投资者会不断评估销售和工程团队的实力,如果情况真的偏离正轨,重组这些团队或许是解决之道。

由于销售和工程部门是组织的领头羊,所以根本不存在“足够好”这种说法。你永远都会被拿来和公司认为理论上能够组建的最佳团队比较。没有人会夜不能寐地琢磨如何才能拥有一个比自己强1.5倍的人力资源团队;但世界上每一位CEO都会竭尽全力去打造一个比自己强1.5倍的销售或工程团队。

因此,你必须不断自我提升,因为一般来说,没有人会去动他们的赚钱团队……至少在他们认为你不行之前不会,到那时你就会被替换掉。

建立销售和工程专业知识

如果你从事与销售或工程相关的领域,你应该认真考虑如何才能在这些关键领域积累更多经验。

很多情况下,销售和工程团队的优先级会高于你自己的优先级。季度最大的订单比你的市场营销演示文稿审核更重要;产品重构的启动比你的产品需求文档更重要。这很正常,实际上往往是企业健康发展的标志。因此,了解销售和工程团队的运作方式及其原因,将有助于你更好地完成工作。你无法逆流而上,所以你需要学会顺应潮流。

我发现领导者陷入困境的主要原因在于他们想当然地认为销售和工程比实际情况要简单得多。他们可能会说,自己不懂技术做项目经理没问题,因为我了解客户。或者,自己不擅长销售也能做市场营销,因为我知道如何拓展客户群体。然而,事实并非如此。你必须尽可能地了解销售和工程——否则,你就像一个看了几个小时体育中心节目却从未真正投过橄榄球的四分卫。

销售与工程风险

销售和工程团队是公司最重要的团队,这意味着销售和工程团队的失败会给公司带来最大的风险。如果你所在的公司这两个团队实力薄弱,你应该认真考虑离开。你几乎不可能力挽狂澜。

一旦你明白了这个道理,许多其他事实模式就会变得更有意义。

  • 科技公司CEO大多来自销售主管和产品经理,而这些人以前往往是工程师。真正了解如何打造产品具有巨大的价值。
  • 面向小型客户的PLG公司即使相对于企业客户而言经济效益较差,通常也能取得不错的成绩,因为它们规避了最大的风险之一(销售团队能力不足)。此外,无需组建庞大的销售团队,使得公司能够加大对工程技术的投入,这往往能带来巨大的优势——许多最成功的SaaS公司都采用了PLG模式。然而,PLG商业模式仅适用于某些特定行业。
  • Y Combinator,史上最伟大的早期投资机构,如果你的创始团队缺乏工程技术方面的专业知识,他们基本上不会投资。降低工程技术方面的风险就是这么重要。

原文: https://staysaasy.com/management/2026/01/15/the-most-important-teams-in-tech.html

本站文章系自动翻译,站长会周期检查,如果有不当内容,请点此留言,非常感谢。
  • Abhinav
  • Abigail Pain
  • Adam Fortuna
  • Alberto Gallego
  • Alex Wlchan
  • Alin Panaitiu
  • Anil Dash
  • Answer.AI
  • Arne Bahlo
  • Ben Carlson
  • Ben Kuhn
  • Bert Hubert
  • Big Technology
  • Bits about Money
  • Brandon Skerritt
  • Brian Krebs
  • ByteByteGo
  • Chip Huyen
  • Chips and Cheese
  • Christopher Butler
  • Colin Percival
  • Cool Infographics
  • Dan Sinker
  • David Walsh
  • Dmitry Dolzhenko
  • Dustin Curtis
  • eighty twenty
  • Elad Gil
  • Ellie Huxtable
  • Ethan Dalool
  • Ethan Marcotte
  • Exponential View
  • FAIL Blog
  • Founder Weekly
  • Geoffrey Huntley
  • Geoffrey Litt
  • Greg Mankiw
  • HeardThat Blog
  • Henrique Dias
  • Herman Martinus
  • Hypercritical
  • IEEE Spectrum
  • Investment Talk
  • Jaz
  • Jeff Geerling
  • Jonas Hietala
  • Josh Comeau
  • Lenny Rachitsky
  • Li Haoyi
  • Liz Danzico
  • Lou Plummer
  • Luke Wroblewski
  • Maggie Appleton
  • Matt Baer
  • Matt Stoller
  • Matthias Endler
  • Mert Bulan
  • Mind Matters
  • Mostly metrics
  • Naval Ravikant
  • News Letter
  • NextDraft
  • Non_Interactive
  • Not Boring
  • One Useful Thing
  • Phil Eaton
  • PostHog
  • Product Market Fit
  • Readwise
  • ReedyBear
  • Robert Heaton
  • Rohit Patel
  • Ruben Schade
  • Sage Economics
  • Sam Altman
  • Sam Rose
  • selfh.st
  • Shtetl-Optimized
  • Simon schreibt
  • Slashdot
  • Slava Akhmechet
  • Small Good Things
  • Steph Ango
  • Stephen Wolfram
  • Steve Blank
  • Taylor Troesh
  • Telegram Blog
  • The Macro Compass
  • The Pomp Letter
  • thesephist
  • Thinking Deep & Wide
  • Tim Kellogg
  • Understanding AI
  • Wes Kao
  • 英文媒体
  • 英文推特
  • 英文独立博客
©2026 搞英语 → 看世界 | Design: Newspaperly WordPress Theme