Brian Gilham

Engineering leader, husband, and father

scope-management

The Tao of Gordon Ramsay

I don’t watch much television these days, but one of my guilty pleasures is old episodes of Kitchen Nightmares. Each episode, through the power of cursing and walking around in dramatic fashion, Gordon Ramsay works to turn around a struggling restaurant. After a quick look around, Gordon inevitably finds a laundry list of problems — everything from dirty fridges to undercooked food, to terrible service. But there’s one problem that crops up, time and time again: large, unfocused menus.

I don’t watch much television these days, but one of my guilty pleasures is old episodes of  Kitchen Nightmares. Each episode, through the power of cursing and walking around in dramatic fashion, Gordon Ramsay works to turn around a struggling restaurant.

After a quick look around, Gordon inevitably finds a laundry list of problems — everything from dirty fridges to undercooked food, to terrible service. But there’s one problem that crops up, time and time again: large, unfocused menus.

Frequently, chefs and owners think the surest path to success is to overwhelm their customers with hundreds of options, spanning multiple cuisines. Their menus are confusing, wait staff are overworked, and the kitchen is chaotic. Each time, Gordon has to sit them down and explain the value of doing a handful of dishes well. Often, he ends up cutting their menu in half.

The result? Customers are less confused, wait staff can recommend their favorite dishes, and cooks aren’t forced to run around like chickens with their heads cut off, trying to cook everything under the sun.

I’ve started to recognize the problem with large menus at the restaurants I visit. More often than not, it means poor food and service. It’s *almost* a universal truth.

A similar problem pops up in failing side projects.

Often, developers worry they’ll “blow it” by cutting features from the first version of their product. Driven by fear, and lacking real feedback on their ideas, they delay launching while they add “just one more feature” or spend three days pushing pixels on the home page.  They try to cram their app’s menu full of *everything* that pops into their head — both figuratively and literally. Then, they wonder why they never seem to launch anything.

Gordon would be disappointed.

In my experience, shipping something half-finished hurts a lot less than never shipping it at all. 

It’s easy to look at someone else’s work and marvel at how polished it is. But remember, every side project could have been better or included more features. Those developers, the ones who consistently ship? They’ve embraced an important idea — at some point; you have to stop. You have to ship.

Until next week,

-Brian


Walk Before You Run

You sit down to start your next project, full of energy and enthusiasm. You’re excited; starting something new is an opportunity to make something great. It starts out simple but, over time, grows into something unmanageable. You add a new feature here, a design tweak there. Until, eventually, your perfect little side project has become something else entirely. Later, with a huge list of tasks to complete and no sign of launching on the horizon, your energy fades.

You sit down to start your next project, full of energy and enthusiasm. You’re excited; starting something new is an opportunity to make something great. It starts out simple but, over time, grows into something unmanageable. You add a new feature here, a design tweak there. Until, eventually, your perfect little side project has become something else entirely.

Later, with a huge list of tasks to complete and no sign of launching on the horizon, your energy fades. You start getting frustrated. Working on your side project stops being fun. You aren’t learning anything new; you’re just trying to *finish* the damn thing.

We’ve all been there. It’s a struggle as old as time itself.

It’s a cycle of failure and, if you don’t change your approach, it’s one you’ll repeat over and over. Managing constraints, priorities, and scope is easy — when you’re at work. There are external pressures and expectations motivating you to get shit done. But when you’re working on a side project — when every decision is yours, and yours alone — you struggle.

Take a moment, right now, and think about why you failed to ship your last project. You might believe the problem was a lack of willpower, discipline, or motivation. You might think your idea, well, sucked. But there’s a good chance that wasn’t the problem at all. The problem was scope management.

You don’t become a master painter overnight. No, you start by painting something small. Taking some classes and learning the basics. *Practice, practice, practice.* The same principle applies to shipping your side projects. Once you successfully launch one small, manageable project, you can ramp up a little bit. Then, ramp up some more. Shipping is a skill that can be learned and practiced, like any other.

So start practicing.

Until next week,

-Brian