--- title: "Forward Deployed Engineers Are Just Professional Services" episode: 113 podcast: "The LeanScale Podcast" publisher: "LeanScale" guest: "Aimee Menne" guest_title: "Chief Revenue Officer" date_published: 2026-09-08 date_modified: 2026-09-14 duration: 00:50:51 word_count: 8290 topics: ["gtm-strategy", "pricing-packaging", "enterprise-sales", "revenue-operations", "sales-leadership"] canonical_url: https://www.leanscale.team/knowledge/podcast/aimee-menne-sourcegraph-fde-professional-services/ source: "LeanScale Knowledge Hub — https://www.leanscale.team/knowledge" license: "Free to quote and cite with attribution to The LeanScale Podcast." --- # Forward Deployed Engineers Are Just Professional Services _Aimee Menne on the two-question FDE test, knowing when customers are pulling you into services, the maturity curve from first hire to P&L, and how Sourcegraph packages implementation, hours and outcomes_ **Episode 113 · The LeanScale Podcast** Aimee Menne, Chief Revenue Officer (Sourcegraph) · Hosted by Anthony Enrico Published September 8, 2026 · Updated September 14, 2026 · 00:50:51 Canonical: https://www.leanscale.team/knowledge/podcast/aimee-menne-sourcegraph-fde-professional-services/ **Topics:** GTM Strategy · Pricing & Packaging · Enterprise & Public-Sector Sales · Revenue Operations · Sales Leadership ## Executive summary Aimee Menne is Chief Revenue Officer at Sourcegraph, the code intelligence platform very large engineering organizations use to make sense of decades of code. Her route there ran through code and customer delivery, not a quota: she studied computer science and started as a developer at IBM on a US Navy project that bored her. She then moved into technical consulting when IBM bought the asset management software Maximo, and later worked in solution architecture and professional services at the travel-tech company Switchfly. At Segment she joined the solution architecture team at roughly $50M in revenue, turned it into a professional services organization and stayed through the Twilio acquisition. She joined Sourcegraph five and a half years ago on a six-person technical success team, stood up professional services there, and now runs all of revenue. Her headline argument is that the forward deployed engineer craze is, broadly, professional services with lipstick on. Sourcegraph's own co-founders were forward deployed engineers at Palantir, which gives her a reference point: the Palantir model means going into a customer's environment and building whatever it needs, fully bespoke. Much of what gets called FDE today is closer to solution architecture, making your own product work without custom development. Her test asks whether the work is a paid, billable engagement and whether the customer is effectively renting an engineer for work that may have nothing to do with a product. If the goal is to deploy, embed, extend or make your own technology stick, she calls it professional services. For software companies deciding when to build services, the clearest signal is customer pull. Before Sourcegraph had a cloud offering every customer self-hosted, and installs could take six months. Enterprise buyers also come in expecting paid 24/7 support, managed upgrades, and vendors who can work through a shipped laptop or VPN access. Sourcegraph debated fixing deployment in the product and concluded that no amount of product work would cover every environment. It chose to back its claim that it works in any customer environment with a dedicated team, citing data that customers on its implementation services retain and grow at a higher clip. The build sequence is a maturity curve: hire people who can learn the work, extract a repeatable playbook, package it with deliverables, timelines and a price, and only then run it as a P&L with utilization targets and margins. Sourcegraph sells three flavors of services. The first is a mandatory implementation attach for self-hosted customers, priced low to avoid friction: $10K base or $25K advanced. The second is resident architect buckets of hours, netted to a weekly burn-down. The third is FDE-style engagements tied to delivered outcomes, the model Amp, the coding agent business Sourcegraph split off, was selling. Pricing is checked against an engineer's fully loaded cost and concurrent engagements. Profit center or adoption lever? She has seen both work, depending on company DNA and market, though bolting services on purely as a revenue stream is culturally hard. She warns against fully outsourcing delivery. The product feedback loop does not survive, managing partners carries real overhead, and customers blame the software rather than the third party. Anthony raises a gap RevOps rarely addresses, supporting professional services. At Sourcegraph, hours are tracked in Salesforce extensions, finance has helped with analysis, and the services leader carries a services revenue target in his variable comp. Anthony closes on the wider shift: as AI shrinks product moats, software companies look more like services companies, a competency Sourcegraph now frames as adoption-led delivery. ## Key takeaways 1. **Most "forward deployed engineering" is professional services with a new name** — Aimee's view is that the FDE craze is broadly professional services with lipstick on. The original Palantir model is bespoke: go into the customer's environment and build whatever they need. Much of what is marketed as FDE now is closer to solution architecture, which means making the vendor's own product work with scripts and API extensions but no custom development. _Why it matters:_ Before hiring or pitching an FDE function, be clear which job you are actually doing. The label does not change the economics, the skills required or how the work should be packaged. _For:_ Revenue Executives, Founders, Customer Success 2. **Two questions separate a true FDE from a rebrand** — Aimee takes Palantir's definition as the standard and asks two things. Is it a paid engagement with a billable metric? And is the customer effectively hiring an engineer for rent, for work that may or may not involve a product? Where the work is about using, embedding, extending or making your own technology stick, she calls it professional services. _Why it matters:_ The dividing line is whose agenda the engineer serves. Work that exists to make your product succeed is services, whatever the title says. _For:_ Revenue Executives, Founders 3. **Customer pull is the clearest signal to stand up services** — At both Segment and Sourcegraph, customers were raising their hands for help. Segment customers struggled to integrate the product into websites and mobile apps. Sourcegraph's self-hosted installs could take six months before it had a cloud offering. Patterns of customers asking for help are, in Aimee's words, the simplest flag that a dedicated function may be warranted. _Why it matters:_ Building services because customers demand them is much easier to integrate culturally than inventing packages because services look like a lucrative revenue stream. _For:_ Founders, Revenue Executives, Customer Success 4. **Enterprise ICPs pull you toward services whether you plan for it or not** — The largest engineering organizations get the most value from Sourcegraph, and they are also used to vendors that provide professional services. They expect to be able to buy 24/7 support, hand off maintenance and upgrades, and give a vendor engineer a shipped laptop or VPN access. _Why it matters:_ Who your ICP is and where you play shapes the services you will end up offering. Selling into large enterprises means planning for those expectations. _For:_ Revenue Executives, Sales Leaders, Founders 5. **If "works anywhere" is your differentiation, product work alone won't deliver it** — Sourcegraph held deliberate debates about solving deployment in the product versus hiring a team to centralize the expertise. It concluded that no amount of product work could cover every environment, network configuration and tech stack. _Why it matters:_ Aimee's rule is that you should usually start by asking whether the product can solve it. But if a claim is core to your value prop, you have to be willing to do what it takes to stand behind it. _For:_ Founders, Revenue Executives 6. **Services attached to implementation correlate with retention and growth** — Aimee cites clear data at Sourcegraph that customers who use its implementation services and maintain and update their instance regularly retain and grow at a higher clip than those who don't. _Why it matters:_ Beyond the revenue, services are a strategic way to get closer to customers and more embedded in their environments, and the retention data is the argument for it. _For:_ Customer Success, Revenue Executives 7. **Earn the right to charge: first hire, playbook, packaging, then P&L** — The maturity curve starts with committing to the capability and hiring people who can learn how to do it. Next comes a playbook that makes delivery repeatable within a known timeframe. Packaging comes after that, with deliverables, timelines and outcomes. Running services as a P&L, with utilization targets and margins, is the third or fourth step. _Why it matters:_ Packaging and margin discipline are downstream of competency. Trying to price and staff a P&L before you can deliver consistently gets the order backwards. _For:_ Revenue Executives, Customer Success, Founders 8. **Make the critical service a mandatory attach, and price it low** — Self-hosted Sourcegraph customers must work with the implementation team because it leads to better outcomes and faster time to value. The package is priced at a deliberately low point, $10K base or $25K advanced depending largely on whether the customer runs one instance or several, so it adds no friction to the deal. _Why it matters:_ When a service protects the outcome, requiring it matters more than earning margin on it. _For:_ Sales Leaders, Revenue Executives, Customer Success 9. **Match the package to the work: fixed fee, bucket of hours, or outcome** — Sourcegraph's fixed-fee implementation covers install, deployment, monthly updates and quarterly maintenance. Its resident architect package sells a yearly bucket of hours for highly customized work like onsite training, netted out to a weekly burn-down. FDE-style engagements, which Amp sold, charge an agreed amount for engineers who deliver defined outcomes such as projects, migrations and activated workflows. _Why it matters:_ Segment ran similar fixed-fee and hours models. The packaging choice follows how standardized the work is. _For:_ Revenue Executives, Sales Leaders, Customer Success 10. **Pressure-test pricing against fully loaded cost and concurrency** — Alongside market feedback, Aimee checks prices against the fully loaded cost of an engineer and how many engagements that engineer can run at once. From there she works out the price point needed to break even and what it would take to reach a goal such as $1M in services revenue by year end. _Why it matters:_ Customers will correct you if the value doesn't match the sticker price, and the cost math tells you whether the package can work for you at all. _For:_ Revenue Executives, Customer Success, RevOps Leaders 11. **Profit center or adoption lever depends on DNA and market** — Aimee has seen both models work. In large enterprises with an extensible, complicated but powerful product, services can become a growth lever. Treating services as a square peg of revenue forced into a round hole is culturally difficult and takes much more to make work. _Why it matters:_ The strategic posture should follow where you sell and why customers need services, not the appeal of an extra revenue line. _For:_ Revenue Executives, Founders 12. **Fully outsourcing delivery trades a dilution worry for bigger risks** — Aimee has not seen the product feedback loop done well with purely outsourced agencies. Partner delivery also carries overhead: someone has to manage relationships, enable partners as the product changes and police quality, because it is your brand they carry. Anthony adds that a partner implementing your technology poorly is probably more damaging than services revenue diluting your multiple. _Why it matters:_ Partners work for regional coverage, as Segment used them. Complex or strategic logos should keep internal teams attached, because customers blame the software, not the third party. _For:_ Revenue Executives, Founders, Customer Success 13. **RevOps is largely missing from professional services** — Anthony calls it a big miss that few RevOps teams offer to support services. At Sourcegraph the PS leader runs the function like his own business, hour buckets are tracked through Salesforce extensions in the system of record, finance has helped with analysis, and RevOps owns tooling and reporting. _Why it matters:_ Once most new and existing customers buy services, that revenue stream belongs in forecasting and annual planning, and RevOps is the natural owner of that analysis. _For:_ RevOps Leaders, Revenue Executives 14. **As product moats shrink, delivery becomes the differentiator** — Anthony argues that with AI shrinking product moats, competitive advantage is moving to value-added services and software companies are starting to look like services companies. Aimee says Sourcegraph is building it into its Command of the Message work as adoption-led delivery, backed by years of playbooks. _Why it matters:_ An industry that never planned to run services will have to learn utilization, packaging and P&L management quickly. The companies that can deliver adoption consistently can sell it as a differentiator. _For:_ Revenue Executives, Founders, Sales Leaders ## Frameworks ### The Two-Question FDE Test (13:11) **Definition:** Aimee's way of separating a true forward deployed engineer, as Palantir defined the role, from rebranded professional services. First, is it a paid engagement with a billable metric? Second, is the customer effectively renting an engineer for work that may or may not involve a product? Aimee states it loosely rather than as a strict checklist. Her decisive line is that work aimed at using, embedding, extending or making your own technology stick is professional services, not forward deployed engineering. ### Palantir Model vs. Solution Architecture (10:56) **Definition:** Two versions of what gets called forward deployed work. The Palantir model goes into the customer's environment and builds whatever the customer needs, fully bespoke. Solution architecture helps a customer use the vendor's software largely out of the box, perhaps with scripts or API extensions, without custom development. Aimee did the bespoke version as a solution architect at Switchfly. Sourcegraph's field engineering team does the solution architecture version, and she sees OpenAI and Anthropic doing similar scope. ### Customer Pull, Not Revenue Push (15:04) **Definition:** Stand up professional services where customers are consistently asking for help. Avoid starting from the premise that services are a lucrative revenue stream to be packaged and sold. Both approaches can work, but Aimee finds customer-driven services far easier to identify, build and integrate culturally. At Segment and Sourcegraph, implementation struggles showed up as a pattern of customers raising their hands. ### The Services Maturity Curve (22:22) **Definition:** The order for building professional services. Commit to the capability and hire people who can learn to do it. Build a repeatable playbook. Package it with deliverables, timelines, outcomes and a price. Only then run it as a P&L with utilization targets and margins. Aimee puts P&L management as the third or fourth step, and expects to start at a loss while learning before working toward break-even. Her summary is to learn to do it well and consistently first, then earn the right to charge for it. ### Three Flavors of Services Packaging (27:08) **Definition:** Sourcegraph's three packaging models. A fixed-fee package, such as the mandatory implementation attach at $10K base or $25K advanced. A bucket of hours burned down over the contract, used for the resident architect package. An FDE-style engagement priced against delivered outcomes. The fixed fee covers installation, deployment, monthly updates and quarterly maintenance. Hour buckets cover highly customized work like onsite training and are netted to a weekly breakdown. Outcome engagements, which Amp sold, cover projects, migrations and workflow activation. ### The Fully Loaded Cost Check (32:44) **Definition:** A way to validate services pricing. Take the fully loaded cost of an engineer and how many engagements that engineer can run at once. Work out the price point needed to break even, then what it would take to hit a services revenue goal. Aimee treats it as one dimension of pricing alongside market feedback. Customers will correct you if the value doesn't align to the sticker price, and the cost math shows whether the package works for you. ### In-House Competency, Partners for Reach (36:25) **Definition:** Keep at least part of delivery in-house to preserve the feedback loop into the product and the customer relationship. Use partners for coverage, such as regional support, while keeping internal teams on complex or strategic accounts. Aimee used multiple regional vendors at Segment for a consistent global experience, but attached internal teams to strategic logos. She warns that outsourcing carries overhead in partner management, enablement and quality, because the partner carries your brand. ### Adoption-Led Delivery (48:51) **Definition:** Sourcegraph's framing for its delivery competency as a core differentiator: years of playbooks that let it deliver adoption consistently and repeatedly. The framing comes out of the Command of the Message work Sourcegraph did through Q2 to orient around value-based delivery. ## Quotes _Speakers inferred from an undiarized transcript — verify before attributing._ > "I felt like I got all of this exposure, but it felt like a mile wide an inch deep." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (04:12) > "The original co-founders of Sourcegraph, they themselves were forward deployed engineers at Palantir earlier in their careers." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (10:29) > "I actually do believe that it's professional services broadly with lipstick on, but you're seeing it evolve in different ways." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (10:45) > "The Palantir model I would say is like, I'm going into the environment, I'm building them whatever they want. It's completely custom, bespoke to what they need." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (10:56) > "It's kind of like engineer for rent." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (13:43) > "If you're using your tech, if you're trying to embed your tech, if you're trying to make your tech more sticky, if you're trying to make your tech work, if you're trying to extend it, all of those things I would argue are professional services, not forward deployed engineering." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (14:02) > "If you wanna play in the enterprise, they're going to have certain expectations." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (17:53) > "There's no amount of product work that could solve that problem 100% of the way." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (19:27) > "Customers who partner with us, who have our implementation services, who maintain their instance and update regularly, et cetera, retain and grow at a higher clip than those that don't." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (20:41) > "You don't get there from the beginning. You get there from deciding that you're going to step into this." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (24:13) > "You start to have these early conversations and the market is going to adjust you pretty quickly on what they think is reasonable." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (25:18) > "It's priced at a really, really low reasonable point to avoid any friction." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (25:46) > "And then you're essentially buying a bucket of hours for that year that you burn down." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (29:04) > "That FDE type package is more tied to like an outcome that's being delivered." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (30:25) > "What's the fully loaded cost of one of the engineers on this team? Okay, how many of these can they do at once?" > > — Aimee Menne, The LeanScale Podcast Ep. 113 (33:17) > "That feedback loop, I have not seen that done well when you're strictly using outsourced agencies." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (37:03) > "Probably what's more damaging is a partner not implementing your technology very well. And you're not investing enough to manage them." > > — Anthony Enrico, The LeanScale Podcast Ep. 113 (39:05) > "They're not thinking about that third party. They're thinking about, man, the software doesn't work for me." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (40:14) > "Especially with AI, a lot of the product moat is starting to shrink. And a lot of the competitive advantage is coming on the value added service side of the business." > > — Anthony Enrico, The LeanScale Podcast Ep. 113 (47:50) > "Learn to do it well, learn to do it consistently first, and then you kind of earn the right to start to charge for it." > > — Aimee Menne, The LeanScale Podcast Ep. 113 (49:16) ## Practical advice by role ### Founders - Stand up services where customers are visibly pulling you, as a pattern of requests for help, not because services look like an attractive revenue stream. - Start by asking honestly whether the product can solve the problem, and build a services team for what product work cannot cover. - If a claim like working in any customer environment is part of your differentiation, fund the team that makes it true. - Expect services to run at a loss while the team learns, then aim for break-even before managing it as a P&L. - Keep at least part of delivery in-house so the feedback loop into the product survives. ### Revenue Executives - Sequence the build: hire people who can learn the work, extract the playbook, package it with deliverables and timelines, and only then manage utilization and margin. - Decide whether services are a growth lever or an adoption lever based on your company's DNA and where you sell. - Give the services leader a services revenue target tied to variable comp so the team engages proactively in deals. - Before outsourcing delivery, budget for the overhead of partner management, enablement and quality control. - If you can deliver adoption consistently, treat that competency as a differentiator in your messaging. ### Sales Leaders - Make the service that protects customer outcomes a mandatory attach, and price it low enough that it adds no friction. - Be able to explain every services line item in the deal: what is included, the timeline, and what the customer can expect. - Bring the services team into deals early to catch customers planning an unsupported deployment method. - Use early services conversations to calibrate pricing; the market will tell you quickly what it considers reasonable. ### Customer Success - Build implementation playbooks that let you tell a newly closed customer they should be up and running within a defined window, such as 30 days. - Size fixed-fee packages by deployment complexity; Sourcegraph uses the number of instances to choose between its $10K and $25K packages. - Net hour buckets out to a weekly burn-down so customers don't reach the end of a contract with hundreds of unused hours. - Use partners for regional coverage, and keep internal teams attached to complex or strategic logos. - Validate package pricing against the fully loaded cost of an engineer and how many engagements that engineer can run at once. ### RevOps Leaders - Offer professional services the same support you give sales: forecasting, planning, tooling and reporting. - Track hour buckets inside your existing system of record; Sourcegraph uses Salesforce extensions rather than buying a new tool. - Bring services revenue, utilization and headcount into annual planning once services attach to most new and existing customers. - Analyze which customer characteristics predict services purchases and usage. ## AI takeaways **Thesis:** AI is the backdrop here, not the subject. The forward deployed engineer label is spreading as AI companies such as OpenAI and Anthropic, and Sourcegraph's own spun-off coding agent Amp, sell engineers who deliver outcomes. Aimee's position is that most of it is professional services by another name. Anthony's is that as AI shrinks product moats, durable advantage moves into delivery. - **** — - **** — - **** — - **** — - **** — **Agent & automation ideas** - An hours-bucket monitor that tracks resident architect burn-down weekly and flags accounts heading toward contract end with large unused balances. - A deal-review assistant that scans opportunity notes for customers planning an unsupported deployment method and alerts the services team early. - A services capacity model that combines fully loaded engineer cost, concurrent engagement limits and pipeline to test package pricing and headcount against a services revenue goal. ## Operations takeaways ### Revenue operations - **.** - **.** - **.** - **.** - **.** ### Pipeline & marketing ops - **.** - **.** - **.** - **.** ### Customer operations - **.** - **.** - **.** - **.** - **.** ## Metrics mentioned | Value | Metric | Context | | --- | --- | --- | | ~$50M | Segment revenue when Aimee joined | The scale at which she joined Segment's solution architecture team, which she later turned into a professional services organization. | | 6 people | Sourcegraph technical success team at joining | The team Aimee joined five and a half years ago, alongside sales. | | Up to 6 months | Self-hosted install time before services | Before Sourcegraph had a cloud offering, it was not uncommon for customers' on-prem installs to take this long. | | 30 days | Playbook time-to-live target | Aimee's example of the confidence a repeatable implementation playbook should give: a newly closed customer that follows it should be up and running in 30 days. | | $10K base / $25K advanced | Mandatory implementation attach | Sourcegraph's fixed-fee packages for self-hosted customers, with the tier driven largely by one versus multiple instances. | | 6–12 weeks | Segment implementation projects | Fixed-fee engagements to install, get the data pipeline running and configure downstream destinations. | | 80–90% | Billable utilization targets | The range Aimee gives as the utilization question to plan against when services reach maturity. | | e.g. $500K | FDE-style engagement size | Illustrative figure Aimee used for an Amp engagement ("whatever the dollar amount may be"), possibly covering around five outcome-based projects. | | e.g. $1M by year end | Services revenue planning goal | Illustrative target Aimee uses when working backward from fully loaded engineer cost and concurrency to package pricing. | ## Entities mentioned - **Sourcegraph** (company) — Aimee's company, where she joined a six-person technical success team five and a half years ago, stood up professional services and now runs all of revenue. It serves the largest engineering organizations. Services include a mandatory implementation attach for self-hosted customers ($10K base or $25K advanced), resident architect hour buckets and field engineering, and the company now frames its delivery competency as adoption-led delivery. · https://www.leanscale.team/knowledge/company/sourcegraph/ - **Palantir** (company) — Where Sourcegraph's original co-founders worked as forward deployed engineers, and the origin of the term. Aimee treats Palantir's definition as the standard: going into the customer's environment and building whatever it needs, fully bespoke. · https://www.leanscale.team/knowledge/company/palantir/ - **IBM** (company) — Where Aimee started as a developer on a waterfall project with the US Navy, then moved into technical consulting after IBM acquired Maximo, working onsite five days a week with a gas utility, a steel company and a telecommunications company. She carried a utilization target there. · https://www.leanscale.team/knowledge/company/ibm/ - **Switchfly** (company) — Travel-tech company where Aimee worked in solution architecture and professional services on B2B and B2B2C white-label software, scoping SOWs and building customer-specific capabilities, which she says sounds a lot like FDE. · https://www.leanscale.team/knowledge/company/switchfly/ - **Segment** (company) — Aimee joined its solution architecture team at about $50M in revenue and turned it into a professional services organization. Customers needed help integrating it into websites and mobile apps. Its fixed-fee implementations ran six to twelve weeks, and regional partners delivered a consistent global experience. · https://www.leanscale.team/knowledge/company/segment/ - **Twilio** (company) — Acquired Segment; Aimee stayed through the acquisition before joining Sourcegraph. · https://www.leanscale.team/knowledge/company/twilio/ - **Amp** (company) — The coding agent part of Sourcegraph, since split off. Aimee says Amp was doing true forward deployed engineering: customers paid an agreed amount for engineers to deliver outcomes such as projects, migrations and activated workflows. · https://www.leanscale.team/knowledge/company/amp/ - **OpenAI** (company) — Cited alongside Anthropic as making a big splash with forward deployed engineering of similar scope to solution architecture. · https://www.leanscale.team/knowledge/company/openai/ - **Anthropic** (company) — Cited alongside OpenAI as making a big splash with forward deployed engineering of similar scope to solution architecture. · https://www.leanscale.team/knowledge/company/anthropic/ - **LeanScale** (company) — Anthony's RevOps firm. He raises professional services as a department RevOps teams rarely talk about supporting. · https://www.leanscale.team/knowledge/company/leanscale/ - **Aimee Menne** (person, guest) — · https://www.leanscale.team/knowledge/guest/aimee-menne/ - **Anthony Enrico** (person, host) — Co-founder of LeanScale and host of The LeanScale Podcast. · https://www.leanscale.team/knowledge/guest/anthony-enrico/ - **Salesforce** (tool, CRM) — Named by Anthony, with HubSpot and Clay, as go-to-market tech companies that outsource much of their services to partners. Aimee also says Sourcegraph tracks services hour buckets through Salesforce extensions inside its existing system of record. - **HubSpot** (tool, CRM) — Named by Anthony as a go-to-market tech company that outsources much of its services to partners. - **Clay** (tool, GTM Data / Enrichment) — Named by Anthony as a go-to-market tech company that outsources much of its services to partners. - **IBM Maximo** (tool, Enterprise Asset Management) — Asset management software IBM had just acquired when Aimee moved from development into technical consulting to learn it and help sell and implement it in the field. She likens its complexity to ERP systems. - **Kubernetes** (tool, Infrastructure / Container Orchestration) — Sourcegraph hired implementation experts deeply seasoned in Kubernetes and the range of configurations customers run, to make self-hosted deployments repeatable. ## FAQ **Q: What is the difference between a forward deployed engineer and professional services?** A: Aimee Menne, CRO at Sourcegraph, whose co-founders were forward deployed engineers at Palantir, treats Palantir's definition as the standard. There, an engineer goes into a customer's environment and builds whatever that customer needs, fully bespoke. She separates a true FDE from a rebrand with two questions: is it a paid engagement with a billable metric, and is the customer effectively renting an engineer for work that may or may not involve a product? If the work is about using, embedding, extending or making your own technology stick, she calls it professional services. On that basis she sees most of today's FDE craze as professional services with lipstick on. **Q: When does a software company need a professional services team?** A: The clearest signal is customer pull: a pattern of customers asking for help. At Sourcegraph, before it offered cloud hosting, every customer installed it on-prem and installs could take six months. At Segment, customers struggled to integrate the product into websites and mobile apps. Your ICP matters too. Large enterprises expect to buy 24/7 support, hand off maintenance and upgrades, and work with vendor engineers through shipped laptops or VPN access. Aimee Menne finds services built in response to that demand much easier to integrate culturally than services invented because they look like a lucrative revenue stream. **Q: Should you fix implementation problems in the product or build a services team?** A: Start by asking whether the product can genuinely solve it. Sourcegraph had deliberate debates about solving self-hosted deployment in the product versus hiring a team to centralize the expertise. It concluded that no amount of product work could cover every environment, network configuration and tech stack. Because working in any customer environment is part of Sourcegraph's differentiation, it built the team so it could stand behind that claim. It also has data showing that customers on implementation services who maintain and regularly update their instance retain and grow at a higher clip. **Q: In what order should you build a professional services organization?** A: Aimee Menne describes a maturity curve. First, commit to the capability and hire people with the skills to learn how to do the work. Second, build a repeatable playbook so a newly closed customer can reliably be up and running within a known window, such as 30 days. Third, package the service with committed deliverables, timelines, outcomes and a price that can be explained in a sales conversation. Only after that do you run it as a P&L with utilization targets and margins. Expect to start at a loss while learning, then work to break even. Her summary: learn to do it well and consistently first, then earn the right to charge for it. **Q: How does Sourcegraph price and package professional services?** A: Sourcegraph uses three models. Self-hosted customers must buy an implementation package, priced deliberately low to avoid friction: $10K base or $25K advanced, depending largely on whether they run one instance or several. It covers installation, deployment, monthly updates and quarterly maintenance over the annual contract. For highly customized needs, such as onsite trainings or materials in the customer's own terminology, a resident architect package sells a yearly bucket of hours netted out to a weekly burn-down. FDE-style engagements, which Sourcegraph's spun-off coding agent business Amp sold, charge an agreed amount for engineers who deliver outcomes such as projects, migrations or activated workflows. **Q: How do you know if a services package is priced correctly?** A: Aimee Menne uses two inputs. The market is the first: early conversations quickly show what customers think is reasonable, and they will push back if the value doesn't match the sticker price. The second is internal cost math. Take the fully loaded cost of an engineer and how many engagements that engineer can run at once, work out the price needed to break even, then see what it would take to reach a goal such as $1M in services revenue by year end. At maturity, services teams plan against billable utilization targets such as 80 or 90 percent and forecast engagements, revenue and headcount. **Q: Should professional services be a profit center or an adoption lever?** A: Aimee Menne has seen both work, and says the choice depends on the company's DNA and where it operates. For companies selling a complicated, extensible product into large enterprises, where buyers expect services from vendors, services can become a real growth lever. Treating services as a revenue stream to force-fit, a square peg in a round hole, is culturally difficult and takes much more to make successful. Her preference is to build services where customers are already pulling the company in that direction. **Q: Should software companies outsource implementation to partners?** A: Aimee Menne argues for keeping at least part of delivery in-house. She has not seen the feedback loop from delivery into product done well with purely outsourced agencies. Partners also carry overhead: someone must manage the relationships, keep partners enabled as the product evolves, and ensure quality, because the partner carries your brand. Partners work well for regional coverage, as they did at Segment, but complex or strategic accounts should keep internal teams attached. Anthony Enrico adds that a partner implementing your technology poorly is probably more damaging than services revenue diluting your multiple, because customers blame the software, not the third party. **Q: How should RevOps support a professional services team?** A: Anthony Enrico calls professional services a department RevOps rarely talks about supporting. Once most new and existing customers buy services, that revenue belongs in forecasting and annual planning, and RevOps can analyze which customer characteristics predict services purchases and usage. At Sourcegraph, the services leader runs the function like his own business and carries a services revenue target in his variable comp. Hour buckets are tracked through Salesforce extensions in the existing system of record, finance has supported analysis, and RevOps oversees tooling, the tech stack and reporting. ## Timeline - **00:00** — Cold open + intro - **01:29** — Computer science to IBM — and the Navy project that bored her - **04:08** — Switchfly and Segment: building services practices from scratch - **06:50** — The flip: internal work vs. work a customer sees - **09:59** — The FDE craze: "professional services with lipstick on" - **12:41** — The two-question test for a real forward deployed engineer - **14:19** — When a software company actually needs professional services - **18:31** — Product problem or service opportunity? How to tell - **21:36** — The maturity curve: first hire → playbook → packaging → P&L - **26:49** — Pricing and packaging: $10K attach, hour buckets, outcome-based projects - **30:38** — Utilization, fully loaded cost, and running a company inside the company - **33:54** — Profit center or adoption lever? - **35:41** — In-house vs. partner-led — what outsourcing really costs - **40:32** — The RevOps blind spot: nobody supports professional services - **44:51** — Staying sharp as a new CRO - **47:43** — Why software companies now look like services companies ## Related episodes - **Ep. 80: Why Enterprise AI Deals Die After the Buyer Says Yes** (Scott Sinatra (Wisq)) — Scott calls forward deployed engineers a requirement that belongs in the growth model, a direct counterpoint to Aimee's view that most FDE is rebranded professional services. He also covers outcome-based pricing in enterprise deals. · https://www.leanscale.team/knowledge/podcast/scott-sinatra-ai-sales-trap/ - **Ep. 91: Why Outcome-Based Pricing Is a Trap for Most AI Companies** (Roee Hartuv (Winning by Design)) — A deep look at outcome-based pricing and the order of packaging decisions, useful framing for Sourcegraph's outcome-tied FDE packages. · https://www.leanscale.team/knowledge/podcast/roee-hartuv-outcome-based-pricing-trap/ - **Ep. 102: I Don't Want Your Product. I Want Your Expertise.** (Noah Marks (ECI Software Solutions)) — The buyer's side of Anthony's point that software companies are starting to look like services companies: an operator who wants to buy expertise rather than product. - **Ep. 63: Customer Success as a Competitive Advantage** (Maranda Dziekonski (Fexa)) — Makes the case for post-sale teams as a competitive advantage in the language of the CFO, including where they sit on the P&L. Useful next to running services as a P&L. · https://www.leanscale.team/knowledge/podcast/maranda-dziekonski-customer-success/ - **Ep. 28: Run CS Ops like a Pro: The 5 Things Every CS Operation Needs to Have** (Adrian Diaz (Findem)) — Builds the operations layer for post-sale teams, the gap Anthony flags when he says RevOps rarely supports professional services. · https://www.leanscale.team/knowledge/podcast/adrian-diaz-cs-ops/ - **Ep. 86: Why the Best CROs Don't Come From Sales** (Jerry Brooner (Levelpath)) — Another CRO who got there without the traditional sales track, echoing Anthony's closing point about operational routes to the revenue seat. · https://www.leanscale.team/knowledge/podcast/jerry-brooner-best-cros-dont-come-from-sales/ ## Full transcript _Machine-transcribed and not diarized; speaker attribution is inferred._ _Transcript only, as a separate file: https://www.leanscale.team/knowledge/podcast/aimee-menne-sourcegraph-fde-professional-services/transcript.md_ ### 00:00 — Cold open + intro **[0:00]** - It's professional services, broadly with lipstick on. **[0:03]** You know, I would say 22-year-old Amy **[0:06]** did not have the CRO aspiration at the time. **[0:09]** I think luckily for my career, I started off at IBM. **[0:13]** - My guest today is Amy Meni, **[0:15]** Chief Revenue Officer at Sourcegraph, **[0:18]** the code intelligence platform that giant engineering orgs **[0:21]** use to make sense of decades of code. **[0:24]** Amy's path to the revenue seat **[0:26]** is one of the most unusual I have come across. **[0:29]** She studied computer science, started her career **[0:32]** as a developer, and rose through Solutions Architecture **[0:35]** and Professional Services before taking on all of revenue. **[0:39]** - It feels good to win that deal. **[0:40]** It feels good to launch that customer. **[0:42]** It feels good to, you know, get to the end **[0:44]** of this work stream or help them, you know, **[0:47]** be able to do something that they weren't able to do before. **[0:50]** Like there is an immense amount of satisfaction **[0:55]** that I get right from those. **[0:57]** Like, you know, the adrenaline hit of that. **[0:59]** Like that FDE-type package is more tied **[1:02]** to like an outcome that's being delivered. **[1:04]** And we're agreeing to some dollar amount. **[1:07]** They're not thinking about that third party. **[1:09]** They're thinking about, man, the software doesn't work for me. **[1:12]** You know, I think that maturity curve, right, is very real. **[1:15]** Learn to do it well, learn to do it consistently first. **[1:20]** And then you kind of earn the right **[1:21]** to start to charge for it. **[1:27]** (logo whooshing) ### 01:29 — Computer science to IBM — and the Navy project that bored her **[1:29]** - Amy, you studied computer science. **[1:31]** You started out as a developer. **[1:33]** Now you run all of revenue at Sourcegraph. **[1:36]** Walk me through how a developer **[1:38]** ends up as a chief revenue officer. **[1:40]** - Yeah, yeah, happy to. **[1:41]** Thanks for having me. **[1:43]** You know, I would say 22-year-old Amy **[1:46]** did not have the CRO aspiration at the time. **[1:49]** Coming out of college, I was absolutely certain **[1:53]** I was going to do development, **[1:54]** kind of path towards, you know, CTO/CIO **[1:57]** was what I thought was on the horizon for me. **[2:01]** I think luckily for my career, **[2:03]** I started off at IBM massive organization **[2:07]** pretty much immediately threw me on to a project **[2:10]** with the US Navy. **[2:12]** And, you know, looking back, **[2:15]** thankfully that was the first project. **[2:17]** I was pretty bored through it. **[2:20]** You know, working on these like very large, **[2:23]** massive pieces of software, very waterfall. **[2:27]** You know, you're releasing quarterly, right? **[2:30]** I was sitting behind a computer and I was like, **[2:31]** this is just not for me. **[2:34]** Luckily being at IBM, where they do so many things, **[2:37]** I was able to move from that really **[2:39]** into technical consulting. **[2:43]** You know, IBM has a habit of acquiring software, right? **[2:47]** Putting their name on it **[2:49]** and kind of taking it forward from there. **[2:51]** And so right time, right place for me, **[2:53]** they had just purchased an asset management software **[2:56]** called Maximo. **[2:57]** And they were looking for people with technical chops **[3:00]** that could learn that and go into the field **[3:03]** and help, you know, sell that **[3:05]** and implement it for customers. **[3:07]** And so it was like pretty early on in my career **[3:09]** that I made the pivot **[3:11]** that was more directly customer facing. **[3:15]** And it really took off from there. **[3:16]** I spent the first part of my career in consulting. **[3:18]** I loved it. **[3:19]** I felt like I got a ton of exposure **[3:21]** to different industries and technologies. **[3:25]** I feel like I learned a lot in a short amount of time. **[3:29]** You're working on RFPs. **[3:30]** You're putting together proposals. **[3:32]** Granted, I was doing more of the solutioning aspect of those, **[3:35]** but you know, you're having to kind of do the full suite **[3:38]** of things when you're in a consultant type role. **[3:42]** And so I feel like, **[3:43]** especially that consultant part of my career, **[3:45]** I was at this interesting intersection of, you know, **[3:48]** of course being very customer facing, **[3:52]** adjacent to sales and working with really, **[3:56]** really technical products. **[3:59]** Asset management, right? **[4:01]** That's like a very complicated comp. **[4:03]** It's like on the level of ERP systems type complexity. ### 04:08 — Switchfly and Segment: building services practices from scratch **[4:08]** And so, you know, fast forward **[4:10]** to make the decision to leave consulting. **[4:12]** I felt like I got all of this exposure, **[4:14]** but it felt like a mile wide an inch deep. **[4:17]** And so when I left consulting **[4:19]** and really wanted to focus more vertically, **[4:23]** I started off in travel tech. **[4:24]** This was actually where Solution Architecture **[4:27]** Professional Services, **[4:30]** company by the name of SwitchFly. **[4:32]** We had kind of the full suite of capabilities. **[4:35]** We were doing B2B and B2B2C software. **[4:38]** So like white label behind the scenes. **[4:40]** You don't even know that you're interacting **[4:41]** with the software and you are. **[4:43]** There was a big professional services portion of that **[4:46]** that I was doing, working with customers, **[4:48]** trying to understand what it was that they need, **[4:50]** actually scoping it out, building SOWs, **[4:54]** working with internal teams to kind of deliver **[4:56]** that functionality that they needed. **[4:58]** Honestly, it sounds a lot like FDE **[4:59]** that I know we'll come back to. **[5:02]** And, you know, building new capabilities **[5:05]** and features specific to those customers. **[5:07]** Took that experience to segment, as you mentioned, **[5:11]** Solution Architecture team joined them **[5:13]** about 50 million in revenue. **[5:14]** We were doing a lot and kind of hit this moment **[5:17]** where we were trying to figure out **[5:18]** kind of repeatable playbooks for ourselves. **[5:22]** Turned that into a professional services organization **[5:25]** as well, stayed there through the Twilio acquisition. **[5:29]** And then that landed me at Sourcegraph. **[5:32]** I was, you know, a lot of it is my passion **[5:35]** and kind of background as you pointed out **[5:37]** from the development side of things, **[5:40]** but it's an extremely technical product. **[5:42]** We work with the most sophisticated **[5:43]** engineering organizations in the world. **[5:45]** And so I feel like so much of my past history **[5:48]** has led me to this moment. **[5:50]** I joined on the technical success team. **[5:53]** We were a small team of six **[5:56]** at the time when I joined right alongside sales. **[5:59]** So really this like, you know, **[6:01]** getting closer and closer to directly revenue, **[6:05]** it was very organic throughout, you know, **[6:08]** the entire five and a half years **[6:10]** that I've been at Sourcegraph, **[6:11]** I've been right here alongside. **[6:13]** Similarly, like you're hearing, you know, **[6:15]** stood up professional services, **[6:17]** started to sell that, scope that. **[6:19]** But being the technical product that we are **[6:21]** and one of our amazing competencies as a company **[6:25]** is our ability to land and really grow our customers. **[6:29]** I think that lends itself **[6:30]** to a lot of my background and experience. **[6:33]** And so, you know, it is a non-standard **[6:39]** kind of career path from what you tend to see. **[6:42]** But I think for me and my journey, **[6:44]** it actually feels like everything has led to this moment **[6:48]** in a very weird way. ### 06:50 — The flip: internal work vs. work a customer sees **[6:50]** - Was there a flip that switched **[6:53]** and something that changed **[6:54]** the moment you were doing something for a customer **[6:58]** versus just developing something behind the scenes? **[7:02]** - I almost feel like it was an immediate shift for me. **[7:06]** So I mentioned, you know, at IBM, **[7:09]** I get put onto this new technology that really, **[7:13]** very few people at IBM knew how to use. **[7:16]** And, you know, hungry scrappy, you know, **[7:19]** 22 year old at the time learning this new technology, **[7:22]** getting to then immediately be deployed out, you know, **[7:26]** I'm onsite five days a week, you know, **[7:29]** in these customer environments **[7:31]** trying to get the software up and running for them. **[7:33]** I loved it immediately. **[7:35]** The problem solving, the figuring out what they need, **[7:39]** you know, I'm working with a gas utility on this project. **[7:43]** I'm working with a steel company on this project. **[7:45]** I'm working with telecommunications company **[7:47]** on this project, right? **[7:48]** So different. **[7:51]** And I think just instantaneously **[7:53]** that ability to interact with people, **[7:56]** understand what they need, what they're trying to do, **[7:58]** what they have in place, where we're trying to go. **[8:01]** And of course applying, you know, my technical skills **[8:04]** and actually like making the software work for them. **[8:07]** It was immediately just this instant **[8:10]** kind of trifecta for me. **[8:13]** - Yeah, I've always felt too, **[8:15]** there's such a difference between doing something internal **[8:18]** versus doing something external. **[8:20]** There's like a level of polish. **[8:22]** And I mean this in a good way, **[8:24]** a level of adrenaline too, of like, **[8:27]** oh, I need to be on my A game. **[8:28]** Like this matters. **[8:30]** And if I do well, this is a win. **[8:33]** And I just think it's totally different. **[8:35]** For anyone who has only done like development or ops, **[8:38]** like behind the scenes only worked internal, **[8:41]** like there's just something different **[8:42]** about doing it for a customer. **[8:43]** - Yeah, yeah. **[8:45]** You know, there's, I think you said discomfort. **[8:48]** There's a stress to it, but it's a good stress. **[8:51]** You know, athlete my whole life, right? **[8:54]** Team, you know, big into team sports. **[8:56]** And like, you kind of get a rush of that **[8:59]** in a professional environment. **[9:02]** It feels good to win that deal. **[9:03]** It feels good to launch that customer. **[9:04]** It feels good to get to the end of this work stream **[9:07]** or help them, you know, be able to do something **[9:11]** that they weren't able to do before. **[9:13]** Like there is an immense amount of satisfaction **[9:18]** that I get right from those, **[9:19]** like, you know, the adrenaline hit of that. **[9:23]** Yeah. **[9:23]** - 100%. **[9:24]** Yeah, I played a number of sports. **[9:26]** Main one I did was wrestling, middle school, high school. **[9:31]** And there's such a difference between practice **[9:33]** and game day. **[9:35]** And that level of speed and that level of attention **[9:39]** that you have and adrenaline in that moment is just, **[9:43]** it's pretty tough to replicate. **[9:44]** And I think in a business context, **[9:46]** game day is when you're doing something in front **[9:49]** of a customer, a prospect. **[9:52]** And that's when I think some of the best work is done too. **[9:55]** - Yeah, I agree with that completely. ### 09:59 — The FDE craze: "professional services with lipstick on" **[9:59]** So walk me through this craze of forward deployed engineer. **[10:06]** I know everybody's throwing it out. **[10:08]** Everybody's coming up with their own version too, **[10:10]** like forward deployed XYZ. **[10:14]** Is this just the same thing that we've always been doing? **[10:16]** Just call it something different? **[10:17]** Why do you think people are hanging onto this so much? **[10:20]** - Yeah, I think craze is definitely the right word there. **[10:24]** It's so interesting to see this evolve. **[10:29]** The original co-founders of Sourcegraph, **[10:32]** they themselves were forward deployed engineers **[10:34]** at Palantir earlier in their careers. **[10:37]** - Part of Genesis of the term. **[10:39]** - Yeah, absolutely. **[10:41]** And so it's so interesting to see the evolution of it. **[10:45]** I actually do believe that it's professional services **[10:50]** broadly with lipstick on, **[10:52]** but you're seeing it evolve in different ways. **[10:56]** The Palantir model I would say is like, **[10:58]** I'm going into the environment, **[11:00]** I'm building them whatever they want. **[11:03]** It's completely custom, bespoke to what they need. **[11:05]** That's my priority is what is this customer **[11:09]** trying to achieve? **[11:11]** And I think that that certainly still exists. **[11:13]** I mean, that's the work that I was doing at Switchly **[11:17]** as a solution architect. **[11:21]** Working with customers, what is it that, **[11:22]** how do you need our product to work? **[11:25]** What do we need to build additional capabilities **[11:28]** to make this work better for you? **[11:29]** Extremely bespoke, very custom to what they needed. **[11:32]** Very, very important, right? **[11:35]** Solving important problems that they had. **[11:37]** You're seeing extensions of it where it's like, **[11:40]** okay, honestly more of like solution architecture. **[11:44]** I would say the way that I think about solution architecture **[11:47]** where it's like, we've got our software **[11:49]** and I'm really just trying to help you use our software **[11:52]** pretty much out of the box, maybe extending some APIs, **[11:54]** but maybe writing some scripts, right? **[11:57]** But like helping make my technology work **[12:01]** in your environment, but not really doing any custom **[12:03]** development to get there, right? **[12:05]** Not really extending the product in that way. **[12:08]** I think we're seeing that theme emerge a lot. **[12:11]** We do that at Sourcegraph. **[12:13]** That is one of the core things **[12:14]** that our field engineering team does. **[12:16]** I know that's, you know, there's a big splash being made **[12:18]** with open AI and anthropic doing similar type of scope. **[12:24]** And so, you know, it's interesting to see kind of **[12:27]** the different iterations of this, **[12:31]** but I really feel like when you look at it **[12:33]** and you boil it down, the heart of what is happening **[12:36]** is its professional services, you know, for customers. ### 12:41 — The two-question test for a real forward deployed engineer **[12:41]** - What would be the difference? **[12:42]** What would be like, oh, this is a proper **[12:45]** forward deployed engineer. **[12:46]** They're using that term in the correct way **[12:50]** versus just throwing it around as a buzzword **[12:52]** and they're really doing pro serve. **[12:54]** What would be the line where you would say, **[12:56]** okay, yeah, that's what that term is for? **[12:58]** - Yeah, well, I mean, right, Palantir created it. **[13:02]** So I feel like their definition, you know, **[13:05]** at least the way that I think about it, **[13:06]** their definition is kind of the standard of that. **[13:11]** And I guess kind of two pieces, you know, that's separated. **[13:18]** One is, you know, are they actually paying? **[13:21]** Is it a paid engagement, right? **[13:23]** Is there any type of, you know, billable metric **[13:29]** to that customer for that work being done, of course, **[13:33]** would be kind of the first ones of that. **[13:36]** But I think the second one is, you know, in some cases, **[13:39]** you literally are just hiring the engineer. **[13:43]** It's kind of like engineer for rent. **[13:45]** I'm hiring you to come and like, and do this. **[13:48]** It could or could not have anything to do **[13:51]** with a product that they have. **[13:54]** I think that you see those elements **[13:56]** of like what I would call true for deployed engineer. **[13:59]** To me, if you're charging, to me, **[14:02]** if like you're using your tech, **[14:03]** if you're trying to embed your tech, **[14:04]** if you're trying to make your tech more stick, **[14:06]** if you're trying to make your tech work, **[14:07]** if you're trying to extend it right, **[14:08]** all of those things I would argue are professional services, **[14:13]** not for deployed engineering. **[14:16]** - Makes a ton of sense. ### 14:19 — When a software company actually needs professional services **[14:19]** I was hoping we'd get into a little bit. **[14:20]** I think a lot of software companies struggle with, **[14:25]** okay, when do I need to bring in professional services? **[14:29]** And then how do I bake that into my model **[14:31]** and manage it without completely wrecking my gross margin? **[14:36]** What would give you a signal **[14:39]** that they need to start layering in **[14:42]** a proper professional services organization? **[14:45]** And how should they start building that out? **[14:49]** - Yeah, in my experience, **[14:53]** and I think that internally, culturally, **[14:57]** this also makes it so much easier **[14:59]** to stand that function up and integrate it, **[15:04]** our customers were always pulling us in that direction. **[15:07]** And so like an example of this at Sourcegraph, **[15:10]** when I first joined, **[15:14]** we did not have a cloud offering, **[15:16]** so all of our customers would install us on-prem, **[15:19]** so like in their own cloud service provider, **[15:21]** in their own data center. **[15:23]** And this wasn't something that we could, **[15:27]** that we were very good at helping them through. **[15:30]** It would take them a very long time to install, **[15:33]** it would take them a very long time **[15:34]** to get the hardware that they needed to get deployed, **[15:38]** configured, right, everything in place to maintain it. **[15:41]** And they were looking to us to help them, **[15:44]** like it was not uncommon at that point in time **[15:47]** for it to take six months. **[15:49]** And so when I say like, **[15:51]** customers were pulling us in this direction, **[15:53]** it's like asking us for that help, **[15:55]** saying that they need this, **[15:59]** that is so much easier to identify that need **[16:03]** and build that need and integrate that need **[16:05]** into your company, **[16:06]** rather than taking a separate approach of like, **[16:10]** listen, professional services can be extremely lucrative. **[16:13]** There are a lot of companies **[16:15]** that have done exceptionally well **[16:17]** and professional service has been **[16:19]** a very big revenue driver for them. **[16:21]** And so you could say, well, okay, **[16:24]** here's a potential revenue stream. **[16:25]** What services could we create? **[16:27]** What packages could we create? **[16:28]** And you can take that approach as well. **[16:32]** And so what's been really interesting, **[16:35]** even at Segment on the solution architecture side, **[16:38]** when people would buy Segment, **[16:41]** it's a Martech platform, **[16:42]** but you need to go and integrate Segment **[16:44]** into your website, onto your mobile apps, right? **[16:48]** There is definitely an implementation component of it. **[16:51]** And they were struggling. **[16:52]** And so similarly, they were like pulling us **[16:54]** in this direction of, hey, we need help. **[16:57]** And so identifying those patterns **[17:00]** and identifying those areas **[17:01]** where customers are actually like raising their hand **[17:04]** and identifying that like there is a true need **[17:06]** and you see that, right? **[17:07]** Emerging in different areas **[17:10]** is obviously the simplest flag **[17:14]** for you to know that there's an opportunity **[17:17]** or maybe you should consider **[17:20]** building out a dedicated function for that. **[17:23]** I think as well, this is certainly true for Sourcegraph. **[17:28]** The largest engineering organizations **[17:30]** are really the ones that get the most value from Sourcegraph. **[17:33]** These are the companies with tons of code, **[17:35]** multiple code hosts, et cetera, et cetera. **[17:38]** Sourcegraph provides a product capability **[17:42]** that just doesn't exist for them. **[17:45]** Those are also the types of companies **[17:46]** that are very used to working with vendors **[17:49]** who provide professional services. **[17:51]** And so there's also a little bit of that tug. **[17:53]** If you wanna play in the enterprise, **[17:54]** they're going to have certain expectations. **[17:56]** They're gonna expect to be able to pay **[17:58]** if they want for 24 by seven support. **[18:00]** They're going to expect that somebody can take over **[18:04]** the maintenance burden for them **[18:05]** and manage their upgrades if they so choose, **[18:08]** that they can ship a laptop to somebody **[18:10]** or give them VPN access. **[18:11]** These are all things that we experience. **[18:13]** And so it's like also very interesting how, **[18:16]** depending on who your product service is, right? **[18:19]** Who your ICP is, where you play, **[18:22]** you may also get pulled in that direction. **[18:24]** That was certainly true **[18:25]** for some of the professional services offerings **[18:27]** that we ended up building here at Sourcegraph. ### 18:31 — Product problem or service opportunity? How to tell **[18:31]** - How do you draw the line between, **[18:34]** hey, maybe my product needs support **[18:37]** and maybe there's things we need to simplify in the product **[18:40]** or help the customer serve themselves versus, **[18:44]** no, this is actually a real opportunity **[18:45]** to help the customer and have a value-added service. **[18:50]** What are some things companies should be looking for **[18:52]** that would be signs that, hey, no, **[18:54]** this isn't a product problem where you need more support, **[18:57]** or it's not really a problem **[18:59]** that just support is designed to solve. **[19:02]** You really need to go a different direction. **[19:04]** What signals should they be looking for? **[19:07]** - It's really interesting that you asked that **[19:08]** because I can remember very deliberate conversations we had, **[19:13]** kind of going back to the example around helping customers **[19:16]** with implementation and deployment. **[19:18]** We had many very deliberate conversations. **[19:22]** Do we go and solve this in the product **[19:24]** or do we hire a team and centralize that expertise? **[19:27]** And I think the reality is there's no amount of product work **[19:34]** that could solve that problem 100% of the way, **[19:38]** different environments, different network configurations, **[19:41]** different needs, different tech, et cetera. **[19:43]** And so for us, we really did think about **[19:49]** that very deliberately. **[19:51]** And one of the things that we pride ourselves on **[19:54]** is being able to work in any customer environment. **[19:57]** Like that for us is like part of our differentiation. **[20:01]** And so if that is part of the core value prop **[20:04]** that we want to take forward, **[20:07]** if we wanna be able to make that statement **[20:10]** and stand behind it, **[20:12]** you have to be willing to do what it takes **[20:15]** to actually be able to follow through. **[20:16]** And for us, again, there's no amount of product improvements **[20:21]** that are going to make that possible 100% of the way. **[20:26]** And I think you said that it's like, **[20:28]** there's also a very proactive strategic opportunity **[20:31]** for us to get closer, get more embedded. **[20:35]** That there is absolutely like a very, **[20:39]** there's very clear data that tells us **[20:41]** that customers who partner with us, **[20:42]** who have our implementation services, **[20:44]** who update, who maintain their instance **[20:48]** and update regularly, et cetera, right? **[20:50]** Retain and grow at a higher clip than those that don't. **[20:54]** There's also like a lot of the data to back that up. **[20:58]** But you have to look at those types of considerations **[21:04]** or characteristics. **[21:05]** Could you truly go and solve this in the product? **[21:08]** I think most of the time, like you would start there. **[21:12]** But for us in some of these scenarios, **[21:16]** who we wanted to be and where we want to operate **[21:19]** and the types of customers we wanna work with, **[21:23]** again, we were like pulled in that direction of like, **[21:25]** we have to be able to bring that expertise **[21:29]** and bring that skill set to make source graph work **[21:32]** in any environment, any configuration. ### 21:36 — The maturity curve: first hire → playbook → packaging → P&L **[21:36]** - Well, let's lead with that then. **[21:38]** So let's assume customers are pulling you in, **[21:41]** they're asking for a lot of help. **[21:42]** It seems like you have an opportunity to help, **[21:45]** not just with the product, **[21:46]** but build out within context of their specific situation, **[21:50]** their unique tech stack, industry, **[21:53]** firmographic design and setup. **[21:55]** And you're about to build this department. **[21:58]** I think the biggest things tech companies **[22:02]** would probably run into is, **[22:05]** how do I price and package this? **[22:08]** And what benchmarks should I be looking at **[22:12]** in terms of staffing capacity, gross margin? **[22:16]** How many people should I have? **[22:17]** And how much revenue should a pro serve org be bringing in **[22:21]** at least relative to the spend? **[22:22]** - Yeah, it's definitely a maturity curve, right? **[22:26]** You have to start somewhere, **[22:32]** you have to make the decision **[22:34]** and commit to we're gonna build this team out. **[22:38]** We want to be able to say yes to this capability, right? **[22:42]** So you kind of start there. **[22:43]** There was a lot that we had to learn. **[22:45]** And the same was true at Segment as well. **[22:48]** The first real task for us **[22:51]** was to figure out how to do **[22:52]** these implementations repeatedly. **[22:56]** We really needed to be able to confidently **[23:00]** close a new customer and say, **[23:02]** okay, if they follow this playbook, **[23:04]** they should be up and running in 30 days, right? **[23:08]** However many weeks or days that project was expected to be. **[23:13]** And so you kind of have to start there. **[23:16]** And you start by learning how to do it, right? **[23:18]** Bringing people with, hiring people with the right skills **[23:21]** and capabilities to start to figure out how to do this, **[23:24]** build the playbook, **[23:25]** how do we start to be able to do the same thing **[23:28]** within the same general timeframe. **[23:30]** Once you start to build out a little bit of that competency, **[23:34]** then you can start to think about, **[23:36]** okay, what does the packaging of this look like? **[23:39]** Because you're thinking about the packaging, **[23:41]** there's the head count, there's the pricing of it, right? **[23:43]** But there's also, you're committing to deliverables, **[23:46]** you're committing to timelines, **[23:47]** you're committing to these outcomes that you're delivering. **[23:51]** And that's an important piece of when you think about **[23:56]** inserting that into the sales conversations, **[23:58]** when you're talking about, what is this line item? **[24:01]** Why should I buy it? **[24:02]** You need to have kind of that level of detail and specificity **[24:06]** to be able to paint a very clear picture for them **[24:09]** of what this is, what this looks like, **[24:11]** what you can expect from us. **[24:13]** You don't get there from the beginning. **[24:15]** You get there from deciding **[24:17]** that you're going to step into this. **[24:19]** And so we knew that we needed to reduce the time to value. **[24:25]** We knew we needed to figure out how to help customers **[24:27]** very consistently get up and running quickly. **[24:30]** We hired incredible experts that are very seasoned **[24:36]** with Kubernetes, with all of the different **[24:39]** types of configurations that our customers might run into. **[24:45]** And we started doing it, we started learning **[24:47]** and we started pulling the playbooks out of that. **[24:50]** And once we had that, we said, **[24:51]** okay, what does this look like **[24:53]** for us to actually go and sell it? **[24:56]** And as well, right, some of that **[24:59]** is a little bit of a guessing game. **[25:00]** There's lots of data out there, right? **[25:03]** Talk to other companies, VCs can share some of that data **[25:08]** as well, certainly, from my past experience, **[25:11]** had some data points. **[25:13]** So there's certainly a starting point **[25:15]** that you're thinking about. **[25:17]** But some of it is like, **[25:18]** you start to have these early conversations **[25:20]** and the market is going to adjust you **[25:23]** pretty quickly on what they think is reasonable. **[25:26]** And you have to really think about **[25:28]** the value of the package. **[25:31]** For us, there are a couple services **[25:33]** that are mandatory attach. **[25:35]** So if a customer self hosts, **[25:37]** mandatory, you have to work with our implementation team **[25:42]** because we know that it leads to better outcomes. **[25:44]** We know that time to value. **[25:46]** It's priced at a really, really low reasonable point **[25:50]** to avoid any friction. **[25:53]** But there are some services that we have **[25:57]** that I would say resemble more of what you see **[26:01]** from forward deployed engineering **[26:04]** in the way that we're thinking about it. **[26:06]** And for that, you really have to help them **[26:09]** have a clear picture of like, **[26:12]** what is the justification behind this price? **[26:14]** Well, we're doing all of these things **[26:15]** and here's what you can expect **[26:16]** and here's what we deliver and da, da, da, da, da. **[26:18]** Right, you have to have the playbook **[26:20]** to really make that clear for them. **[26:22]** It's like an alignment of value to the services provided. **[26:26]** And so it's like, that's kind of like, **[26:28]** this like second step. **[26:29]** And then it takes time for you to get to the place **[26:33]** where you're running it as a P&L, **[26:35]** you've got the utilization targets, **[26:37]** you're thinking about kind of the margins behind it. **[26:41]** Like you get there, I would say like, **[26:44]** that's the third or fourth step in line. ### 26:49 — Pricing and packaging: $10K attach, hour buckets, outcome-based projects **[26:49]** What are some ways that you price and package? **[26:52]** Are you doing packages of hours? **[26:54]** Are you tying it to projects, fractional access to people? **[27:00]** Does it depend on what you're doing? **[27:02]** What are some packaging models that you've seen work well? **[27:05]** Yeah, absolutely depends on what you're doing. **[27:08]** Like I mentioned, so mandatory attach, **[27:11]** when customers self-host, we have like the base 10K **[27:15]** and then we have the advanced 25K. **[27:18]** And so what that gets you, **[27:21]** it's essentially a series of activities **[27:23]** and things that we're doing. **[27:24]** We're helping you install, we're helping you deploy. **[27:27]** We're helping you monthly update your instance. **[27:31]** We're helping you quarterly do maintenance, right? **[27:35]** Making sure there's not anything that we need to fine tune **[27:38]** to keep the instance performant, et cetera. **[27:40]** And so, do you have one instance? **[27:43]** Do you have multiple instances, right? **[27:44]** That kind of helps us understand, **[27:46]** should you be in the 10K package or the 25K package? **[27:48]** But it's that set fee and you're getting a sense of like **[27:52]** throughout that annual contract, the different services **[27:55]** and the touch points that you're getting with the team. **[27:57]** So, right, that's fairly standard. **[27:59]** Similarly, that was kind of the base package **[28:03]** at segment as well. **[28:05]** You know, they paid that fixed amount. **[28:07]** We would come in, we would help them to install, right? **[28:10]** Get the data pipeline up and running, **[28:12]** get their integrations, **[28:14]** their downstream destinations configured at six week, **[28:17]** you know, six week, 12 week project, and then you're done. **[28:20]** So it was like kind of that fixed cost. **[28:22]** We've also done it, we have a resident architect package **[28:27]** where, you know, we have customers who, **[28:30]** they want things done in a certain way. **[28:32]** They want onsite trainings. **[28:34]** They want materials that use their terms **[28:38]** or use their language or, right? **[28:40]** Highly, highly customized to their environment. **[28:42]** And so in those situations, we do sell packages of ours. **[28:47]** And there was a similar model as well of that at segment two. **[28:51]** But, you know, what are the types of things you want to do? **[28:55]** What, you know, work streams are we doing train the trainer? **[28:58]** Are we coming onsite once a quarter, right? **[29:00]** Like let's get a sense of what those activities **[29:02]** are that you want. **[29:04]** And then you're essentially buying a bucket of hours **[29:06]** for that year that you burn down. **[29:09]** And, you know, it works out to avoid, you know, **[29:12]** it's not feasible to say, oh, we have 200 hours left **[29:16]** and our contract expires in a week. **[29:17]** We want to use those, right? **[29:19]** You net it out to, you know, a weekly breakdown. **[29:23]** Maybe there's a work stream and, you know, we pull from that. **[29:26]** But in general, they're buying, you know, a bucket of hours. **[29:31]** So there's like, you know, that's the second flavor of it. **[29:34]** The third flavor that we have is, **[29:38]** and, you know, we were doing this more. **[29:40]** So Sourcegraph, we split off from our coding agent, **[29:45]** the coding agent part of our company, AMP. **[29:47]** And AMP was really doing forward deployed engineer. **[29:51]** Like you're, you know, you're paying 500k, you know, **[29:56]** whatever the dollar amount may be, **[29:57]** you're paying some amount of money **[30:00]** and you're getting access to these engineers **[30:02]** that are going to come in **[30:03]** and we're going to deliver an outcome. **[30:06]** We're going to help you with this project. **[30:10]** We're going to help you with this migration. **[30:11]** We're going to help you activate this workflow, right? **[30:14]** And so, and, you know, **[30:16]** maybe we're doing five of those projects for you, right? **[30:19]** And so it's like more tied to, we're hearing, **[30:22]** we're hearing this of this emerging theme **[30:24]** around outcome based pricing. **[30:25]** But I would say like that FDE type package **[30:28]** is more tied to like an outcome that's being delivered. **[30:31]** And we're agreeing to some dollar amount that, you know, **[30:35]** we attach to that. ### 30:38 — Utilization, fully loaded cost, and running a company inside the company **[30:38]** - And as it sounds like at the beginning, **[30:40]** maybe you're operating this at break even, **[30:43]** maybe even a loss just to get the traction **[30:46]** with your product. **[30:47]** As it matures, what should you be working towards **[30:52]** in terms of utilization and gross margin of the overall org? **[30:57]** Let's assume it'll probably take some steps to get there. **[31:00]** But when you're kind of running this at full maturity, **[31:02]** what does that tend to look like? **[31:04]** - Yeah. **[31:05]** Yeah, I mean, you know, when you get to full maturity, **[31:08]** you have a sense of, you've done enough of these **[31:13]** that there's like predictability in the pipeline, right? **[31:16]** So you can correlate and, you know, **[31:18]** in the same way in sales, we're planning ahead, right? **[31:21]** Our quarters, our years, you can look at that **[31:23]** and you can plan out, okay, I should expect **[31:26]** this many types of engagements, this much money coming in. **[31:29]** Here's, you know, what my team can handle, you know, **[31:33]** is it, we're looking for 80% utilization, **[31:35]** 90% utilization, right? **[31:37]** What is that that we want them billable? **[31:39]** And you're, you know, you're forecasting that growth, **[31:41]** you're forecasting a revenue target, **[31:43]** you're forecasting head count, right? **[31:44]** And you're able to have a lot of predictability. **[31:48]** - You're almost running a company **[31:50]** within the company at that point. **[31:52]** - Yeah, absolutely. **[31:53]** I mean, and I saw this firsthand, **[31:55]** like when I was at IBM, I had a utilization target. **[31:58]** I was, you were not expected to be, you know, **[32:00]** on the bench, you were expected to be **[32:01]** staffed on projects, delivering for customers, right? **[32:05]** And so, you know, early on in my career, **[32:10]** this was something that I myself was, **[32:13]** I was, I was metric and gold on. **[32:16]** And so you get, you know, you get, **[32:18]** you get to that level of maturity. **[32:22]** You know, one thing that I'm always thinking about is, **[32:25]** you know, you want to get to that breakeven point. **[32:27]** Like you said, you, you started a loss, right? **[32:29]** You kind of have, I feel like you kind of have to, **[32:31]** you need to really learn-- **[32:33]** - Just to start getting traction **[32:34]** and know what you're going to do, right? **[32:35]** - Yeah, exactly. **[32:36]** So then, you know, the next step you're trying to, **[32:39]** you're trying to break even from that. **[32:42]** And, you know, you're getting a sense of, **[32:44]** okay, well, what's the fully loaded cost **[32:46]** of like this employee of this team? **[32:47]** How much can this team handle? **[32:49]** You know, that's like, that's a really good exercise **[32:52]** for validating some of your packaging. **[32:54]** It's like a dimension of it. **[32:56]** Again, the market, the customer, you know, **[32:59]** customers are going to correct you. **[33:01]** If, if they don't feel that your services align, right? **[33:06]** The value aligns to the sticker price. **[33:10]** But another kind of useful data point, **[33:13]** going back to the example of these implementations **[33:15]** that we do, it's like, you know, **[33:17]** what's the fully loaded cost of, **[33:19]** of one of the engineers on this team? **[33:21]** Okay, how many of these can they do at once? **[33:23]** Okay, you know, what would that, **[33:25]** what would that price point need to look like **[33:28]** for this to make sense for us to even break even? **[33:30]** Okay, well, what does that look like **[33:31]** if we want to get a million dollars **[33:34]** of professional services revenue by the end of the year? **[33:36]** Right, what does that look like? **[33:37]** And so those types of data points and conversations **[33:40]** are also really helpful when you're thinking about **[33:43]** how to price this, what does it entail? **[33:46]** How much should we be doing **[33:49]** for any one of these engagements? **[33:50]** How many people do I need, et cetera? ### 33:54 — Profit center or adoption lever? **[33:54]** - Should companies be looking at this as, **[33:58]** hey, this is something that helps get the adoption **[34:01]** of my product and kind of running near break even is okay **[34:06]** or should they be looking at this as a decent profit center **[34:10]** that they can drive real growth from? **[34:15]** - I've seen both, I've seen both for sure. **[34:19]** I think some of that does somewhat depend on, **[34:23]** a bit on the DNA of the company. **[34:26]** And I think, I think, and you know, I said this earlier **[34:29]** but I also think some of that depends **[34:31]** on where you're operating. **[34:33]** Like for us, you know, for us operating in the large **[34:36]** enterprise, professional services are not a one-off thing. **[34:42]** You know, like they work with tons of vendors. **[34:45]** They, you know, in some cases just expect to have this. **[34:49]** I think when you're operating in those types of environments **[34:52]** with a really extensible type of product, **[34:56]** a very complicated yet powerful type product, **[35:00]** you have a real opportunity to turn that **[35:02]** into a growth lover for your business. **[35:06]** But, you know, if you're just looking at it as like, **[35:10]** oh, here's a potential revenue stream. **[35:12]** Let me go try to make this, you know, **[35:14]** square peg fit in a round hole. **[35:17]** That's gonna be really difficult culturally, right? **[35:20]** Internally, and that's going to require a lot more, **[35:23]** I think, to make successful. **[35:25]** It's one of the reasons why I love that, you know, **[35:28]** where I've found myself in companies really building **[35:32]** and using professional services, **[35:35]** the customers are pulling us in that direction. **[35:40]** Makes a ton of sense. ### 35:41 — In-house vs. partner-led — what outsourcing really costs **[35:41]** One thing I see too, I've noticed this **[35:44]** in the go-to-market tech space quite a bit. **[35:47]** So if you look at companies like Salesforce, HubSpot, **[35:50]** Clay, they tend to outsource a lot of the services **[35:54]** to partners. **[35:57]** And then some companies say, no, **[35:59]** we're gonna own the full experience. **[36:02]** On the spectrum to fully outsourcing, **[36:04]** to fully having in-house, **[36:07]** what are some of the reasons to go one direction **[36:09]** or the other if somebody's not sure **[36:11]** how to sort through that? **[36:12]** - Yeah. **[36:13]** I've encountered that as well, even with vendors, **[36:16]** you know, across tools in our revenue stack. **[36:20]** Mandatory services, maybe you have to go **[36:22]** with this outsourced third party. **[36:25]** From my experience, having, there is such value **[36:29]** in having that competency in-house. **[36:32]** So, you know, my experience, what I've seen, **[36:36]** I've lived through it as an IC, **[36:37]** I've lived through it now multiple times, right? **[36:39]** As a leader, there is such value in having **[36:43]** at least a portion of that experience in-house. **[36:46]** You know, you're going, you're learning things, **[36:47]** you're connecting with customers, right? **[36:52]** You're getting more deeply ingrained. **[36:54]** You're hearing feedback that leads to improving **[36:57]** the product in some places. **[36:58]** You're, you know, going and building something custom **[37:01]** and you get this idea to go productize that. **[37:03]** That feedback loop, I have not seen that done well **[37:07]** when you're strictly using outsourced, **[37:09]** you know, outsourced agencies. **[37:12]** I think that you can start to outsource, **[37:15]** you know, it's super, super helpful **[37:16]** for like regional type support. **[37:19]** At Segment, you know, we had multiple vendors **[37:23]** in different parts of the world to really help us, **[37:27]** to help us give a very consistent experience globally. **[37:32]** But, you know, there were absolutely some projects **[37:35]** that due to the complexity or due to the strategic nature **[37:39]** of the logo or the, you know, **[37:42]** what they were trying to accomplish **[37:43]** that we absolutely wanted our internal teams attached **[37:46]** to that so that we could learn, **[37:48]** so that we could strengthen the relationship, **[37:50]** so that we could use those learnings to go and, you know, **[37:52]** build out that industry vertical, make our product better. **[37:56]** So I think that there are very strategic reasons **[37:58]** for taking that on. **[38:00]** And then as well, you know, you outsource it. **[38:03]** There is an overhead to that, right? **[38:07]** Somebody has to manage those relationships. **[38:10]** Somebody has to make sure that they are delivering **[38:13]** the service at the quality that you would expect. **[38:16]** You know, it's your brand that you're outsourcing **[38:19]** and having them take forth. **[38:20]** And so how do you keep them, **[38:22]** how do you make sure that they get enabled and up to speed? **[38:25]** How do you make sure that they know, you know, **[38:27]** how the product is evolving? **[38:29]** How do you make sure that they're able to provide, **[38:31]** you know, the level of support **[38:33]** that you would provide, et cetera? **[38:34]** And so there's also that very real consideration. **[38:37]** It can seem very appealing of like, yeah, let's just, **[38:39]** you know, let's just outsource this, but you have to know **[38:42]** and you have to be ready to solve **[38:45]** for those overhead dynamics. **[38:50]** - I've definitely seen it done wrong **[38:52]** where a company has completely outsourced **[38:57]** maybe things like implementation. **[38:59]** So like, no, we want pure tech revenue. **[39:00]** It's got the highest multiple. **[39:02]** Maybe that revenue is gonna dilute. **[39:05]** And it's like, maybe, but probably what's more damaging **[39:09]** is a partner not implementing your technology very well. **[39:13]** And you're not investing enough to manage them. **[39:16]** As you mentioned, it's not for free. **[39:18]** It's just another strategy. **[39:21]** The only time I've seen where maybe it starts to make sense **[39:25]** is if there's a certain level of industry **[39:27]** or domain expertise where maybe, hey, **[39:30]** this is more of a horizontal type of tech play. **[39:35]** And we have partners that are specialized **[39:38]** in certain industries, but if you're just expecting people **[39:41]** to know your product better than you are, **[39:43]** it seems like a risky bet to me. **[39:45]** - Yep, yep. **[39:46]** And you know, you might get to, **[39:48]** you're trying to do too many things, right? **[39:50]** It's easier to outsource that. **[39:51]** Like you're growing really fast. **[39:53]** You have more customers you can't hire. **[39:56]** It can seem very, very appealing, truly. **[40:00]** But yeah, you're spot on. **[40:03]** Like a customer buys your software, **[40:07]** they wanna get it up and running. **[40:09]** And if they are having problems, **[40:11]** if they're not getting what they need, **[40:14]** they're not thinking about that third party. **[40:16]** They're thinking about, man, **[40:17]** the software doesn't work for me. **[40:19]** This isn't delivering what I hoped it would. **[40:22]** And so, right, there's that very real risk to it. **[40:26]** - Yeah, you're gonna end up getting the blame **[40:28]** if you don't fully own the experience. ### 40:32 — The RevOps blind spot: nobody supports professional services **[40:32]** I was wondering, you know, **[40:34]** 'cause I've run a RevOps agency, **[40:36]** so I'm helping fast companies, **[40:40]** B2B SaaS companies grow in scale **[40:42]** and help them augment the RevOps teams. **[40:45]** This is an interesting area where I feel **[40:47]** like RevOps doesn't talk too much about. **[40:50]** Do you lean on RevOps to help with things like forecasting **[40:54]** for your professional services, **[40:57]** helping them with their internal tech stack and tools? **[41:00]** It's a department that a lot of RevOps people **[41:03]** are not talking about helping. **[41:04]** - Yeah. **[41:08]** Yes and no, I would say. **[41:11]** Partly, I have an incredible PS leader right now **[41:16]** who really, you know, you talk about, **[41:18]** you think of it as like your own business within, **[41:21]** in the business. **[41:22]** He really has that level of ownership over it. **[41:25]** You know, we think about and, you know, **[41:28]** the available bandwidth and what do we need **[41:31]** and what's, again, the fully loaded cost, right? **[41:33]** He's thinking about those elements **[41:37]** of his team, of the performance. **[41:41]** We've been fortunate enough to, you know, **[41:44]** I mentioned kind of, there are packages **[41:46]** where we sell buckets of hours, right? **[41:48]** Being able to track that. **[41:50]** There are some great extensions off of Salesforce **[41:53]** that exist so that you can do that right **[41:55]** from within the one system. **[41:58]** So it's already the tool in our stack. **[42:00]** We haven't needed to, you know, necessarily go buy a new one, **[42:04]** able to report, right, in our system of record, et cetera. **[42:08]** So it's like, we've been fortunate to, **[42:11]** where we've needed to do that, **[42:12]** find tools, find plugins, you know, **[42:15]** connectors within those existing tools. **[42:20]** I've leaned on a lot our finance, **[42:23]** our finance team of helping us do some of the analysis **[42:26]** around this over the past several years. **[42:30]** But RevOps, you know, certainly overseeing our tooling, **[42:34]** overseeing the tech stack, making sure that, you know, **[42:37]** we're reporting on what we need to report on, **[42:40]** you know, et cetera, et cetera. **[42:41]** Like they are definitely a key part of that for sure. **[42:46]** - Yeah, I was just wondering, **[42:47]** I feel like it's kind of a big miss **[42:48]** for some RevOps teams to lean in and offer some help. **[42:54]** It's fantastic you have the leader that you have, **[42:55]** but I imagine a lot of companies are operating **[42:59]** without maybe the analytics firepower or technical, **[43:04]** probably very technical on whatever platform **[43:07]** they're supporting, **[43:08]** but technical on the productivity stack **[43:10]** that the team's using. **[43:12]** Just wondering if it would make sense **[43:13]** for those teams to lean in **[43:16]** and then help in that area of the business too. **[43:18]** - Yeah, I mean, yeah, absolutely. **[43:21]** Like I mentioned, you know, you're thinking, **[43:23]** you get to a point where it's more common than not **[43:27]** that somebody that, you know, **[43:29]** you bring on a new customer or even existing customers, **[43:32]** right, they want to leverage these services. **[43:36]** You know, that becomes part of the forecasting **[43:39]** and part of the planning. **[43:40]** And you're thinking about, right, that potential stream **[43:43]** and like RevOps obviously plays a huge part in that. **[43:47]** So there is a lot of data analysis that can be done **[43:51]** looking at different characteristics, right? **[43:53]** Looking at, you know, this type of customer, **[43:57]** they, you know, they bought these services, **[43:59]** they use that, right? **[44:02]** It's definitely a piece **[44:04]** that needs to come into your annual planning. **[44:09]** It needs to be considered. **[44:11]** And, you know, my professional services leader, **[44:13]** he, you know, he has a revenue target. **[44:15]** He has a services revenue target tied to his variable comp. **[44:19]** Like we want him, you know, we want him and the team **[44:22]** thinking about that, thinking very strategically, **[44:24]** thinking very proactively, getting integrated into deals, **[44:29]** figuring out where there's, you know, early risk. **[44:31]** Where's a customer trying to do something **[44:33]** that is, you know, really not by the book **[44:36]** or not a supported what we would call deployment method. **[44:39]** Let's identify that early. **[44:40]** Let's get into those conversations. **[44:42]** And so it's also like helping us be a lot more proactive **[44:45]** at some of this identification as a company. ### 44:51 — Staying sharp as a new CRO **[44:51]** - As a new CRO, where are you going to stay sharp **[44:56]** and to learn? **[44:59]** - Well, I am very lucky to have many mentors to lean on. **[45:04]** That first and foremost, I listened to a lot of podcasts. **[45:13]** You know, lots of podcasts, I'm always very hungry. **[45:16]** What are other people doing? **[45:18]** I try to have connections with folks in my network, **[45:23]** you know, meet on a quarterly basis, monthly basis, **[45:25]** try to trade notes. **[45:26]** What are you doing? **[45:27]** What are you seeing? **[45:28]** Here's a problem I'm having, you know, what would you do? **[45:32]** And so, you know, there's a lot of information out there, **[45:38]** you know, for folks to learn, **[45:40]** to hear what people are doing. **[45:44]** But yeah, I find, and you know, **[45:47]** I think part of this is like not being behind the computer. **[45:50]** I like to network, I like to connect, I like to learn. **[45:53]** And, you know, this whole topic of forward deployed engineer, **[45:56]** I've had a lot of conversations with people thinking about **[45:59]** and trying to build this and sharing my notes **[46:02]** of like what I've seen and what I would do different, **[46:04]** you know, what I would do differently **[46:05]** if I was starting this over, **[46:06]** as they're starting to step into that journey. **[46:09]** And there's just so much that you can learn very quickly **[46:14]** from others who have gone through this **[46:16]** or are trying to figure this out and write your trading notes **[46:19]** and kind of getting to that place together. **[46:21]** And like, also listen, I have a fantastic team, right? **[46:26]** You know, supporting me. **[46:27]** I have a wonderful, you know, global head of sales **[46:30]** that I learn from every day. **[46:33]** And there's a great, you know, collaboration between that. **[46:36]** And so there's definitely been a learning curve. **[46:40]** You know, I'd be lying if I didn't say **[46:42]** there was some imposter syndrome early on, **[46:45]** but using my network, using my mentors, **[46:48]** there's great articles, there's books out there, right? **[46:52]** You know, podcasts like this. **[46:53]** There's so much that you can learn **[46:55]** and adapt about yourself. **[46:58]** - Yeah, I think if you're not feeling **[46:59]** a touch of imposter syndrome, **[47:00]** you're probably not challenging yourself enough. **[47:02]** So I always look at that as a good sign. **[47:05]** If it feels like I should be in the room, **[47:06]** then maybe I'm not pushing hard enough. **[47:09]** But no, I really appreciate that. **[47:12]** I just think it's, things are changing so quickly. **[47:16]** And it's really, really hard to keep up **[47:19]** and then sift through the noise and find the signal of, **[47:22]** hey, what are people actually doing? **[47:24]** How are people actually operating? **[47:26]** And that's what we try to make this whole podcast about too, **[47:28]** is not just launching buzzwords, **[47:32]** not just launching strategic things, **[47:36]** but what are you actually doing? **[47:38]** What's the execution layer behind **[47:40]** how you're getting this stuff done? ### 47:43 — Why software companies now look like services companies **[47:43]** And I appreciate all the details that you have shared **[47:47]** about this part of the business because, **[47:50]** especially with AI, a lot of the product moat **[47:55]** is starting to shrink. **[47:58]** And a lot of the competitive advantage **[47:59]** is coming on the value added service side of the business. **[48:03]** A lot of service, or sorry, a lot of software companies **[48:06]** are now starting to look a little bit more **[48:07]** like service companies. **[48:09]** And there's just an entire industry **[48:11]** that's never even really thought about doing that. **[48:13]** That's gonna need to start implementing these teams, **[48:16]** need to start managing this whole new type of business **[48:19]** that they haven't had to manage before. **[48:22]** And it's happening really quickly. **[48:23]** So I think a lot of the frameworks and roadmap **[48:27]** that you laid out will be really helpful **[48:30]** for anybody that's going through that transition right now. **[48:32]** - Yeah, that's great. **[48:34]** You just mentioned that we're, through Q2, **[48:36]** we've been really building out **[48:39]** our command of the message framework. **[48:40]** We're really trying to get oriented **[48:42]** around value-based delivery. **[48:44]** And one of our core differentiators is, **[48:51]** we're framing it as adoption-led delivery, **[48:53]** but it is absolutely a competency for us. **[48:56]** We've got years and years of experience of doing this. **[48:59]** We've built out those playbooks. **[49:00]** We can do it very consistently and repeatedly. **[49:03]** And it is absolutely a differentiator. **[49:06]** And to your point, you're seeing this come about **[49:10]** with a lot of companies. **[49:11]** And so I think that maturity curve is very real. **[49:16]** Learn to do it well, learn to do it consistently first, **[49:21]** and then you kind of earn the right **[49:22]** to start to charge for it. **[49:25]** But it is such a core part of the value **[49:30]** that we unlock for customers **[49:32]** and the value that they get from our platform. **[49:33]** It's based off of the people and the experts **[49:37]** and the domain expertise that they bring **[49:39]** to those engagements. **[49:41]** - Absolutely. **[49:43]** I think everything you're doing **[49:45]** is really exemplifying the trend **[49:48]** that the market is going in, **[49:50]** especially with software companies **[49:52]** needing to differentiate with their services. **[49:53]** So I think everything you mentioned, **[49:56]** it's a huge competitive advantage. **[49:57]** And people really need to get the value **[50:00]** out of the technology that they're buying **[50:02]** as quickly as possible. **[50:03]** So Amy, I just want to say thank you **[50:06]** for being on the podcast, being on the show, **[50:08]** sharing everything you did, going into detail, **[50:10]** the nitty and the gritty of it. **[50:12]** And I think it's such a cool thing **[50:15]** to see a different path to Chief Revenue Officer as well. **[50:20]** So a lot of people still have in their minds, **[50:22]** like, oh, I got to go. **[50:24]** S-D-R-A-E sales manager, that's the only path to CRO. **[50:28]** But I think we're seeing a lot of these operational routes **[50:33]** to get to the highest seat in the revenue org. **[50:36]** And it's excellent to have an example of that on the show. **[50:39]** So thank you, Amy. **[50:40]** I appreciate everything you have shared. **[50:43]** And I can't wait to see what you and Sourcecraft do next. **[50:46]** - Awesome. **[50:47]** Thanks for having me. **[50:48]** Enjoy the chat. --- _LeanScale Knowledge Hub. Free to quote and cite with attribution to The LeanScale Podcast (https://www.leanscale.team)._