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 being a tech lead for projects at these companies, I would always try to get the ball rolling on securing approvals in these areas first as these discussions almost always 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.

Connecting it to a programming analogy, you can think of it like multi-threading:

• XFN tasks should be spun up as separate threads outside of the main thread (i.e. engineering work)
• You want to do it as early as possible to minimize long-running threads from blocking the overall "program" from finishing (i.e. completion of the full project)
• Stronger tech leads and engineers in general are able to spin up more threads concurrently to maximize productivity (i.e. multi-task)

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 I made to learn more about these (it includes concrete examples): System Design Series: Taro Playlists [Part 7] - How Can Things REALLY Break?

For the full system design series, you can find it here: System Design Masterclass: Taro Playlists

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 (tech leading) 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.

A huge mindset shift every engineer must make to become a tech lead is to develop a strong sense of holistic ownership and feel deeply responsible for everything in a project, not just the stack-specific slice applicable to them. I have seen so many engineers struggle with this going from mid-level to senior, and this was something that admittedly took me a while to get as well.

For more resources around being an effective tech lead, I recommend these:

• What Makes A Truly Great Tech Lead - A VP of Engineering's Perspective
• [Case Study] Becoming A Tech Lead Again In Just 1 Month After Joining Robinhood From Meta