Faire and Segment on Scaling Engineering

Marcelo’s Role in Scaling Faire

Marcelo is the co-founder of Faire. He initially led engineering before hiring Paul Poppert, and is now Chief Architect. 

Tido’s Role in Growing Segment to Acquisition

Tido joined Segment as VP of Engineering and later became CTO. He managed hundreds of engineers and is now the co-founder of Koala. 

1. Maintaining Velocity as You Scale

Keep Teams Small to Preserve Context and Speed As You Scale

• Faire’s founding team included Max as the product-focused CEO with Marcelo and Daniel running engineering and design.
• As Faire grew past 15 employees, context began to break. To give teams autonomy and the freedom to make decisions on the fly, Faire split their teams into smaller groups each with a product lead, engineering manager, and design support.  
  
  • The goal of these splits was to replicate the speed and agility the team had on day zero with small, autonomous pods that are responsible for their own mission and outcomes, and are empowered to generate and prioritize ideas without waiting for centralized decisions. 
• As you scale, you’ll need to introduce more processes. But Marcelo believes in only adding processes when absolutely necessary to unblock bottlenecks
  
  • Example: documentation for things like email subject lines should not hold a team up – this would previously have been decided ad hoc by a co-founder.
• This pod structure scaled with the company to 100+ employees and helped preserve context and speed at Faire while eliminating bureaucracy.

‍

Visibility Enables Better Resource Allocation Between Teams 

• Faire’s initial pod splits weren’t clean. Teams shared some resources like design and backend, while other functions like front-end and mobile engineers were siloed between pods.
• As teams grew, juggling these shared resources became harder. Faire’s team introduced lightweight tools to track the number and composition of each pod and what resources each had access to.
  
  • There’s no perfect system—but transparency in how people and resources are allocated was crucial for Faire. Marcelo would regularly adjust pods and resourcing to meet Faire’s needs.

‍

Pods Should Align With The Company’s High-Level Goals

• Segment’s pod philosophy aligned closely with Faire’s. Tido believes that the CEO’s job is to create clarity and set up pods with a clear mission that’s inspiring and challenging. 
  
  • These missions varied widely: improving onboarding, increasing reliability, reducing infrastructure cost, or doubling ACV with value-add products.
  • Missions also had to be “slightly stretchy”—ambitious enough to inspire, but concrete enough to avoid ambiguity.
• As soon as the mission is clear, you should delegate as much as possible 
• Segment’s typical pod structure at ~20 engineers:
  
  • Figure out the top three biggest goals for the company each year (e.g. onboarding, enterprise features, new initiatives) and set up a vertical pod for each with full-stack resources.
    
    • Example: Full-stack pods avoided matrixed dependencies like “⅓ of a designer,” which created friction and coordination costs.
  • One horizontal pod responsible for shared services needed by multiple pods 
• As Segment scaled to 400+ engineers, pod sizes scaled too, but leadership worked to maintain a simple, understandable structure across the org.

‍

Hold Pods Accountable For Their Work

• At Faire, each pod is fully responsible for its own results—including hitting deadlines, maintaining quality, and executing effectively.
  
  • Use dashboards and metrics to track quality signals. These dashboards won’t give you the answers, but they’ll tell you where to poke and what questions to ask:
    
    • Bugs found before and after launch
    • Customer complaints
    • Task coverage, latency, unassigned JIRA tickets
  • If something seems off, intervene quickly — don’t wait.
• If things went wrong (missed timelines, bugs, misalignment), the root cause was usually within the pod—scoping gaps, poor handoffs, or lack of communication.
  
  • Engineering should work alongside product before implementation begins, but everyone in the pod checks functionality before a launch to ensure alignment and quality.
• As teams grow, managers become more essential, but not to add red tape:
  
  • A manager’s job is to navigate and unblock processes and ensure the pod can still move with the same autonomy and velocity it had when the company was smaller, getting out of the way unless necessary
