Jean-Denis Greze and Albert Strasheim on Scaling Engineering

Jean-Denis’ Role in Scaling Plaid

Jean-Denis joined Plaid when the company had roughly 20 engineers and no formal engineering leadership structure. He helped scale the org from 20 to over 550 engineers, while expanding his own scope from engineering into product, design, and support, eventually overseeing all of Plaid’s R&D functions. Before Plaid, Jean-Denis was at Dropbox, where he joined as an IC when the company was about 100 people and eventually became the Director of Engineering reporting to the CTO. 

Albert’s Role in Scaling Rippling

Albert joined Rippling nearly three years ago, when the company’s engineering team was roughly 500 people and scaled it to nearly 1,000 engineers. Before Rippling, he was at Cloudflare, which he joined in 2013 when it was about 50 people and grew with the company through its expansion to 300 as he transitioned from senior IC to manager. He then joined Segment as its first Director of Engineering and later became VP of Engineering, helping scale the team from a dozen engineers to more than 250 through the Twilio acquisition.

1. Maintaining Speed

Maintaining Velocity at Scale

• When growing from 20 to 50 or 100 engineers, one of the most common frustrations founders face is their orgs lose speed. 
  
  • This is also often when speed and taste begin to feel like a tradeoff teams have to make. 
• This slowdown is mostly inevitable and happens to every startup as their engineering teams scale to hundreds. Accepting this reality allows leaders to focus on managing velocity instead of trying to preserve an unsustainable pace. 
• Instead of focusing on maintaining speed, founders should learn which sources of friction are acceptable and which ones will compound your team’s inertia over time. Founders must develop the judgment to distinguish expected slowdowns that come from coordination drag as the team scales, from existential drag coming from bad systems and misaligned priorities. 
• Most founders misdiagnose the problem and blame work ethic, citing examples like “most people used to come in on Saturdays”. In reality, slowdowns usually stem from deeper structural issues like:
  
  • Slow decision-making speed 
  • Bad architecture that sets the team back months
  • Misaligned goals or poor product quality that leads to constant firefighting within the org
• Instead, Jean-Denis suggests comparing your organizational speed to entropy.
  
  • As you grow, “garbage” will constantly attach to your systems. Jean-Denis believes that the solution will not be a one-time fix through implementing OKRs or planning frameworks, but instead will involve the continuous cleaning and fixing of your systems. 
    
    • What implementing fixes like OKRs will do is slightly improve your planning processes rather than reigniting speed within your org
• Founders should benchmark themselves against realistic peers, not consumer tech companies like TikTok or Instagram that have far faster iteration and experimentation speed. 
  
  • At Plaid, they were not objectively fast given that working with financial data, privacy, and bank integrations requires caution. But they were 5x faster than their competitors, which was all that mattered.
  • Jean Denis believes that “your constraints define your speed.” An API company has different tradeoffs than a social app because deprecating APIs is painful. So, you design slower by design.

Avoid Focusing on Metrics Too Early

• Jean-Denis believes that recording metrics while your engineering org is smaller than 100 people is premature. Instead, he suggests focusing on operational hygiene and taste-based thresholds that don’t require dashboards. 
  
  • For example, there’s no need to granularly measure CI/CD pipeline time: it will either be acceptable (<5 min) or broken (>5 min). If builds are fast, engineers stay focused. If not, they’ll context switch to another task
  • In these cases, you don’t need a complex measurement framework. Common sense on what matters should generally be enough

Example: Jean-Denis’ Framework for Maintaining Velocity Across Three Vectors 

• Jean-Denis argues that as organizations scale, speed will naturally decay but founders can manage it by pulling three levers: culture, meta-processes, and metrics
• Culture
  
  • Velocity begins with cultural ownership. This looks like how often people talk about speed, how many leaders and ICs are advocates for it, and how consistently poor or slow execution is called out.
    
    • Jean-Denis emphasizes that this tone must come directly from the founder: you have to be the one calling out when something took too long, asking why it wasn’t raised earlier, and helping people fix it
  • He suggests having candid one-on-ones when projects stall. The goal with these should not be to punish, but to help teams unblock themselves and see how they can prevent future blockers arising again. 
  • The goal should be to create an internal chorus of people who treat speed as high priority. This way people who once complained about slowness become part of the solution by being empowered to identify issues and hold peers accountable, and asking peers what they need to move faster.
    
    • People remember speed. You can leverage team members who’ve experienced a fast culture to protect it
