Shipping at big tech is a social construct, not just a technical milestone. Sean Goedecke, a Staff Software Engineer at GitHub with prior experience at Zendesk, wrote a viral blog post titled “How I Ship Projects at Big Tech Companies” after observing that many engineers deliver code but fail to get recognition because they misunderstand what “shipping” actually means. In large organizations, a project is only considered shipped when the management chain—sometimes up to the CEO—believes and talks about it as shipped. This episode explores the real mechanics of getting projects across the line in complex, multi-team environments, and why technical skill, organizational awareness, and speed all matter.
What shipping really means
Shipping is defined by perception, not deployment. You can deploy code to production and still not have “shipped” if leadership doesn’t recognize or value it. Conversely, a project that leadership celebrates as shipped is shipped, regardless of how an engineer might feel about its technical quality.
This doesn’t mean ignoring customers. In healthy companies, management wants customers to be happy because that drives revenue. The apparent tension between “making the boss happy” and “making the user happy” usually dissolves when the company is well-run.
Sometimes leadership rightly ships things customers don’t love. Examples include:
Strategic positioning, like shipping an AI feature to remain competitive in a market, even if it’s not yet polished.
Security and regulatory compliance, such as FedRAMP requirements that force inconvenient changes like expiring API keys—users dislike it, but the company must do it to access government contracts.
Senior engineers are expected to prioritize company goals over personal preferences. This is a key transition at the staff+ level: recognizing that your job is to serve the organization’s needs, not just your own engineering ideals.
A humbling lesson from Zendesk
Sean spent six months obsessively maintaining flaky staging tests, fixing broken selectors, and keeping the test suite green—only to be told by his manager, after complaining in a meeting, “you just don’t have to fix them.”
He was so angry he left the meeting mid-sentence and updated his résumé. The experience felt like a betrayal of engineering craft.
The real learning came later: when a critical deployment needed to go out with red tests, the team simply manually tested the cases and deployed anyway. The “rule” of green tests before deployment was a soft rule that bent under business pressure.
Key takeaway: Rules about code quality are not immutable laws. When the company has a clear and present need, those rules will flex. If you care deeply about something the company doesn’t, that’s your misalignment to resolve—not the company’s.
Why most projects fail
The default state of a project is to fail. Projects only succeed because someone actively drags them to the finish line. Left alone, nine out of ten projects won’t ship.
Common obstacles are coordination failures nobody anticipated:
Forgetting a security review until a week before launch.
Two teams each assuming the other was building a critical component.
Relying on a service that’s actually in beta, or that can’t handle the required load.
Big tech shipping often requires 5–25 teams to coordinate. It only takes two teams being badly misaligned to sink the entire project.
The directly responsible individual (DRI)
Every successful large project has one engineer who holds the entire technical structure in their head. Projects don’t ship because teams coordinate—teams coordinate because one person understands the whole flow end to end and can anticipate problems.
This is the DRI (Directly Responsible Individual) model, often paired with a TPM for program management. The DRI is usually a senior or staff engineer whose job is to understand every piece of the project, how they connect, and where things can break.
It can feel thankless, but it’s not invisible. Managers notice who de-risks projects and delivers. Being known as someone who can be relied on leads to more impactful work and stronger promotion cases.
The best tech leads don’t just identify risks—they bring solutions. When a team says they need two weeks, an average tech lead negotiates it down; a great tech lead looks at the codebase, talks to the engineers, writes the unblocking diff themselves, and gets things moving the next day.
Technical skills vs. soft skills
Sean wrote about political skills because engineers already know technical skills matter—but he says technical skills are actually more important. You can only ship a project if you understand it end to end, and that requires deep technical ability.
Speed is the cardinal virtue of shipping. Not just implementation speed, but speed of reaction and communication. Every extra week is another week something can go wrong. Technical skill is what enables you to move fast—to answer questions from any angle, to pivot, to unblock teams.
Technical strength is a superpower in large companies because it connects you to reality. Many managers and stakeholders are non-technical; they do strategy and planning, but those plans only multiply in value when they lock into someone who can actually build things.
Ways to leverage technical skills more visibly:
Go talk directly to your skip-level, PM, or designer about what needs doing—don’t wait for plans to percolate through epics and tickets.
Fix quick wins for support, design, or product that aren’t on your team’s backlog.
Build a technical demo to cut through weeks of debate about whether something is possible. One working demo can blow people out of the water.
Be aware of the trade-off: Going around process can make your manager unhappy. If leadership pushes back, it’s worth understanding why—there may be an existential company problem you should be working on instead.
Earning and maintaining trust with leadership
The best way to build trust is to ship consistently. Delivering on visible, high-profile projects gets you put on more important work, creating a snowball effect.
Keep your regular workload at around 60–80% capacity so you have bandwidth to step up when something critical comes in. If you’re always at 120% burning down tickets, you won’t have the capacity to save a high-profile project.
Learn to communicate in management’s language. Using terms like “circle back” or “synergize” might feel slimy, but it signals that you understand how leadership thinks and makes it easier for them to share crucial context with you.
Understand what the project is actually for. A project might be for box-ticking an audit, attracting new users, extracting revenue from existing users, or satisfying a VP’s vision. Each requires a different approach—new user features need to be polished; enterprise features need inflexible compliance. You can only learn this by communicating in a way that makes management comfortable being honest with you.
A case study in shipping a politically motivated project
Gergely once shipped a product that made no business sense because an executive had struck a deal with another company. His PM was upfront: “We have to build it, we’ll retire it in a year, use a crappy UI, skip edge cases, just make it borderline work.”
Being transparent with the team about the constraints actually helped. The team deprioritized complexity, shipped quickly, had very few users as predicted, and retired the code 12 months later.
This only worked because of a high-trust relationship with the PM and the fact that the team was in a different office from HQ, where such candid conversations were easier to have.
How GenAI is changing shipping
GenAI’s biggest contribution is speed. It gets you 80% of the way quickly and provides volume for free. This matters because speed is the cardinal virtue of shipping.
It’s especially powerful for working across unfamiliar codebases. An engineer who knows Ruby on Rails deeply won’t be helped much by AI in their home codebase, but AI can be dramatically faster at writing Go in an unfamiliar load balancer repo—and shipping often requires touching many repos you don’t know well.
Sean uses it for prototyping and personal projects. He built a five-model Texas Hold’em simulator in a day that would have taken multiple days before. For learning, the ability to ask endless questions of something that never tires is transformative.
But GenAI hasn’t made Sean dramatically more ambitious at work because the hardest part of shipping is the final 20%—the correctness, integration, and edge-case handling that AI can’t reliably deliver.
Building AI tools is itself getting harder. LLMs are difficult to turn into reliable software due to hallucinations, the text modality, and the pace of change. The learning curve for concepts like evals, logits, and grammar enforcers is steep, and even colleagues are learning in real time.
Over time, AI literacy will become a standard part of software engineering, similar to how backend engineers are now expected to understand frontend concepts. Knowing what RAG pipelines and fine-tuning are will be table stakes.
Working across time zones
Sean is based in Australia, working with US-based teams. Being remote and in a minority time zone has trade-offs: it can make you more willing to align with company needs (fewer local job options), but it also creates unique advantages.
For nine months, Sean was the only APAC engineer on his team. His mornings were busy catching up on US handoffs, but his afternoons were clear for deep work—a structure that set him up for success.
Follow-the-sun handoffs can effectively double delivery speed for work with low handoff cost, like bug investigations. A bug reported by a US user in the afternoon can be fixed by APAC engineers overnight, so the user wakes up to a resolution.
Async-first communication is essential. Teams need to produce written artifacts, RFCs, and demos that can “speak” while you’re asleep. This requires people who are comfortable both writing and reading long-form documents.
Don’t hire just one person in a time zone. It’s a lonely experience and not for everyone. GitHub now has full APAC and US squads, which works much better.
Who thrives in full remote work
Sean is naturally comfortable going long periods without synchronous human interaction, which is a key trait for remote success. Many talented engineers flame out because they can’t stand the isolation.
The pandemic gave Sean a trial run. Melbourne had some of the world’s longest lockdowns, so by the time he joined GitHub, he already knew he could work from home effectively.
To keep a coveted remote role, you need to take the company’s goals seriously and make them your own. Engineers who insist on their own standards—perfect code, full test coverage, only working on preferred stacks—may find themselves at odds with the organization. Aligning with what the company needs is what keeps the arrangement sustainable.
Rapid fire
Favorite framework: Ruby on Rails. It’s not new or sexy, but it’s the most programmer-friendly way to build large web apps. GitHub is still largely a Ruby on Rails shop—almost every interaction on github.com goes through Rails.
Book recommendation:The Name of the Rose by Umberto Eco. It’s a murder mystery set in a 1300s Italian monastery that’s really about people doing their best in complicated systems—which resonates with the challenges of shipping in big tech.
