The default state of a project is to not ship and you are paid to combat that. Shipping has to come first, before Customer Experience and praising engineers. If you deploy something but the leadership team is unhappy with it, you did not ship. If you ship something users hate and makes no money, but your leadership team is happy, you still shipped. Shipping doesn’t mean deploying code, it means making your leadership team happy. Deploy early, constantly ask yourself if you can ship right this second. If you can't, what needs to be changed? Engineers who think shipping means delivering a spec or deploying code will repeatedly engineer their way into failed ships. You must have a deep technical understanding, remove any ambiguity possible, and keep time for implementation as well as last minute issues. Your leadership doesn't know if potential technical problems are serious or not, you have to step up to address it or they will side for caution and cancel the project. Get clear on what the company is looking to get out of the project: more money from some users, more money from all users, grow the user base, a leadership pet project. Prefer working on leadership trust and communication rather than meeting deadlines for the same reason that it is better to be the engineer who hotfixes an incident than preventing it. Leadership trusts your estimates and expects you to anticipate technical problems as well as to answer technical questions. Maintaining leadership's trust should be your top priority. One person on the project, often called Tech Lead, must have end-to-end understanding of the whole thing, how it hangs together technically and what product or business purpose it serves. Keep leadership's trust by keeping a past record of past ships, having confidence in the project, having competence related to the project and communicating professionally, concisely, often. Put what you build in front of as many eyes as possible (yours, other engineers, product, design, leadership, etc.) by playing with the actual features for a few minutes, to bring up issues, and reassure leadership. Nothing builds trust like having fallback plans because they indicate control over the situation in case of emergency. Leadership will be more likely to interpret the delay as an unavoidable problem that you handled effectively instead of as a mistake you made that means they can’t rely on you. Don't fear, deploy as much as you can as early as possible and do the scariest changes as early as you can possibly do them. You have the most end-to-end context on the project which means you should be the least scared of scary changes. Everyone else is dealing with more unknowns and is going to be even less keen to pull the big lever.
Sean GoedeckeWe are communicating with the world around us all the time and yet, we misstep often. Really listen to build on what others say. Ask detailed questions to show genuine interest. Choose words wisely so they are well interpreted. Be genuine, authentic, transparent, to resonate in every interaction.
Jenn BuchYour activation metric doesn’t have to be perfect, choose something your team can rally around. Don’t outsource your critical thinking, prioritize time to think about strategies and decisions. Pressure is a privilege. When faced with high-stakes situations, acknowledge the opportunity that comes with it. Create a central, canonical document for each project that outlines key information: work streams, owners, processes, and meeting norms. Prioritize hiring disagreeable givers, people who are committed to the organization’s success but aren’t afraid to voice differing opinions.
Naomi Gleit