Process Tips from Hitsville

In the 1960s, a young record label named Motown put 110 hits on the Billboard charts. They had the highest hit-to-released-single ratio of any record company in history. Motown had 30 #1 hits over the decade.

Founder Berry Gordy, who for a short time worked in a Ford auto factory, had created a process that let his label generate popular songs on a regular, predictable basis. According to Motown engineer Bob Olhsson, the work-flow was something like:

1. Each writing/producing team was required to come up with 5 new songs per day. To accomplish this, there was a large area with a lot of little rooms, each with a piano and tape recorder.
2. Each team submitted their “5 best” at a weekly production meeting.
3. Each team got approval to record the best two of their submissions.
4. Usually, only one of the two tunes would emerge complete from the recording process.
5. Each finished tune was mixed (with about 15 different mixes by several people).
6. Each finished mix was turned into an actual record.
7. The Quality Control department listened to each record and picked out the “A” side that was released and promoted.

This was a well rehearsed process. So much so, that the Four Tops hit It’s the Same Old Song (listen, wikipedia) was famously written and released to DJs in 24 hours. Watch artists and producers reminisce about how hits were churned out at Motown.

Olhsson also mentions: “The gotcha is that this IS a very expensive process. The idea was to have more flops within the company and fewer on the streets”.

Brain Trusts and Change Boards

If you want more features that hit and fewer that flop, maybe Gordy’s process can teach us something.

The secret sauce for Motown’s process is probably the “brain trust”. Friday morning Quality Control sessions were infamously harsh, with each producer defending their own song as a hit. Some tunes that ended up charting were rejected several times before being accepted later with a new mix.

“Gordy had three rules for the meetings: that no producer could vote on his own record; that only Gordy himself could overrule a majority vote; and that anyone who was more than five minutes late would be locked out of the meeting.”

What would this look like as a feature review process? There are some small lessons:

• Make decisive judgements. Each member of the “brain trust” would vote up or down. No futzing.
• Everybody takes part. Let’s get a little extreme for the moment and say that “everybody” should be taken liberally. Get marketing, UI/UX, backend and product folks in there. Gordy says “This was the one place where everyone was not only free to speak their minds, they were expected to. Everybody in the room was fair game, even the sales executives who were sometimes attacked for not promoting the product well enough.
• A majority vote of all members. If we’re talking about software product, Gordy’s veto is more likely a veto from a developer (regarding infeasibility), or maybe a founder.
• Demand the best. Vote for things you think are hits. Great, world-class product. Don‘t vote for B-sides, for “good enough”. If the “brain trust” is to work via majority, voters should not be making allowances.
• Get fresh perspective. Gordy would invite kids off the street to listen with the “brain trust” and speak their mind. Bring in somebody off your normal team to review the UI, or tell you their thoughts on the new idea.
• Show things in the real world. Quality Control could have listened to recordings on tape instead of on vinyl, but at the end of the day nobody else would have heard the tape. Recordings were played from vinyl by DJs and customers alike, and knowing exactly how the final product would sound was important. Use a “labs” feature toggle or staging servers to prototype features and code in real-world setting.

The rigorous, intense reviews that Motown used relied on trust and respect between team members. Songwriter Leon Ware said of Quality Control:

"Berry…pitted talented people against each other. The challenge was you didn’t even bring your song in unless you were really sure about it, ‘cause the people you were up against would walk in with some really brilliant work. What you did there had to be excellent.”

Steve McConnell suggests Change Boards as a best practice in his classic process book Rapid Development. The Change Board is a group of interested parties across departments that together decide what changes to product requirements are allowed. McConnell advocates for this by claiming it leads to better visibility of feature creep, more cross-department sign-up for the changes that go through, and a weeding out of weak or less important features.

The traditional Change Board sounds unbearable in a startup. Coupling them with another strategy he espouses, Prototyping, could create a more Motown-esq work-flow:

1. Generate feature ideas. Lots of them. Explore different UI options and mock them up quickly. Timeboxing is another strategy McConnell talks about that could be useful. Force yourself to generate X ideas a day, keep moving forward.
2. Have a group pick the best 2 and prototype them. Bring in a larger team that can bring the mocks up to the level of a clickable interface, or at least a higher quality design pass.
3. Whatever features survive prototyping, bring them up to a Change Board. This is your “brain trust”. If the majority love a feature, it goes forward to become production-ready (or is rewritten to become production ready). If there are many dissenter who think it isn’t ready, kick it back to prototyping or out entirely.

Prototyping, and throwaway prototyping, are how an organization could make up for the expensiveness of Gordy’s process. Gordy’s assembly line insights can help there as well.

Rapid Prototyping and Making Hits

Motown was a hit factory because it was an idea factory. Songwriters prototyped 5 ideas a day, and their best 5 a week were narrowed down to 2. One of those would likely make it through the whole recording process and into Quality Control. Motown threw away 24 songs and 14 mixes for every song they voted on.

Though the leading artists would change from session to session, the backing band for almost every Motown song was The Funk Brothers. Stax Records in Memphis had a similar backing group in Booker T. and the M.G.’s. The songwriters, band, and engineers worked together every day.

Their process ensured that the best ideas were developed, but the practiced musicians and engineers are why iteration could happen quickly. William “Mickey” Stevenson said of the Quality Control sessions “We’d end up with two great songs, sometimes three. We’d pick out the one to go out, and then we’d have other songs ready to go, so we…never ran out of (hits).”

Hiring the best talent is one takeaway from Motown’s success. There are lessons in prototyping as well:

• Use techniques and tools everybody knows. The Motown composition style used chords often similar from song to song. The band arranged tunes on the fly because they all knew the musical formula. Thoughtbot created a Ruby Gem named suspenders to create new Rails projects. They can spin up a new app and deploy it to Heroku in minutes (if not seconds), and because they all use the same Gem everybody at the company is instantly familiar with the libraries being used. Pick one tool for mocks and stick with it. Encourage everybody to learn it.
• Practice or automate time-consuming stuff. Generating 5 songs a day gave Motown’s writers amazing practice. Building up a product team that can churn through ideas means more possible hits. On the tech and prototyping side, try to automate server and even workstations configuration as much as possible (DevOps is all about this).
• If it doesn‘t exist yet, don‘t be afraid to build it. The Motown producers were famous for using new techniques and sounds in recordings (snow chains, stomping, a tire). The engineers were building new audio gear from scratch to get just the right sound. Don‘t limit yourself to the tools available, go beyond them where you need to.
• Rapid iteration makes tough reviews even more important. Your goal is to find the best ideas. To do that you will need to throw away lots of good ideas. Stevenson saids the flip side of this is that you always have good ideas waiting in the wings, in case you can’t find a great one.

Ready for Hitsville?

Building a process exactly mirroring Motown’s for software & product development is an interesting thought experiment. If anybody did try it, I would be fascinated by the results. Even if you cherry-pick individual elements of his method, you can see Gordy making a strong case for quality creative work through iteration and review. It’s notable that he emphasizes both the iteration and criticism elements so strongly, happily dismissing much of the process’s output through rigorous review.

The lessons of Motown could also be applied to generating business ideas (sound like MVP strategies, anyone?), or code design and review (run Pull Requests like a “brain trust”!). In general, Motown’s success shows that you can create amazing output from a small team if you embrace iteration and criticism.

You should really watch that clip about Motown. If you want to read more, here are some of the sources I used. Thanks to @fancyremarker for reviewing this post! If you need a good pun, I encourage you to contact him.

Discuss on Hacker News