• Meta-Processes
  
  • Instead of adding heavy processes, Jean-Denis builds small “meta-processes” designed to keep projects from stalling.
  • One example is Plaid’s Key Project Check-In
    
    • Once per quarter, he picks 4–5 projects across the company that he didn’t feel confident were on track. Each met with him weekly for a five-minute status check.
    • The purpose of these meetings was not to re-litigate product or technical decisions, it was purely about accountability. When issues popped up, Jean-Denis would ask teams: you told me you’d do X last week; you didn’t. What’s blocking you?
  • The conversations surfaced organizational friction like missing resources, unclear ownership, cross-team dependencies. When consistent blockers surfaced, he committed to unblocking them personally.
    
    • He was also clear about the expectation that if the same blockers persisted the next week, it would get escalated.
    • While some decisions will still require your call, this process ensures they surface quickly so you can address them head-on
  • These check-ins signal urgency and focus. Jean-Denis only selected four projects at a time, so everyone knew these were top priorities and were willing to sacrifice other work to get them back on track. 
• Metrics
  
  • While Jean-Denis cautions against over-measuring at small scale, he believes in a few high-signal operational metrics that serve as “smells” of underlying problems.
  • These include:
    
    • CI/CD time: Slow pipelines directly correlate with lost engineering focus.
    • Number of SEVs or incidents: Spikes here usually indicate architectural or process decay
  • This data can serve as an early proxy for friction that may exist within your engineering team to help you detect drag early on. 

Why Speed Drops After 30 Engineers

• Albert believes that that engineering velocity naturally drops once the org passes a certain size (a Dunbar number) typically between 20 and 50 engineers. At that point, everyone doesn’t know everyone anymore, and communication shifts from individual relationships to structured teams and manager coordination.
  
  • Early Rippling engineers felt the same growing pains as teams at Segment when they went past this Dunbar number. The things that used to let their teams move fast started breaking down
• When reaching this state, the key is to recognize that this transition isn't a failure of the engineering team, it is a structural shift that requires new habits.

Process Isn’t the Enemy of Speed

• Founders often believe that all processes are the enemy of speed and associate process with bureaucracy. Instead, Albert argues that a bit of organization can actually make you faster.
  
  • At Segment, he saw teams resist even simple planning by skipping short writeups or weekly alignment docs and it dramatically slowed execution. 
  • Especially within engineering, spending a little time aligning on a plan can save you weeks of programming. Even a half-page Google Doc on what’s happening over the next two weeks can prevent misalignment and wasted effort.
• Rippling doesn’t enforce uniform processes like sprint planning across every team.  0→1 teams operate differently from scaled teams, but each must have some system for planning and accountability.

Framework: Rippling’s MMDD Strategy to Drive Execution

• One of Rippling’s most effective tools for maintaining speed is the MMDD, which stands for Month-Month-Day-Day. Created by Parker Conrad, the MMDD is a strong commitment where any time someone promises to do something, they must specify by when.
• The rule enforces a falsifiable plan:
  
  • Instead of saying “I’ll do that,” you must say “I’ll do that by 10/20.” If the work isn’t done by the date, you owe the team a new date and an explanation.
• The MMDD creates org-wide urgency and peer accountability where if someone says they’ll do something, and it doesn’t show up by the time they said, you can immediately go and ask them about it. Albert calls MMDD a “tiny made-up process” that acts as Rippling’s cultural operating system that gives the org a simple shared language for commitments.

Balancing Speed and Taste

• There is no formulaic answer to balancing speed and taste. It’s an art. The artistic part of being a great engineering leader is knowing when to build better infra and when to move fast and take some technical debt.
• Jean-Denis warns against over-metricizing decisions. Reducing everything to ROI can kill craftsmanship and intuition.
  
  • For example, an internal API at Plaid was so painful to use that engineers tried to quantify the hours it cost before fixing it. Jean-Denis argues that at some point, you have to “eat your vegetables” and fix issues that may not be easily represented via a clean ROI metric. 
• The key is to allow teams to make taste-based decisions and trust experienced engineers to do what feels right when metrics can’t capture the tradeoff.
  
  • Eventually at Plaid, ~20% of engineering time was reserved for “taste work” like fixing internal tools, refactoring, or cleaning tech debt. Teams used this time to improve their environments proactively, not chase new projects.
  • This preserved long-term velocity and kept morale high.

Framework: Rippling’s Speed-Taste Matrix

• Albert shared a framework used at Rippling to evaluate team performance based on two dimensions: Speed and Taste (Quality/Thoughtfulness). The model plots teams or individuals across four quadrants to diagnose whether a group is operating effectively or stuck in the wrong tradeoffs. 
• High Speed / High Taste 
  
  • Teams in this quadrant ship quickly and with strong product judgment. Their output reflects both pace and quality. These are the performers you want to replicate across the org.
  • Albert believes people with good taste can move fast. You don’t have to trade one for the other. Teams that understand their domain deeply tend to make better decisions faster.
