Summary

Gracefully managing risks in project delivery is key to success, especially when you have challenging deadlines. Even in high complexity projects with no strict deadlines you can manage to align expectations, arrange to deliver a simpler MVP or be creative with what you are delivering. But what happens when you have a deadline you can't negotiate with? In some cases you have to guarantee the delivery within a deadline no matter what, so take responsibility over it.

Taking responsibility

Depending on your job description, it's obvious that you should take responsibility over delivery, particularly for Engineering Managers. But even if you are not directly accountable for it, for instance, TechLeads and Staff Engineers should share with their EMs the burden of deadlines. In order to make the best technical decisions for a project, you have to know the scope very well, including the project, the tech, the people and the deadline.

Make a plan and follow it

Make a plan! But be prepared with a fallback, you may have to follow your plan B or even your plan C, nonetheless write down and share the plan with your team, everyone should be aware of it. But what should you consider inside your plan?

First of all, what's the scope of features of the product you're delivering: be explicit with all features listed. Don't keep questions from your stakeholders, negotiate what you can, send some features for a following version if possible. But make sure you deeply know what product you are building.
Get to know your deadline: why did they choose this date as a deadline? Is it correlated with some strategic marketing date for the company? Is it explicitly agreed on a contract with an important client? Or is it just a random date chosen by some VIP? Sometimes you can negotiate deadlines, sometimes you don't, but it's important to know what's behind that specific date, as it will help you make some decisions. Maybe you can postpone it for some days, maybe you can reduce your feature list, but in some cases you will have to make rough technical decisions to avoid delaying the project.
Consider your team capabilities before writing your plan: how many developers are in your team? Do you need designers to collaborate with the project? Does someone have a scheduled vacation during the time frame? Can you count on everyone's full time dedication for the project?
The last step is indeed writing the plan: use the tool that pleases you, but write something down and then share it with your entire team. Be as detailed as you can, list the features, what will enter your first version, what will be delivered in a version 2, what are the known vacations and holidays, and add the negotiated steps with stakeholders and other players (perhaps the company has a staging phase before the deadline that you have to respect). Try to split the work in cards over the weeks or sprints arranged until the deadline and make sure what you gotta do is viable in the time frame. And don't forget to make an alternative plan if something goes off (you should be able to list the most probable things to go wrong in the planning phase).

Note: I am not saying you should always plan in detail several weeks or months ahead, especially in an agile culture company, but if you have a deadline you cannot miss, some agile rules might be broken, unfortunately.

Keep in mind your team’s strengths (and weaknesses)

Unless you are the EM of your team, you might ask: why should I take account of people related issues during a project? In a challenging project, every person counts and you should consider it even for technical decisions.

If you have to deliver some product in two months but two of the three developers are juniors, maybe it's not the right time to re-write that core part of the code the team is willing to do.

If one of the senior developers got a scheduled vacation during the project, maybe you will have to negotiate a temporary help from another team in order to keep the deadline.

If your team is not proficient with some fancy technology you wanted to use, maybe it's not the right time to use it.

No matter what your case, people related issues are not only for the EM. TechLeads and Staff Engineers should care as well and share the concerns with them.

Conclusion

As a TechLead or a Staff Engineer, you should consider planning ahead every time you get a complex project with a strict deadline. In those cases, don't wait for your EM to do the entire planning alone, as it can sabotage your own technical decisions.

Sharing responsibility with your EM and being prepared for it will guide you to the best decisions.
Make a plan, months ahead if needed. And don't spare details: consider the scope, the feature list, the technology, the people and the deadline.
Don't forget the people related issues. As a TL or Staff you never do the work alone, so know your team's strengths and weaknesses and use it in your favor.

Cover image by Martin from Pexels

Managing risks in project delivery