Taro Logo

How to sequence activities to reduce risk?

Profile picture
Anonymous User at Taro Community3 months ago

I watched the video What Makes A Truly Great Tech Lead. I am particularly interested in the point: "Great TLs sequence their project in such a way that all the highest risk things get knocked out first". Can you please give examples of doing that in a real life? 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?

8 Likes
752 Views
5 Comments

Discussion

(5 comments)
  • Alex Chiou
    Robinhood, Meta, Course Hero, PayPal
    3 months ago

    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).

    1 Like
  • Architect
    Architect [OP]
    Self
    3 months ago

    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?

    0 Likes
  • Alex Chiou
    Robinhood, Meta, Course Hero, PayPal
    3 months ago

    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.

    1 Like
  • Senior Software Engineer [L5]
    2 months ago

    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?

    0 Likes
  • Alex Chiou
    Tech Lead @ Robinhood, Meta, Course Hero, PayPal
    2 months ago

    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.
    5 Likes