• As soon as you start to notice signs that something isn’t working well, you need to step in quickly, identify what’s getting in the way, and address it.
• Tido believes leaders should establish visibility systems to monitor what pods are producing—what’s working, what’s broken, and what their leads are (or aren’t) aware of.
  
  • A red flag for Tido is when external teams report issues that don’t match what pod leads acknowledge. He believes these are signs of blind spots in leadership. 

‍

Let Pod-Level Gaps Guide Org Design

• Segment struggled to architect a “perfect” org from the top-down. They were more successful when they treated their org structure like a codebase—applying "just-in-time patches" instead of full-scale refactors.
  
  • This looks like plugging holes and fixing what’s broken, team by team, as problems emerge.
• Instead of preemptively adding senior roles, Tido starts by identifying gaps and upgrading pods incrementally. Only when a strategic need becomes clear (like building a world-class eng team), should you layer in leadership like a VP of Engineering.

Example: How Marcelo Operationalized Metrics at Faire

• Early on, Marcelo recognized that if you care about something, you have to track it.
  
  • Even with just a few pods, Faire needed visibility into code quality, velocity, and user experience.
  • They built lightweight dashboards that monitored three types of bugs:
    
    • Issues caught before launch through internal QA
    • Exceptions detected automatically post-launch
    • Customer-reported issues (the most severe)
• As the company scaled, they organized around a pillar-pod structure:
  
  • Pillars like EPD Foundations, Retailer Tools, and Retailer Growth each included multiple pods
  • Each pod was responsible for tracking metrics relevant to their work—defects, latency, engineering process health, and task coverage
• Every pod had a dashboard that surfaced issues:
  
  • Engineering managers reviewed these regularly
  • Automated systems flagged unassigned tickets, missed SLA targets, or endpoint latency regressions
• These systems didn’t give exact answers, but they highlighted where to poke
• With 2–5 pods running simultaneously, Marcelo could quickly spot outliers and help teams focus on the right problems
  
  • The goal was to create lightweight, visible accountability around what mattered most

Example: How Faire Scaled Hiring for Pods

• While Faire was early, they tracked hiring and team allocation closely, since every new hire had an outsized impact across just 2–3 pods
  
  • A single backend hire could change a pod’s velocity—so allocation decisions were highly deliberate
• Today, with many more pods and a larger team size, the process is more pod-led and bottom-up:
  
  • Each pod is responsible for flagging their talent needs, categorized by priority level (P0, P1, P2)
  • Pods log headcount requests in Notion, specifying the role, urgency, justification, and recruiter assignment
• Once a candidate is hired, an allocation committee reviews open requests and places the new hire
  
  • The process enables flexibility while keeping priorities visible across the org
• While less hands-on than in the early stage, Faire still maintains a lightweight but transparent system to monitor what high-priority pods need

A Great PM Acts Like a Mini-CEO

• Marcelo emphasized that in the early days, a great PM is effectively a stand-in for the CEO of a specific product area. 
  
  • Their core responsibility is deep and frequent understanding of the customer—their pain points, needs, and behaviors. They must have a clear vision for how to prioritize what to build, especially when resources are limited and each product decision could materially change the company’s trajectory.
  • As the company scales, not every PM decision will be company-defining—but in the early stages, they often are.
• At Faire, the CEO Max stayed highly involved in product decisions across pods, even as the team scaled. His ability to track and contribute across pods ensured product leadership while empowering pods to move independently once direction was clear.
• Every pod needs someone responsible for orchestration—ensuring team members are productive, aligned, and not overloaded
  
  • This could be the PM, an engineering lead, or another strong operator in the pod

Example: How Segment Scaled the PM Role

• At Segment, anyone could write a PRD or contribute to product thinking
  
  • Engineers, designers, and even success team members regularly authored specs
  • Segment’s best-performing pods had early collaboration between PMs, tech leads, and designers
