Shipping projects at Big Tech with Sean Goedecke

Stream the Latest Episode

Available now on Spotify, YouTube and Apple. See the episode transcript at the top of this page.

Brought to You By

DX⁠ → DX is an engineering intelligence platform designed by leading researchers. Check out their unified framework for measuring developer productivity: the DX Core 4

—

In This Episode

In today’s episode of The Pragmatic Engineer, I’m joined by Sean Goedecke, Staff Software Engineer at GitHub. I learned about Sean after reading his viral blog post, “How I ship projects at big tech companies.” In our conversation, he shares how to successfully deliver projects in large tech companies. Drawing from his experiences at GitHub and Zendesk, Sean reflects on key lessons learned, and we discuss the following topics:

• Why shipping cannot exclude keeping management happy

• How to work on stuff the company actually values

• Why you should take on extra responsibility to get projects done

• Why technical skills are still more important than soft skills

• Soft skills you should learn: including learning the “management lingo”

• First-hand remote work learnings: advantages, disadvantages, and how to thrive in this setup

• … and much more!

Takeaways

My biggest takeaways from this practical conversation:

1. Getting things done starts by being technical. Sean’s original article got plenty of criticism because it talks so much about the “soft” part of the job of a tech lead. Many readers assume that Sean implies that things like managing up are more important than being a good engineer. But this is not the case.

Being technical – and being able to build and ship solid code – is where “getting stuff done” starts. Being technical is necessary – but not sufficient to be seen as someone who gets things done in larger companies.

2. You can move mountains if you proactively build technical demos. If you can help product or design folks create prototypes they can use – or show: this is a great way to make yourself indispensable and get more visibility across your team or organization.

So, work on this skill! Build prototypes when you can on the side, pairing with, e.g. product folks or other people from the business.

3. As a tech lead: learn the “management lingo.” Engineering leadership and product management will oftentimes speak less directly at larger companies, especially in writing. To be an efficient tech lead, you need to both understand this language – and read between the lines. Speaking it “back” to managers will help you do so.

How do you do this? Spend time with managers, note the phrases they use, make note of ones that you’re unsure what they mean, and consider getting a mentor in the org: such as a PM or a TPM.

4. Software projects “want to fail” – unless you intervene! Sean observed how the default state of a project would be to fail: because so many things can trip projects up.

As a team member – or a tech lead – figure out the various ways the project could fail, and mitigate these risks. You can do this by doing proper planning, prototyping unknown parts, over-communicating with dependencies – and just being a little “paranoid” about ways things could go wrong.

5. When working as a remote engineer, you could need to “absorb” the company’s goals more. Sean shared interesting and candid thoughts about succeeding as a remote engineer. There are a few realities of remote software engineers:

• The number of full-remote positions is shrinking. This means that it’s harder to get a full-remote position, should your current one not work out.

• In some regions, full-remote positions are extremely rare. Sean’s example is a good one: not many tech companies are hiring for full-remote engineers in Australia!

This means that there’s a lot of competition for remote engineering positions, and it’s easier to backfill than it is for in-office positions. So expectations will naturally be higher. Sean suggests taking your role very seriously and:

• Avoid pushing your own goals against the company’s goals

• Absorb the company’s own goals, and be proactive in helping make them happen

High agency is expected as a remote engineer – so take the lead!

The Pragmatic Engineer deepdives relevant for this episode

• Software Engineers Leading Projects

• Shipping to production

• Paying down tech debt

Timestamps

(00:00) Intro

(01:50) What is shipping?

(05:35) Reasons management may choose to ship something customers don’t love

(09:20) A humbling learning from Sean’s time at Zendesk

(13:27) The importance of learning which rules need to be broken for good business outcomes

(15:28) Common obstacles to shipping

(18:13) DRI: Directly responsible individual

(23:06) The value of strong technical skills and why moving fast is imperative

(28:44) How to leverage your technical skills the right way

(32:16) Advice on earning the trust of leadership

(36:10) A time Gergely shipped a product for a political reason

(38:30) What GenAI helps software engineers do more easily

(41:08) Sean’s thoughts on GenAI making engineers more ambitious

(43:20) The difficulty of building AI tools

(46:10) Advantages of working remotely and strategies for making it work

(52:34) Who is best suited to remote work

(54:48) How the pandemic provided a remote work trial for Sean

(56:45) Rapid questions

Resources & Mentions

Where to find Sean Goedecke:

• X: https://x.com/sjgoedecke

• LinkedIn: https://www.linkedin.com/in/sean-goedecke-5495a7137/

• Website: https://www.seangoedecke.com/

• GitHub: https://github.com/sgoedecke

Mentions during the episode:

• Agile Manifesto: https://agilemanifesto.org/

• FedRamp: https://www.fedramp.gov/

• Zendesk: https://www.zendesk.com/

• GitHub Copilot: https://github.com/features/copilot

• ChatGPT: https://chatgpt.com/

• Ruby: https://www.ruby-lang.org/

• Ruby on Rails: https://rubyonrails.org/

• Golang: https://go.dev/

• AI tools for software engineers, but without the hype – with Simon Willison (co-creator of Django): https://newsletter.pragmaticengineer.com/p/ai-tools-for-software-engineers-simon-willison

• Applied AI Software Engineering: RAG: https://newsletter.pragmaticengineer.com/p/rag

• RAG vs. Fine-tuning: https://www.ibm.com/think/topics/rag-vs-fine-tuning

• APAC: https://en.wikipedia.org/wiki/Asia%E2%80%93Pacific

• The Little Book of Deep Learning: https://fleuret.org/public/lbdl.pdf

• The Name of the Rose: https://www.amazon.com/Name-Rose-Umberto-Eco/dp/0544176561