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?
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: