Describe a time your project lost focus

We're interested in understanding how you handle challenges in project management and maintain team focus. Tell me about a time when a project you were involved in lost focus. What were the contributing factors, and what steps did you take to regain focus and get the project back on track?

Answering: Describe a time your project lost focus

As a Senior Engineering Manager at Google, I've seen projects veer off course a few times. One particular instance stands out where we were developing a new feature for Google Maps related to real-time traffic incident reporting.

Situation

The initial goal was clear: allow users to report traffic incidents (accidents, road closures, etc.) directly within the Maps app, providing near real-time updates to other users in the vicinity. We had a tight deadline due to a competing product launching a similar feature. The core team consisted of five engineers, a product manager, and myself.

Task

My responsibility was to ensure the team stayed on track, delivered a high-quality product, and met the deadline. This involved managing resources, removing roadblocks, and keeping the team aligned on the project goals.

Action

Initially, the project progressed smoothly. We had a well-defined scope and a clear roadmap. However, about halfway through the development cycle, scope creep started to set in. Some engineers, driven by their own interests and technical curiosity, began exploring ancillary features. One engineer decided to experiment with integrating a more sophisticated machine learning model to automatically classify incident types based on user descriptions. Another started building a complex visualization dashboard to track the number and types of reports over time. A third wanted to refactor the entire data pipeline.

While these ideas were potentially valuable in the long run, they were not part of the core feature set and threatened to derail the project. The product manager, also, started entertaining requests from other teams who wanted their APIs integrated into the workflow.

I noticed the team's velocity slowing down, and discussions in stand-up meetings became less focused. It became apparent that we were losing sight of the initial objective.

To address this, I took the following steps:

1. Held a Project Reset Meeting: I called a meeting with the entire team and the product manager to re-emphasize the original project goals and deadlines. I reminded everyone of the strategic importance of launching the core feature on time.
2. Re-Prioritized Tasks: We reviewed the remaining tasks and explicitly labeled them as either "must-have" (essential for the initial launch) or "nice-to-have" (features that could be deferred to a later iteration). We ruthlessly cut the "nice-to-have" features that weren't critical to the initial launch.
3. Created a Feature Backlog: All the ideas for additional features were added to a separate backlog for future consideration. This allowed the team to capture those ideas without distracting them from the immediate priorities.
4. Increased Communication & Monitoring: I scheduled more frequent check-in meetings with individual engineers to monitor progress and provide support. I used the opportunity to reiterate the importance of focusing on the core features.
5. Protected the Team: I pushed back on all the requests from other teams who wanted to tack on API integrations. The product manager and I agreed to shield the team from those requests until the project launched.

Result

By taking these actions, we were able to regain focus and get the project back on track. We successfully launched the core traffic incident reporting feature on time. While some of the "nice-to-have" features were delayed, they were eventually implemented in subsequent iterations. The project successfully launched on time, and we saw a significant increase in user engagement with the map.

More importantly, the experience taught me the importance of proactive project management, clear communication, and unwavering focus on the core objectives. It also highlighted the value of creating a safe space for engineers to voice their ideas without fear of derailing the project. I learned that it's crucial to manage expectations, both internally and externally, and to be willing to say "no" to scope creep in order to achieve the desired outcome.