Lunch at Don Giovanni’s with Phillip. He’s amped. We haven’t even seen our waiter and he’s already cleared the table and is scribbling furiously on the white paper table cloth.

“See, we needed to speed up our release cycle which is, of course, insane, but we figured out a way! We call it Train releases. We’ve got four releases going at the same time and a train leaves the station every month. If a feature is ready to go, it gets on the train and if it’s not, it waits for the next train. We’ve already released two trains in six weeks!”

I nod watching the scribbles become increasingly incoherent. I’d buy Phillip a nice glass of Chianti to take the edge off, but he’s a Mormon, so I try the truth.

“Phil, you’re screwed twice. First, you’re screwed because you’re going to need, at least, twice the staff to qualify these ever increasing releases and you’re a start-up. You’ve got one QA guy and if he hasn’t blown a fuse yet, just wait a month. Second, and most important, you’ve got no downtime. You’ve got no time to design because everyone is going to be panicked about which train they’re supposed to be riding.”

“Phil, in order to create, you’ve got to think.”

REACT versus THINK

Why can’t you think when you’re busy?

Dumb question, right? Answer: “I can’t think because I’m busy.”

Wrong. You can’t think because when your busy, you’re not thinking, you’re reacting.

Example. You walk into my office and start yelling, “Rands, it’s two days from shipping and we’ve just found a bad bug, a showstopper. What do we do? Are we screwed?”

I will respond and my response might look like thinking, but I’m not doing anything creative because I’ve dealt with the showstopper two days before ship scenario IN EVERY PRODUCT I’VE EVER BUILT. Survived it each time, too. Got some great stories. It’s that experience I’m using when you walk into my office and tell me the sky is falling. I’m not actually doing anything new, I’m just telling you the story of how I propped the sky up last time.

Yes, you can argue that one can be exquisitely creative when one’s hair is on fire. It’s the necessity is the mother of invention argument, but, seriously, if you’re hair’s on fire are you going to take the time seriously consider all hair dousing techniques or are you just going to stick your head in the nearest convenient bucket before it really hurts? Panic is the mother of the path of least resistance.

You won’t be a successful manager without well developed react instincts. A quiver full of experience gives you all sorts of arrows to shoot at problems and the timing and accuracy of some of those shots will be brilliant, but your quiver will slowly empty unless you take the time to think.

For the sake of this article, let’s partition your brain — one half is the creative brain. This is the part of your brain that is the source of inspiration. The other half of your brain is your reactive brain. This is the part of the brain that loves it when the sky is falling because it gets to move so gosh darned quick.

Your react brain doesn’t actually like to think because thinking is messy. Thinking involves slowing down and actually soaking in a problem and your react brain thrives in the familiar. Your creative brain loves the unknown. It’s a sponge and it’s only happy when it’s full of new ideas. This is part of the reason thinking is hard to pull off at work — it doesn’t fit nicely into daily course of business because it’s full of mind bending paradoxes and uncomfortable realities your mechanical manager is going to barf all over. Some examples:

• Thinking is not something you can constrain by time or a meeting. There is no beginning and there is no end — you never know when you’re done.
• Doing more thinking always pays off, but time is money and you’ve got 27 other meetings this week.
• The more people you include in the thinking process, the more genuine ideas you’ll find, but the process of finding those ideas will linearly slow down with each person who shows up.
• Everyone thinks differently.

The time to kick off your deep thinking is right after your last major release. It’s when every single lesson of the prior release is forefront in the team’s mind. They’ve just gone through the crunch where they had to stare at each poor design decisions illuminated by repeated painful deferral of bugs. They’re exhausted, but they have hope because they know they can fix it in the next release.

GETTING STARTED

The first step is defining a time when the team can think. In the past, I was a fan of kicking things off with an offsite. A good solid day of thinking somewhere other than corporate headquarters where folks can forget about their daily professional woes. The problem with this is that while everyone loves a field trip, the day is an illusion. Sure, the coffee tastes different and, yeah, everyone seems really excited about the next version, but tomorrow you’re going back to headquarters which is where you’re going to do 95% of your actual thinking. You’ve got to create a thinking conducive environment in your natural setting.

Start with two meetings a week. The first is a brainstorm meeting and the second is a prototype meeting. Both are, at least, an hour long.

Make sure there is time between the brainstorm and prototype meeting. Give everyone involved time to stew on the results of the brainstorm meeting. Conversely, you don’t want to wait too long to see a prototype because you’ll forget the context of the initial brainstorm. Once a week meetings are study in futility because folks forget everything during the course of a weekend and meetings up end up rehashing the same thoughts from the week before.

PLAYERS

When the meetings begin, you need a driver. Maybe it’s you, maybe it’s not. There’s another paradox here. Structured thinking kills thinking, but unstructured thinking leads to useless chaos. Your meeting driver must be able to swerve the conversation back and forth between the two extremes, but generally keep it in the middle. Organics tend to be best at this. More on this in a bit when we figure out if your meeting is actually working.

Whom to invite? This is the hard one. If you invite every single person on the team, you’ll get nothing done… even with the world’s best driver. You’ve got to start small and let the momentum build. This is where you might initially piss people off because everyone wants to sit in this meeting because everyone has an opinion. If you have an idea of what the initial topics will be, invite those you know have an educated opinion. If you have no clue where to start with topics, roll the dice… pick at random. You never know what you’re going to find in the minds of engineers. The good news is that one of the best signs of a productive design process is that the players change. More on this in a moment.