• High Speed / Low Taste 
  
  • Teams in this zone deliver quickly but create downstream problems through poor decisions or brittle systems. They might appear productive in the short term, but their work erodes quality and slows others down later.
• Low Speed / High Taste 
  
  • Often justified as “craftsmanship,” but usually a trap. Parker Conrad believes that if you really look at those teams, the quality isn’t actually that good either
  • Slow teams rarely produce true excellence. Great taste usually shows up fast because the best people iterate toward quality quickly.
• Low Speed / Low Taste 
  
  • The obvious underperformers. Slow, unfocused, and producing low-quality outcomes.
  • These teams or individuals likely need to be restructured or reassigned.

2. Culture and Values

Codifying Culture Through Values

• As Rippling grew so did the need to talk openly about cultural slowdown. This helped teams name and navigate the discomfort of moving at a different pace as the company scaled.
  
  • Leaders must proactively surface this conversation to help teams understand what slower decision-making will feel like and how to combat it.
• Roughly five years into Rippling’s growth, the engineering leadership team ran a company-wide values exercise to better articulate how Rippling actually operates.
  
  • The team gathered a group of employees in a room with a whiteboard and sticky notes, listing people who had been most successful at the company: those who had been promoted, expanded scope, or consistently delivered.
  • They then analyzed what traits made these people successful, ultimately synthesizing these patterns into Version 2 of Rippling’s values.
    
    • The qualities they identified weren’t just aspirational words, they were the things the org as a whole actually valued. 
• This exercise helped define the way good work got done at Rippling and surfaced a framework for how high performers operate and how the organization should make decisions, collaborate, and hold itself accountable.
• Two of the most enduring examples of these values include:
  
  • Go and See: Regardless of seniority, everyone from the CEO to individual contributors is expected to personally inspect details rather than rely solely on reports from others.
  • Push the Limits of Possible: Employees are encouraged to set ambitious goals and deadlines. Missing them is acceptable, but only if they can clearly explain why.
• Albert describes these values as meta-processes in disguise, giving teams a shared vocabulary for accountability and constructive critique. 
• By codifying this language, Rippling created a scalable culture that reinforced speed, ownership, and clarity at every level

Repeat Values to Keep Them Alive

• Jean-Denis cautioned founders against treating values as a one-time branding exercise. Founders will spend a month writing the perfect values for their company, launch them at all-hands, and it’ll be the last time anyone talks about them.
  
  • At Plaid, he recalled that every year the design team created beautiful posters for newly tweaked values but there wasn’t enough follow-through across the org.
• Spend ten times more effort on reinforcing values than defining them. He argues that true cultural adoption comes not from wordsmithing, but from embedding values into everyday conversations, rituals, and performance management.
• When Plaid struggled with ambition and urgency, Jean-Denis replaced abstract slogans with three traits he wanted to see across engineering: ambition, urgency, and scrappiness. Each week, he sent a company-wide email highlighting examples of employees demonstrating those behaviors.
  
  • He also reinforced them in all-hands, one-on-ones, skip-levels, product reviews, and performance cycles. Performance management and promotion cycles were directly tied to these behaviors. In reviews, managers had to point to explicit examples of how employees demonstrated ambition, urgency, or scrappiness. Those who couldn’t were rated lower.
• Values only matter if they’re operationalized. At Plaid, Jean-Denis gathered Plaid’s most senior ICs and managers to showcase specific instances of how each had demonstrated ambition, urgency, and scrappiness in the past. 
  
  • These case studies became internal teaching tools for how senior talent should operate and gave newer engineers a concrete reference for what “good” looked like. 
  • Product reviews were restructured around the three traits. Every major engineering or product discussion was framed through the lens of “Is this ambitious enough? Are we moving with urgency? Are we being scrappy enough in execution?” This created consistency between how leadership talked about performance and how they evaluated progress.
  • Company investments were reweighted toward ambition. When deciding where to allocate resources or which projects to back, Jean-Denis deliberately funneled funding and talent toward the most ambitious initiatives, signaling that ambition was not just encouraged but resourced.
• Jean-Denis believes you know your team has internalized your values when they start repeating it back to you and teammates use your language with each other.
  
  • Examples at Plaid included engineers pushing peers to be “more scrappy,” or asking to raise OKR targets mid-cycle because goals felt too easy.
• It’s hard to make speed itself a value. There’s always a tradeoff with quality, security, or rigor. Instead, identify the traits you want to preserve while moving fast, and make those the foundation of your company’s values.
• Unlike process, which can be implemented overnight, culture takes time to build but has far greater reach. It seeps into every part of the organization and shapes how people behave in areas where no formal rules exist.
  
  • When your culture embeds the right tradeoffs around speed, teams will instinctively make decisions that reflect the company’s true priorities even without being told.

Scaling Good Judgement

