Taro Logo
27

How can I better proactively account for risks in my projects?

Profile picture
Mid-Level Software Engineer [L4] at Google2 years ago

I've hit a lot of issues pretty deep into the project's execution that hold it up. It can come as late as running the A/B test where we find a big problem that delays everything and takes weeks to solve. This messes up the initial estimates I set up.

Part of this is because I transitioned between teams recently: On my previous team, it was easier to set up components and test them early, but in this current team, it's hard to get real signal until everything is set-up and we run a full end-to-end test.

Lastly, if I hit an issue like this, how can I minimize its effect on my performance and restructure the timeline in an acceptable way?

925
1

Discussion

(1 comment)
  • 20
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    2 years ago
    • Make sure to allocate ample time for planning - Back at Meta, I would allocate as much as 3 weeks just for planning, especially for very large projects with heavy XFN needs. A lot of being proactive is being able to think clearly in a focused way. Not having enough time with a rushed timeline puts you in a very reactive, frantic state.
    • Bring as many people together as you can - In big companies like Google, there's going to be tons of deep connections between teams and their components that are non-obvious. The tech specs I wrote at Meta would also cc a ton of people, just to make sure I scoured every possible relevant avenue. You can leverage your manager/TL to figure out all the people you should give a heads up to as you're planning the project.
    • Look for recurring themes in past project retros - Once you find themes, very deliberately think about them as you're planning your own project. It's rare for a project to fail in a completely unique way compared to other projects the team has worked on historically.
    • Look into ways that you can decouple your team's systems - Make it so that you don't need a full end-to-end test before you're able to find issues. An example is creating a mock networking layer so the client can test its portion of the flow without full back-end support.
    • Stay calm and communicate well if things blow up - Mitigate the issue as much as possible and escalate as necessary. Make sure to allocate a lot of retro time to talk about this, so the team can learn from this and not repeat the same mistake in the future. Things blowing up is a natural part of life (especially at a crazy complicated and giant company like Google) - It's best to embrace it and steer a clear course forward.

    For more resources around effective project management and being a great tech lead:

Google is an American multinational technology company that focuses on search engine technology, online advertising, cloud computing, and much more. It is considered one of the Big Five technology companies.
Google86 questions