Using "Merit" in Your CRB Process

| Oct 25, 2012 min read

I don’t normally post about work related subjects. It’s just not something that I do. Lately we’ve been doing a lot of organizing around process at work (I work in Healthcare IT) specifically as it relates to product development. A few days ago and idea came to me during a call where a couple of our team members were absent.

What about merit?

You see, there are a bunch of people on this team. The ideas that we capture in Trello are all fantastic even if everyone knows we’re not going to be able to implement them. Someone takes the time to write down what they think will provide value for one of our products and it gets into the workflow.

And then an interesting thing happens; nobody wants to carry the ball. What if, instead of having meetings at predetermined times to review all this stuff, we just let folks contribute as they have time in written form? That’s the merit I’m talking about here.

If you contribute, you get to vote.

Think about it. A world where those who take the time to participate get to shape the course of a product’s lifecycle or evolution. I can’t tell you how often some member of the team has had to rally around, “So-and-so feels really strongly that this is an important feature” only to find the note count on the Trello card at zero.

Think about how fast things would move if people got used to taking the five minutes of their day when they’re checking sports scores or stock prices; and instead jotted down the first three things that came to mind on a feature request in the backlog. If you did this, you could easily start shelving anything that goes five business days without comment or augmentation. If you had such ruthless elegance behind your PDLC; wouldn’t the products you develop naturally be more valuable?

The proposal is simple, design a process that’s so dead-simple that anyone can participate (Trello is great for this) and then apply some really basic, but cut-throat rules.

  1. Any feature without an defender for five days gets shelved.
  2. Any feature without a clear producible outcome for five days gets shelved.
  3. Any feature with an open, unanswered question gets shelved after five days without response.

If you did this, your CRB would start to feel like it was powered by jet fuel, instead of coffee. You’d be able to audit the history of your products solely by examining the members that participated in the construction of the requirements used to produce it.

You’d ultimately resolve to better outcomes because your development team would constantly be engaged in the creative process. The rate of response from your team would go up dramatically because everyone would know that they need to speak up or walk away. There’d be no in-between and lazy descriptions of functionality or proposed value.

Anyone at your organization would be able to participate, from the mail room to HR; from the board room to QA. The rules are simple, you play the game to win; or sit down and watch it happen.

You’d lose those features that we all despise, the contrived and inelegant solutions meant to serve a single customer with no real-world application beyond serving someone’s ego.

Ultimately, you’d have fewer meetings altogether. The development team would be engaged and start reporting back immediately when they’ve made progress on something because they’d know that at least one person in the company thinks the feature they are work on is “cool.” Your management team would be able to spend more time dealing with scheduling instead of herding cats and planning reciprocal meetings.

Maybe the proposal isn’t really clear. Maybe I’m just rambling.

I’m pretty sure I’m right.