• Good judgement is one of the hardest things to scale in an org. It rarely develops in isolation and must be taught through stories, shared experiences, and institutional memory. 
  
  • For example, if you’re trying to teach everyone among the team how to design an API with strong usability, you could have a history of API design at your company that everyone has to go through during onboarding
• Codify lessons as company lore. Create a “history of API design” document that walks through past successes and failures, especially costly mistakes that taught the company something fundamental.
  
  • Include examples of both extremes: an API that was poorly designed and caused downstream pain, and another that succeeded because of iterative testing with real users or design partners.
  • Make this part of onboarding or recurring internal talks so every new engineer understands the lineage of decisions that shaped current best practices.
• Designate internal experts as cultural anchors. Identify a few engineers or product leaders with strong “taste” for API design and make it explicit that no new API ships without their approval.
  
  • This lightweight gate reinforces that API design is a craft, not an afterthought, and that the company takes it seriously.
  • The process itself signals to new engineers that it’s okay to not get the design right the first time, but we learn fast and document why.
• Use stories to shape behavior and accountability. Narratives of past missteps serve as cautionary tales that encode judgment. When people start to move too fast or bypass review, pointing them back to these stories is more powerful than enforcing compliance.
  
  • If people are frustrated by the speed, point them to the story. Remind them why the tradeoff exists
  • Even dissenters (pirates) are valuable. Their complaints often surface valid points or edge cases that force teams to revisit assumptions.
• Onboarding is the highest-leverage moment for culture transfer.
  
  • Startups often underinvest here, focusing on getting new hires productive immediately. But if you’re growing 100% year-over-year, half your company will be new every 12 months.
  • Thoughtful onboarding, even just one or two days, becomes a mechanism for cultural replication and reinforcement of judgment.
• Keep onboarding lean but intentional. Have two or three senior engineers or product leads share “lessons of taste”: the unwritten rules that shape decisions around design, architecture, or tradeoffs.
  
  • Pair talks with a few written artifacts that embody these lessons, such as internal postmortems, architecture notes, or past product retrospectives.
  • The goal is not to slow people down, but to give them a mental model of how the company thinks so they can act with context instead of guesswork.

Amplify the Superstars Within Your Team

• Jean-Denis emphasized that founders often underestimate the range of talent within their organizations, especially how much outsized impact a few exceptional people can have.
  
  • Plaid had an API review committee with some of their best engineers. But in reality, a few were just so much better at API design that Jean-Denis realized they should just do every API design, no matter the product area
• Instead of focusing solely on training everyone to the same level, he argued that founders should identify their true superstars and put them in positions to hit home runs repeatedly. A junior PM who consistently ships products customers love should be promoted and trusted with harder projects over a more senior PM whose performance is inconsistent.
  
  • The fastest path to progress isn’t training everyone to be world-class, it’s identifying and amplifying those who already are
• Jean-Denis warned founders against stepping away from their original superpower.
  
  • As companies scale, founders often stop doing the things that made their company great — writing code, talking to customers, or designing product surfaces — because they want to “move up” into leadership roles.
• Instead, keep founder-operators close to the work that drives the business forward,  even if that means being a hands-on IC again.

Framework: Rippling’s Quality Week

• Albert described Quality Week as one of Rippling’s key rituals for maintaining speed without sacrificing craftsmanship. Once a year, the company pauses regular work to focus entirely on fixing long-standing issues, improving developer tools, and reinforcing shared ownership of quality.
  
  • The purpose of this is to reinforce that speed and quality are not opposites and must coexist. It also normalizes direct feedback and accountability when code quality falls below expectations.
• How It Works:
  
  • Once a year, teams pause normal development for a full week dedicated to quality improvements. Engineers propose projects bottom-up (leadership does not dictate priorities).
  • Typical projects include:
    
    • Fixing painful internal APIs or developer tools.
    • Resolving customer bugs that never rise to the top of the backlog.
    • Improving CI pipelines or reducing tech debt.
  • All ideas are collected in a shared spreadsheet (now a Rippling app), and engineers self-organize around common pain points.
    
    • Engineers know the next five things they want to fix, you just have to give them the space
  • The event is designed to feel social and celebratory with T-shirts, banners, pizza, and Slack energy to make it visible that leadership truly values this focus. Engineers record Looms or short demos of their projects at the end of the week, regardless of size or scope.
  • The company holds a demo day and awards ceremony to highlight the best fixes, tools, and improvements.
• Cultural Impact
  
  • Reinforces a dual focus on speed + quality as part of Rippling’s DNA.
  • Encourages cross-team collaboration: engineers from different orgs often band together to solve shared issues.
  • Builds long-term velocity by addressing systemic friction that slows future development.
  • Creates visible wins that strengthen engineers’ sense of ownership and pride in the codebase.
