“I deliberately understaff every project” | Leadership lessons from Rippling’s $16B journey
Executive Summary
Matt MacInnis discusses firsthand diagnosis, product foundations, sequencing, context-specific metrics, useful feedback and learning from escalations. Selected third-party transcript coverage excludes understaffing prescriptions, death-march stories, personal wellbeing, investment claims, AI passages and numerical company results. Rippling examples are his accounts, unverified here. Untimed editorial topics are not video chapters.
Key Takeaways
Inspect the system before prescribing a fix
MacInnis describes changing his view after entering the product function rather than observing it from outside. He found basic needs that his earlier diagnosis missed. His lesson is to study the specific work and develop a hypothesis from what is actually happening.
Put foundations before later-stage optimization
He describes missing standards for test coverage and product inspection. Asking for sophisticated adoption tracking before those basics were in place skipped dependencies. The useful question is what must work first for the next improvement to matter.
Move with urgency in the right order
MacInnis says fast work still needs a sequence. Leading from concrete circumstances can reveal which steps unlock others. Urgency does not make a prerequisite disappear or justify importing a process that does not fit the current problem.
Adapt outside ideas before using them
He is reluctant to copy a product-management idea without breaking it into parts and understanding how it applies. Prior experience can provide patterns, but those patterns need a local test. A familiar framework is an input to reasoning rather than the answer by itself.
Match metrics to product maturity
He distinguishes products ready for adoption improvement from products still needing stability work. Adoption can matter greatly once the experience and instrumentation are sound. A uniform metric priority across every product can distract from the actual constraint.
Give useful feedback and allow discussion
MacInnis argues that withholding helpful feedback for personal comfort does not help a teammate improve. He also says his feedback remains open to questions and discussion. Directness is paired here with the possibility that another perspective changes the interpretation.
Use escalations to improve the system
He treats customer escalations as information about what is not working. The response should investigate the cause and the process that produced it, rather than only close the immediate ticket. Individual problems can therefore teach the organization where its build process needs to change.
The Conversation Breakdown
Inspect the system before prescribing a fix
⏱ Untimed topicMacInnis describes changing his view after entering the product function rather than observing it from outside. He found basic needs that his earlier diagnosis missed. His lesson is to study the specific work and develop a hypothesis from what is actually happening.
Put foundations before later-stage optimization
⏱ Untimed topicHe describes missing standards for test coverage and product inspection. Asking for sophisticated adoption tracking before those basics were in place skipped dependencies. The useful question is what must work first for the next improvement to matter.
Move with urgency in the right order
⏱ Untimed topicMacInnis says fast work still needs a sequence. Leading from concrete circumstances can reveal which steps unlock others. Urgency does not make a prerequisite disappear or justify importing a process that does not fit the current problem.
Adapt outside ideas before using them
⏱ Untimed topicHe is reluctant to copy a product-management idea without breaking it into parts and understanding how it applies. Prior experience can provide patterns, but those patterns need a local test. A familiar framework is an input to reasoning rather than the answer by itself.
Match metrics to product maturity
⏱ Untimed topicHe distinguishes products ready for adoption improvement from products still needing stability work. Adoption can matter greatly once the experience and instrumentation are sound. A uniform metric priority across every product can distract from the actual constraint.
Give useful feedback and allow discussion
⏱ Untimed topicMacInnis argues that withholding helpful feedback for personal comfort does not help a teammate improve. He also says his feedback remains open to questions and discussion. Directness is paired here with the possibility that another perspective changes the interpretation.
Use escalations to improve the system
⏱ Untimed topicHe treats customer escalations as information about what is not working. The response should investigate the cause and the process that produced it, rather than only close the immediate ticket. Individual problems can therefore teach the organization where its build process needs to change.
Core Frameworks & Ideas
Firsthand system diagnosis
Observe the work and identify missing basics before choosing a fix.
Maturity-based metric choice
Prioritize stability or adoption according to the product's actual constraint.
Escalation-to-process learning
Trace an immediate problem into the process that produced it and improve that process.
Actionable Next Steps
- ✓Inspect one product workflow before recommending a change.
- ✓List the prerequisites for the next planned metric improvement.
- ✓Check whether adoption or stability is the current constraint.
- ✓Use a customer escalation to investigate a repeatable process problem.
Notable Quotes
“The lesson is that everything must be done in its time and order, and you can move really, really quickly.”
“You got to lead from the specific circumstances you observe.”
“Fundamentally, the most selfish thing you can do is withhold feedback from someone.”
The One Thing to Remember
Study the specific system and its prerequisites before prescribing the next product improvement.