• Picking the right thing is the main skill Segment would look for in PMs
• While flexible roles worked well early on, dedicated PMs became essential as the team scaled or the stakes of decisions increased. A good sign of when to hire is when pods begin skipping critical user research and rushing into build mode.
  
  • Designers were sometimes leveraged to fill the PM gap, but doing so often underutilized their core design skills
  • Tido warned that while engineers can flex into PM-ish roles, it’s costly and not always aligned with their core strengths
• There’s no universal “right ratio” – PM-to-engineer ratios will vary:
  
  • Enterprise pods with high external coordination needs might have 1 PM for every 4 engineers
  • Infrastructure pods with more technical autonomy might run with ratios as low as 1 PM to 15–30 engineers

2. How to Recruit and Build Strong Engineering Teams

Align Your Team Behind a Compelling Engineering Story to Attract Great Engineers

• Tido emphasized the importance of figuring out your team’s story. Upon joining, the early impression was that Segment was just another boring B2B app. 
• Segment’s team realized there was an engineering story buried in the 30k requests per second they were handling 
  
  • The engineering story grew into a mission-critical one surrounding how every time they onboarded a new large customer, their load demands would dramatically increase. 
• To find their engineering story, Segment looked for what their best engineers were excited about and found a few unique problems they were working on to shape into a branded engineering message.
  
  • Example: Stripe’s story was not one of wild scale, but high complexity and the importance surrounding how everything breaks if Stripe goes down.
  • Segment’s blog strategy allowed them to surface and share these stories publicly to further build their engineering story
• Great engineers want to solve technically hard problems that are also mission-critical to the business. 
  
  • You want to sell them a hero’s journey where the engineer is the protagonist and their output moves the needle. 

Example: How Segment Built a Strong Engineering Brand

• When Tido joined Segment (~10 engineers, scaling from $2M to $10M ARR), the platform was under immense pressure—everything was on fire, with major infrastructure stress from systems like Redshift
  
  • Hiring was their top blocker to company growth—they had capital but couldn’t scale engineering fast enough
    
    • Funnel efficiency was terrible: engineering interview time per hire was way too high
    • Tido started by brute-forcing it—hiring a recruiter and increasing interview volume—but it wasn’t working
• Peter Reinhardt (Segment’s CEO) decided to instead invest in building an engineering brand for a couple quarters
  
  • They did this by:
    
    • Raising the bar on who gets through the funnel: Segment would only bring in candidates they were ~80% confident in: aligned on comp, stage, expectations. This cut the amount of time they spent on people who were the wrong fit.
    • Building an engineering brand: the team would spend hours on blog posts designed to hit the front page of Hacker News (40+ hours per post, written by strongest storytellers). They’d also host a quarterly event called Segfault, where infra leaders shared outage stories in Segment’s office. 
  • Segfault was not officially a recruiting event—no pitches, just smart people + good vibes + casual networking
    
    • Recruiters attended but were told not to mention hiring explicitly
• 2–3 quarters in, the flywheel took off—more inbound interest, better candidate alignment, stronger technical culture perception

Network Won’t Scale. Invest in Scalable Hiring Channels at 20-30 People. 

• When Faire was at 100-300 people, the entire engineering team was in Canada 
• For the first 20-30 hires, hires were made exclusively through the founder's network while avoiding any cold outreach. The focus was only on the absolute best engineering hires. 
  
  • The team used repeated coffees/lunches, advisory convos, slow-burn selling over 12+ months
• The team initially underestimated recruiting – they assumed it was just job posts and interviews. 
  
  • Faire gave their office manager/chief of staff a dual role as recruiter. The belief was that if they could interview them, they’d be able to spot the good ones. This ended up being ineffective and unsustainable. 
• The team eventually learned that recruiting = sales. 
  
  • They hired a dedicated recruiting team, built clear job descriptions, and structured outreach
  • Developed data-driven recruiting dashboards:
    
    • Funnel visibility (reachouts → onsites → offers → acceptances)
    • Weekly review of rejection reasons (comp, location, RTO, equity, etc.)
    • Region-specific breakdowns (Canada vs. Brazil vs. US had totally different dynamics)
