DJ Chung

Generally, the engineering manager (EM) is more involved than the individual contributor (IC) engineers. First, before planning of individual features happen, I make sure the EM is involved and aligned when we are creating the product strategy of our team. Doing this makes getting alignment on individual features much easier because the engineering team knows what the higher level goals are and why we are going after those goals. I've found that in order to get buy in with engineering, I have to make sure the team understands why the work they are doing is important - how it ladders up to a bigger strategy or goal.

This is a continual process! It is important to have regular syncs with the engineering team to discuss progress, open product questions, and review next steps. I don't think this can be done in stand ups, but rather having a weekly 30 min sync has worked for me. I don't think it's possible to spec out every single detail of a product up front. It's important that you have ~70-80% of the details defined before engineering starts work, but as you start to define the rest of the 20%, sync with the engineering team regulary so that you can clarify the scope. 

For a visible project that has the attention of upper leadership, I think of 3 checkpoints with leadership: 1. Showcasing the vision at the beginning of the project Once I have nailed down the problem to solve, why it's important to solve, how it contributes to broader business goals, and you have an idea of how you want to solve it i.e. conceptual mocks - I present the vision for the project to get alignment with upper leaderships. While I'm getting this ready, I will make sure to keep my manager and other key stakeholders in the loop to get their feedback and refine the vision. 2. Reviewing detailed designs that we plan to implement Once I get feedback from the vision, we incorporate them into the designs that we plan to implement. Once we feel confident in the designs that we want to implement, we do another review to make sure leaderships understands at some level of detail what will actually ship and when. 3. Weekly updates on project progress Once we're aligned on the detailed designs and start building, we send out weekly updates on our progress. This allows leadership to chime in if clarification is needed. Note: If at any point there's a major change in the product direction because of new information, I make sure to communicate up to leadership and schedule a meeting if needed. 4. Feature has shipped and measuring impact I make sure to communicate timelines on when the feature will ship and when it shipps, I make sure to emphsiaze in our update that the feature has gone out the door and is in the hands of users. Also, I try to follow up a few weeks or a month later with metrics that show the impact of the feature.

At the beginning of the project. Before we start implementation, I make sure to define: * What problem are we trying to solve and for whom? * Why is this problem important to solve? * What is the business impact? * How does this project ladder up to the broader product/company strategy? * How will we measure success? 

Don't think there's a "right" ratio, but I would say 1 PM to 6-12 engineers is a good ratio. I think beyond 12 engineers, it gets a little difficult for a PM to stay on top of projects and the PM could become a bottlenect to project progress. I would also say 1 designer to 6-12 engineers is a good rule of thumb. 

Ideally you have the right market insights before you start building. However, if you have open questions, I encourage you to break down the project into smaller milestones you can ship that help you answer those questions. This way, you are continually shipping, but they are smaller in scope, but also helps you de-risk when there's a lack of clarity in market insights.