One land mine you’ve got to be aware of in your attendee selection is obstructionists. These are folks who’ve fallen into a total react lifestyle. You can easily identify them by their tendency to map every new idea against previous experience and then declare the idea “unoriginal”. The reasons for this attitude varies. Maybe they were early designers of the product and can’t escape from the original design. Maybe it’s the fear of unknown. Whatever the cause, these folks are a creativity buzz kill.

CONTENT

The goal for the first brainstorm meeting is to start reliving the pain on the last release. What bug did you hate to defer? What feature didn’t get pulled off? Who hates this UI? Everyone? Yeah, I thought so. Hey, who is our customer anyway? You want to walk out of your first brainstorm meeting with 5 hot topics that folks want to address.

The second meeting is your prototype meeting. You want to see the results of the last brainstorm meeting in a prototype… paper… code… wireframe… bulleted list. It doesn’t matter as long as there is documented evidence of what occurred in the prior meeting. Maybe you just had a list of customer types? How about a list of the five things the team hates about the product? Your goal here is documented continuity between meetings. This documentation will eventually turn into mock-ups or actual working prototypes, but out of the gate, keep the documentation focused on remembering what the hell happened last time.

When you do get to mock-ups or prototypes keep them lightweight and devoid of detail. If it’s week three and the team is arguing about which icons fits where, you’re too deep. I’m a fan of wireframes when it comes to visually wiring an application together. They give all the geometry of a visual idea without suggesting a look or feel.

IS IT WORKING?

Ok, you’re two weeks into the Rands Creativity Plan and it’s going poorly. No one said anything during the first meeting because they’ve never been asked their opinion before. The meeting consisted of you in front of the white board and a lot of nodding. This lack of brainstorming content led to a very dull prototype meeting, so you stuck with more brainstorming. Week two rolled around and folks started talking except, well, they were yelling because there’s a fundamental disagreement about who the customer actually is. That’s painful progress except when you roll into your second prototype meeting and everyone’s silent again because who wants to be yelled at?

Good work. Really.

It’s a big deal to mentally stumble about and bump into shit during your initial brainstorm meetings. This seeming lack of mental coordination is what finding innovation is all about… but you still need to understand if you’re making progress. Some things you can look for as the weeks pass:

• Are decisions being made? Is the group working well enough to make a decision? Yes? Good.
• Are decisions being revisited? Is the group limber enough to go backwards to refine a previous decision? Even better.
• Are decisions constantly being revisited? Ok, problem here. Your team has spun into creative nirvana. A good time to step back and apply a little structure to the process. Reviewing decisions to date is a good way to find structure and move forward. Oh, you weren’t writing down the results of brainstorm meetings? Ooops. Start now.
• Are the players changing? If you’re four weeks in and the faces at the table haven’t changed, you might have a problem. If you’re working on a sizable project, there is no way you picked the right brainstorm team from the onset. The diversity of thought sitting outside of the room must be brought into the conversation. Time to start mixing it up.
• Are basic truths about your design showing up? These are the gems of brainstorm. These are decisions which are made that define the basic design of your problem. You’ll know these when they show up, stand up to scrutiny, and eventually starting virally wandering the hallways.
• Is it therapy or work? If you’ve just been through a brutal release, the team is going to spend the first brainstorming meetings venting. That’s ok, they need it. If it’s week three and you’re still on the vent, it’s time to make changes.
• Are holy shit moments occurring? Similar to the basic truth discovery, but louder and infrequent. “HOLY SHIT, we’re completely wrong.” Holy shits are disruptive, but are a good sign a limber creative process.
• Is the to do list growing or shrinking? If you’re early on in the design phase, it should be growing. If you’re getting close to the end of your design phase, it better be getting smaller. I know engineers want to solve every problem in the product in any given major release, but THAT NEVER EVER HAPPENS EVER. Better is the enemy of done and if it’s your project, you need to draw a line on what topics/ideas you intend to tackle and stick to it.

My rule of thumb is if you aren’t staring at one hard decision per meeting… you might be wasting your time. You’ve got the wrong people and/or the wrong driver and while it sure is fun to have an hour to chat… that’s all you’re doing. Chatting.

WHEN TO STOP

If your meetings are healthy, the meetings will naturally move from one topic to another. Decisions are built, ideas are vetted, yelling occurs, and prototypes are reviewed. I’ve found that these meetings will slowly die off as you move from hardcore design into serious development. If they don’t then you’re probably becoming addicted to thinking, and while that sounds appealing, you’re not working for a university, you’re working for your shareholders and they want to see new product yesterday. You can still design during the depths of development, but the trend you want to see in your meetings are that questions are being answered, not created.

FIGHT STAGNATION

Google knows you’ve got to take time to think. It is rumored they ask their employees to spend one day a week working on their own projects. Do that math. Google is investing 20% of the engineering budget on thinking. I’m sure that nothing comes from a majority of those projects, but Google gets two wins out of the program. First, some of the projects create value for the company. It’s probably one in five, but that’s not the real value. Google is creating a culture of thinking by allowing their employees to wander about and bump into shit.

I don’t know what you do and I don’t know what you build. I am certain that if you don’t demonstrate creative thinking in what you build, you’re screwed because you, your team, and your product will stagnate. Kicking off brainstorming meetings are a tricky proposition. They are poorly defined, hard to run, and harder to measure. What comes out of these meetings might be brilliance or stupidity… the difference between the two is magnificently slim. Good luck.