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?

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