Designing the right kind of internal review process
And the feedback-gate trap that will slow you down if you're not careful
Hello dear builders! Forgive the content break, I wish I had a good reason for not sending a newsletter last week but to be deeply transparent … I got behind reading Dune and needed to finish so I could see it on the big screen 🤭 We all have our priorities and science fiction is one of mine. The idea behind this piece hit me while onboarding to a new team that has a very different (healthier!) operating process from the last team I was on. Review process is especially varied across different orgs, and its hard to do right. Read on for ways to think about evolving yours! -Nickey
In the last few years, I’ve seen inside several technology organizations. These companies are similar-ish on the outside; they have hundreds of engineers (or more), scaling product organizations, passionate customers, and products that are growing like crazy. Yet, the only thing they truly have in common is that they have nothing in common. Each business has a unique operating system designed around completely different principles. As a long-time builder, this is inspiring because it means that each company has built processes unique to its own product and teams. These companies are often successful, not because they have an awesome product, but because they have designed a successful system where the primary output is an awesome product.
Table stakes, yet still incredibly hard to do.
Perhaps even more interesting is how these organizations processize the getting of feedback. Most organizations have a shared process for getting their work “approved” to ship and its typically branded as a review. This shared process typically looks like product reviews, design crits, code reviews, really any meeting or check-in moment you have around what you’re shipping to get feedback. These happen at all levels of the org chart, peer to peer on up to the executive team.
In doing research for this piece I came across a French word called: Charrette. It means a systematized way of coming together to align on how to solve a problem. Charrette, or charretttttttte as I like to say while smoking a skinny French cigarette, literally translates to cart. From Wikipedia:
The word charrette is French for "cart" or "chariot." Its use in the sense of design and planning arose in the 19th century at the École des Beaux-Arts in Paris, where it was not unusual at the end of a term for teams of student architects to work right up until a deadline, when a charrette would be wheeled among them to collect up their scale models and other work for review. The furious continuation of their work to apply the finishing touches came to be referred to as working en charrette, "in the cart."
Most product orgs have them, and they are clearly older than I had imagined, 19th century no less!!! And here’s the thing about internal feedback reviews, they are often either under or over-designed. I’m not sure what it is about them that makes them hard to do right, but they are literally all flawed in some way. Flaws like:
The process is put into place, the org grows, and then it doesn’t scale.
The process isn’t reviewed or tweaked on a regular cadence. It isn’t retro’d.
It’s designed around exec needs, rather than the needs of the teams on the ground.
It disempowers, it slows teams down, it erodes trust.
The list goes on. As a builder, it’s your job to help your team design a review process and to give feedback to leadership when it’s not working.
The many flavors of review sessions
Before we get into how to design your own, here are a handful of different review types I’ve seen in my ten years of building shit, loosely when to employ them, and how they fall down over time.
Reviewing decisions
There are reviews to double click on one-way door decisions, or changes that if made are irreversible. These are awesome moments to check in with leadership or at the least spend a bit more time understanding second-order effects.
When to employ them? When you’re working on platforms or systems where second-order effects can slow you down over time. Also good in larger orgs where you can’t review everything, but you can be very aligned on the things that are hard to change later.
How are they abused? These are typically pretty healthy and I can’t remember a time where a team wasn’t better for talking about one-way door decisions. Just be clear on what a one-way door means to your org.
Reviewing principles
These reviews are great to do upfront to make sure the foundation of what you’re building, or the principles that will guide all decisions being made, are understood, shared, and solid.
When to employ them? Good at the beginning, before you get into design or write strategy. Good when lots of different teams are working on pieces of a thing. They are great for forcing alignment.
How are they abused? These fall over when they’re not socialized or people aren’t aligned on them. Seek alignment!
Reviewing design
Design reviews or critiques (or charrette’s if you’re fancy like me), are a helpful tool to get feedback on design work in process.
When to employ them? Mid-stage, before work is final. They are best used to vet strategic design decisions and are best done frequently to show the evolution of work overtime.
How are they abused? They focus on pixels alone. They become an approval moment, rather than an avenue for feedback. They should bring people along, not be a gate.
Reviewing product strategy
I’ve seen many shades of product reviews over time but the best ones couple strategic vision alongside execution. Ie. review the why, alongside the how.
When to employ them? When you have autonomous teams who can cruise with little guidance.
How are they abused? When they become the only gate for feedback. Or when they are done at the very end of a project, before it ships. When they regularly block instead of unblock.
Reviewing code
Hashtag not an engineer, but regular code reviews, and alignment on technical direction is a good thing. A good code review/PR process helps the team have vis into how the codebase is evolving.
When to employ them? Always practical!
How are they abused? When they’re done without a technical spec/proposal/prototype that’s reviewed first. When they’re done at the end of a project only. When too few people are doing the reviews and they become a bottleneck.
The feedback-gate trap
If we think about feedback and reviews as nodes in a larger operating system, you can imagine how it quickly issues happen when feedback gets delivered in a silo without the rest of the system being aware of it. Furthermore, when feedback and approvals are used to gate forward progress (ie. the feedback-gate), you have to be extremely careful that the gates aren’t slowing you down over time. The example below is fictional, but I’ve seen similar examples where each discipline had its own review process, and there wasn’t a central system that the team was running on. It looked a bit like this:
Ouch. Different folks on the same team will be present for different reviews outside of their respective discipline. If feedback is gated, and needs to happen in one org before it can move to the next, you’re not set-up for speed. This is much easier to manage with smaller orgs and smaller teams, but at bigger companies, it spirals quite fast. And a lot of time is wasted in pure coordination cost, which as a builder who needs time and resources to cruise, will be death by 1,000 papercuts.
So how do you design your own? Resilient orgs typically opt for more centralized process. They can still diverge a bit, but there’s a single high-street that the full team travels together, providing feedback at different moments in the development process. The reviews aren’t hard gates where you have to turn around if things aren’t perfect, but where you can pass through with feedback and clarity on what’s expected next. Here’s what it could look like:
You’ll just want to figure out what check-in moments your team needs and why. The core team should be involved at each step, distributing feedback and context accordingly. And with that info in hand, it’ll lead to a much cleaner process (and better product) for everyone.
Figuring out what’s right for your team
To wrap, you might be on a team that has a really high-functioning review process and things are great. Amazing! Share what works for you in the comments below. That said, you’re more likely in an organization where your review process needs some love. If yours is not working for you, here are some ways to change it:
Schedule a retrospective to talk about the process, dig into how it’s going, and brainstorm how to push it forward.
Schedule time quarterly to reevaluate with leadership (or more frequently depending on your stage of product and size of team) to make tweaks based on what you’ve learned.
Push leadership to be clearer on their needs. Ie. when they want to check-in, and what info they need on what cadence to participate thoughtfully.
Approach all processes iteratively and they should scale as your org scales!
Map the process so you understand how it lives across different disciplines and in different orgs. Put it on a timescale to understand its order of operations.
Get clear on whether feedback is meant to be a gate, or if it can be taken while the train is still moving forward on the tracks.
I’ll wrap here because I’m a process nerd and I could go on (and on and on). If you have a particularly good review process comment below or send me an email and I’ll share next week. Thanks for reading!