Code, Leadership & the Remote Dev Life

Tag: Project Management

  • Aligning Roadmaps With Team Capacity

    Aligning Roadmaps With Team Capacity

    Early in my career, roadmaps felt like a wishlist. Marketing wanted X, sales wanted Y, and we—engineering—were somehow supposed to make it all happen. And when we couldn’t, we were labeled blockers.

    It took years (and more than a few failed quarters) to realize the issue wasn’t execution. It was misalignment. We were promising more than our team could realistically deliver.

    Here’s what I’ve learned about making sure roadmaps aren’t just ambitious—they’re achievable.

    1. Start With Capacity, Not Deadlines

    Before locking in a roadmap, I now ask: “What can this team realistically handle over the next cycle?”

    Not what the business hopes for. Not what looks good on a slide.

    That means looking at:

    • Who’s available (and for how long)
    • Time already committed to support, bugs, or tech debt
    • The velocity you’ve actually observed, not idealized

    Setting the roadmap after capacity is understood isn’t pessimism—it’s adulting.

    2. Separate Strategy From Execution

    Leadership often confuses goals with commitments. Strategy says “we want to grow revenue by 30%.” Execution says “we need three new features to get there.”

    I’ve started drawing a bright line between the two. Strategy sets direction. Execution defines what the team can actually ship.

    If the roadmap doesn’t fit the team’s reality, something has to give—either the timeline, the features, or the resources.

    3. Build in Slack Time

    Every roadmap should include breathing room—for surprises, for iteration, for life.

    If your plan assumes everyone works at 100% capacity, 100% of the time, you’ve already failed. Someone will get sick. A requirement will change. Production will break.

    I typically plan for 70–80% of theoretical capacity. The rest goes to the stuff we can’t predict but always happens.

    4. Be Transparent With Stakeholders

    I’ve stopped sugarcoating what’s feasible. When a stakeholder asks, “Can we squeeze in one more thing?” I walk them through the cost:

    • What gets pushed out
    • What breaks our velocity
    • What causes burnouts

    Instead of just saying “no,” I show why it doesn’t fit—and offer choices. Sometimes, they prioritize differently. Other times, we push the timeline. Either way, they’re part of the decision, not just recipients of it.

    5. Review and Re-align Often

    Roadmaps aren’t static. Things shift—people leave, dependencies slip, goals evolve.

    I do biweekly check-ins to track:

    • Are we on track?
    • What’s blocked?
    • Has capacity changed?

    At work in Caseproof, we use EOS as our company’s “operating system” to help us regularly review and re-align our goals.

    These aren’t full replans—just touchpoints. They let us course-correct before we end up way off base.

    Roadmaps Aren’t Promises—They’re Plans

    If you treat the roadmap like a contract, every delay feels like a failure. But if you treat it like a plan, it becomes something your team and stakeholders can adjust together.

    Alignment doesn’t mean you can do everything. It means everyone knows what you’re doing, why you’re doing it, and what it will cost.

    When you get that right, your roadmap becomes more than a wishlist. It becomes a tool for trust.