Table of Contents
Sean Goedecke reveals why shipping success depends more on management perception than customer satisfaction, and how technical strength becomes a superpower for navigating complex organizational dynamics.
Successful project shipping at large companies requires understanding that "shipping" is a socially constructed fact—your management chain must believe the project is shipped, not just customers.
Key Takeaways
- Shipping means making your management chain happy with project outcomes, which should align with customer happiness in healthy companies
- Projects have a narrow path to success and millions of paths to failure—the default state is failure without active intervention
- Technical skills matter more than soft skills for shipping, but you need both to navigate organizational complexity effectively
- Speed is crucial because delays create more opportunities for project-killing events to occur
- One person must have the entire technical context in their head for complex multi-team projects to succeed
- GenAI tools excel at getting you 80% of the way quickly, especially in unfamiliar codebases or technologies
- Remote work success requires high agency, async communication skills, and alignment with company goals over personal preferences
- Building trust with leadership comes primarily from consistent delivery and maintaining capacity for high-priority work
Timeline Overview
- 00:00–01:50 — Intro: Introduction to Sean Goedecke and his viral blog post about shipping projects at big tech
- 01:50–05:35 — What does shipping mean?: Shipping as a socially constructed fact dependent on management perception
- 05:35–09:20 — Reasons management may choose to ship something customers don't love: AI positioning, regulatory compliance, and business necessities
- 09:20–13:27 — A humbling learning from Sean's time at Zendesk: Six months maintaining staging tests that management didn't care about
- 13:27–15:28 — The importance of learning which rules need to be broken for good business outcomes: Understanding when rules are soft versus hard constraints
- 15:28–18:13 — Common obstacles to shipping: Coordination failures, forgotten details, and dependency misalignments across 5-25 teams
- 18:13–23:06 — DRI: Directly responsible individual: Why one engineer must hold complete technical context for project success
- 23:06–28:44 — The value of strong technical skills and why moving fast is imperative: Technical strength as connection to reality and speed as project survival
- 28:44–32:16 — How to leverage your technical skills the right way: Going beyond code cleanup to solve business problems through direct stakeholder engagement
- 32:16–36:10 — Advice on earning the trust of leadership: Consistent delivery, maintaining capacity, and learning management communication styles
- 36:10–38:30 — A time Gergely shipped a product for a political reason: Box-ticking exercise requiring strategic trade-offs and clear communication
- 38:30–41:08 — What GenAI helps software engineers do more easily: Speed advantages and 80% solutions in unfamiliar domains
- 41:08–43:20 — Sean's thoughts on GenAI making engineers more ambitious: Personal project ambition versus workplace caution
- 43:20–46:10 — The difficulty of building AI tools: LLMs, hallucinations, and rapidly evolving technical landscape challenges
- 46:10–52:34 — Advantages of working remotely and strategies for making it work: Follow-the-sun development, async communication, and clear handoffs
- 52:34–54:48 — Who is best suited to remote work: High agency, comfort with isolation, and strong written communication skills
- 54:48–56:45 — How the pandemic provided a remote work trial for Sean: Melbourne lockdowns as unintentional remote work preparation
- 56:45–END — Rapid questions: Ruby on Rails advocacy and book recommendations
Redefining What "Shipping" Actually Means
Sean's most controversial insight challenges engineers' fundamental assumptions about project success, shifting focus from technical delivery to organizational perception.
- Shipping is a "socially constructed fact" that occurs when your management chain believes and talks about the project as shipped
- Deploying code to production doesn't mean shipping—you can deploy a complete disaster that management considers failed
- The metric for shipping success scales with project scope: manager approval for small projects, CEO satisfaction for large initiatives
- This definition frustrates engineers because it relinquishes control over success metrics, making outcomes dependent on reception rather than technical quality
- In healthy companies, management wants customer happiness because it drives revenue, creating natural alignment between management and customer satisfaction
- Understanding this reality with "open eyes" leads to better project planning and more successful outcomes than assuming technical delivery equals success
This perspective forces engineers to think beyond code quality toward organizational impact and stakeholder satisfaction.
When Management Ships Things Customers Don't Like
Strategic business decisions sometimes require shipping features that compromise customer experience, illustrating the complexity of large company priorities.
- AI positioning requirements may force box-ticking features that users don't appreciate but are necessary for market positioning
- Security and regulatory compliance often create user experience friction that's legally or contractually required
- FedRAMP compliance, for example, requires API key expiration policies that users find inconvenient but are mandatory for government contracts
- Senior engineers must "suck it up" and prioritize company goals over personal project preferences when business stakes are high
- Management has context about company positioning, financial pressures, and strategic requirements that individual engineers may lack
- These decisions become easier to accept when engineers understand the broader business context driving apparently customer-hostile choices
The key insight is that apparent conflicts between customer and business interests often reflect incomplete information rather than fundamental misalignment.
The Staging Tests Lesson: When Companies Don't Care About Your Priorities
Sean's experience maintaining unreliable staging tests for six months illustrates how engineers can invest heavily in work that doesn't align with company priorities.
- Six months of dedicated effort keeping staging tests green felt like important engineering craft work but received minimal recognition
- The breaking point came when Sean's manager casually suggested not fixing broken tests, triggering anger and immediate resume updating
- The revelation occurred during a critical deployment when red tests were simply ignored in favor of manual testing and immediate shipping
- This experience taught that rules written down as procedures aren't immutable facts—they're soft constraints that bend when business needs require it
- Companies will find ways to ship critical code regardless of process obstacles, revealing what truly matters versus what's merely preferred
- The sunk cost fallacy made Sean feel the work had to be important because of the time invested, but company priorities don't adjust to individual effort
This lesson demonstrates the importance of understanding which company priorities are real versus aspirational before investing significant effort.
Technical Skills as a Superpower in Large Organizations
Technical strength provides unique advantages in large companies by connecting engineers to reality and enabling rapid problem-solving that cuts through organizational complexity.
- Technical demos can "move mountains" and resolve weeks of theoretical discussions about feasibility through concrete proof-of-concept work
- Strong technical skills create a "superpower" by connecting engineers to actual product reality rather than abstract strategy discussions
- Non-technical managers and stakeholders rely on technically strong engineers to unlock the "multiplicative factor" of strategic and marketing work
- The ability to quickly understand and modify unfamiliar codebases becomes crucial when projects require coordination across 5-25 teams
- Speed of reaction and communication matters enormously because delays create more opportunities for project-killing events to occur
- Technical surface area across multiple domains allows engineers to become force multipliers for business stakeholders who lack implementation ability
The most impactful engineers combine technical strength with willingness to apply it toward business problems rather than just code quality improvements.
The Critical Role of the Directly Responsible Individual (DRI)
Complex multi-team projects succeed because one individual maintains complete technical context, not because teams coordinate effectively through process alone.
- Projects ship because one engineer has the entire technical structure in their head, enabling them to anticipate problems and answer questions quickly
- This role often becomes formalized as the DRI (Directly Responsible Individual) who takes technical responsibility for project success
- Coordination requires both program management (ensuring teams communicate and commit to dates) and technical integration (understanding how pieces fit together)
- TPMs handle the first type of coordination, but an actual engineer must handle technical coordination because the complexity requires deep technical understanding
- Whether this becomes "your job" officially, performing this role consistently builds trust and leads to higher-profile project assignments
- The narrow path to project success requires someone actively dragging projects "kicking and screaming to the finish line" rather than hoping coordination emerges naturally
This insight explains why some engineers become known as reliable project drivers while others struggle to deliver despite strong individual contribution.
Strategic Application of Technical Skills
The most successful engineers apply their technical strength toward business problems rather than purely technical improvements, maximizing their organizational impact.
- Going directly to stakeholders (skip-level managers, PMs, designers) to ask "what needs doing?" can surface high-impact work that doesn't appear in typical backlogs
- Fixing persistent customer support issues demonstrates technical capability while solving real business problems
- Building quick technical demos for uncertain product ideas can unlock weeks of strategic discussion and planning work
- Working on unfamiliar codebases (load balancers, admin tools, infrastructure) provides opportunities to apply GenAI tools effectively where domain expertise is lacking
- The key is willingness to "put technical strength in service of people who have thought hard about what needs doing but don't have technical skill to do it"
- This approach may circumvent established processes, requiring political sensitivity but often delivering disproportionate impact
The balance involves surfacing technical capability in ways that solve business problems rather than just improving code quality metrics.
Building Trust Through Consistent Delivery
Leadership trust develops primarily through shipping reliability rather than technical perfection, requiring strategic capacity management and effective communication.
- The best way to maintain trust is to ship consistently and deliver on commitments, building a reputation for technical strength and reliability
- Maintaining 60-80% regular capacity allows for 120-130% effort on high-visibility projects when they arise, rather than staying at constant 120% utilization
- Learning to communicate like management ("circle back," "synergize") may feel uncomfortable but enables receiving crucial project context
- Understanding project purpose (box-ticking, new user acquisition, enterprise requirements, executive vision) determines appropriate quality and feature trade-offs
- Managers won't share sensitive context unless they trust your communication discretion and business judgment
- Building this trust requires asking about trade-offs using business language rather than engineering terminology ("user experience trade-offs" versus "crappy UI")
The investment in management communication skills pays dividends through access to strategic context that improves technical decision-making.
GenAI's Impact on Software Engineering Workflows
AI tools excel at providing speed and 80% solutions, particularly valuable for shipping projects that require work across unfamiliar domains and codebases.
- GenAI's primary value is speed—getting 80% of the way to solutions quickly rather than achieving perfection
- Tools like GitHub Copilot and ChatGPT shine when working in languages, frameworks, or codebases where you lack deep expertise
- Building internal admin tools, working with company load balancers, or prototyping in new technologies becomes dramatically faster with AI assistance
- Personal project ambition increases significantly because previously time-consuming experiments (like multi-model poker simulations) become achievable in hours
- At work, caution remains appropriate because the hardest 20% of production software correctness often requires human expertise
- The learning potential through "endless questions to someone who never gets tired" transforms exploration of new technical domains
The tools prove most valuable for expanding technical surface area rather than replacing expertise in familiar domains.
Remote Work Strategies and Realities
Successful remote work, especially across time zones, requires specific personality traits and organizational approaches that not all engineers or companies can effectively implement.
- Follow-the-sun development can double project speed through effective handoffs between US and APAC engineering teams
- 24/7 bug fixing capabilities create exceptional user experiences where problems reported in the afternoon are resolved overnight
- Async-first communication becomes essential—engineers must be comfortable both writing and reading RFCs, memos, and technical documentation
- High agency and comfort with isolation are crucial personality traits for remote success, especially when working solo across time zones
- Companies benefit from hiring clusters of engineers in the same time zone rather than isolated individuals to provide peer support and collaboration
- Deep work advantages in quieter afternoon hours can offset the challenge of busy morning catch-up periods
The approach works best for engineers who naturally thrive in written communication environments and can maintain motivation without constant social interaction.
Common Questions
Q: What does "shipping" actually mean in big tech companies?
A: Shipping occurs when your management chain believes and talks about the project as successfully delivered, not just when you deploy code to production.
Q: Are technical skills or soft skills more important for shipping projects?
A: Technical skills are more important because you can't understand projects end-to-end or react quickly to problems without strong technical foundation, but soft skills are needed for organizational navigation.
Q: How do you handle projects where multiple teams need to coordinate?
A: One engineer (the DRI) must maintain complete technical context in their head to anticipate problems and coordinate technical decisions across teams.
Q: What's the best way to build trust with leadership?
A: Ship consistently, maintain capacity for high-priority work, and learn to communicate using business language to access strategic context.
Q: How does GenAI change software engineering work?
A: AI excels at providing speed and 80% solutions, especially valuable when working in unfamiliar codebases or technologies, but the hardest 20% still requires human expertise.
Conclusion
Sean Goedecke's insights reveal that shipping projects at large tech companies requires understanding the social and political dimensions of technical work. Success depends on aligning technical excellence with organizational priorities, maintaining awareness of business context, and building trust through consistent delivery.
The most successful engineers combine deep technical skills with strategic thinking about how to apply those skills toward business problems. They understand that perfect code that doesn't serve company priorities is less valuable than imperfect solutions that address real business needs.
Most importantly, Sean's experience demonstrates that remote work and complex project delivery are achievable with the right combination of technical skills, communication practices, and organizational alignment. The key is maintaining high agency while staying connected to what the company actually needs to succeed.
Practical Implications
- Understand that shipping success depends on management perception, not just technical delivery—align your work with what leadership cares about
- Maintain complete technical context for your projects rather than relying on coordination to emerge naturally from process
- Apply technical skills strategically toward business problems by engaging directly with stakeholders when appropriate
- Build trust through consistent delivery while maintaining capacity for high-priority work when it emerges
- Learn to communicate using business language to access strategic context that improves technical decision-making
- Use GenAI tools to expand your technical surface area and work more quickly in unfamiliar domains
- For remote work, focus on async communication skills and ensure you're part of a time zone cluster rather than working in isolation
- Recognize that rules and processes are often soft constraints that bend when business needs require flexibility
- Speed matters enormously because delays create more opportunities for project-killing events to occur
- One person must be willing to take responsibility for project success rather than hoping it emerges from team coordination
