How marketing technology works and when to hire for it

Executive overview

Most companies hit a point where their growth tools become unmanageable — no one knows how data flows, contracts are a liability, and nothing can change without breaking something. MarTech (marketing technology) is the discipline that owns this layer: the systems, tools, and data infrastructure that power growth.

The function sits at the crossroads of product, engineering, and marketing. At small companies it's informal; past 100–150 people it needs to be centrally owned.

The core insight: tools exist to solve problems — not to be implemented because they're familiar or popular.

What MarTech is and who does it

• MarTech manages both third-party tools (Segment, Amplitude, Braze) and first-party systems built on top of them
• The role is distinct from growth: growth sets the goals, MarTech builds and maintains the infrastructure to pursue them
• MarTech vs. MarOps: MarTech requires an engineering background; MarOps is semi-technical (SQL, campaign setup) but not engineering-based
• The best practitioners are scrappy engineers or people who've taught themselves to code — not necessarily CS graduates

When to hire a MarTech person

• Below 30–40 people: growth and engineering overlap; one person can manage tools informally
• At 100–150 people: village-style tool management breaks down — someone must own schema, data flow, contracts, and permissions
• The trigger is usually pain: teams can't make changes because no one understands how something was set up, or tool sprawl is creating risk

Where MarTech lives in the org

• B2C: best placed alongside or reporting into the head of growth; the growth team is its primary customer
• B2B: messier — often sits in rev ops; sometimes decentralized into marketing or product ops
• B2B2C (e.g., Notion, Ramp): most complex; must manage both a user acquisition funnel and a CRM layer simultaneously
• Decentralized models tend to fail unless the company is very large; centralized ownership is usually better
• Where it lives should follow the leader's skill set: ops-leaning → keep in function; technically strong → could sit in product or engineering

Day-to-day responsibilities

• Automating permissions and access (e.g., who gets edit access to HubSpot — getting this wrong causes public embarrassment)
• Designing 1–2 year system roadmaps and building financial models to justify them
• Managing contracts: SaaS costs that seem fine at 500 MTUs become catastrophic at 1M MTUs
• Architecting the "build and buy" layer — buy a tool for 90%, build custom tooling for the remaining 10%
• Leading platform migrations (e.g., moving from a small email tool to Braze without losing revenue)

The B2C tool stack (then and now)

• 2016–2020: CDP (Segment or mParticle) in the center, with third-party tools connected around it — simple, effective
• 2021+: warehousing costs dropped; now it's viable to store and model all data in Snowflake and activate it via reverse ETL
• Reverse ETL moves data from the warehouse to tools (e.g., ad networks, email platforms); key standalone products: Census, Hightouch; also built into Segment and mParticle
• Two valid approaches today:
  • CDP-first: buy a CDP, connect tools, minimal engineering overhead — right for teams without strong data infrastructure
  • Warehouse-first: collect into Snowflake, model in dbt, activate with reverse ETL — right for engineering-heavy teams

The B2B stack

• Salesforce is still the gravitational center; everything else orbits it
• B2B2C complexity: B2C tools model the world as user + event; B2B adds a company/entity object — bridging these is one of the hardest MarTech problems today
• Having both HubSpot and Salesforce (common at Notion, Ramp) creates data mapping hell; there's no universal fix, only deliberate design choices

Attribution: building the right foundation

• First touch: credit to the channel where the user first arrived
• Last touch: credit to the channel where the user last arrived before converting
• MTA (multi-touch attribution): splits credit across all touchpoints — more accurate, harder to implement
• MMM (mixed media modeling): statistical model for spend allocation across channels; useful but most companies aren't ready for it and should focus on MTA first

How to future-proof attribution from day one:

• Capture the referring URL, all UTMs, and ad network click IDs (GCLID, FBPID, TikTok ID, etc.) on every page view
• Store first and last UTM separately on both the user object and in events
• This lets a data team reconstruct a full attribution path without waiting to rebuild the pipeline later

The post-ATT reality

• 2010–2020: deterministic matching — precise one-to-one attribution from ad click to install
• Post-iOS 14: IDFA opt-in rates are near zero; mobile attribution is now mostly aggregate and probabilistic
• Browsers are also stripping URL parameters, pushing more traffic into "organic" buckets even when it came from paid
• Third-party cookie blocking removes pre-conversion data entirely for anonymous users
• The shift: marketers must now make spend decisions using probabilistic models, not individual-level data

Hiring and interview approach

What to look for:

• Intellectual curiosity — the tooling landscape is too large for anyone to master; continuous learning is non-negotiable
• Scrappy engineering ability — JavaScript, Python, ability to read API docs and make requests
• Cross-functional influence — this role has no direct authority over engineering, product, or data; persuasion is the core skill

Interview questions Austin uses:

• "How did you prepare for this interview?" — reveals systems thinking, planning instincts, and how seriously the person takes the role
• "You're starting Monday — by Friday you need to write up everything we should change. What do you do?" — surfaces tool bias; good candidates ask about problems first, not tools

Red flags to avoid fixating on:

• Resume gaps — often explainable and irrelevant
• School prestige — a poor shortcut that filters out strong candidates

Key frameworks

• Tools are meant to solve problems — repeat this constantly; it prevents tool-for-tool's-sake thinking and forces problem-first reasoning
• PPS: Problem → People → System — before touching any tool, define the problem, identify who it affects, then design the system; most people skip straight to the system
• Build and buy (not build vs. buy) — buy a third-party tool to get 90% of the way, then build custom tooling on top; this is faster, cheaper, and keeps vendors invested in your success
• Think gray — resist the urge to make premature decisions; delay committing until you must; applies to systems choices and people judgments alike

The golden stack (Austin's recommendations)

B2C:

• CDP + product analytics: Amplitude
• Email: Customer.io (upgrade to Braze at scale)
• Data warehouse: Snowflake
• Reverse ETL: Hightouch
• Mobile attribution: AppsFlyer (or Branch)

B2B (web-first):

• Same as above, but swap to Branch for attribution (stronger on web)
• CRM: Salesforce
• Email: Customer.io → Braze
• Reverse ETL: Hightouch