• For smaller companies, Albert suggested lighter cadences such as a “Quality Afternoon” every four weeks instead of an annual event.

3. Hiring

Hiring Your First Engineering Manager

• Albert and Jean-Denis both emphasized that most companies wait too long to bring in their first true engineering manager: someone who models what “good management” looks like while staying close to the code.
• Most successful startups add their first manager around 20–25 engineers, once the founder can no longer directly manage every IC.
  
  • The trigger point is when communication and prioritization start breaking down, not when you simply feel busy
• Avoid over-hiring (e.g., a “VP from Google”). Teams often reject managers who are too abstracted and operate at too high of a level or are not technically credible.
  
  • Promoting unprepared ICs (“battlefield promotions”) often leads to burnout and reversals.
  • Conversely, hiring a big-company veteran risks teams possibly rejecting them if they can’t earn technical respect.
• Look for a high-slope leader (like someone who’s grown quickly from IC to tech lead to manager) and can scale with you for several phases. They should be hands-on and capable of implementing lightweight process without stifling speed.
• The first great manager sets the tone for what management means at your company. They clarify expectations, coach new managers, and free the founders to focus on higher-leverage tasks.

Identifying the Right Role to Hire Next

• Jean Denis advises founders to begin by diagnosing what’s breaking rather than by defaulting to standard org templates or titles. Instead of hiring for specific titles, hire to solve bottlenecks. 
• Step 1: Diagnose the actual problem 
  
  • If org breakdown is happening due to prioritization or roadmap clarity, he suggests hiring strong engineering managers to own surface areas and decisions. 
  • If the issue in the org is due to technical depth, he suggests hiring domain experts (for example, a billing PM if you need to expand internationally)
  • If the issue is due to hiring or recruiting velocity, he suggests hiring a charismatic Head of Engineering to be able to repeatedly attract top talent
• Step 2: Don’t Over-Specialize Early
  
  • Avoid replicating big-company titles or making role definitions too rigid. 
    
    • Jean Denis compares this to “cooking at home” as opposed to “working at a Michelin Star Restaurant”. Early teams need generalists who can own full problems end-to-end, not specialists for different silos. 
• Step 3: Match Roles to Stage, Not Org Charts
  
  • Specialized roles (TPM, EM, TL, etc.) become valuable only after the org grows large enough to justify domain segmentation.
  • Before 50 engineers, flexibility and clarity of ownership matter more than formal structure.

Your Hiring Process Should Get You Strong Signal

• Jean-Denis believes that most early interview loops are too weak to identify world-class talent, especially in technically complex domains. If you’re repeatedly hiring engineers or managers who underperform, it’s likely the interview process isn’t producing true signal.
• Ways to Strengthen Signal in Your Hiring Process:
  
  • Work Trials:
    
    • Run short 2–3 day working sessions where candidates collaborate directly with the team. These can be hard to get candidates to commit to, but are usually great filters for future performance. 
    • Provides a more realistic view of judgment, collaboration, and technical depth than whiteboard or take-home tests.
  • References:
    
    • Backchannel references are usually more revealing than formal references
    • Reach out to trusted mutuals who’ve worked with the candidate directly.
    • These are usually some of the strongest predictors of someone’s ability
  • Structured Take-Homes:
    
    • For technical roles, scoped tasks that mirror real company challenges often yield far more predictive signal than generic coding exercises.

How to Onboard Well

• Jean-Denis explained that hiring in waves naturally creates strain on the existing team. The faster the company grows, the more chaotic onboarding becomes, and there’s no way to eliminate that entirely. It’s just a function of scale.
• The key variable to focus on is ramp-up time, not just the number of hires.
  
  • In healthy organizations, new engineers reach full productivity in about three months.
  • One month is excellent; anything beyond three months signals deeper issues in onboarding or technical architecture.
  • If onboarding takes too long, the problem is often insufficient mentorship or an unclear technical structure.
• To improve ramp-up speed, he suggested focusing on three levers:
  
  • Structured onboarding: Create clear, repeatable processes that help new hires understand the system deeply enough to start contributing early.
  • Assigned mentors: Each new engineer should have a directly responsible individual ensuring they’re productive and integrated within the first month.
  • Team design: Organize teams in ways that minimize dependencies. For instance, horizontally scoped teams (working on one layer or component) allow new hires to ramp faster than vertically integrated teams that touch every part of the stack.
• He cautions founders against overreacting to temporary drops in productivity.
  
  • During the first three months of rapid hiring, velocity will likely flatten or dip. That’s normal.
  • What matters is whether, once ramped, new hires contribute close to one full engineer’s worth of output (ideally around 0.9x efficiency per person when factoring in ramp-up costs and coordination overhead).
