Don't make gates optional, make them flexible | Hacker News Reader

Don't make gates optional, make them flexible

wakamoleguy.com

50 pointswakamoleguy8 comments

Yes and the word you want isn't "flexible" it's "proportional".

A gate is best when it's proportional to what goes through it. Small project? The business case is "Pam thinks it's could be a good idea". Large project? The business case is a formal study. The word "proportional" makes it much easier for all the participants to understand that the gate is a sliding scale.

A compelling post. Something it doesn't mention that I immediately wonder about is how you ensure the decision to escalate from "a quick DM" to a "full business case review" (or whatever) isn't unreasonably biased.

If everyone is working with good intent then this doesn't matter. But the real world is full of unconscious 'isms so I suspect there's a risk that underrepresented folks are more likely to trip the extra process flag and thereby get slowed down disproportionately, leading to negative feedback loops.

That's a really good question. This may also end up depending on the level of trust within the team. One thing I didn't call out is that an "optional gate" can still just be checked by sending a DM, like "Hey, do you think I need this check on this project?" So in high trust teams the differences are small.

On lower trust teams, I could see the cycle you mention crop up more. I'm not sure of the answer, but I don't think it is to force everybody through the onerous process out of perceived fairness. Any ideas on how to bring visibility to that failure mode?

I think trust is important, yes. Self awareness is, too—sometimes it's enough for the gatekeeper to stop and ask themselves if they've checked their biases. Another tool is for the metagatekeeper to periodically review the gatekeeper's decisions; the metagatekeeper can be the next level up of management, or it could be a set of peers who check each other.

However you do it, it's a matter of "who watches the watchers?"

Agree with the entire article - but if I knew Pam, I'd coach her on

> Pam sees this and wonders, "What is considered a large project?"

The first interaction when getting hit with artificially introduced friction _SHOULD NOT_ be to just adhere blindly to the friction without a meta-consideration for the friction itself.

Pam shouldn't be asking "What is considered a large project?" - Pam should be asking "Why would a large project need this review and a small project not need this review?" Then categorize her project based on that answer. Understanding the purpose of the review should give her much more autonomy and confidence in saying "My project doesn't need X review." without relying on "I identified it as 'small'" and instead rooting her decision in whatever business concern is being hedged against.

The product manager example doesn't make sense to me. Basically all that's happening is that the work of deciding is being centralized in one person instead of distributed across the team. If there are dozens of projects going on Hopper is not going to be the one that's best suited to decide if a project warrants more review. Plus he's going to be spammed with all the little projects meaning he's more likely to make mistakes and let things slip through.

Ouch - weird metaphor (or simile, whatever) in the very first sentence: "Pam is a product manager driving her team's roadmap."

Huh? You don't drive a map; you use it to guide your driving. You drive a car, and read a map to do it.

Might have worked better if the two key words -- "drive" and "map", in this case -- had nothing at all to do with each other, but as is, they kind of clash with each other.

Oh well, now that I'd started anyway, I guess I'll read a little further.

Just don't make the gates so flexible that due diligence can be avoided

Reply on news.ycombinator.com