Bookend leadership
05 Oct 2026In an effort to avoid the “hey, can we talk about your PR for a minute”, which then dovetails into a 10 person meeting on a project you thought was narrowly scoped, I’m sharing a framework I use to help my senior engineers manage their time. I call it bookend leadership, this idea that as a senior member of a team, you have the most impact at the beginning and end of a project.
In the beginning, being involved while planning and design (both product and engineering) are in review gives you a chance to really help set the direction, identify issues and ensure you understand the scope on day 1. Later on, if you see a discrepancy in a PR, you can point back to the design document: “I thought we landed on doing X?”. If the code changed but the design doc didn’t, this is a good opportunity to meet w/ the DRI and regain context (and confidence) in this new path.
In the middle, your job is much simpler. PR and code changes shouldn’t surprise you. Rarely will you need to block a code change or be the bottleneck on implementation because you’ve already agreed to the design. Your job here is to make sure what’s being implemented meets your bar and the agreed upon contracts. It also prevents re-litigation on big ideas that can implode a project and people’s time. The reduced time and stress this produces is a welcome change because before this, senior engineers would scour PRs looking for the next big issue, where now they’re looking for big discrepancies from plans. It’s a much different day to day, and it cuts down the FUD for everyone, not just the seniors, since the DRI isn’t bracing for a surprise redesign in review.
In the end, when the feature is nearing completion and the team is holding bug bashes or release readiness reviews, this is also a great time for you to jump in. Does this release meet your bar? If it does, great, if it doesn’t what would you want to see changed to get there? This is both a mentorship opportunity and a confidence building exercise for everyone involved.