How to sequence activities to reduce risk?

Can you please give examples of doing that in a real life?

Back and Meta and Robinhood, legal/privacy/compliance were crucial towards shipping anything as both companies are highly scrutinized (and in Robinhood's case, it is legitimately very highly regulated as a brokerage).

When TLing projects at these companies, I would always try to get the ball rolling on securing approvals in these areas first as these discussions can take a lot of time. These tasks are often referred to as "XFN" (cross-functional) work items, and XFN factors are often the culprits when it comes to the riskiest things on a project.

What are some examples of activities that you found higher risk than others and therefore you decided to do them first to minimize the risk?

Adding on to the XFN point from before, there are a lot of tricky technical patterns to seriously think about and handle when designing systems. I recommend this system design video to learn more about these (which includes concrete examples).

Thanks, Alex. Re securing approvals of legal/privacy/compliance first, do you wait until you get approvals of these departments before starting the development work or you continue the development while waiting for XFN approvals to come?

You always want to sequence things in parallel whenever you can. You can still write code while securing an XFN approval. As a tech lead, it is your goal to make sure that those XFN discussions running "on the side" don't explode and ultimately land, so the bandwidth spent writing code wasn't for nothing.

Would it be accurate to say that a huge part of de-risking is building alignment between different stakeholders in a project, especially early on?

What are some common risks engineers tend to ignore but tend to blow up on our faces later?

Would it be accurate to say that a huge part of de-risking is building alignment between different stakeholders in a project, especially early on?

Yep! This is why I always start any project project I'm TL-ing with a kickoff meeting and a master spec.

What are some common risks engineers tend to ignore but tend to blow up on our faces later?

It's almost always stuff out of their comfort zone. The further away the issues are from their comfort zone, the more likely they are to miss it. I've seen missed angles across 3 different tiers - Let's illustrate with a back-end engineer trying to TL their first big project:

1. Technical issues outside of domain - The back-end engineer failed to recognize that the junior iOS engineer has scoped out their timeline to be far too aggressive and won't make it. The junior iOS finally understands they're in over their head just 1 week before the project. The team scrambles to find a senior iOS to support them in the final stretch, but the iOS portion is delivered over 1 week late.
2. Direct XFN product issues - This is usually product and design. In our example, the back-end engineer forgot to work with the designer to submit the product's designs through design review, a council of Staff+ designers who make sure that all product designs follow the company's overall design standards. They give feedback that completely changes the designs, delaying shipping by another 2 weeks.
3. Very distant XFN issues - This covers privacy, compliance, legal, and others. In our example, the back-end engineer should have talked with the compliance team early on about how to make the project GDPR compliant. A compliance specialist catches these problems a few days before the project ships as they happened to see a Slack project update in an XFN channel. They force the project through compliance review, delaying it by another month.