• Albert added that hiring faster than 100% year-over-year tends to break systems because new people start to outnumber seasoned employees.
  
  • When that happens, institutional memory and quality decline temporarily, and the company “picks up a ton of destruction in the wake of it.”
  • He advised not to exceed 100% growth per year unless there’s a clear plan for onboarding and mentorship.
• On interns, Albert noted that even at large scale, the capacity to absorb interns is limited.
  
  • As a rough benchmark, no more than 20% of your full-time engineering headcount should be interns at once.
  • At Rippling’s size (1,000+ engineers), that translates to about 15 interns in winter and 15 in summer—around 5% of the org at a time.
  • Dropbox’s early years illustrated the danger of overhiring interns: each intern required nearly a full-time engineer for code reviews and mentorship, halting org-wide productivity.

Learn to Fire Well

• Jean-Denis argued that firing decisively is a superpower for early-stage founders and becomes harder as the org scales.
• Up to roughly 50–75 people, the founder personally knows every team member’s work and can make clear calls on performance. After that point, layers of management slow down performance management.
• The founder’s ability to make early calls on performance management when the company is still young is a superpower. Managers are often worse at firing people than founders.
  
  • When the company is small, the founder still knows who’s good, who’s bad, and what work everyone is doing, and can make those calls clearly.
• Bad hires are inevitable. Success depends on how quickly you correct them.
• Accept that 40–50% of early hires may not work out. It’s a normal part of startup life.
  
  • Early on, this gives founders more flexibility to take hiring risks, since they can quickly part ways with people who aren’t working out.
• To fire well, be direct, humane, and fast:
  
  • Say clearly: I’m sorry it’s not working out. You no longer have a job at this organization.
  • You can make the process more humane by offering fair severance, such as waiving the cliff or adding an extra month.
  • Avoid delaying hard decisions behind HR processes like PIPs or formal warnings; they don’t apply at early-stage scale.
• Jean-Denis added that strong hiring signal reduces the frequency of firing but never eliminates it.
  
  • Use work trials (2–3 days) or take-home projects to get a more realistic signal of judgment and collaboration.
  • Do backchannel references; they’re often the most reliable indicator of true excellence.
• Albert noted a common challenge founders face as they scale are battlefield promotions.
  
  • Early engineers are often promoted into management before they’re ready, simply because they know the company.
  • Many of these transitions fail, and the individual ends up leaving, not because they’re bad, but because they weren’t supported or ready.
  • Occasionally, bringing in an experienced external manager who has done it before but isn’t too senior can help set the bar.
  • A short work trial can be invaluable here: have them sit with your team to see if they can actually jam and add value.

Build a Pipeline of Future Managers

• You should intentionally seed the team with people who could one day step into management. This helps you avoid the classic dilemma of one day having to choose between promoting ICs who dislike people management or risk hiring external managers who lack org context
  
  • By pre-vetting a few people for people skills or leadership potential, you de-risk both scenarios
• To do this, during early hiring prioritize EQ alongside technical ability.
• Hire one or two engineers who have managed before but are willing to IC for a year. These will become your future “battle-tested” managers. Also identify internal candidates who show natural coaching ability, strong communication skills, or cross-team empathy.
• Promote from within only once you have a model of good management (from your first strong manager or director).
  
  • You should also support new managers with mentorship and clear expectations. Don’t assume they’ll figure it out alone

Supporting First-Time Engineering Managers

• Jean-Denis emphasized that promoting first-time managers is always a risk, especially when the founders themselves have limited management experience.
  
  • New managers often need a coach or mentor to teach them the basics of people leadership.
  • This can be done through an external coach (for example, a senior manager or former director who meets weekly) or an internal mentor who has managed before.
  • If none of the founders have prior management experience, this is where a head of engineering or VP Eng can be especially valuable in building that muscle across the org.
• Early engineering organizations should aim for a roughly even mix of internal promotions and external hires over time.
  
  • Many strong early hires can grow into managers, but not all will scale.
  • External hires bring structure and pattern recognition, while internal promotions maintain cultural continuity and trust.
• When you’re small, most of your eng team’s issues will actually be technical prioritization issues, and any people issues can be resolved by not having two people work together for a while.
• Jean-Denis explained that it’s common for strong staff engineers to be great at project direction but weak at the “pure management” aspects like firing, performance management, and hiring.
  
  • Senior engineers often have strong communication and influence skills, which make them effective IC leaders but don’t automatically translate to comfort with conflict or accountability.
  • Promoting them into management without support risks losing both a great engineer and gaining a mediocre manager.
