Running business systems at enterprise scale has some unique challenges—especially when that enterprise is Hubspot.
Today we're fortunate to chat with Rich Archbold, whose team supports all GTM systems and automation at Hubspot, including Hubspot's own Hubspot implementation.
This is a truly fascinating peek behind the scenes at one of the most iconic tech companies. Rich also shares generously from his deep experience, providing insights into how to foster a culture of agility, customer-centricity, and impact within a business systems team.
Many thanks to the sponsor of this episode - Knak.
If you don't know them (you should), Knak is an amazing email and landing page builder that integrates directly with your marketing automation platform.
You set the brand guidelines and then give your users a building experience that’s slick, modern and beautiful. When they’re done, everything goes to your MAP at the push of a button.
What's more, it supports global teams, approval workflows, and it’s got your integrations. Click the link below to get a special offer just for my listeners.
Rich Archbold is VP of Engineering for GTM Systems at Hubspot. He is passionate about building and scaling high-performing, highly engaged teams that build and operate world-class, mission-critical technology products and services. Prior to Hubspot, he held business systems and engineering leadership roles at Intercom, Facebook, and Amazon.
https://www.linkedin.com/in/richardarchbold/
This November, MOps-Apalooza is back in sunny, Anaheim, California, and it's going to be the marketing ops event of the year, packed with hands-on learning from real practitioners.
This is the only truly community-led tech-agnostic MOPS conference out there. It's got the best speakers, the best networking, the best social events, and maybe even a trip to Disneyland. This isn't your 50,000 person tech company conference. It's an intimate gathering of folks who are in the trenches every day.
Registration is capped at 700 attendees, and tickets are going fast.
Visit the RevOps FM Substack for our weekly newsletter:
welcome to rev ops FM.
2
:Everyone today, we're going to take a
deep look at how to run go to market
3
:systems at enterprise scale and
even more exciting, we'll get a peek
4
:behind the scenes at one of the most
iconic tech companies around HubSpot.
5
:Today's guest is rich Archibald
VP engineering for GTM systems
6
:and automation at HubSpot.
7
:We're among other things.
8
:His team manages HubSpot's
own HubSpot implementation,
9
:FinTech and data engineering.
10
:Prior to HubSpot, Rich held engineering
and business systems leadership roles
11
:at companies like Intercom and Facebook.
12
:And Rich, I just have a ton
of questions for you today.
13
:So we're going to dive in and I'm really
appreciative of you coming on the show.
14
:Rich Archbold: Thanks Justin.
15
:I'm delighted to be here and as
I said offline, thank you so much
16
:for all of the content you put out.
17
:I am an avid listener of your
podcast and just find it so helpful.
18
:Justin Norris: Thank you so much.
19
:To start with maybe just a
little bit about your background.
20
:You've written about how you started
out, in more of an infrastructure
21
:backend engineering type of role.
22
:Transition to business systems.
23
:I'd love to understand from an
engineer's perspective, what kind of
24
:shock to the system did that provide?
25
:And what were some of the
learnings that you went through
26
:as you entered that field?
27
:Rich Archbold: so as you said, I
started off in backend infrastructure
28
:engineering and I think.
29
:I always loved solving hard, gnarly
scalability and operations challenges
30
:and didn't really mind if other people
didn't find them glamorous or if
31
:there wasn't a shiny front end set
of systems you needed to deal with.
32
:So perhaps it was kind of no surprise
that I Eventually made the move into
33
:business systems and go to market systems.
34
:It started out at Intercom, where at
the time we had a homegrown billing
35
:system that operated as an Integration
layer between Salesforce and Zora,
36
:and this was maybe 4 or 5 years ago.
37
:Now, when, I think we were making so many
changes to pricing and packaging at the
38
:time, and maybe how we had implemented
some of our usage based billing systems,
39
:uh, intercom just really didn't.
40
:integrate well with Zora at.
41
:we were having a lot of operational
challenges, scaling Zora and our CEO
42
:at the time said, Rich, you seem to
be good at fixing backend systems,
43
:any chance you could jump in and
take a look at our billing system.
44
:And that, really was the beginning
jump off point for me, diving into
45
:billing systems and realizing that
these are like fascinating, very
46
:difficult, Computational problems.
47
:there's real magic and innovation in
integrating between your pricing and
48
:packaging and somebody else's product
catalog and billing systems and learning
49
:how you need to match up data models and.
50
:found it absolutely fascinating.
51
:I incredibly difficult and just had a real
appreciation for the engineers and leaders
52
:who work in this space that there's,
there's just really valuable craft.
53
:I think, while the engineering work was
difficult, the more difficult thing was
54
:stakeholder management and understanding
who your internal customers are really
55
:being on that point of intersection
between oil and water, almost where
56
:you have, salespeople and sales that
really work to the quarter and have
57
:quarterly targets and have, like really
hard deadlines they need to hit and
58
:really, meaningful performance based
compensation that if they can't hit
59
:it, it's really materially impacts
them and engineers and product managers
60
:on the other side who operate to like
a much more gentle or longer term
61
:cadence and understanding the friction
that can happen when people don't.
62
:really understand each other,
and, don't really have the
63
:right empathy for each other.
64
:And that kind of human relationship
building and empathy and understanding of.
65
:Each side of the coin, I found every
bit as interesting and humbling
66
:as, the actual engineering work.
67
:And, over time, I grew to love the space.
68
:I like the.
69
:Breath of different people you
get to interact with and learn all
70
:different parts of the business.
71
:and progressively, then I moved from
leading our, teams in, owning, billing
72
:to when intercom hired its first CFO.
73
:I switched to report to the CFO to
build out are first ever centralized
74
:business systems function and run
go to market applications, which had
75
:salesforce marketo and intercom on
intercom, our billing team and also
76
:took over our data engineering teams.
77
:And again, that was just, So many
new things to learn that I'm really
78
:kind of motivated by learning,
and I love to learn new things.
79
:Some people would say they
have 20 years of experience.
80
:And I go, is that really 20 years?
81
:Or is it the same 1 year, 20 times over?
82
:And I try and kind of push myself to have
a new year of experience every time and
83
:getting to report to a CFO and having
all of, like, really Senior finance
84
:execs in your peer group was just a gift.
85
:Fascinating learning experience.
86
:Justin Norris: And you alluded a little
bit to the contrast between what you were
87
:doing in business systems and folks on the
product side, where you've got engineering
88
:teams and product management teams.
89
:And in that structure, every team's
a little bit different, but usually
90
:product management is kind of.
91
:The interface between, the customer
and business needs and then the
92
:engineering team who's responsible
for how do we bring this to life
93
:in a technically scalable way.
94
:And then in business systems, you
kind of have that stripped away.
95
:You're sort of judge, jury, and
execution are all wrapped up into
96
:one, so to speak, and that you've
got to interface with the business.
97
:You've got to define your requirement.
98
:You, don't have often that
separate product management layer.
99
:Was that.
100
:Disruptive for you at all?
101
:Or did you feel a gap not having
those functions surrounding him?
102
:Rich Archbold: Yes and no.
103
:You're right that it's totally different.
104
:And even if you do have PMs, while
those PMs share some common skill
105
:sets, how they approach their
job has to be very different.
106
:That if you're a PM, um, In core products
in HubSpot, you are building a product
107
:that is a good product market fit for
millions of SMBs, and if your product
108
:doesn't match 100 percent of the needs of
the customer, they still have the freedom
109
:to leverage their own engineering team
to buy or integrate a different solution.
110
:You don't have to do the last mile
Customer installation or professional
111
:services or customer support.
112
:You've dedicated teams for those.
113
:So it's really a, very specialized, very
long term, strategic thinking position,
114
:but when you operate as a PM of a business
systems team, you have one customer,
115
:usually an enterprise customer rather
than an SMB customer who you have to
116
:build 100 percent product market fit for.
117
:You need to do all of the professional
services, all of the customer support.
118
:You need to do absolutely
everything yourself.
119
:You find it very hard to say no,
because that customer you have a
120
:real personal relationship with
and that customer generally.
121
:Doesn't have the luxury or you actually
really don't want them to have the
122
:luxury of going out and hiring some
other consultant or hiring some
123
:other people because that leads to
fragmentation, collaboration tax,
124
:that's kind of how, you
know, you're failing.
125
:It's not whether your customer is like
telling you, you're doing a great job.
126
:It's whether they've gone off and
spun up a shadow it, function or.
127
:or.
128
:not, so I think the 2 roles are, I
mean, obviously, there's a lot of
129
:commonalities, where, you aren't
doing a Coupa implementation project.
130
:What you're actually doing is a
procure to pay efficiency project.
131
:And so you need to make sure that
you understand who is the customer?
132
:what is the business problem?
133
:What is the ROI?
134
:and don't get over focused on.
135
:Implementing any 1 particular
technology or other.
136
:So I think that's where those are some
of the, I mean, you need to be really
137
:great at communication and have great
empathy and great, problem solving skills.
138
:But, yeah, I think the 2 roles are quite
different in the go to market space.
139
:I think, that's really what we look
to have our best BSAs, step in and
140
:kind of perform that role where the
best BSAs are, part project manager,
141
:part systems administrator, part
systems integrator, part customer
142
:support, part solutions engineer.
143
:And, BSAs I've worked with, they
really, Look and feel like, a very
144
:operationally focused, product
145
:Justin Norris: And just in case that
acronym isn't transparent for anyone,
146
:BSA equals business systems analyst.
147
:Rich Archbold: Yeah,
business systems analysts.
148
:Like, I've seen multiple archetypes where
some business systems analysts will lean
149
:more on the, product owner or Product
manager, almost like a program manager
150
:archetype, and some will lean more towards
the systems engineer, solution engineer,
151
:integrations engineer, where they're
really adept at being able to configure or
152
:maximize a particular service or leverage,
integration technology, like Workado.
153
:So they're almost more like solutions.
154
:engineers, and I think it can be
very difficult when you're in a very
155
:small environment, you want your to
be able to do all of those things.
156
:But the bigger you get, it can be
sometimes difficult to have, like, you
157
:want to have some amount of Swiss army
knife, business systems analysts that
158
:can really jump in and do anything.
159
:But I think once you reach a certain
point, that's where you need to
160
:think about, do I actually need, A
Swiss army knife, business systems
161
:analyst, or do I need a dedicated
internal go to market product manager.
162
:And I think at HubSpot today, we're, I'd
say we're almost like 90, 10 or 80, 20
163
:in favor of each of our individual teams
are generally led by a product manager.
164
:And we do have some amounts of
amazingly fungible, business systems
165
:analysts who are really are the.
166
:glue in a lot of different projects
where they're able to participate in many
167
:different ways at many different levels,
depending on the project that is at hand.
168
:Justin Norris: so maybe digging
a little bit deeper than into
169
:your team and its structure,
where does it sit within HubSpot?
170
:Is it rolling up into like an it function?
171
:Is it connected to different
functional areas that you support?
172
:How does that structure work?
173
:Rich Archbold: So, today we roll up
through the, Product organization,
174
:so the R and D arm as such.
175
:So I have a product partner who rolls
up through our head of product and
176
:I myself roll up through our CTO.
177
:But for me, I always think I have many
bosses that I, like, I feel equally
178
:accountable to our head of sales, head
of marketing, head of support, our CFO.
179
:And, while the CTO is my manager, it's
great that, like, I certainly report to
180
:him from an engineering quality and from
an engineering execution perspective,
181
:but I need to make sure this is such a
highly cross functional space with, so
182
:many different, uh, leaders involved that
you really have to consider yourself.
183
:You are accountable to the, companies
go to market leadership team.
184
:Justin Norris: And when you say
you have a product, partner,
185
:tell us about that relationship.
186
:Like, how does that work?
187
:Rich Archbold: Yeah, so I have a
product partner, Kitty Chu, who is
188
:based in Seattle and Kitty and I, so
our mission is to help bring HubSpot's
189
:go to market strategy to life.
190
:And so the, 2 of us will
partner with each of the various
191
:different go to market leaders to.
192
:Understand what the company's go to market
strategy is, how it's going to be evolving
193
:each year and then use that to break down.
194
:what are the big rock projects?
195
:We need to get our teams
to execute in each of the
196
:different parts of the business.
197
:As I said, each of the
teams generally have, uh.
198
:Product manager, uh, designer and an
engineer and all of the product people
199
:roll up through my product partner and all
of the engineering people roll up through
200
:me.
201
:Justin Norris: Got it.
202
:So it really is structured in a lot
of ways, like an externally facing
203
:product team would be with engineering
204
:product
205
:Rich Archbold: very much so.
206
:And we share a lot of the same core
values around solving for the customer
207
:and making sure that we're, thinking
long term and that we're building really
208
:high quality into the product services,
workflows and data that we generate.
209
:Justin Norris: So kind of traveling
down the tree, if you like, of,
210
:your org structure, beneath you
and kitty, how do you structure
211
:those different groups or pods?
212
:Are they around systems or are they
around the go to market teams or
213
:what does that structure look like?
214
:Rich Archbold: we try and set up
our teams to, try and generate
215
:relatively clean relationships
with each of our key stakeholders.
216
:So there's a marketing focused
team or a marketing focused group.
217
:There's a sales focused group.
218
:There is a customer support
and success focused group.
219
:There's a partner focused group.
220
:And then we have a shared kind
of CRM, data, focused, function.
221
:As well.
222
:And then as I said, we have our
FinTech, function, which is kind of
223
:like our own homegrown, uh, pricing and
packaging, CPQ billing invoicing and,
224
:some of our finance systems, functions.
225
:And all of those individual groups or
teams at various different layers would
226
:have a product management leader, uh,
design leader, and an engineering leader.
227
:And we have this concept
of what we call interlock.
228
:So this would be, a set of regularly
occurring meetings where you'd
229
:have members from, like, the go to
market systems function and their
230
:relevant counterparts in, rev ops
or, the various different in field
231
:leadership functions, like a sales
leader or a marketing leader or, uh.
232
:support leader, and we, kind of realized
that this is like a fast moving space.
233
:It's very cross functional.
234
:we have a concept of hashtag 1 team
that even though we all roll up to
235
:different leaders, you have to think of
yourself as like 1 cross functional team.
236
:It's up to you all to make
the decisions and make sure
237
:that there's minimal friction.
238
:Between Rev Ops and engineering or Rev
Ops and product or sales and Rev Ops, we
239
:try and think of ourselves as just one,
cross functional team, working together
240
:to help bring our go to market strategy to
241
:Justin Norris: life.
242
:And in a smaller organization, a lot of
the systems ownership, you know, usually
243
:lives within RebOps or marketing ops,
you know, this functional ops teams.
244
:Um, How do you think about the
roles and responsibilities with your
245
:group and then the rev ops function?
246
:Like what do they do?
247
:They're a stakeholder of yours.
248
:I am assuming.
249
:but how do those lines
of responsibility flow,
250
:Rich Archbold: that's a great question.
251
:And what I think of the Product teams that
roll up through me as much as possible.
252
:We're trying to build systems and
build functions that allow RevOps
253
:to have the right level of agency
and control and configuration.
254
:We actually want them to be able
to move fast and experiment.
255
:And so I think about it as like
trying to keep the cycle times.
256
:Low and keep the agility high.
257
:So in each of our rev ops teams, we do
have some that have hands on ability
258
:to make changes or have some work out
our skill sets to, do some last mile
259
:Automation and, customization, know,
I've been, I've seen organizations
260
:in the past where, people try and
put every single thing inside of
261
:that single business systems function
or single sales systems function.
262
:And I think, I've seen the cycle
times be too high, around that.
263
:And I think you really need to strive
to give the business the right level
264
:of agility and control over the
things that are happening day to day.
265
:And if there's a small change that.
266
:Can be made, you want it made as close
as possible to the person requesting it.
267
:And I think that's why we have
powerful, easy to use platforms
268
:like CRM platforms, right?
269
:Like that, I, I think that
is some of the value of it.
270
:So I definitely do like the.
271
:Centralized teams to a certain extent,
because I think that removes some
272
:siloing and allows you to make bigger,
bolder decisions more, quickly.
273
:It allows you to stay focused on customer
problems rather than parts of a process.
274
:But I also think it's just really
important that the business feels like
275
:they are beholden to you for every
single change they want to make, that
276
:they will have the right context.
277
:you just want to be able to have
the shortest possible cycle times
278
:for, the categories of change
that, that actually makes sense
279
:for.
280
:Justin Norris: what you just mentioned
to me addresses what I've observed.
281
:And also what I think is generally
perceived as the major risk and
282
:shortcoming of the centralized team
is that you essentially recreate
283
:the it dynamic where it's like.
284
:A big queue of tickets, it's
sort of this fortress mentality.
285
:They're pushing away work We'll see you
in three months and of course that's what
286
:leads to the the shadow it cropping up
again or the consultants or we just have
287
:to do it on the side i've also seen to
your point that you know inevitably folks
288
:that are coming up through operations
that don't necessarily have like Maybe
289
:they develop systems expertise, but
it isn't necessarily their background
290
:You Eventually when you're thinking
about an enterprise architecture vision
291
:you go beyond what those folks are
able to accomplish at least without
292
:Further upskilling and you really do
get into a much more technical domain
293
:So it seems like you have this sweet
spot dynamic setup do you feel that?
294
:This is just inevitable that, you know,
once you pass, I don't know what it is, 5,
295
:000 employees for, I don't know, whatever
the number is that you have to kind
296
:of have a centralized business systems
function, or do you think that you can
297
:just have functional ownership of tools,
you know, within ops teams in perpetuity,
298
:Rich Archbold: You know, the answer is,
I think it depends, if you have a, a
299
:relatively simple and stable, business
model, and you're not making a lot of
300
:changes to your go to market strategy, I
think you can keep things simple and keep
301
:functional ownership, as long as you can.
302
:But I do think there's certainly a
level of change that happens, a tipping
303
:point of complexity or tipping point
of change where you actually can't make
304
:changes in isolation, where if we're
going to start selling a new product,
305
:we need a new skew in salesforce.
306
:We need to be able to meet her.
307
:It's usage in a new, different way.
308
:In our billing system, we need to be
able to account for revenue and in.
309
:In a different way inside
of our Rev Rec system.
310
:It's going to mean different
product usage data flowing into
311
:our customer success platform.
312
:I'm going to mean that we try and drive
cross sell upsell renewal a different way.
313
:I think it's really hard to implement
those type of transformational projects
314
:or really big step function projects
without some sort of, central governance
315
:or, architecture and, management.
316
:So I think, yeah, you just kind of reach a
tipping point of complexity where it makes
317
:sense to have a more centralized function.
318
:But, That doesn't mean that every time
you want to add a new field inside of the
319
:CRM, it needs to go to that centralized
team either, though, you know, I think
320
:that that's where I mean, there's some
some types of changes where you really
321
:want to make sure the teams closest
to the problem have the right level
322
:of agency and autonomy over solving
323
:them.
324
:Justin Norris: a bit of a, like
a hub and spoke model, if you
325
:want to think about it that
326
:Rich Archbold: exactly.
327
:Justin Norris: Yeah, no, that
makes makes perfect sense.
328
:Let's talk a little bit about
your stack, which is kind of
329
:a fun thing to think about.
330
:I presume HubSpot's in there somewhere.
331
:what else are you folks using?
332
:Rich Archbold: definitely HubSpot is
pretty much the center of everything and
333
:we're a massive, marketing hub, sales hub,
service hub, and, HubSpot CRM platform.
334
:we use a lot of our own CRM UI extension
capabilities in order to build the spoke
335
:and tailored experiences inside of HubSpot
and customize the views we provide to,
336
:each of our different reps and our PMs
and designers spend a lot of time talking
337
:to our internal stakeholders to make
sure we're tailoring those correctly.
338
:one of the.
339
:More interesting ones that we've
launched recently was using our
340
:own prospecting workspace to help
organize the, prospecting layout and,
341
:uh, and tool tips that We provide
to our reps and adoption for that.
342
:And engagement with that has
been, very high from A CPQ.
343
:And, and, billing and invoicing
perspective, a lot of that
344
:is custom to ourselves.
345
:And we have, uh, quite an artisanal
set of, processes and capabilities.
346
:And that's something that
our, FinTech organization
347
:takes care of on the back end.
348
:We use NetSuite, from a, call
recording and coaching perspective.
349
:We use Gong and are, and
we are big fans of Gong.
350
:We think that's a great product as well.
351
:from a.
352
:Data engineering.
353
:So from an analytical data perspective,
all of our data flows into snowflake.
354
:We're, big fans of dbt and, looker
and airflow from, uh, an automation
355
:and, data plumbing perspective,
Yeah, curious, what else, are you
356
:you mentioned WorkAuto
a few times as well.
357
:Yeah, so Workado, we're, we're
massive, massive fans of Workado.
358
:And, use, that as our
last mile automation.
359
:And, in some cases,
integration technology.
360
:And, you know, our teams have built some
really novel, Automation on top of that.
361
:And I've used it to, create some hooks
into chat GPT and, yeah, just some really
362
:interesting use cases there as well.
363
:I come from, the Marketo space, you
know, traditionally, although I've
364
:always been a HubSpot respecter, but
the conventional wisdom, let's say
365
:on the street, at least in Marketo
circles, it's sort of like HubSpot.
366
:Yeah, it's good.
367
:But you know, you might reach a point
where you can't scale it and you're going
368
:to need to migrate to, and same thing,
I guess, with the CRM to Salesforce.
369
:Here you are obviously
a very large enterprise.
370
:Uh, using HubSpot for both
CRM and marketing automation.
371
:how would you respond?
372
:Let's say if someone proposed that
point of view to you, like, yeah,
373
:it won't necessarily scale with you.
374
:Like you've scaled it.
375
:what are your thoughts on them?
376
:I think that's wrong.
377
:so I've come from a world of, so at
Intercom I use Salesforce and, Marketo,
378
:and I would say the bane of my life was
dealing with, you know, Duplicate leads
379
:in, Marketo to, HubSpot, uh, syncs and
bottlenecks and integration and having
380
:to deal with multi enrichment challenges
between, Marketo and Salesforce and trying
381
:to implement ring lead as a solution
to try and have, centralized enrichment
382
:and account management and survivorship.
383
:But, when, I left Intercom, I wanted to
go to HubSpot because I felt like they
384
:had it all sorted out and I wanted to
have one single stack that everything,
385
:was there and present with a single
consistent data model that I could have
386
:marketing and sales, both used together.
387
:Didn't have to deal with
any integration challenges.
388
:It was just all there natively.
389
:And now I'm living in the
promised land, you know, it works.
390
:And so there's a whole
degree of challenges that,
391
:I didn't have to deal with.
392
:that now I don't have to deal
with because I have that seamless
393
:integration and the partnership between
marketing and sales and the handle.
394
:I mean, you're working in the go to market
world for a while and you go, what are
395
:some of your hard fought lessons learned?
396
:Handoffs between teams and tools is like
where all of the friction is, going to
397
:happen is where a lot of the data quality
issues, where a lot of the scalability
398
:bottlenecks are going to happen.
399
:It's going to make problems twice as hard.
400
:I don't have to deal with that.
401
:You know, I've got everybody in the
one platform with a shared data model.
402
:They've got the same source of truth.
403
:That does, sound nice.
404
:let's think about, innovation
on the platform in general.
405
:I assume you've had to push the
boundaries in some cases to.
406
:You know, solve interesting
challenges that you've had.
407
:What are just some cool things, I guess,
that you're doing on your own platform
408
:that might be interesting to folks,
409
:as I said, probably the most fun for
us at the moment is that prospecting
410
:workspace and feels like we have, you
know, we're really able to, partner deeply
411
:with our reps and understand what is the
absolute ideal workflow you want to have.
412
:Like we can do lots of rep shadowing
and really build that empathy for our
413
:reps and go where do you wish you had?
414
:what's your ideal layout here?
415
:How would you like
things to be prioritized?
416
:if you could wave a magic wand,
how would this work for you?
417
:And the HubSpots, prospecting
workspace layout, and then the CRM,
418
:UI capabilities give us the ability
to really bring that to life.
419
:Pretty quickly and easily, which has
been, just wonderful to see, I guess.
420
:I'm just trying to think of, like, some
of the other things that we're that
421
:we're doing that
422
:maybe just on the, on the prospector
workspace, because I'm super interested
423
:in that feature and I've, I've read a
bit about it, but let me just tell you,
424
:give you my read on what I think it is.
425
:You can tell me if I'm right or not,
but it kind of solves that perennial
426
:challenge of, you know, I've got one lead
or contact or person record, whatever we
427
:call it within that system's nomenclature.
428
:but that person may go through a buying
process or a funnel trip Multiple times,
429
:and it's very difficult to, report on
that, to capture that because the data
430
:model is, kind of one dimensional.
431
:And so the prospecting workspace sort
of introduces this idea of many, I
432
:don't know if you call them leads or
what they're called exactly, but many
433
:different entities that can relate
to that single person that represent
434
:those iterative buying journeys.
435
:is that what it is?
436
:the problem, that we use it to solve is
437
:slightly different.
438
:And the way I describe the problem
is I'm a sales rep and I have
439
:hundreds of companies under my name.
440
:And, some of these companies are,
already customers and I need to, Think
441
:about account management and account
maintenance and cross sell upsell.
442
:Some of them are cold prospects,
and some of them are warm prospects.
443
:And I've got hundreds of these
inside of my capacity like that
444
:are assigned to me and every day.
445
:I need to come in and figure
out what's the best way for
446
:me to spend my time today.
447
:there's undoubtedly been.
448
:Maybe a lot of signals that have happened.
449
:Maybe there's been new enrichment events,
or, new activities on our marketing sites
450
:that might have contributed to events.
451
:Maybe the companies that are actually
customers of mine, there's been
452
:some new usage data that has flowed
into the system and I'm a rep with.
453
:to meet what should I do today?
454
:And so what we use our prospecting
workspace is a way to, break up the
455
:companies segment, the companies that
reps own into kind of like cold, warm,
456
:maybe hot, existing customers then we
can use various different types of,
457
:machine learning models in the background.
458
:To help prioritize the activities for the
rep and make it transparent to the rep why
459
:we have prioritized different things in.
460
:Different ways to just make it much
easier for the rep when they come in
461
:in the morning, not to be hit with,
just a search list of here are hundreds
462
:of companies that you are responsible
for looking after and for them having
463
:to think about lots of searching and
filtering to actually come in with a
464
:beautiful, tailored, high quality, UI
that, fits natively inside of HubSpot,
465
:where there has been a lot of, you know,
thoughtful engineering in the background
466
:to make sure that we're showing them the.
467
:Most actionable things for them to
do and making it easy for them to
468
:understand why
469
:Justin Norris: Got it.
470
:So it's more about prioritization,
sort of task management or activity
471
:management and, uh, and directing them.
472
:And you've alluded a few times to the
UI customization capabilities, and I'll
473
:confess, I'm, I'm a little bit ignorant,
actually, of HubSpot's capabilities in
474
:this area are actually a lot ignorant.
475
:what can you tell me?
476
:Is it akin to like a Salesforce
lightning page layout or like a
477
:Rich Archbold: very much.
478
:So yeah, very much.
479
:So, so like a lot of the flexibility
and customization you have with that,
480
:there's lots of kind of like low
code ways that you can customize it,
481
:but we can go as far as embedding an
iframe directly inside of a particular
482
:portion of one of those windows.
483
:And that can.
484
:Be backed by some of our own, fully
bespoke and custom built, web applications
485
:that our own quoting experience being
one of those examples of where we
486
:can embed, uh, our own custom CPQ
application directly inside of the
487
:HubSpot
488
:app.
489
:one of the The great things about
this and one of our, I guess,
490
:overriding philosophies is that
we ask our reps every quarter.
491
:How do you feel about the
amount of tools you have to use?
492
:you want to keep reps on the
same pane of glass inside of the
493
:same app as much as possible.
494
:You want to have, Unified data
models inside of your CRM.
495
:So this is one of those things
that we consistently look at is
496
:how many different applications
are we asking our reps to work in?
497
:How can we cut that down?
498
:Is there something else that we can
move natively inside of the HubSpot
499
:app and that we can have the data,
uh, authoritatively stored for
500
:directly inside of HubSpot as well?
501
:because if it is a rep
productivity is improved.
502
:The amount of context switching they
do is minimized, but also having that
503
:data, source of truth inside of the
CRM in a nested custom object format
504
:allows all of our work out of folks
to generate additional, last mile.
505
:Automation and, customization in, um, kind
of safe and scalable way then as well.
506
:Justin Norris: Let's dive
into that one a little bit.
507
:I'm also a big fan of work.
508
:Um, how do you think about it
from a roles and responsibilities
509
:point of view within the stack?
510
:Like when might you use HubSpot's internal
automation capabilities, if at all, versus
511
:saying this is where we need to layer in
a work order recipe to achieve a goal.
512
:Rich Archbold: so I think that work
was a great tool for ops teams.
513
:To use to automate their workflows,
I think when you're doing anything
514
:that HubSpot customer scale, that's
actually going to scale with the
515
:amount of customers that we have.
516
:It's kind of hard to use, uh,
work just from a cost perspective.
517
:If you're doing something that's
going to be running, you know,
518
:hundreds of thousands times a day,
growing at scale with our customers.
519
:And those are the things that, Generally,
we would use more scalable software for.
520
:I also think you get beyond
the level of complexity.
521
:Like, Ricardo is great for automating
things, but it's really hard to do.
522
:Unit testing or integration testing,
there's kind of like a size of complexity
523
:that once you actually go beyond it, maybe
you want to use some more traditional
524
:software engineering processes and
best practices for, but I think it's
525
:a great tool for ops teams to use to.
526
:Automate their processes and
yeah, if you're operating at a
527
:smaller scale, I think it's fine.
528
:I think it's a great integration tool.
529
:I generally do believe in that.
530
:citizen automator model Work auto use,
but I just think there's a point of scale
531
:and complexity where it makes sense, both
from a financial perspective and also from
532
:a scalability and operational excellence
perspective That you will want to convert
533
:it into software, but we would often start
with, hey, we have this idea for something
534
:that we think might be valuable to reps.
535
:Let's build it as a prototype in workado
and roll it out to a subset of our reps.
536
:And if it proves valuable, then we can.
537
:think about scaling it up and turning it
into a fully fledged software solution.
538
:So it ends up being like a really
valuable prototyping and fast
539
:paced prototyping tool for us
540
:Justin Norris: I had a fascinating
conversation with a fellow
541
:named Niles Fote, from Trey.
542
:so we're Cotto's competitor, but, using
Trey as part of their go to market.
543
:And he, uh, has developed a
fairly sophisticated model where
544
:it kind of all their, lifecycle
processing is happening in Trey.
545
:So they're doing like the
event capture from the website.
546
:All of that sort of
enrichment scoring MQL stuff.
547
:And just, I thought made a compelling
case around why that was more scalable
548
:and, um, overcame some of the limitations
that you get, like with, you know,
549
:in Marketo, you're capturing fields
onto the person objects, so it can be
550
:really hard to manage race conditions
because those events can get overwritten
551
:before other processing happens.
552
:There's like a limit,
beyond which you can't go.
553
:What are your thoughts about that?
554
:Or maybe just tell us a
bit more how you run that.
555
:call it operational
backbone of your system.
556
:Are you doing that in HubSpot
or have you written sort of
557
:your own software for that?
558
:How does it work?
559
:Rich Archbold: so we have a homegrown
bespoke lead pipeline system, given
560
:the, given the scale that we're at.
561
:And so we have some custom software
that allows us to capture All of
562
:those events and send them through
a homegrown enrichment territory
563
:assignments, and, routing system.
564
:And so that really is all
homegrown custom software for us.
565
:And we have various different levels of
operational dashboards, and pay, like,
566
:a lot of attention to making sure that.
567
:A lead that enters the system
actually gets routed to, a rep,
568
:and we pay a lot of attention to
when it actually gets to the rep.
569
:Did the rep think it was a good lead
or did they end up disqualifying it?
570
:Because some of the.
571
:Enrichment data didn't seem like it
was right, or some of the segmentation
572
:data, or some of the territory data,
or, that's some of the things that we
573
:thought made it actually a qualified
lead actually weren't a qualified lead.
574
:And those are some of the metrics
that I paid most attention
575
:to, to be honest with you.
576
:I looked to see, did the
process from capturing the lead.
577
:To qualifying it and getting
it in the hands of the rep.
578
:What did the rep think?
579
:Did the rep think it was good or bad?
580
:And why not?
581
:And like, are they policy issues
or are they software issues?
582
:And for the ones that are software
issues, do we make sure that we have
583
:the right teams thinking about, how to
improve our enrichment systems or how
584
:to improve our segmentation systems or
how to improve our assignment systems.
585
:And for ones that are policy
issues, are we making sure that
586
:we're giving that feedback?
587
:And that the ops teams are getting all
that feedback, do they feel like they have
588
:the right configuration tools out there?
589
:and do they feel they have the
right agency to make changes to
590
:tweak things that they want, or
are those features, We need to
591
:build,
592
:Justin Norris: that makes perfect sense
and you've alluded to data a number of
593
:times that's also within your purview So
maybe we'll turn to that This is a broad
594
:question, but how do you think about data
strategy at the scale that you're at?
595
:Like, what are the sorts of first
level concerns that you're dealing with
596
:when you think about HubSpot's data?
597
:Rich Archbold: I
598
:think it's the most important thing.
599
:and again, if you said to me, what
are some of those hard fought lessons
600
:learned that you pick up as you go
from working in infrastructure to
601
:working in, the go to market world.
602
:I think as a product person, as
an engineer that builds a products
603
:for customers to buy, you generally
take data quality for granted and
604
:you focus on building features.
605
:you have full control
of all of the databases.
606
:You've got to pick the
database technology.
607
:if it's my SQL, you can rely on nice,
clean, simple, my SQL replication,
608
:or even if you need to stream it into
some other sort of a search, elastic
609
:search database, there's like nice
clean patterns for doing that, and
610
:you're all about building features.
611
:And then when you come into the go to
market world, you realize it's the exact
612
:opposite You get to buy your features.
613
:HubSpot is going to give you features.
614
:Salesforce is going to give you features.
615
:Marketo is going to give you features.
616
:You need to build your data.
617
:you're actually, the more systems you
have, you end up with a heterogeneous
618
:multi master database replication system
with, no good consistency checking.
619
:And so you've multiple sources of truth,
data replicating, left, right, and center.
620
:it's a native integration here,
and then it's a workato integration
621
:over there, and they're all point
in time integrations, and nobody's
622
:written a data checking thing.
623
:there's no, primary keys anywhere,
there's duplicates all over
624
:the place, and you're going.
625
:Well, you have a new, B2B SaaS
software rep going to sell you some
626
:new features to solve your problem,
and so people will sell you features.
627
:You can buy your features.
628
:Features are not the problem.
629
:The problem is the data quality.
630
:and so that's where I spend, again, and.
631
:Inordinate amount of my time, thinking
about, how do I make sure people
632
:understand the hierarchy of needs of data
and that my company object is the single
633
:most important thing I need to have good
governance and quality over followed
634
:closely by my contact object as my, as
my 2nd, most important thing and then
635
:flowing down to deals or opportunities
and then select contracts or.
636
:Subscriptions to invoices and
understanding that hierarchy of of
637
:data and making sure that we have.
638
:Some sort of a governance process on
each, like the, Schema management of
639
:each of those different core objects
that we have some semblance of what does
640
:good mean for each of the attributes?
641
:Inside of these individual objects.
642
:So, like, how do we uniquely
identify a company or an account?
643
:And do we have the right semantic
and syntactic safeguards in place
644
:to make sure that that remains?
645
:A unique identifier.
646
:how do we think about company size?
647
:if we are enriching a company
from 7 different sources, how
648
:do we think about survivorship
rules around each of these things?
649
:How do we think about
hiding the mess from reps?
650
:So that reps only see 1 value rather than
the 7 values, but they have the right
651
:level of, lineage and discoverability.
652
:So.
653
:Even though we're only showing them
one they know why it's only one.
654
:and so, yeah, I spend a massive amount of
my time thinking about and evangelizing,
655
:operational data quality inside of
our CRM and making sure that each of
656
:the different groups and teams are.
657
:Thinking about it, that we've got
the right schema management strategy,
658
:that we've got the right data
ingestion strategy, that we've got
659
:the right data, processing strategy,
that we've got the right safeguards
660
:along the way, that all of this.
661
:It's so easy to get caught up in
data quality for data quality's sake.
662
:And you're like, I do, data quality.
663
:No, you're here to help the company
bring its go to market strategy to
664
:life, which means reps doing their jobs.
665
:That's what you're here to do.
666
:And one element of it is you
need to keep the data, right.
667
:So that all of that can happen.
668
:And so you can get caught
up in a world of like where.
669
:Data quality, I'm going
to remove some duplicates.
670
:And you go, well, you could remove
75 percent of the duplicates, but it
671
:could have zero impact on a reps, work.
672
:And so you need to be talking
to your reps and talking to your
673
:RevOps leaders and go, whereabouts
are you feeling your pain points?
674
:And where do you think, Is your problem,
generating net new business is your
675
:problem doing cross sell upsell?
676
:Is your problem doing forecast accuracy?
677
:is your problem, doing life
cycle marketing because you don't
678
:have enough product usage data?
679
:where's your problems?
680
:I'm here to solve your problems.
681
:And odds are there's a CRM data
quality challenge in there that
682
:we're going to need to figure out.
683
:But yeah, just making sure that.
684
:Whatever we do is in service
of those, business problems and
685
:business opportunities rather
than, polishing our data quality
686
:because you can spend forever.
687
:You can spend
688
:all of your
689
:time
690
:Justin Norris: And it's never
691
:Rich Archbold: CRM data
692
:quality and it's never done.
693
:and it's never right.
694
:but we're not here to generate
good data quality we're here
695
:to, delight our customers and.
696
:generate leverage for the business
and we focus on those two things
697
:first and data quality is a means to
698
:an end.
699
:Justin Norris: feel like we could do
a whole show just on data because,
700
:yeah, there's so much in what you
just described, both in terms of
701
:the current state of things and
mess that we generally all inhabit.
702
:and accept as normal and the
different things that you can do to
703
:try to mitigate that just for fun.
704
:I want to double click on maybe just
one of them to see how you solve for it.
705
:Tactically you mentioned about like
the data lineage and you might have,
706
:you know, seven different, data
sources for a particular data point.
707
:you have some means of, Consolidating
that, displaying only one to the
708
:rep, but in the background you can
still track what you got and from
709
:where, like how do you solve that
specific problem, to take an example.
710
:Rich Archbold: probably maybe the most
applicable way was, how we were solving
711
:it at Intercom and how we were bringing
in, ring lead, or I think like zoom
712
:info ops OS, what we were able to do
was plug in multiple enrichment sources
713
:into ring lead and program some pretty
complex survivorship rules for these
714
:things that then, ultimately updated
this, single field in Salesforce.
715
:And we could say, like survivorship
rules of where you have linked in data.
716
:Um, Always use linkedin data where
you don't have linkedin data if
717
:you have, let's say zoom info
data and some other data provider.
718
:And if it's in North America default to,
zoom info, but if it is in Europe default
719
:to luscia, Data, let's say, like, I don't
think there's any, 1 size fits all here.
720
:The different data providers will
have different strengths in different
721
:regions and different segments.
722
:I think that the key thing is,
you've got to keep talking to your
723
:reps and getting feedback from reps
on what's actually working well for
724
:them and what's not working for them.
725
:I think that, the secret for me, or the
key is that you're, rarely ever going
726
:to have somebody articulate to you.
727
:Hey, your priority zero
problem is CRM data quality.
728
:You need to go and, I'm going to
allow you down tools and not integrate
729
:any new software for me or not build
any new workflows for me and just
730
:go spend 80 percent of your time
cleaning up the data inside of our CRM.
731
:that's pretty much never going to happen.
732
:And.
733
:Okay.
734
:If you don't know any better, or
if you haven't done up the battle
735
:scars, it's very easy to listen
to your internal stakeholders.
736
:And they'll say, I want this tool.
737
:I want this workflow.
738
:I want you to launch this product.
739
:I want this new enablement source
and you end up spending 120 percent
740
:of your time, adding new to the
system and adding new complexity.
741
:Quickly, as you can, and that's
the path to getting out of control.
742
:And I think that the real secret to us
is having the conviction to know that,
743
:this is where you're going to go wrong.
744
:You're going to go wrong.
745
:If you're not constantly gardening
and gatekeeping, uh, some of the data
746
:inside of the CRM that you aren't, um.
747
:Preaching this to your team that you
aren't putting those guardrail metrics in
748
:place that allows you to get a sense of.
749
:this is kind of how good or bad it is that
you're continuously talking to reps and
750
:that you're listening out for these type
of keywords, that were, and you're able to
751
:tie it back to, I'm hearing data quality,
but it's actually a prospecting thing.
752
:I can now go sell it to the business
and go, Hey, here's how we can improve
753
:prospecting, or here's how we can
move the numbers you care about.
754
:it's by investing In this thing, and I
think as engineering leaders, it's up
755
:to us to champion that and to have that
mindset and to not, unknowingly, walk
756
:ourselves into a corner of not necessarily
technical debt, but Data debt, I think,
757
:again, if you're building products for
external customers, you're all about
758
:the technical data and know that like
software isn't being properly reused.
759
:And we need to take the time to
refactor this software so that
760
:we're carrying less software.
761
:I think the same is true
in the go to market world.
762
:It's in the data space.
763
:It's like, are we taking the time to
refactor our, data, eliminate data
764
:that's now duplicate or unnecessary.
765
:And for me, difference between
building product and building go
766
:to market is just a role reversal.
767
:One, you build products, the
other is that you build data so,
768
:that you can buy your features.
769
:Justin Norris: And maybe the last
question we have time for, but you've
770
:mentioned a few times about, this
push and pull with your stakeholders,
771
:identifying what work you need to do.
772
:figuring out your priorities.
773
:I think this is perhaps the most
challenging and an important job, you
774
:know, for any leader in the space.
775
:Cause if you make the wrong
decisions, all the other work
776
:downstream, loses its impact.
777
:How do you think about that problem?
778
:how do you manage it?
779
:Rich Archbold: I think you're right.
780
:I think it is one of the hardest things.
781
:so at HubSpot, we have an excellent annual
planning process that happens each year,
782
:which, that's where we kind of set out
a lot of our, uh, Big rock goals, and we
783
:try and make sure we're generally hyper
aligned with our business stakeholders
784
:on what are the biggest strategic needle
moving projects that we need to do.
785
:And we make sure that we set
aside capacity for those things.
786
:But we also know the business is,
agile, the world changes around
787
:us, and we need to be nimble
and responsive to those changes.
788
:the first port of call for being
able to be nimble and agile to those
789
:changes is those, technical BSAs
that we have embedded inside of rev
790
:ops, who we're continuously trying to
build features and capabilities that.
791
:they can tweak and respond to.
792
:We also have work that enables us
to, deliver some amount of agile
793
:automation, in that manner as well.
794
:And then we have our.
795
:Various different interlock meetings,
our sales interlock, our support
796
:partner interlock where we have
an ongoing intake process where,
797
:people could submit new requests.
798
:And we review those interlock
meetings are happening on a
799
:bi weekly basis at the moment.
800
:I'd love to say they're frictionless,
but they're not, sometimes we will
801
:discover dependencies that we didn't
realize we had, or dependencies that
802
:were maybe bigger than we thought.
803
:Um, we need to adapt to them.
804
:it's, definitely not always perfect,
but, some of the really interesting
805
:things are, What do you do when sales
ops wants to do one thing, but your
806
:reps want to do something else or maybe
the priorities aren't quite aligned
807
:where the reps will obviously be the
ones to see the paper cuts and the
808
:friction with the existing processes.
809
:They all like.
810
:See and feel them every single day,
every single deal they work, whereas
811
:the, sales ops or rev ops folks
might be 1 step removed from that.
812
:And they're, more hyper focused on the
bigger swing, strategy plays or supporting
813
:some of the new product launches or
supporting maybe a bigger Segmentation
814
:change or something like that.
815
:And that's actually where it
gets really interesting for me,
816
:where your first desire is, I
want to make those reps happier.
817
:I want to fix those paper cuts for
those reps, but maybe it's the same
818
:group of people that would be working
on executing the larger strategic
819
:project, those are the really tough ones.
820
:the philosophy I preach is to try
and set aside, no more than 70
821
:percent of your capacity for your,
Big rock strategic goals and leave
822
:30 percent of your capacity, free to
respond throughout the year and to.
823
:Address those paper cuts.
824
:And then my other tip, is, the more
closely you can connect your engineering
825
:teams and your systems teams to the reps,
the more rep shadowing you do, the more
826
:empathy you can build with those reps.
827
:The teams will just find a way to
go, Oh yeah, we know these people.
828
:We're talking to them a lot.
829
:We know they're feeling this pain.
830
:We'll find something that we'll find
a way to address some element of it.
831
:Just so it's not a sharp, but if
you say we're primarily here to
832
:execute the strategy, but we measure
the rep friction and we really
833
:care about rep friction as well.
834
:and you set aside some capacity for it
and you get, The engineers and the PMs
835
:and the designers meeting regularly with
the reps, everything just gets easier.
836
:That's the secret, the closer you get
to reps, the more rep shadowing you
837
:can do without actually getting in the
way, the more empathy you can develop,
838
:for them, the more you can help see
around corners and fix things before
839
:they break or fix things before you're
840
:even
841
:asked
842
:to.
843
:Justin Norris: It's knowing
your customer, you know, right?
844
:Rich Archbold: 100%,
845
:Justin Norris: closer you are to
your customer, more empathy you
846
:have, the more you'll intuitively
be drawn to fix those problems.
847
:Rich, this was so, so interesting.
848
:Uh, could have probably
booked a three hour session.
849
:We'd still have more to cover, but really
grateful for you joining us today and
850
:just being generous, sharing all your
insights and what you folks are doing.
851
:I think it's fascinating.
852
:So thank you so much.
853
:Rich Archbold: Thank you for having me.