Manage tight timelines | Marshall Shen

Manage tight timelines

Manage tight timelines

Tight timelines are common in the technology industry. In a world where technology is everywhere, speed and quality are essential elements of a successful company. Delivering sophisticated products with speed and quality requires collaboration and execution of a group of people. We can apply several principles in managing a project with a tight timeline.

Start with an end goal. What does shipping this project look like? Imagine the various aspects when the project is shipped: the company’s reaction, team morale, and production maintenance. What is the best-case scenario? What is the worst-case scenario? Be super honest with ourselves about how we foresee the project outcome from various angles. Having such a clear and realistic picture is crucial because if a leader doesn’t have such a clear vision, the rest of the team won’t know where they are heading. By being explicit about best-case and worst-case scenarios, we can triangulate actions that optimize for the best-case scenarios while mitigating against the worst-case scenarios.

Design ownership on the project. A project, such as building new software, has multiple components that can be developed independently with agreed contracts on how those components should integrate later (e.g., API specifications). Managers should work with engineers to understand and define those components well. If the components are defined well, it should become evident what knowledge is required for each domain and who is best suited to own that component. Be cautious about dividing the components by purely following conventional wisdom. For example, when developing a mobile application, it’s really easy to design ownership around back-end API, iOS, and Android development. Although we might start dividing the ownership that way, we might need to adjust the ownership based on specific situations. For instance, instead of having engineers going back and forth on an API contract, it might be easier to let one engineer own both the API and mobile development for a feature. Pay attention to the progress and detail after the initial ownership, and adjust them if necessary.

Given specific ownership, be explicit about timeline and action items towards achieving that timeline. It’s a difficult but necessary conversation to have with the team about timelines (e.g., what and when a feature is due), and the conversation needs to be backed up by specific details. A great team doesn’t mind difficult discussions as long as it leads to well-defined problems and feasible expectations. As managers, we need to prepare for those difficult conversations with details - put ourselves in the engineers’ shoes, what would we wish to know as engineers - and do our best to answer those questions before the meeting started.

Be wary of the negative cycle of too many meetings. People tend to feel rushed in a tight timeline. When people rush, confusion amounts. When confusion amounts, people like to schedule more meetings to clear up the confusion. More meetings take away development time and make the project fall further behind. Managers should try best to understand the context and drive outcomes of meetings. Make action items out of each meeting, and defend people’s time when a meeting is not necessary.

Stay tuned to team morale. Burnout happens under a tight timeline. When we experience burnout, we feel unmotivated and make more mistakes. One way to prevent burnout is to be intentional about setting time blocks for team members to take time off. Proactively ask team members if they would like to take some time off during a specific week when there’s extra time for the project.

Communicate often about team problems and progress. Have a specific format on how to communicate outside of the team. If there’s an established common language or process, do our best to understand that and communicate the team’s progress using that format. In addition, expose problems early (e.g., feature A is falling behind by one week) so that we are less surprised later. This is hard to do because our human instinct tends to avoid sharing bad news. But exposing problems forcing us to confront reality, which is the first step towards solving a problem. By exposing issues early, we hold ourselves accountable and give ourselves more time to solve them.