Metadata
- Author: seangoedecke.com
- Full Title: How I Ship Projects at Big Tech Companies
- Category:#articles
- Document Note: Дельные мысли о доставке фич при разработке ПО.
- Document Tags: development Outline shipping Shipping
- Summary: Shipping projects in big tech companies is more about gaining leadership approval than just writing code. A single person, often a technical lead, must ensure the project meets goals and builds trust with management. To successfully ship, prioritize communication, anticipate problems, and deploy early.
- URL: https://www.seangoedecke.com/how-to-ship/
Highlights
-
The most common error I see is to assume that shipping is easy. 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. (View Highlight)
-
That means that in almost all cases, shipping has to come first. You cannot have anything else as your top priority. (View Highlight)
-
What does it mean to ship? It does not mean deploying code or even making a feature available to users. Shipping is a social construct within a company.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. (Maybe you shipped something, but you didn’t ship the actual project.) You only know you’ve shipped when your company’s leadership acknowledge you’ve shipped. (View Highlight)
-
So if your primary job when shipping something is to make your company’s leadership happy with the project, what does that mean in practice? First, you have to get clear on what the company is looking to get out of the project. (View Highlight)
-
Second, no matter the project goal, your leadership team (the people in your reporting chain who care about the project) will always have basically zero technical context about the project compared to you. That means they will be trusting you for estimates, to answer technical questions, and to anticipate technical problems. Maintaining that trust should be your top priority. (View Highlight)
-
How do you maintain trust with your leadership team? This could be a whole article (or book) by itself, but here’s my summary: • 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 (View Highlight)
-
It is much, much more important to do these things than for the project to ship with zero bugs on the exact deadline. If a project has to be delayed for technical reasons, in my experience you will not suffer consequences so long as you communicate it clearly, confidently (and ideally with some warning). (View Highlight)
-
You need to stay light on your feet so that when these issues come up you’re not neck-deep in other work. That usually means not being fully heads-down on implementation (i.e. delegating tasks to other engineers on the project). Ideally you should have at least 20% of your time free from implementation in the early stages of the project, scaling up to 90-100% in the final days. If you do that, when issues do come up you’ll be able to grant them your full attention. (View Highlight)
-
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. (View Highlight)
-
The best way to anticipate problems is to deploy early. (View Highlight)
-
I think a lot of engineers hold off on deploys essentially out of fear. If you want to ship, you need to do the exact opposite: you need to deploy as much as you can as early as possible, and you need to do the scariest changes as early as you can possibly do them. Remember that you have the most end-to-end context on the project, which means you should be the least scared of scary changes. (View Highlight)
-
Summary • Shipping is really hard and you have to make it your main priority if you want to ship • Shipping doesn’t mean deploying code, it means making your leadership team happy • You need your leadership team to trust you in order to ship • Most of the essential technical work is in anticipating problems and creating fallback plans • You should asking yourself “can I ship right this second?” • Have courage! (View Highlight)
📂 Articles | Последнее изменение: 23.01.2025 07:41