• Founders have two main paths:
  
  • Option 1: Remove performance management responsibility. Treat these staff engineers as tech leads or mentors, not true people managers. The founder (or another senior leader) keeps responsibility for performance management and tough conversations until the org matures.
  • Option 2: Develop them deliberately into real managers. If the company needs them to manage, founders must invest in structured coaching. This can take several forms:
  • Hire an external coach or mentor with hands-on management experience to guide them weekly.
  • Hold them accountable to develop the skillset through direct oversight. For example, having them draft talking points to deliver hard feedback, deliver it, and then debrief with you immediately with a report afterward.
• Jean-Denis also cautioned founders that if they know performance issues exist, the responsibility sits with them.
  
  • When a manager hesitates to act, the founder must intervene directly.
• He isn’t a fan of hiring managers driving pipeline. Instead, he prefers recruiting teams and VPs generating pipeline and hiring managers driving candidates through the process.
• It’s unrealistic to expect early engineering managers, especially those leading infrastructure or backend teams, to also be deeply commercial. 
  
  • Their strengths lie in building reliable systems, reducing costs, and defining technical SLAs, not in owning business outcomes. While having someone who’s both technical and commercial is ideal, it’s quite rare and not worth optimizing for.
  •  The priority should be managers who are technically credible and operationally strong; commercial instincts can come later or sit closer to product engineering or with the founder.
• Albert added that one of the most effective tools at Rippling is the Talent Check-In. It’s a lightweight, recurring process to force reflection and action with busy managers:
  
  • Every six weeks, each manager spends five minutes per report rating them as off-track, on-track, or exceptional.
  • They then meet as a small leadership group to review results and decide what actions to take: who needs coaching, who deserves recognition, and where tough conversations are required.
  • This keeps performance management from slipping through the cracks when managers are busy firefighting.
• Albert shared that at Segment, he and the CTO did a similar exercise by rating everyone 0–10 and comparing notes 

When to Hire PMs, TPMs, and Technical Leaders 

• Jean-Denis shared his view that early-stage startups should resist hiring PMs too early, as great product decisions at that stage depend on intuition and direct customer proximity, not metrics or process
• In pre–product–market–fit environments, most PMs struggle without data or established user signals. Product judgment at that stage is more artistic than analytical.
  
  • Roles like Billing, Internationalization, or Privacy can support early PMs because they follow repeatable, well-understood patterns.
• For core product work, founders and product-minded engineers or designers should stay close to users and own decisions directly.
• TLM (Tech Lead Manager): Managers who code and lead technically, When you’re small, you want this.
• TPM (Technical Program Manager): Only necessary once you have >100-200 engineers and cross-functional workstreams that span many teams.
• Pure managers detached from the tech should be avoided early; as AI-assisted coding grows, technical credibility in leadership becomes even more critical.
• Ideal Early Team Composition:
  
  • Strong ICs with leadership potential.
  • 2-3 strong designers tightly integrated with engineering.
  • Founders or tech leads driving core product decisions until deep PMF exists
• Your early team will likely need a VP of Eng if the founder doesn’t like hiring/isn’t the right person to build the engineering team. This is usually a harder role to hire for and you’ll likely have to move on from the first person you hire 40% of the time. 

Tech Lead vs. People Manager

• Jean-Denis explained that whether to promote an IC into a people manager or a tech lead depends entirely on the company’s immediate needs and team composition.
• If the team is made up of senior engineers who are independent, collaborative, and don’t need much people support, it’s often better to promote someone into a tech lead role rather than a full people manager.
  
  • The tech lead focuses on project prioritization, technical direction, and coordination across engineers, while the founder continues to handle light-touch one-on-ones to stay connected to individuals.
  • In contrast, if the founder no longer has time to meet with each engineer regularly, or if the team requires more active career support and feedback, it makes sense to promote someone into a people manager role who can absorb that responsibility.
    
    • This person takes over recurring one-on-ones, feedback loops, and personal development discussions, freeing up the founder’s bandwidth.
• The best case is when promotions can happen in stages rather than all at once.
  
  • Start by giving someone tech lead responsibilities, then have them mentor junior engineers.
  • If they demonstrate empathy, communication skills, and an interest in people development, transition them into a formal management role later.
• However, many startups don’t have the luxury of time for a gradual path and must rely on “battlefield promotions” where ICs learn management on the job.

Managing Battlefield Promotions

• Albert emphasized that even with battlefield promotions, structure and checkpoints matter.
  
  • At Rippling, roughly half of the staff-level engineers who stepped into management did so through a structured trial process.
  • The company built a plan with defined checkpoints: after two or three milestones, leadership would check in with both the new manager and their team to assess progress.
  • If the team reported that things weren’t working, the conversation happened early, well before performance issues escalated.
• The goal is to create closed-loop feedback instead of open-loop promotions. A common mistake is to promote someone, assign them new responsibilities, and then fail to check in until months later when problems have compounded.
  
  • By contrast, Rippling’s process explicitly included a plan to evaluate the transition after 2–4 weeks and again at the next phase, ensuring both the manager and team had space to adjust or unwind the change.
