Software Development: Signs you need a culture of peer review

on by Tommy Messbauer, CTO

Technology moves very quickly. Companies attempt to develop products at unscalable rates, execute a go-to-market strategy before the product is fully developed or have to implement a course correction for a product or entire business because an idea wasn’t fully analyzed. When these things happen, it’s time to take a look at your company’s process and culture.


  • Is your calendar filled with more meetings than time to actually work?
  • Are you having trouble delivering products or features?
  • Are discussions going in circles?
  • Do people make factual statements with feelings instead of data? e.g. “I feel like we’d convert better if we just send everyone more email.”
  • Is your team spending a lot of time on maintenance or re-work?

If any of these are true, you should consider integrating a culture of peer review immediately.

The Myth of Brainstorming

Brainstorming is a horizontal exercise that generally emits lists of undeveloped ideas. There is one, and only one, time you want that—when you have no ideas.

When someone says “brainstorming session,” it is a fancy way to give credence to “a meeting where too many people are going to talk in abstractions and someone will have to clean up the mess.” I’m admittedly cynical on the term. Brainstorming sessions, by definition, emit a bunch of unactionable ideas without supporting research, metrics or insight.

Skip the brainstorm meeting and hit happy hour with your co-workers. You’ll solve more problems.

Leaders often consider the output of these types of meetings as actionable direction. But it is a perilous practice to take a half-baked idea and push it to engineering. Assumptions will be made, and we know what they say about assumptions.

Hyperbole aside, assumptions usually end up in one of two outcomes:

  1. Mid-development scope change and refactor
  2. Ship the feature as is, then spend another development cycle re-implementing it.

As you can see, neither option is beneficial. I’d argue that option two is much worse because now those assumptions are in user-land. It is better to spend more time diving deeper into the problem or doing more research before going to market—resulting in a better product that spent less time in development.

There are many reasons why companies and their leaders choose meetings and brainstorming as their primary tool for innovation and idea creation. Here are some examples:

“If we put all of our smart people in a room, their brain power will magnify.”

This is total rubbish. It is more like, “Too many chefs spoil the broth.” It is better to have one chef start the broth, then ask the others to taste it and find the Goldilocks zone.

“We want everyone to feel included, so our meetings are open to everyone.”

Opening meetings to a wider audience (especially at a small startup) is a lazy way to make everyone feel involved. People feel involved when they are empowered, not simply invited. Worse, it is a waste of time for most attendees who won’t have any input on the conversation and may still end up feeling excluded.

“When you are a hammer, everything looks like a nail.”

Sometimes people keep doing what they’ve always done. Maybe your manager came from a company with a culture of brainstorm sessions.

Design By Committee

Design By Committee is when a group of people attempt to solve a problem without structure or plan. Similar to brainstorming, it is often an open forum of “anything goes.” Lots of bad things come out of design by committee, such as:

  • Uninformed decisions, often based on feelings, not facts.
  • Group dynamics can make people fight for things over pride rather than facts.
  • Wagging the dog. Keep your goal in sight.
  • Weird compromises that add unnecessary complexity.

The hardest part of preventing design by committee is to recognize that you are doing it.

Once a team realizes it is engaging in design by committee, it is important to step back and determine how to split the problem into phases and unify the process.

Individuals Go Deep, Teams Review

Instead of gathering a group for brainstorming or design by committee, develop a solid problem statement. Once the problem is clearly stated and defined, have one or more people dive deep into it individually. Then, have them present or share their findings with the group.

Everything should be written down during the entire development process of an idea or product. Products will evolve. Employees will come and go. Do everyone a favor and write it all down.

Repeat after me: Everything should be written down.

Once an idea has been thoroughly vetted, researched and written down, the peer review process can begin. A peer review can be a meeting or it can be asynchronous, staggered across employees or departments. In either case, the team should ask questions, offer polite and civil critique (please) and provide suggestions for the next phase of ideation.

When presenting criticism or feedback, there are a few guidelines to follow that ensure the process doesn’t revert to a battleground:

  • Critique should be targeted at the idea and be specific.
  • Remember that a lot of this is subjective. Early stages will be more ambiguous.
  • Avoid use of names or pronouns and be specific when describing an issue. Instead of, “You put the button in the wrong place,” say something like, “The button does not follow our style guide. It should be green and on the bottom right.”
  • Avoid hyperbole. Instead of, “This is going to tank our conversion,” try something like, “We tried this in the past, and it hurt our conversion because . Maybe we can put together a success metric and slowly ramp traffic to this new feature?”
  • Remember to say what you like. Peer review is not just about finding what is wrong—it is also be about reinforcing positives. Spread some love.

The project owner should incorporate feedback and ensure artifacts get updated. Rinse and repeat.

When individuals have the opportunity to research, gain deep knowledge, make recommendations and develop leadership skills, they feel included and valuable. That in turn makes them more valuable to the company. Smart, dedicated people want to push themselves and grow. This is a win-win.

About CBANC:

We are the professional network for the banking industry, powering the largest online community of banks and credit unions in the world. Every business day, CBANC helps thousands of verified financial professionals and their institutions make more intelligent vendor decisions, navigate compliance challenges, and answer questions.

Our software leverages the network effects inherent in our community, enabling our members and the vendors that serve them to work together to solve problems. The results are more efficient operations, the ability to better serve customers, and an improved competitive position for our members and the US banking system.