Roadmap decisions rather than dates. | Irrational Exuberance<br>One thing that bothered me about Imprint’s product after joining was our lack of passkey support.<br>Passkey support is a rare opportunity to increase resiliency to phishing attacks<br>while simultaneously reducing login friction. If it’s good for our members, our partners, and our product,<br>it felt like something we should have already shipped.<br>Nonetheless, it was hard to get it onto the roadmap alongside everything else we were working on.<br>To dig into passkeys, I started sketching out the implementation as a side quest.<br>Some iterations later, I had something implemented behind a disabled feature flag for team review.<br>At that point, most problems had a concrete solution implemented, and the remaining issues<br>were messy intersections between passkey implementation and user experience.<br>Issues remained, but the tangible implementation made tradeoffs explicit, and we were able to work through them.<br>Soon thereafter, we launched passkeys to a small group in our web experience,<br>iterated on feedback, finalized the details, and brought those details forward to our native<br>mobile experiences as well.<br>It never got onto the roadmap, but it did ship.<br>Our passkey release planted a seed for me, but it required another experience to fully germinate.<br>We had a discussion about hitting a date for a product extension we’re developing.<br>Our conversation kept anchoring on the idea that pulling in a date was dependent on pushing out dates for other<br>projects. Presenting two conflicting projects as requiring timeline tradeoffs wouldn’t have caused me<br>to blink an eye five years ago, but in this conversation it inspired a sort of instinctual revolt:<br>with modern development techniques, I believe very few projects are essentially constrained by execution bandwidth.<br>Some are constrained by approvals, others are constrained by cross-team and cross-functional handoffs,<br>and many are constrained by missing decisions, but almost none should be constrained purely on time.<br>Shifting blocks of time across projects to speed up delivery felt wholly divorced from the reality<br>I work in.<br>Grappling with my frustration for some time didn’t lead to a profound awakening, but<br>it did help me bring together my thoughts about how effective modern organizations operate.<br>The modern organization operates most effectively by orienting itself around highly empowered teams who broaden their capabilities to<br>absorb cross-team and cross-functional handoffs,<br>can rely on automated harnesses to address most remaining cross-functional approvals,<br>and accelerate high-quality decision making through rapid prototyping.<br>The premise here is an old one, but AI-tooling has shifted what’s possible in remarkable ways.<br>Reducing handoffs with team and individual accountability<br>In 1975, Fred Brooks’s The Mythical Man-Month<br>warned us that adding individuals to a late project makes that project even later rather than speeding it up.<br>However well-understood this is, it remains extremely common for leaders to repeat this mistake, even today.<br>My personal theory is that most leaders performing the “ask for more staffing” gambit intuitively know they are optimizing to<br>“get stuck” in a way that shifts responsibility off them because they didn’t get the requested funding,<br>rather than that there is no way to accomplish the task at hand.<br>Even if teams avoid the simplest versions of the mythical man-month’s trap, organizations that operate through<br>strict ownership of defined boundaries introduce the same problem.<br>Well, of course your team can’t launch that without approval from the architecture team and the security team and performing<br>a user research study. That’s not really your team’s ownership area, you’ll need approval from the membership accounts team, at a minimum!<br>Agile, with the idea of collective code ownership, rejected this idea in principle, although certainly it remains messy in practice.<br>Even with strong AI-enhanced workflows, I still find human review of load-bearing technical decisions (e.g. a decision that will<br>meaningfully impact subsequent decisions) to be extremely valuable. This is why the highly-empowered team model is an effective<br>compromise: there needs to be an experienced engineer whose perspective is infused into the architecture, who shares the team’s<br>context, and who is aligned with the team’s priorities. This creates space for earlier career folks to be highly effective,<br>while also allowing teams to largely operate independently across complex, intersecting goals.<br>The final piece of driving accountability is rejecting the argument that a problem is too confusing or too hard for someone to know the consequences of their work.<br>There are a lot of hard problems, and that’s what makes creating software such an interesting job.<br>However, in a world with infinite feedback readily available, even if that...