• Jean-Denis added that founders must stay personally accountable for how these transitions go. Promoting a manager doesn’t remove the founder’s responsibility; it just shifts the scope.
  
  • Instead of managing five individuals directly, you now manage one person and their relationship with those five individuals.
  • This only saves about 50% of your time, not all of it. You still need to invest in coaching, oversight, and feedback.
• Both agreed that some battlefield promotions will fail, and founders should plan for that upfront. The point is to learn early and correct fast, not to avoid all mistakes.
  
  • A failed experiment in management is recoverable if caught quickly and handled with honesty.

CEO/CTO Coaches

• Albert and Jean-Denis both shared that they worked with Joe Dunn
  
  • Jean-Denis emphasized that finding a good coach is not about landing on one person who “solves everything.” You should talk to multiple coaches to gauge fit, ensuring their experience aligns with your company’s stage and your goals.
• He also mentioned that for early-stage engineering managers, platforms like Plato or similar services can be helpful, as they connect teams to experienced startup mentors who have managed before.
• Both noted that external coaching should be treated as an interim solution. The long-term goal is to have your VP of Engineering and senior managers act as the internal mentors and coaches for the next layer of leaders.

4. Head of Engineering

When to Hire a Head of Engineering

• Hire a Head of Engineering once the founder or CTO can no longer personally manage all engineers
  
  • This typically happens around 20–30 engineers or post-Series B
• At this stage, engineering complexity begins to outpace founder bandwidth and coordination, hiring quality, or performance management start breaking down.

Start by Defining the Gaps You’re Solving

• Founders should start by identifying what problems the new leader must solve.

• At Rippling, before Albert joined, the company had scale but lacked a consistent, high-quality hiring process. Parker recognized this gap and specifically sought someone with exceptional recruiting and scaling skills.
• Founders should involve key engineers and product leaders to pinpoint pain points

Two-Year vs. Four-Year Candidates

• Founders often face the choice of hiring a “two-year” or “four-year” candidate.
  
  • Four-year candidate: has managed 150–200 engineers, scaled orgs through multiple growth phases, and can stay longer-term. These hires are rare, take 9–12 months to close, and are difficult to convince to join a smaller stage.
  • Two-year candidate: has managed 50–75 engineers, is hungry for their first VP-level role, and can effectively scale the company for 18–24 months.
• Founders should meet both types:
  
  • Use senior candidates to pressure-test your thinking and gather market context.
  • Evaluate rising managers for near-term fit and readiness.
• If you suspect the hire is a “two-year” candidate, say so explicitly in the recruiting process. Avoid pretending they’ll run the whole thing forever.
  
  • Strong candidates will respond positively and work hard so you won’t need to layer them
  • Clarity on timeframe prevents future ego conflicts and misaligned expectations.

When a Candidate Is Beyond Their Sweet Spot

• Many leaders eventually hit a ceiling where the company’s scale outpaces their experience.
• Founders should continually assess whether their Head of Engineering is learning faster than the company is growing.
  
  • If not, it’s better to layer proactively than to wait until the org’s performance drifts.

Build a Rigorous Recruiting Process

• Even at Rippling, executive searches took 4–6 months and required dozens of conversations.
• Founders should first do their own outreach to understand the talent market before engaging a search firm.
  
  • Once a firm is engaged, they typically present an initial “burst” of strong candidates that slows over time. This is where you have the highest likelihood of finding your exec candidate
  • Expect a 4–6 month timeline for VP-level searches even with top recruiting help.
  • Founders should balance urgency with patience. Rushing leads to poor fits, but waiting too long risks operational slowdown.
  • Albert noted that if Rippling took months to find the right person, earlier-stage startups should expect it to take even longer
• To refine your interview process:
  
  • Run full interview loops with a few lower-probability candidates to debug the process.
  • Avoid repetitive, generic questions between rounds; focus on questions that will give you the most signal around leadership judgment, recruiting ability, and scaling experience.
• Assess both cultural compatibility and hard skills (whether they can execute on the specific problems your company faces now).

Backchannel Relentlessly

• Rippling’s rule of thumb is to keep running backchannels until at least one person gives critical feedback. If everyone only says positive things, you haven’t dug deeply enough.
  
  • The goal isn’t to find perfection, but to uncover the candidate’s weak spots 

Founder–Head of Engineering Relationship

• The relationship must be built on fast feedback loops and trust.
• Founders should spend significant time with candidates 
  
  • This involves multi-hour working sessions and informal conversations to test for chemistry and communication style.
  • If the early conversations feel strained or unnatural, trust your gut. It rarely improves post-hire.

‍