How I ship projects at big tech companies

Summary

Summarized wtih ChatGPT

Shipping projects at big tech companies requires focus on leadership satisfaction, not just completing code. A single responsible engineer, often a technical lead, is crucial for guiding the project to successful delivery. Effective communication and early deployment help maintain trust and ensure projects ship smoothly.

Key Takeaways:

1. Prioritize making leadership happy over polishing code.
2. Ensure one person is accountable for the overall project.
3. Deploy early and often to anticipate and address potential issues.

Highlights from Article

The default state of a project is to not ship: to be delayed indefinitely, cancelled, or to go out half-baked and burst into flames. Projects do not ship automatically once all the code has been written or all the Jira tickets closed. They ship because someone takes up the difficult and delicate job of shipping them.

• Completing projects is very difficult.

In my experience, projects almost always ship because one single person makes them ship. To be clear, that person doesn’t write all the code or do all the work, and I’m not saying the project could ship without an entire team behind it. But it’s really important that one person on the project has an end-to-end understanding of the whole thing: how it hangs together technically, and what product or business purpose it serves.

• This is easier with the accountability that comes with one (technical) owner.

Concretely, that means that a project is shipped when the important people at your company believe it is shipped. If you deploy your system, but your manager or VP or CEO is very unhappy with it, you did not ship.

• The goalpost isn’t the metric, it’s the signoff. Signoff can help.

First, you have to get clear on what the company is looking to get out of the project.

• First step to doing this well is understanding why the project is happening (which sets which parameters are focused on when shipping to get signoff)

That means they will be trusting you for estimates, to answer technical questions, and to anticipate technical problems.

• Second important part is to answer questions and give solid estimates. Keep the trust!

The best thing is a track record of having shipped in the past, if you can get it Project confidence (if you’re visibly worried, they will be too) Project competence. You want to aim for something like a NASA mission control vibe Communicate professionally and concisely, and don’t make them chase you for updates: post a daily or weekly thread somewhere

• Have the experience that invokes confidence, be confident, manage the project obsessively, and communicate frequently

The key thing is to get whatever you’re building in front of as many eyes as possible: yours, but also other engineers, and ideally leadership, product, design and so on. Five minutes playing with the actual feature, even in a very rough state, will bring up issues that nobody anticipated. Being able to directly see it themselves also does wonders for reassuring leadership that you’ve got things under control.

Remember, your main priority is maintaining trust with your leadership team.

All material owns to the authors, of course. If I’m highlighting or writing notes on this, I mostly likely recommend reading the original article, of course.

See other recent things I’ve read here.