How can I be a better partner to product managers on my team?
I recently completed a project where I was the sole IC on the project. The project mainly involved migrating logic from a legacy service but involved integrating with a service managed by another team. I was responsible for the design of solution, estimating a timeline and delivery of the project (writing the code and testing).
Unfortunately, I ran into errors last minute and had to communicate delays a day before the expected completion date. We also ran into a tricky error post launch but I failed to communicate an expected deadline after the cause of the bug was identified. My manager and I have spoken on potential strategies and the need to communicate expected completion time.
My question here: What can I do a better in the future? When driving a project, how are you structuring your work so errors are surfaced as early as possible? How are you communicating risks and concerns that come up during a project?
Discussion
(1 comment)- 4
a year agoAndroid Engineer @ RobinhoodIt's impossible to completely avoid last minutes errors for every project: we often don't see bottlenecks, bugs, and/or errors until we're knees deep into implementation. This is a reality that every lead/owner ends up having to eventually accept, but we should always analyze the nature of how the error came about to avoid similar issues for the next project. For your particular scenario, the breakdown of questions I'd have would be:
- Could this bug have been caught and prevented earlier? There's generally multiple layers of process in a project that we can catch issues in: design review, code review, unit tests, intergration tests, bug bashes are the main ones top of my mind. Looking at the bug and the state of your company's software development process, could this bug have been caught in an earlier part of the software development process? Could processes be introduced or better improved to catch these issues?
- Were there direct controls that were planned around that would derisk the migration? Migrations are always risky to perform: one overlooked piece of business logic in a migration could lead to a different (often times, broken) flow of code for customers, so there should always be controls & rollout plans to mitigate the potential negative impact caused from failure. Questions I have for this would be: is the migration behind a feature gate, was an incremental % or whitelist based rollout possible (and planned), and did you plan for when the migration has to be rolled back?
- How are you communicating progress? Are you communicating progress only when critical events happen (hitting milestones/when issues come up) or are you proactively communicating progress at a fixed interval? From my experience, the former is often why "communication" issues are called out: if communication is only focused on the highlights & lowlights, issues often times feel more jarring because there's a lack of visibility on what potentially built up to the issue. Management may not always know exactly what's going on, but they do want paper trails when issues come up.
- And mostly importantly, are you going to retrospectively think about the issue and share those thoughts out to the team? There's 2 standard processes in the SDLC for retrospectively thinking about issues: a SEV report or a retrospective. From my very high level view, it seems like this was a last minute issue so I would except a SEV report at the very least. Regardless of how you end up retrospecting, you need to call out: why this issue happened, what was the overall impact on the business, and how will the team/company look to prevent similar issues in the future. You can use the previous bullet points I have to get a rough starting point on what questions your retrospection should look to answer.
Without being directly involved in your project, I can't give as nuanced of a response as I'd like. But I do hope this feedback helps give you a clearer sense of how to proactively and reactively respond to issues when they come up.