• Marcelo also admitted that Faire was too late to invest in employer brand 
  
  • They introduced cash bonuses ($1k-$3k) for approved blog post contributions 
  • Faire set up an editorial process to ensure consistent quality and pacing of posts
• What worked for recruiting in one geography completely broke in others 
  
  • They had to relearn sourcing, interviewing, and compensation norms in each hiring market
• Recruiting is an art and a science—founder-driven sales works at first, but scaling requires dedicated teams, clear pipelines, brand storytelling, and data visibility
  
  • Marcelo still runs weekly recruiting reviews 8+ years in—to stay close to the funnel

Tactic: How Segment Built a Hiring Pipeline through Hacker News

• The title and hook will make or break your blog post—test multiple hook ideas before investing in writing
  
  • Successful themes included open sourcing a piece of work Segment had done or doing a big, technical deep dives into topical themes
• After choosing a hook, the team would invest heavily in producing long-form technical storytelling with clear, polished architecture diagrams they’d pass by a freelance designer
• Segment treated every post like a marketing launch – they tested headlines, invested in visuals, and polished the narrative
• First impressions matter—to new talent, your startup looks like a bunch of clowns until proven otherwise
  
  • These blog posts became assets in their recruiting funnel. Candidates came in already familiar with Segment from Hacker News, which changed hiring dynamics to boost trust, increase funnel conversion, and shorten close cycles
• Over time, ~50% of blog posts hit the front page of Hacker News
  
  • Success came from iterating on what resonated, timing, and consistent experimentation

Flexing On Compensation Is Worth Keeping Great Talent

• Segment aimed for 80-90th percentile in equity to attract talent aligned with long-term upside and an owner’s mentality
  
  • Base compensation was around 50th percentile to reflect Segment’s positioning relative to Big Tech cash offers. 
• Tido believes it's valuable to make case-by-case exceptions for candidates with real financial needs. 
  
  • If a candidate has a valid reason, it’s worth going up to 75th-80th percentile in base. 
• Segment also had clear, upfront conversations during the hiring process to filter for people with the right mindset – for candidates in process with FAANG companies, they were transparent about Segment’s counterpositioned compensation structure. 

Example: How Faire Competed for FAANG Candidates

• At 30 employees, Faire prioritized recruiting the best people possible, no matter what it took — within financial constraints.
• Instead of focusing solely on compensation benchmarking, Marcelo focused on individual motivators and spent significant personal time with each candidate to identify what they cared about and double down during the pitch
  
  • Faire used personal credibility (e.g., Marcelo’s own time at Google) to build trust.
  • They would always sell upside and meaning, even if the cash comp was lower.
• Marcelo often showed homemade equity value spreadsheets to storytell their projected Series B–D valuations and the future worth of current equity.
  
  • Messaging to former Big Tech engineers emphasized:
    
    • Upside vs. capped FAANG comp
    • Impact
    • Ownership and growth over bureaucracy
  • Selling equity gets harder with the market as people become far more conservative – adaptability is key.
• The goal was to make Faire’s worst-case scenario comparable to a FAANG base case, and best-case exponentially higher.
  
  • The team tailored offers to individual needs — some candidates needed near-Google-level cash, which often meant trading off equity.
    
    • In some cases, signing bonuses (e.g. $50K) were used as a bridge when equity alone didn’t close the gap.

3. Hiring your VP of Engineering & the CEO/CTO Relationship 

No Single Archetype for VP of Engineering

Faire

• There’s no one-size-fits-all script for what a CTO or Head of Engineering should do — it depends on personal strengths, company needs, and growth stage.
• Early on at Faire, Marcelo did everything: coding, recruiting, payroll, infra, IC mentorship — even with 20+ direct reports.
  
  • This wasn’t ideal – Marcelo considered engineering a core strength but wasn’t a strong manager
• As Faire’s growth accelerated, it became clear that structure was needed 
• Instead of incrementally increasing middle management, Faire split the CTO role into two:
  
  • As CTO, Marcelo owned the technical vision, architecture, coding standards, and IC recruiting/interviewing
    
    • Even after the split, Marcelo wanted to stay close to technical decisions and processes, and still recruited Faire’s technical hires
  • The Head of Engineering would own team management, processes, manager hiring, consistency across pods, and career development. 
    
    • Marcelo had no experience being a manager and didn’t know how to hire good managers either 
• The Head of Engineering had to:
  
  • Standardize process and structure across pods
  • Ensure managers shared a unified way of operating so talent can move between teams smoothly
  • Keep Faire’s highly motivated engineering team engaged, unblock them, and build strong leadership 
• Marcelo interviewed 80+ candidates to find the right Head of Engineering
  
  • He eventually repeated the process again at larger scale to hire a new CTO before transitioning to Chief Architect to refocus on deep technical work

Segment

• There’s no one-size-fits-all engineering lead archetype – success depends on having a clear understanding of what needs to be done and transparent alignment with the CEO
  
  • He believes the most important thing for teams is to have a stable, clear long term objective to work towards
• Segment initially hired Tido as the VP of Engineering reporting to CEO Peter Reinhardt, with the two technical co-founders continuing to report to Peter. 
  
  • Within a week, the structure shifted so the two co-founders reported to the new VP Eng and Tido alone reported to Peter to simplify and clarify communication among leadership 
• Tido saw his job as making the engineering function legible to the rest of the org – especially the CEO and sales team – instead of keeping it as a black box. 
• He treated Peter as a co-navigator – he saw it as his role to make sure Peter understood what was working, what was broken, and what levers he had to influence outcomes. 
  
  • He viewed part of his job as producing and clarifying tradeoffs (e.g. investing in doubling ACV vs. maintaining infrastructure velocity)
• Tido also focused on how he could continue to up-level team performance by increasing clarity of mission, providing room for career growth, and managing employee productivity

‍

If You Have a Technical Co-founder Don’t Overly Shield Senior Engineering Hires From Leadership

• Faire’s founding team operated as equals. Even though the Head of Engineering (Paul) reported to Marcelo (CTO), they operated as collaborative partners. 
  
  • Marcelo set org-level technical vision while Paul executed on it
  • They’d meet 2-3 times a week to align on team structure, performance issues, and engineering priorities.
  • Paul was responsible for day-to-day people management, hiring processes, internal mobility, and operationalizing engineering scale.
• This structure allowed Marcelo to remain close to code, technical recruiting, and architecture – areas he loved and excelled at. 
  
  • Paul focused on building and running the team, which Marcelo didn’t want to do
• Marcelo regrets overly shielding Paul from the executive team, which he believes limited his exposure and growth
  
  • Marcelo acted as engineering’s exec interface, handling tough conversations and feedback loops. This removed pressure from Paul but slowed his development as a cross-functional leader.

‍

The CEO’s Voice is Powerful; Be Careful As You Scale

• A strong CEO–CTO relationship depends on mutual trust and clear protocols — especially as the team scales.
• The CEO’s voice is powerful. If not careful, you can derail the team with one-off comments. To avoid this, set clear expectations. 
  
  • Marcelo wanted autonomy to do his job. In cases where something was broken, he wanted time to investigate before reporting back. 
• Max and Marcelo set clear expectations that the CTO would commit to surfacing issues transparently while the CEO would avoid micromanagement. 
  
  • Some of Max’s pushes were right – his criticism of Marcelo not using a recruiting pipeline was valuable and changed how Faire recruited and scaled. 
  • Other mannerisms proved unproductive – when Max would “go low” in the org and question line engineers about AWS cost spikes or missing features, it would only create unrest. 
    
    • Individual ICs would get distracted or panic, chasing answers or reprioritizing based on informal CEO comments 
    • This would disrupt existing workflows and send mixed signals to the team. Instead, Marcelo asked Max to express concerns through the leadership chain. 

‍