27
How can I better proactively account for risks in my projects?
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?
913913 Views
11 Comment
Discussion
(1 comment)- 202 years agoTech Lead @ Robinhood, Meta, Course Hero
- 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:
