Can you discuss your approach to managing stakeholders in the event of a project delay or setback?

Typically Stakeholders at Acutance are :

a) Cloud Ops

b) DBAs

c) Product Managers

d) Leadership team

There are different approaches I took - based on the stakeholder I had to interact 

For Cloud Ops and DBAs I had thier resource embedded into my team, so that we can move fast.

For PMs - I had engaged them during Planning meetings - working closely with them to do estimation and figuring out dependencies of features. During the execution phase, I had a week meeting and also a report on the progess and risks for the project.

For leadership - there was a weekly sync with org SDMs we would discuss the challenges or blocking issues we are working on and then there was a Montly report on the operational status and the development of our features our team owned.

During the crucial period of one of the project, the cloud eng. assigned to our team left the company, this caused a delay in our sprint execution. I communicated about this delay to Product Managers and my leadership - and the risks associated to customer impact. I also offered alternate solutions we are exploring to minimize the risks.

By establishing multiple channels - though meetings and through weekly/monthly reports I ensured tha the stakeholders are aware of the blocking issues and pro-active steps I am taking to reduce the risks. 

In order to manage stakeholder expectations - I need to have a clear communication channels. At Motorola, I worked closely with my Product Managers to set a clear expectation on what features my team can realistically complete with in a give time period. Always had a risk assesment in the meetings. I set up several channels to get this done - 1. A Weekly report on the progress 2. End of sprint demo to ensure that the PM has a good understanding on where we are headed 3.Daily standup sync, if there is any issues 4. Slack as informal mode of communication 5. Weekly product sync to discuss what is coming up in the pipeline and any reprioritization that needs to be done for subsequent sprints. These constant communication with stakeholder helped me resolve any conflicts before it became an issue. Above all, I had that human connection which was super important to me. By following these steps I could manage stakeholder expectations and maintain positive relationship

Yeah, so let me break it down in terms of the first part of the question, which is who are typically my stakeholders. So I often work with startups, in which case stakeholders are often my CEO, my co-founders, cross-functional partners in design, marketing, at times compliance and legal, and then oftentimes just the investors, straight up. And for the second part of the question, you asked what's a time that we didn't meet expectations in a timely manner, and how do I go about managing their expectations, right? And concretely what that looked like, my process is essentially getting the status report internally, get all the details. Two, present that information, communicate what the situation is. Three, manage expectations in terms of what we believe we'll be able to get done, what the next steps are to remedy, and when we can get back on track. Four, have milestones and metrics in order to inform our progress, so make sure we're on track for the next milestone. And five, support and follow-up in terms of I'm blocking my team, keeping everyone in the loop, and making sure having a retrospective on the next cycle when we did or did not meet those expectations. So concretely what this looked like was there was a cycle at Dendron, this company where I was an engineering manager essentially for a team of 10, and we had not yet found product-market fit in terms of finding the right users, needed to hit retention metrics of a very high percentage, and this was taking more time than expected. This is like the most important metric for any startup. So internally, well, I talked with the team and it looks like, yeah, we're mixed it, where there's an interesting hypothesis developing around what's possible, and we have figured out possible next steps in terms of new features that we wanted to build. We brought this information to our meetings with our investors, and we were able to say, look, these metrics look promising, and we're developing new hypotheses, new features to test in those. So we were able to keep them up-to-date on what our progress was, what our plan was going to be, and we had these metrics in terms of goals we wanted to hit. For example, we wanted to hit 70% four-week retention on these metrics, these milestones, and we were able to inform them in the next couple of weeks on our progress with respect to those metrics. And concretely, we were able to engineer these solutions, in particular with infrastructure engineers, actually, for this note-taking app that we were building. So we realized a lot of parts that they were missing was they didn't need to context switch, so we built features that allowed them to take notes as efficiently as possible on the configurations or whatever they're working on without context switching out of that engineering mode. And we were able to deliver and grew retention from something like 50% to 70% within that particular niche, and we were able to get the buy-in and the trust of all those stakeholders back again.