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

Question

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?

Alex Chiou · Accepted Answer

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:  What Makes A Truly Great Tech Lead - A VP of Engineering's Perspective How can I minimize thrash when I present technical designs for my projects? How to sequence activities to reduce risk?

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

Discussion